IPv6 multicast background traffic (Part 6) - Apple's Bonjour

by Jeremy Barth [Published on 8 Dec. 2011 / Last Updated on 8 Dec. 2011]

In this article the author discusses Apple's Bonjour.

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

Introduction

Having examined Microsoft's zero config framework earlier in this series, we now move on to Apple's Bonjour. Ultimately changed due to a trademark issue, the Bonjour technology's original name, Rendezvous, points up its conceptual roots in multicast.

Apple's history in zero config goes back decades. Though it had its deficiencies, the AppleTalk protocol that came with the original Macs and LaserWriters 25 years ago actually worked remarkably well. You plugged in a new printer and it just showed up on your AppleTalk LAN. As the world moved to IP-based networks, with their many advantages, the baby got thrown out with the bathwater and AppleTalk's prescient plug-n-play benefits got lost along the way. One possible reaction to the confusing welter of acronyms and protocols under the Windows Rally umbrella (UPnP, DLNA, DPWS, SSDP, WS-Discovery, PnP-X, WCN, LLTD, etc.) is: weren’t we supposed to be trying to simplify the process of networking devices together?

Bonjour is AppleTalk for the 21st century, modernized but at core the same simple, minimalist philosophy. Ubiquitous among Apple products (Macs, iPhones, iPads, iTunes, etc.), Bonjour capabilities are present on almost all network printers manufactured today and it is available on the Windows platform (for example, it’s bundled with iTunes), Linux and Android phones.

Betamax wars redux?

At this point in time, both Microsoft and Apple have major commitments to their respective visions of the multicast-enabled networks of the future where devices and services dynamically come and go, plug in seamlessly, and find whatever they need without any need for human intervention. Manufacturers are hedging their bets and are, to date, trying to support both methods of zero config networking.

It may be going too far to analogize this state of affairs to the Betamax vs. VHS wars of the early VCR days – for one thing, this particular war has lasted many years now. But my guess is that Apple’s lighter-weight approach will become much more ubiquitous, if only because mobile devices such as smartphones are outselling traditional PCs and if all you want to do is print from an iPhone, there’s nothing simpler than connecting it to a wireless LAN, browsing for Bonjour-enabled printers, and away you go. The heavier-weight UPnP / DLNA approach is likely to persist as well. However, it requires membership in an industry trade forum and takes months or years for a device to achieve DLNA-ready status, so it's likely the rate of penetration on enterprise LANs will be lower (though for home networks, it's hard to say).

Bonjour’s Name Resolution Protocol: mDNS

In the absence of a central DNS server, multicast enables a kind of DNS-lite on local LANs. Instead of issuing a unicast DNS request to port 53 on a DNS server, hosts issue name lookup requests to a multicast address on the local link. Microsoft’s LLMNR is one approach, Apple’s mDNS is another. Wikipedia notes:

In 2000, Bill Manning and Bill Woodcock described the Multicast Domain Name Service which spawned the implementations by Apple and Microsoft. Both implementations are very similar. Apple's Multicast DNS (mDNS) is an open specification, while Microsoft's Link-local Multicast Name Resolution (LLMNR) is little used and the specification is not an IETF standards track publication. The latter was published as informational RFC 4795.

The two protocols have minor differences in their approach to name resolution. mDNS allows a network device to choose a domain name in the local namespace and announce it using a special multicast IP address. This introduces special semantics for the local domain, which is considered a problem by some members of the IETF. The current LLMNR draft allows a network device to choose any domain name, which is considered a security risk by some members of the IETF. mDNS is compatible with DNS-SD as described in the next section, while LLMNR is not.

There are plusses and minuses to each approach. A potential concern for mDNS, for example, is its use of the .local namespace. Companies that use this name internally may have issues utilizing Bonjour.

The IPv6 multicast address ff02::fb is used for mDNS traffic.

Bonjour Service Discovery: DNS-SD

Service discovery, as we saw earlier with Microsoft’s SSDP and WS-Discovery, is the third critical leg of zero config. In DNS-SD (DNS Service Discovery), Apple found a way to leverage the same multicast DNS it was already using for localized name resolution and extend it for use with service discovery.

Wikipedia gives a good summary of mDNS’s twin naming and service discovery uses:

Multicast DNS (mDNS) is a protocol that uses APIs similar to unicast Domain Name System but implemented over a multicast protocol. Each computer on the LAN stores its own list of DNS resource records (e.g., A, MX, SRV) and joins the mDNS multicast group. When an mDNS client wants to know the IP address of a PC given its name, mDNS client sends a request to a well-known multicast address; the PC with the corresponding A record replies with its IP address. The mDNS multicast address is 224.0.0.251 for IPv4 and ff02::fb for IPv6 link-local addressing.

DNS-SD is the other half of Apple's solution, built on top of the Domain Name System. It is used in Apple products, many network printers and a number of third party products and applications on various operating systems. The Apple solution uses DNS messages, in contrast to Microsoft's competing technology, SSDP, which uses HTTP messages. It uses DNS SRV, TXT, and PTR records to advertise Service Instance Names. The hosts offering services publish details of available services: instance, service type, domain name and optional configuration parameters. Service types are given informally on a first-come basis. A service type registry is maintained and published by DNS-SD.org.

Printers and Protocol Wars

Lurking in the background, as we discussed earlier, is the battle between two industry titans for defining the nature of zero config networking. In our next example, a Konica Minolta BizHub printer tries to be agnostic and multicasts its service offerings both over Microsoft’s SSDP and Apple’s DNS-SD:


Figure 1

Slightly more amusing is that when we drill down into a sample packet with the vendor-neutral sniffer Wireshark, it’s aware that this is an mDNS packet (strictly speaking, the protocol in question is DNS-SD, which is compatible with multicast DNS but also works over unicast) and readily disassembles the response. Note, as is common with DNS-SD that multiple records and types (TXT, SRV, PTR, and AAAA) are being delivered within the single packet:


Figure 2

But when we look at the same Apple-protocol packet with Microsoft’s Network Monitor, the packet is seen neither as DNS-SD nor mDNS, just an undifferentiated UDP packet, and the payload is simply listed as a BLOB (Binary Large OBject):


Figure 3

I'm gently ragging on Microsoft here, but Wireshark isn’t perfect either. Out-of-the-box, it sees Microsoft’s WS-Discovery packets as undifferentiated blobs:


Figure 4

Whereas Network Monitor, not surprisingly, natively understands Microsoft’s SOAP protocol and can decipher the packet:


Figure 5

So what have we learned?

  1. Printer manufacturers are being careful not to choose sides in the zero config wars.
  2. Microsoft and Wireshark don’t agree on the corner cases where there’s no clear IETF standard – us lowly tech folk need to use two different network sniffers to get our jobs done.

One final thing about mDNS and LLMNR should be considered: security. On home networks this isn’t necessarily critical and even on corporate LANs it’s not clear how big a deal this really is, but one should note this concern cited in Wikipedia:

Because mDNS operates under a different trust model than unicast DNS—trusting the entire network rather than a designated DNS server—it is vulnerable to spoofing attacks by any system within the multicast IP range. Like SNMP and many other network management protocols, it can also be used by attackers to quickly gain detailed knowledge of the network and its machines.

Right! This gets to the heart of zero config and whether it is appropriate for use on corporate LANs, a question we’ll take up at the end of this series.

While that quote is specific to mDNS, Microsoft seems to have taken this particular concern to heart in the Windows Firewall defaults it chooses for its similar LLMNR protocol. If you look at the default Windows Firewall settings, LLMNR is only enabled on the Private Profile (typically this means the home). While neither LLMNR nor Bonjour by default operates in a Domain context, Apple does allow Bonjour to be used in a Public Profile context:


Figure 6


Figure 7

The argument in favor of Microsoft’s firewall approach is that it’s more secure. The argument in Apple’s favor is that if you’re on the road, allowing Bonjour to find publicly available services (such as printers) on a hotel LAN is one of the whole points behind zero config networking. My personal view is that the smaller my Windows laptop’s attack surface is when it’s roaming on a public network, the better. But YMMV -- smartphones being a prime example -- and there are certainly cases where it could be useful to locate multicast services on a public LAN.

This concludes the background to Apple's Bonjour. In the final part of this series, we'll take a look at how some specific Apple products use IPv6 multicast and then wrap up.

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

Advertisement

Featured Links