Understanding Zeroconf and Multicast DNS

Author and Editor's Note: Networking was never supposed to be hard -- but it is. At best it's an annoyance, at worst it's a show stopper. Granny May's got her new printer and after hooking it up, she just can't get it to print across the network, damnit. But an emerging standard, Zeroconf, just might help networking become what we've always wanted it to be: easy.

Zeroconf, and its direct competitor UPnP, provide for automatic configuration and address allocation. This can be accomplished on both Ethernet and wireless networks, but we think it's a good bet that this protocol will become wildly popular in the wireless world. You walk into a room with your laptop, it discovers a printer, you send a print command, paper emerges.

This article delves into Zeroconf (also branded as Rendezvous by Apple Computer), compares it to UpnP, and shows you how these protocols might finally make networking logical and easy to administer.

It Just Works (We Hope!)

Branded by Apple as Rendezvous (the same way that IEEE 802.11b became Airport and 1394 became Firewire), Zeroconf is designed to bring the "It Just Works" Apple swagger to IP (Internet Protocol)networks.

Related Reading 802.11 Security By Bruce Potter, Bob Fleck Table of Contents Index Sample Chapter Read Online--Safari Search this book on Safari:   Only This Book All of Safari Code Fragments only

IP -- as the name suggests -- is the force that brought us the Internet, and has pretty much won the war for local networks as well. Lying vanquished in unmarked graves are old diehards like LANtastic, IPX, and (significantly to this story), Appletalk.

Much loved, but obsolete, Appletalk was a crucial component of Apple networking for years. Plug in a printer and it showed up in the Chooser within seconds. You didn't have to tell your computer about the printer -- it knew already, thank you very much.

Stuart Cheshire, an old Machead, knew the joys of Appletalk, but also its failures and encroaching obsolescence. Back in 1997, an idea for an alternative began to form on a Mac networking mailing list. That idea germinated for a couple of years before culminating in semi-formal meetings and, finally, the establishment of a full Internet Engineering Task Force Working Group in September of 1999.

The Emergence of Zeroconf

The Zeroconf Working Group defines its mandate as making sure that four things get done on our IP networks:

• Automatic Interface Configuration.
• Automatic Multicast Address Allocation.
• Name-to-Address Translation (and vice versa).
• Service Delivery.

As the working group focused on these four goals, they kept in mind an additional requirement: that network security would be no worse than when they rode into town.

Automatic interface configuration deals with the fact that on an IP network, each device has an address, and those addresses have to be unique. IP already has a mechanism for determining which addresses are in use; Zeroconf simply establishes some additional etiquette around what to do if two devices try for the same address.

The automatic multicast addressing is similar in function, except for the special requirements that come with multicasting.

Multicasting is a little-used aspect of IP. If unicast is a FedEx delivery -- door to door -- multicasting is like a radio station. The same way that radio waves are all around us, and a receiver tunes out all other frequencies to listen to the station that we want -- multicast data is sent to all devices on a network, and it's up to them to decide what they want to listen to.

Zeroconf's ZAMAAP protocol is a simple way for devices to choose amongst themselves who gets which frequency.

Mundane, yes, but important, the address allocation aspect of Zeroconf banishes forever the annoyance of typing in dot-decimal IP addresses.

Less mundane are the address translation and service discovery -- which are downright clever.

Clever because they makes the venerable DNS (Domain Name System) protocol juggle, stand on its head and entertain the in-laws -- without adding anything new to it.

To over-simplify a bit, DNS is designed to be centralized, in the sense that there are the Grand Root Servers that lord over all the lesser DNS servers scattered throughout the Internet.

Zeroconf relies on what is called Multicast DNS. Say you are at a party and you need to talk to a woman named Suzy. Unicast DNS is like asking the host of the party who she is; multicast DNS is like shouting "Is Suzy here?" to the whole room.

Naturally, things would get awfully loud if it was a big party, but Zeroconf was designed for small local networks, so it isn't a problem. And best of all, no one person has to know everyone in the room -- being a host is tough, and it's the user who usually ends up with the job.

Service discovery uses the same broadcast mechanism, but instead of looking for a particular person, you look for capabilities. It's like yelling out, "Anyone here know how to mix a Tequila Sunrise?" and waiting to see who puts their hand up.

This particular bit of magic is accomplished via a seldom-used DNS packet, lovingly named SRV.

The SRV packet was originally designed to locate a service over the open Internet. To find Apple's Web server, theoretically, your Web browser would query for "_http._tcp.apple.com". If anyone actually used the SRV functionality, a DNS server would reply with a list of HTTP (Web) servers and some other useful information, such as in which order you should try them.

Zeroconf takes this capability and makes it work on the home network. Say a word processor wanted to know what printers were on a network. It would broadcast a query for "_lpr._tcp.local.arpa" to every device on the network (LPR is a common printing protocol). Any printer that heard it would respond with a SRV packet with its name and whatever information that it felt like giving about its capabilities (color, pages per minute, etc.).

Simple, n'est pas? Almost makes you wonder why it took so long to get this all worked out.

Well, like they say, "the great thing about standards is that there are so many to choose from." Zeroconf may be the most elegant, but it certain is not the first.

Some of its predecessors weren't IP based, like Appletalk, and by that virtue alone are out of the running. Some were overbloated and weird; some, like DHCP, where underpowered.

But with all of those crotchety technologies set out to graze, Zeroconf will rule the network, right?

Right?

Make Room for Microsoft

Enter the 800 pound gorilla. With Universal Plug 'n' Play -- Microsoft's bid in the hands-off networking arena -- we're looking at a war. Both UPnP and Zeroconf deal with precisely the same problem space, in a fairly similar manner. The automatic interface configuration, for instance, is identical.

The big distinction is while Zeroconf uses tiny DNS packets and focuses on service location, UPnP uses heavier HTTP and XML and goes to great lengths to define exactly how those services are accessed.

Intrinsic to the spirit of UPnP are the Device Control Protocols (DCP). Currently there are four of them: Internet Gateway Device, MediaServer/MediaRenderer, Printer Device, and Scanner. There is also an effort to create a more generalized Basic Device. The process of creating a DCP takes about a year and a half and is guided by the charter of the UPnP Forum, which has over 500 members.

Any device that claims to be a UPnP device has to conform precisely to one of these DCPs. In the case of our word processor, not only would it know that there was a printer present, but also how to speak to it.

In contrast, Zeroconf relies on existing protocols. It's more of a negotiation process, a back and forth to decide on a protocol. For example, a printer might speak the previously mentioned LPR, or any number of other protocols -- it is up to the word processor to choose which one is appropriate.

Under UPnP, there is one printing protocol, which is defined by one committee, which must be based on SOAP. End of story.

Let the Competition Begin

So which is better? Zerconf is the simpler and cleaner of the two, but it also leaves some things undefined. For example, the printer that returns its capabilities under Zeroconf uses an unstructured text field to do so. There's a presumption that some sort of separate, perhaps de facto, standard will emerge to structure that information, but there is a possibility that balkanization might occur.

The tightrope of defining too much and being inflexible, and defining too little and allowing incompatibilities, is perhaps the most important line to be drawn in a standard. UPnP's definite lean to the former is typical of recent Microsoft.

And don't expect Redmond to back down on this front. UPnP's heavy reliance on SOAP is an attempt to bind device manufacturers to MS' bet-the-farm .Net initiative. This is a strategically important battle.

So which side do the other big techs come down on?

Sun Microsystems came out with their own (heavy and very Java-centric) entry into the war with the release of Jini a couple of years ago, which is presently so dead you could stick a fork in it. Now they seem to be hedging their bets by having people on both the UPnP Forum and the Zeroconf Working Group. IBM is doing likewise.

Intel has released a UPnP SDK to the public under an open source license, presumably to spur on the more processor-heavy XML protocol.

Apple is 100% behind Zeroconf (unsurprisingly); an implementation of most of the specification appeared with the 10.2 (Jaguar) release of their operating system. They've also announced that said implementation will be open sourced under their APSL license. Given this, combined with the fact that it's a patent-free (unlike UPnP) and completely open specification, look for major Linux and BSD distributions to start including Zeroconf within the next year.

However, the war is going to been won not on the desktop, but in the chips of the device manufacturers.

Automatic network configuration is squarely under the jackboot of Metcalfe's law (utility being equal to the square of the number of devices). A protocol that claims to be a connecting force is, by definition, either universal or useless.

And (if you discount computers and low level networking hubs) I couldn't find a single device that supports UPnP at time of writing -- despite the fact that the protocol has been coupled to the vast MS marketing engine for over two years.

The younger Zeroconf camp is equally barren of gizmos; Apple, however, has wrung out a couple of press releases from the likes of HP, Lexmark, Epson, and Xerox stating intent to include Zeroconf support. Interestingly enough, both HP and Xerox also happen to be on the committee that drafted the Printer DCP for UPnP, released this August ...

It's too soon to tell, but it's a pretty safe to predict that neither Zeroconf or UPnP are going to disappear for a while. Device manufacturers might even decide that the two protocols are light enough to support both of them at once.

Regardless of who wins, it's clear where networking is headed in the next couple of years.

Stuart Cheshire talks about the rats nest of cables behind the average computer desk and home entertainment system: USB, Firewire, Optical Audio, RGB, RCA. Imagine all of that replaced with Ethernet, or better yet, wireless.

The world is going IP -- for everything.

He talks about something as simple as the TiVo in your bedroom being able to talk to your TiVo in the living room, or two people on a train hooking their laptops together for a quick game of something, without having to go through the "What's your IP?" ritual.

Sometime in the future, you are going to drive up to your house, and your Car Area Network (CAN), is going to seamlessly merge with your Home Area Network (HAN).

Best of all, you're not even going to think about it.

Heath Johns is Chief Architect at Point Clark Networks, an network automation company in Toronto, Canada

Return to Wireless DevCenter