IPv6 multicast background traffic (Part 4) – Box Chatter – P2P Multicast and the Zero Config Wars

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


As we saw in the last two articles, there is a steady trickle of multicast background traffic on modern LANs that’s related to auto-configuration of the IPv6 stack. What surprised me when I started looking into IPv6 traffic on various LANs was how many packets were flowing that seemingly had nothing to do with the Windows operating system or the network’s infrastructure (Cisco) gear. Instead, there was a wide variety of intermittent, oddball IPv6 traffic to unusual multicast addresses that I began thinking of as random “box chatter.”

It turned out that this box chatter was all related to what is known as zero-configuration networking. Various devices, applications and services, ranging from printers and smartphones to Windows Media Center and iTunes, were engaged in a continual, low-level subterranean exchange of unsolicited auto-configuration messages over IP. The remainder of this blog series is devoted to a look at this traffic.

We’ll look at specific examples, examine the technology framework they fit into, speculate about emerging trends, and offer suggestions to help you plan for the future.

Back to the future

The idea of turning on computing devices, having them self-configure and announcing their presence on the network is an attractive idea with a long pedigree. In the 1980s, for example, the AppleTalk protocol allowed non-technical people to install Macs and printers on a network without any need for gurus or centralized servers.

Stated most broadly, the problem is how does one add devices and services to an existing system? At the physical device level, various flavors of USB and Plug-n-Play gradually emerged as solutions to the problem of how to add peripherals to an existing machine. Services, on the other hand, tend to be located higher in the stack, at the software application layer, and there have been numerous attempts over the years to standardize their provisioning, most vendor-specific in nature. DHCP and DNS are examples of services that have successfully been standardized and are largely vendor-neutral.

The term “zero-configuration networking,” which I’ll refer to from here on as zero config, gradually took hold. At root, zero config is a way of doing Plug-n-Play over a network using IP. In the interests of full disclosure, I should note that what was originally the generic term “zero configuration” now tends to refer to a specific framework, Bonjour, promoted by Apple. Microsoft has a competing framework known as Windows Rally. A website run by Apple’s “Wizard Without Portfolio” Stuart Cheshire pushes his vision, largely at Microsoft’s expense, of what zero config should be. While I will try to be neutral in my presentation, I find Cheshire’s framework a clear and useful way for thinking about zero config.

The three legs of zero config

In essence, zero config technologies attempt to solve three different problems:

  1. automatic IP address assignment
  2. device or service naming
  3. service discovery

IPv6 link-local fe80 (and IPv4 169.254) address self-assignment effectively solves the automatic IP address question and is a solution largely shared in common between Apple and Microsoft. From there, the two industry giants radically diverge. Apple chose to leverage a multicast-enabled form of DNS to solve both remaining problems: naming and service discovery. Microsoft, on the other hand, created new protocols: LLMNR for name resolution and SSDP/WS-Discovery for service enumeration.

To be clear, there have been other zero config frameworks. In the 1990s, when Sun’s Java was in its heyday, the Jini protocol promised to create a universal “network dialtone.” Unfortunately, as was so often the case with Sun, Jini was an ingenious idea whose early promise Sun was unable to capitalize on. To this day there are several approaches to zero config, some public domain and others proprietary, but there is no universally agreed-upon framework. In practice, though, Microsoft’s Rally technologies (UPnP and DPWS) and Apple’s Bonjour are the most common zero config frameworks and it’s on these two that we’ll focus.

Here’s the view from 30,000 feet:

Protocol suite

Address Auto-assignment


Service Discovery

Microsoft Rally technologies

Self-assigned addressing (APIPA for IPv4 and link-local auto-configuration for IPv6)

Link-Local Name Resolution (LLMNR)


Simple Service Discovery Protocol (SSDP) is the basis of Universal Plug-and-Play (UPnP) discovery. It uses HTTP messages to announce and search for services on a local LAN.

WS-Discovery, a more recent approach, uses XML SOAP web service messages.

Microsoft works with two major trade organizations on service discovery issues: the UPnP Forum and the Digital Living Network Alliance.

Apple Bonjour & ZeroConf

Self-assigned addressing (APIPA for IPv4 and link-local auto-configuration for IPv6)

Multicast DNS (mDNS)

Open specification, on a long-running IETF standards track.

DNS Service Discovery (DNS-SD). Most commonly implemented as multicast DNS (mDNS).

Uses DNS SRX and TXT records but without the need for a central DNS server. On Windows, clients running the Bonjour program mDNSResponder.exe can participate in multicast DNS service discovery.

Table 1

Microsoft’s Rally Technologies: More Acronyms Than You Can Shake a Stick At

Rally is Microsoft’s attempt to bring its diverse portfolio of device auto-configuration and service discovery under one umbrella. Besides Universal Plug and Play (UPnP), another set of home-networking technologies has come together in the form of a Sony-led industry consortium Digital Living Network Alliance (DLNA). At the enterprise level, Device Profiles for Web Services (DPWS) is preferred. UPnP and DLNA utilize Simple Services Discovery Protocol (SSDP) while DPWS uses the extensible WS-Discovery protocol. There are additional protocols and technologies: Link-Layer Topology Discovery (LLTD), Windows Connect Now (WCN), Plug and Play Extensions (PnP-X) and who knows what else.

The DLNA should be mentioned because it involves virtually all of the world’s largest consumer electronics companies. While seemingly far removed from traditional IT, the DLNA has to deal with many of the same network auto-configuration and service-discovery challenges as enterprise technologists. There are certainly differences — enterprise shops typically aren’t interested in preventing devices from connecting because of a Digital Rights Management (DRM) mismatch — but as often before in the history of IT, developments in the consumer space have implications for the enterprise IT space.

I won’t try to sort this out any further for you – even Microsoft seems to have trouble keeping track. Much of the promise of these technologies has yet to be fulfilled (see this CNET article on DLNA, for instance). But since our focus here is on IPv6 multicast, let’s simplify things and look at the three kinds of zero config packets you’ll commonly see on today’s Windows 7 LANs: LLMNR, SSDP and WS-Discovery. The first is a name resolution protocol while the latter two are discovery protocols, that is, they’re involved in advertising or locating devices and services on a local LAN without the need of a central directory server.


Link-Local Multicast Name Resolution (LLMNR) is Microsoft’s equivalent to the name resolution portion of Apple’s multicast mDNS. LLMNR is pretty much used only by Microsoft and has never become an IETF standard, though there is an informational RFC available. mDNS is still on an IETF standards track but has not yet been finalized. Both technologies offer solutions to the problem of looking up machine names in the absence of (or in parallel with) a centralized DNS server.

Unlike mDNS, which largely extends the existing DNS protocol, LLMNR is an entirely new protocol. It works over multicast, in the case of IPv4 to and with IPv6 to ff02::1:3. Here’s a typical LLMNR packet, an attempt by a PC to find a Web Proxy Auto-Discovery (WPAD) server:

Figure 1

IPv6 multicast is just the latest incarnation of a long-standing approach to doing non-server-based name lookups. For example, note that the same PC not only issued both IPv4 and IPv6 multicast LLMNR queries, but also used the ancient NetBIOS protocol, a 1980s-era form of pre-DNS local name resolution for local LANs:

Figure 2

The LLMNR query above is for a record of type A (an IPv4 address). The other LLMNR query you’ll occasionally see to ff02::1:3 is for a record of type=ANY. These are rarer and I have not been able to find any documentation explaining their purpose, but my hunch is that these type LLMNR type=ANY requests are made when a PC boots up and is trying to establish that its name is unique:

Figure 3

LLMNR works over both TCP and UDP:

C:\Windows\System32\drivers\etc>findstr /illmnr services
llmnr 5355/tcp #LLMNR
llmnr 5355/udp #LLMNR

and as we saw above, it works over both IPv4 and IPv6:

C:\Windows\System32\drivers\etc>netstat -an | findstr /i “5355 proto”
Proto Local Address Foreign Address State
UDP *:*
UDP [::]:5355 *:*

As with any service, running LLMNR increases a PC’s attack surface. And in fact, “critical” security vulnerability in LLMNR was the subject of an April 2011 Windows patch. If you are not planning to utilize Microsoft’s zero config P2P capabilities on your domain, it’s possible to disable LLMNR entirely through Group Policy:

Group Policy > Computer Configuration > Administrative Templates > Network > DNS Client > Turn off Multicast Name Resolution = Enabled

That finishes Microsoft’s IPv6 multicast name resolution. In our next post, we’ll take up Microsoft’s IPv6 multicast service discovery protocols.

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

About The Author

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