If you haven't built a local area network lately, you may have forgotten just how painful a project it can be. But what if your users could just plug in, power on, and connect, building their own ad-hoc network? Zeroconf, the basis of Apple's Rendezvous product and an emerging networking standard, puts the play back into 'plug-and-play.' Here's how Zeroconf works.
If you haven’t had to configure a local area network (LAN) recently, you’ve probably forgotten what a pain it is. While most people tend to take their LAN for granted once their computer is online, those responsible for installing and configuring hosts often wonder whether all the trouble is really worth it. Because LANs require you to assign IP addresses, set up and configure DNS, and modify applications to use the services of other machines, it’s no wonder that many small office users simply give up on building a LAN and transfer data between computers using two old standbys, the floppy disk and a good pair of sneakers.
Fortunately, there are a handful of new protocols on the rise that promise to help end-users and IT managers alike get beyond typical network configuration woes. Collectively dubbed, “Zeroconf,” short for “zero configuration networking,” these protocols allow networked devices to select their own IP address, resolve their own hostnames, and advertise their own services for others to use — all without any human intervention. With Zeroconf, just plug a new device into the network and it’s instantly able to share (consume and provide) services with all other connected devices.
Sound good? Yes! But there’s just one problem: no one can seem to agree on exactly what group of protocols to use.
From Concept to Protocols
Zeroconf began in 1997 when a group of network programmers, students, and other Macintosh enthusiasts on the net-thinkers mailing list started discussing the poor usability of IP networking. A Stanford University Ph.D. student named Stuart Cheshire suggested that some form of auto-configuration could be brought in to the mix by layering the existing AppleTalk Name Binding Protocol over UDP Multicast. Although the plan to use AppleTalk was later dropped on the advice that the Internet Engineering Task Force (IETF) wouldn’t accept it as a standard, the core concept — that services could announce themselves and discover one another on a network without any configuration — remained.
By 1999, proponents had formed the IETF Zero Configuration Networking working group, which Cheshire (by then, an employee at Apple Computer) co-chaired with Sun Microsystem’s Erik Guttman. Although service discovery across the Internet was and is a growing issue, the Zeroconf working group decided to focus their work initially on local area networks. “Zeroconf is a safety net for those networks too small to warrant infrastructure and administration, like two laptops and an Ethernet cable,” says Cheshire. “Zeroconf could work for a hundred or even a thousand hosts, but if you have a hundred computers on your network, you can probably afford to install a DHCP server.”
The working group determined that, to create a network that truly required no configuration on the part of the user, three things would need to happen.
1. Each device on the network would need to obtain its own IP address.
2. Users would need to be able to refer to hosts by name, not address.
3. Users would need some way to browse the available services on a network.
(Originally, there was a fourth requirement that allowed for the allocation of multicast addresses without a MADCAP server, but it was dropped due to a lack of interest.) Table One shows the layers at which these three requirements are generally implemented.
Table One: Proposed IETF solutions for meeting Zeroconf requirements,
and the layers at which the protocols are likely to be implemented.
PROPOSED IETF SOLUTION
1. Automatic IP allocation
2. Name resolution
3. Service discovery
The first requirement — automatic IP assignment — was relatively easy to fulfill. For years now, both the Mac OS and Windows operating systems have automatically been allocating so-called “link-local” IP addresses in the 169.254/16 range to their network interfaces whenever no DHCP server or pre-assigned IP address can be found. Cheshire, Guttman, and Microsoft’s Bernard Aboba published an IETF draft that took the Mac OS and Windows system one step further and outlined how devices should detect and manage collisions that could occur if two devices selected the same IPv4 address. In essence, the draft states that devices must pick an address at random in the 169.254/16 range and then check to see if any other device on the network responds to that address. If another device does respond, it means that the address is already in use, forcing the requesting device to select a different address and try again.
As shown in Table Two, Linux users with IPv4 networks can add this support to their systems by installing the zcip package from the SourceForge Zeroconf project. However, users of any operating system with IPv6 support don’t need any additional packages because IPv6 already has IP auto-configuration built in.
TABLE TWO: Current operating system implementations of Zeroconf requirements.
(Brand name or package name provided in parentheses when available.)
APPLE MAC OS X
1. Automatic IP allocation
2. Name resolution
3. Service discovery
The second Zeroconf requirement — allowing users to refer to hosts by names without needing a DNS server — has turned out to be somewhat tricky, due more to market forces than anything else. Both Apple and Microsoft issued drafts that proposed very similar solutions, and both initially referred to the process as multicast DNS name resolution (mDNS). Ultimately, the IETF DNSEXT working group chose Microsoft’s Link Local Multicast Name Resolution (LLMNR) draft for further refinement and dropped the mDNS moniker. Indeed, the latest version of LLMNR is more advanced than — and incompatible with — mDNS, and now includes provisions to keep link-local addresses from accidentally being propagated into the greater DNS space. However, it’s unclear who exactly plans to use LLMNR, since, as
of this writing, Microsoft won’t say whether it plans to add support for it in upcoming versions of Windows. Apple, meanwhile, has already moved forward with an earlier version of the mDNS specification and is shipping it as part of Rendezvous, the company’s brand name implementation of Zeroconf networking.
Rendezvous puts Apple ahead in the Zeroconf game because the technology provides a solution for the critical third requirement of zero configuration networking: service discovery. The solution was made available thanks to Cheshire’s DNS Service Discovery (DNS-SD) specification, which gives applications the ability to use multicast DNS queries to broadcast and discover services on a local network.
It’s important to mention, though, that members of the development community aren’t exactly rallying around DNS-SD. Critics are concerned that DNS-SD won’t scale, meaning that yet another protocol will be needed to implement service discovery across large networks. Likewise, some argue that it’s inappropriate to piggyback a service discovery protocol on top of what was originally intended for name resolution.
“DNS-SD is a proposal for the use of DNS as a service discovery protocol that was based on early versions of the IPv4 link-local and multicast name resolution protocols,” says Microsoft’s Bernard Aboba, one of the authors of the LLMNR draft. “In terms of status, it is an individual submission with no IETF status or RFC publication plans.”
Given such sentiment, it’s becoming more and more likely that the IETF will approve its existing Service Location Protocol (SLP) as a standard solution for Zeroconf’s critical third requirement. According to Sun’s Guttman, SLP goes beyond DNS-SD in that it can scale to an entire network under common administration. “SLP is an IETF standards- track protocol,” says Guttman. “DNS-SD is a protocol layered on top of mDNS used as part of the Rendezvous product. DNS-SD is not a work item in any IETF working group, and it is not likely to become one. DNS-SD is therefore a non-standard protocol.”
Despite the lack of endorsement, Apple still plans to continue forward with DNS-SD. “We feel that DNS serves as a wonderful foundation for naming and service discovery,” says Bill Evans, an Apple spokesperson. “It is a well-known protocol that is a vital element of the Internet itself. So rather than create a new technology from scratch, we felt that leveraging the elegant and unique characteristics of this well-known and widely deployed technology would serve our developers and users best.”
Perhaps the strongest case for DNS-SD is the fact that Apple has been supplying end-users with working Zeroconf products since the release of Mac OS X 10.2 last August, while competing software vendors are still deciding what to do. As Evans puts its, “Rendezvous is a real technology shipping in real products.”
And that’s an attractive argument for the likes of Aspyr, Brother, Chaparral, Canon, Epson, HP, Lexmark, Sybase, Tivo, World Book, and Xerox — all companies that have released or announced products with Rendezvous networking support. Topping it off, Apple has even open sourced the code for Rendezvous, making it that much easier for developers to start creating additional Rendezvous applications. The strong head start means that any competing technologies will be playing catch-up for quite some time.
Putting Zeroconf to the Test
Of course, theory and first-mover advantage can only take a technology so far. It’s how well the technology works once it has been deployed that ensures its long-term survival.
To test Rendezvous in a small office/home office (SOHO) configuration, Linux Magazine visited Jeff Keller, the brain behind DCResource.com and PowerWatch.com, a site that was legendary during Apple’s foray into its Mac clone program. Keller’s setup is similar to that in many home offices that have more than one computer with Internet access: a DSL modem brings in the broadband connection, and an adjoining Apple Airport base station acts as both a direct Ethernet hub for his desktop computer and a 802.11b wireless access point for his laptop and any other mobile devices that colleagues bring into the area.
To test whether the first requirement of the Zeroconf working group — the automatic assignment of IP addresses — was properly implemented, we set up Keller’s Airport base station so that it did not assign any IP addresses. Upon rebooting an Apple iBook loaded with Mac OS X 10.2 on the local network, we used the Network Utility to check the system’s IP address. As expected, the machine had self-selected 169.254.0.1, an IP address in the block reserved for link-local addressing.
Users of Mandrake Linux 9.1 can actually see this IP selection process in action if they have the zcip module installed and are booting up without a DHCP server or an explicit IP address. When we set the iBook’s address to 169.254.0.1 and powered up a Mandrake distribution on the same local network, the Mandrake boot window showed that the operating system tried to select the same IP by default, determined that there was a collision, and then selected the next sequential address. Mandrake determined that the second address was fine, and finally continued with the boot procedure.
For the next test — name resolution — we opened a terminal window on the iBook. A ping to jeffkeller.local showed that Keller’s machine was indeed online and reachable via his Zeroconf hostname. (The Zeroconf hostname is the one item that end-users do have to configure themselves in a Zeroconf network. The configuration is easy, though: you simply note the name you want to use in the Network Preferences panel. If you don’t do this, the name will default to something chosen by the operating system like “Jeff Keller’s Computer” which can be a problematic name if you’re try to ping it.)
Unfortunately, we ran into a snag while trying to do a similar name resolution test between the iBook and a system running Mandrake 9.1. Although the iBook could resolve “ibook.local” and “mandrake.local,” the Mandrake system could not resolve “ibook.local,” suggesting that the iBook wasn’t responding correctly to mDNS requests from Mandrake, or that the Mandrake system wasn’t correctly parsing responses. At press time, we’re still looking into the problem.
For the final test — service discovery — we launched the latest version of iChat to see if it would automatically “discover” Keller’s iChat client. Sure enough, having selected the “Rendezvous messaging” checkbox in the preferences menu of the instant messaging application, the iBook was able to see Keller’s client and was able to do a peer-to-peer chat with him, all without ever having to find out Keller’s IP address or ask him for his username. As Apple likes to say, “It just works.”
Although such an example may seem trivial, it does have great implications for administrators who want their employees to be able to chat, but don’t want the hassle of configuring all of the clients or having all those messages travel off the network to a central instant messaging server just to come right back to the local network. Employees at O’Reilly & Associates have reported using iChat and Rendezvous in this way at their headquarters in Sebastopol, CA, with great success.
Tests of other applications all worked as expected. When we both launched iTunes, we were able to see each other’s music libraries and stream audio files between machines. Similarly, we both launched Freshly Squeezed Software’s Bookie application and were able to share bookmarks with any other machine on the network.
Now Appearing in Open Source
When Apple open sourced its Rendezvous code last September, Strangeberry Inc.’s Arthur van Hoff quickly wrote a Java implementation. Jrendezvous, as the implementation came to be known, uses DNS-SD to broadcast services on the local network. A service can be virtually any application that handles input via sockets.
For example, we used gnump3d, an open source MP3 server, on a Windows Me machine. After launching the gnump3d server, we registered it with Jrendezvous using the following command:
% java -jar jrendezvous.jar -rs MP3s \
_http._tcp local. 8887 index.html
Now Jrendezvous was ready to listen for incoming service discovery requests. Again, on the iBook, we launched Apple’s Safari Web browser and navigated to the Rendezvous selection in the Bookmarks list. Doing this causes Safari to send out a multicast service discovery request to all machines on the local network. Any DNS-SD responders, such as Jrendezvous, send back a list of services that they know about. In this case, Jrendezvous sent back a pointer to the MP3 service that was registered from the Windows Me system.
Safari listed this service in its Rendezvous Bookmarks menu, and allowed us to launch it just as if I were navigating to any other Web page.
The beauty of a service discovery feature like this is that it eliminates some annoying steps that end-users would normally have to take to access a distributed service. With Jrendezvous, users on the local area network no longer have to know the IP address or the port number where gnump3d is running. Users could simply go to their Safari Web browser and select the MP3 link from the Rendezvous Bookmarks menu. If the location of the server ever changes, Jrendezvous (or a similar responder) can be used to advertise the correct information; the end user doesn’t even have to know that anything has changed.
The benefits of JRendezvous extend beyond personal computing. Josh Lucas, a release engineer at CollabNet, uses Jrendezvous in an enterprise environment on a regular basis. By launching Jrendezvous on various servers within CollabNet, Lucas can add servers to the network in an ad-hoc manner. “The service advertised is an XML-RPC one which the master build box can use to query the status of the build as well as the various meta-info about the configuration,” says Lucas. “This way I can add a new box without having to update all sorts of configuration files.”
If Lucas wanted to remove even more steps in the process of adding new servers to his network, he could build a DNS-SD responder directly into his XML-RPC service. Or, he could give the service the ability to register with a central responder provided by a Zeroconf-enabled operating system. This would eliminate the need for him to have to launch the Jrendezvous responder — truly making it a zero configuration system.
Whither JINI and UPnP?
Apple isn’t the first to implement and distribute a zero configuration system. Long before Zeroconf and Rendezvous, there was Jini from Sun. Jini “offers a simple infrastructure for delivering services over the network and creating spontaneous interaction between programs that use these services, regardless of their hardware or software implementations,” reads an executive overview on Sun’s Web site.
The similarity to the Zeroconf mission is not coincidental. When the company released Jini in 1999, executives touted it as the one solution that would make accessing devices and services as easy as surfing the Web. But developers weren’t as gung-ho about the technology, mainly because its Java APIs meant that services would have to be built in Java or somehow connect to Java objects. Similarly, device manufacturers weren’t keen on having to build both Java runtime and RMI support into their products.
When asked how he saw Sun’s efforts in this area changing now that Zeroconf was coming together, Guttman wrote, “Sun is extremely committed to the standards process. The Zeroconf protocols have not yet been published as standards. This is a major contributing factor to why Sun has not yet shipped Solaris supporting these features.”
As is the case with Apple, it seems then that Sun is waiting to see what standards come out of the IETF working groups before making a decision on what it will implement in the long run.
Meanwhile, Microsoft has been working on yet another zero configuration technology that it calls Universal Plug and Play (UPnP). Announced just months after Sun’s release of Jini, UPnP is based on the Simple Service Discovery Protocol (SSDP) and HTTPMU, a multicast variant of HTTP. Although these are lighter weight and easier to implement in devices and services than Jini, some developers have been put off by the highly structured nature of SSDP responses, which are in the form of XML documents. Handling these documents often requires an XML parser, which can eat up valuable resources, especially in devices with small memories. Additionally, security flaws found in Windows implementations of UPnP have scared many IT managers and home users into disabling support for it.
Yet, UPnP might have a chance of surviving because of its relative compatibility with Zeroconf. Both are modular enough that the service discovery level can run independently of the automatic IP and name resolution levels. “In many ways, there’s no conflict here,” says Guttman. “Those implementing UPnP can use link-local autoconf and link-local name resolution protocol while still running the UPnP ‘non-standard’ protocols.” This means that a stereo manufacturer could create a system that would connect to and download MP3s from your desktop computer, regardless of whether that computer was running Mandrake Linux 9.1, Mac OS X 10.2, or Windows XP.
Whether device manufacturers actually go to the trouble of implementing both specifications, though, is still unclear. Raj Nathan, Senior Vice President and General Manager of Sybase’s Enterprise Solutions Division, says his company is keeping an eye on UPnP, but is not likely to implement it any time soon. Sybase is already distributing Rendezvous-enabled clients that automatically detect and list various Sybase server processes running on a network. “Sybase will monitor standards such as UPnP as they evolve, and should they reach a point where we see customer acceptance and adoption, we will incorporate them into our software,” says Nathan. However, he adds, “So far, we’ve heard little or no demand for UPnP.”
A Not So Automatic Future
As useful as Zeroconf seems in the creation of ad-hoc networks, a bright future is not necessarily guaranteed. If operating systems vendors can’t come to a consensus — and specifically, if Apple sticks with DNS-SD, and neither Microsoft nor Apple ever implement LLMNR — then applications developers and device manufacturers will be forced to either write code for multiple protocols or choose one over the other. More likely it will be the latter, leading to a result that doesn’t seem all that much different from the days when Apple users would turn on AppleTalk to link computers and devices that were specific to Apple, and Microsoft users would flip on NetBUI to link computers and devices that were specific to Microsoft.
At the least, Apple’s Rendezvous shows that a zero configuration network is possible. And despite the naysayers, the company’s DNS-SD proves that a service discovery protocol doesn’t have to be complicated or all-encompassing. Indeed, few people can fault Apple for providing its customers with working technology, not even the chair of the Zeroconf working group. “In the link-local realm in which it is used, [Rendezvous] seems to work,” concedes Guttman. “Vendors must ship products. They can’t wait for the IETF to complete these efforts.”
Despite this practicality, Guttman holds out hope that, one day, the idea that anyone can simply plug into a local network and start using services will no longer be a dream. “Hopefully, once the standards appear, we can get everyone into the fold.”
Amit Asaravala is an independent journalist based in San Francisco, CA. Prior to becoming a full-time writer, he was the founder of
magazine and the Editor-in-Chief of
Web Techniques magazine.