If you would like read the next part in this article series please go to:
- IPv6 multicast background traffic (Part 2) – Multicast and IPv6 Stack Auto-Configuration
- IPv6 multicast background traffic (Part 3) – Multicast and IPv6 Stack Auto-Configuration (Cont.)
- IPv6 multicast background traffic (Part 4) – Box Chatter – P2P Multicast and the Zero Config Wars
- IPv6 multicast background traffic (Part 5) – Microsoft’s Multicast IPv6 Service Discovery Protocols
- IPv6 multicast background traffic (Part 6) – Apple’s Bonjour
- IPv6 multicast background traffic (Part 7) – iChatter and the Future of Zero Config
Introduction
IPv6 traffic, the next-generation Internet Protocol, is likely flowing across your enterprise LAN as you’ve been reading these words, especially if your organization is running Windows 7. Unless you’ve taken explicit steps to configure IPv6, however, what’s unusual about this traffic is that it’s almost all multicast. There is a continual low-level IPv6 multicast hum on most Windows 7 LANs, most of which is related to zero-configuration networking: in plain English, box chatter. This article, the first in our series, reviews key concepts in IPv6 and multicast, setting the stage for the rest of the series.
This series of posts covers this IPv6 multicast background traffic from various perspectives: where it’s coming from, the battle between industry titans who are putting it there, a bunch of low-level packet traces, and why you should care. The series presupposes at least a passing familiarity with IPv6 but we’ll review key concepts throughout.
Here’s what we’ll be covering:
- Box Chatter: IPv6 Multicast Backgrounder (this post)
- Multicast and IPv6 Stack Auto-Configuration: Part One
- Multicast and IPv6 Stack Auto-Configuration: Part Two
- Box Chatter: P2P Multicast and the Zero Config Wars
- Microsoft’s Multicast IPv6 Service Discovery Protocols
- IPv6 Multicast: Apple’s Bonjour
- iChatter and the Future of Zero Config
IPv6 Multicast Backgrounder: Key Things to Know
Multicast
IT professionals are most familiar with unicast IP addresses where, to simplify, network traffic passes one-to-one between two unique endpoints. Multicast is similar to broadcast, with one-to-many or many-to-many transmission on the same IP address, but differs from broadcast in one key way: multicast is based on a subscription model. Multimedia streaming is the classic multicast use case but on modern networks it is finding an entirely new use: dynamic auto-configuration of devices and services. At the time IPv4 was defined, multicast was still considered experimental and didn’t make it into the official protocol (it was added afterward). In IPv6, on the other hand, multicast is a mandatory part of the core protocol and tends to be much more widely used than in IPv4.
IPv6 addressing
A quick recap of IPv6 addressing. IPv6 addresses are 128 bits long, compared to IPv4’s 32 bits, and are scoped. Scoping means that an address is unique and only valid within a certain domain, such as the local LAN vs. the entire IPv6 global internet. Scoping is effected through the use of IPv6 prefixes. An IPv6 prefix is usually the first 64 bits of the address and essentially corresponds to an organizational boundary, with the final 64 bits of the address, which are usually derived from a device’s MAC address, designating a unique host. Here is a typical IPv6 address, with the prefix portion highlighted: 2001:db8:2:0:1477:3e9a:966c:b3ca
IPv6 unicast addresses are almost always self-assigned, with neither static addressing nor even DHCP being necessary. For globally-unique IPv6 addresses, the first portion of the IPv6 address, the prefix, is usually obtained dynamically from the local router (we’ll discuss this later). If the local router hasn’t been configured to provide a prefix and the host has no other way of learning it, then it will use the so-called link-local prefix fe80, which is similar to the IPv4 link-local scope 169.254.0.0/16. This guarantees address uniqueness within the scope of a local LAN.
IPv4 multicast addresses are in the so-called Class D range 224.0.0.0 through 239.255.255.255. In IPv6, the prefix ff00::/8, i.e. the 8 bytes at the beginning of the address, designates a multicast address. The multicast addresses we’ll be covering here are all in the ff02 range, where ‘2’ indicates that they are link-local in scope, i.e. that IPv6 won’t route these packets beyond the local LAN.
Table of Link-Local Multicast addresses we’ll talk about:
IPv6 Multicast Address |
Type |
RFC or Other Reference |
Notes |
ff02::1 |
ICMPv6 |
IANA Link-Local All Nodes Address Router Advertisements are sent to this address, e.g. ICMPv6 Option (Prefix information), Sample 64-bit prefix: 2001:db8:2:: |
|
ff02::1:2 |
DHCPv6 |
All DHCP Agents (servers or relays), Link-Local Scope On Windows 7 LANs, the Option Request in packets sent to ff02::1:2 is always for one of: 1. Domain Search List (24) 2. DNS recursive name server (23) 3. Vendor-specific Information (17) 4. FQDN (39) |
|
ff02::1:3 |
LLMNR |
Microsoft’s counterpart to Apple’s mDNS Used for link-local name resolution where a central DNS server either isn’t available or appropriate. |
|
ff02::2 |
ICMPv6 Router Solicitation |
ICMPv6 type 133 (Router Solicitation) PCs looking for an IPv6 router send packets to this address |
|
ff02::16 |
ICMPv6 MLDv2 |
ff02::16 is the Link-Local scope all-MLDv2 routers address. A packet sent to this address reaches all MLDv2 routers on a sub-network. Packets are always of Type = 143 (Multicast Listener Report Message v2) of the form Mode = Include or Exclude |
|
ff02::c |
WS-Discovery, SSDP |
Universal Plug and Play (UPnP) and other Windows Rally technologies. |
|
ff02::fb |
mDNS |
Multicast DNS (mDNS), Apple’s counterpart to Microsoft’s LLMNR |
|
Solicited Node, source address is :: |
Neighbor Solitication |
Solicited Node addresses always begin with ff02::1:ff and end with final 6 octets of proposed source address, e.g. ff02::1::ff45:3042, ff02::1::ff99:c1cc, etc. |
Windows 7 is the first widely-adopted Microsoft desktop operating system in which IPv6 is a first-class citizen. IPv6 is on by default and numerous Windows services utilize IPv6 multicast. To get a quick sense of your PC’s IPv6 status, try the following commands.
Does your PC have any IPv6 addresses (link-local or otherwise)?
ipconfig /all | findstr IPv6
What IPv6 endpoints are on your Windows machine?
netstat –abn –p tcpv6
netstat –abn –p udpv6
netstat –abn –p icmpv6
For example, my PC has a single, non-globally-unique self-assigned link-local address beginning with fe80 and there are several IPv6 TCP and UDP endpoints:
Figure 1
You can also get a sense of what services potentially use IPv6 multicast by reviewing the Windows Firewall’s Group settings. In the screenshot below, many of the services related to Network Discovery, Remote Assistance, and Media Center Extenders (among others) utilize multicast to do their job.
Figure 2
Broadly speaking, there are two kinds of IPv6 multicast traffic you’ll see on a typical network: IPv6 stack auto-configuration and peer-to-peer (P2P).
- Stack auto-configuration is the internal housekeeping IPv6 performs to set itself up. For example, obtaining a prefix or DNS info from a DHCP server.
- P2P traffic enables clients and various services to find one another and advertise their presence without the need for a central server.
In the next post, we’ll start with IPv6 stack auto-configuration as it is relatively straightforward. P2P traffic, which is much more diverse because it is ultimately associated with applications (such as media) and devices (such as printers and smartpads), will be covered afterwards. P2P also raises “appropriate use” questions on corporate LANs. We’ll discuss the mechanics of what’s going on, examine the different P2P frameworks provided by Microsoft and Apple, the services on offer, and business considerations.
If you would like read the next part in this article series please go to:
- IPv6 multicast background traffic (Part 2)- Multicast and IPv6 Stack Auto-Configuration
- IPv6 multicast background traffic (Part 3) – Multicast and IPv6 Stack Auto-Configuration (Cont.)
- IPv6 multicast background traffic (Part 4) – Box Chatter – P2P Multicast and the Zero Config Wars
- IPv6 multicast background traffic (Part 5) – Microsoft’s Multicast IPv6 Service Discovery Protocols
- IPv6 multicast background traffic (Part 6) – Apple’s Bonjour
- IPv6 multicast background traffic (Part 7) – iChatter and the Future of Zero Config