Zero Configuration Networking (Zeroconf)
The IETF Zeroconf Working Group was chartered September 1999 and held its first official meeting at the 46th IETF in Washington, D.C., in November 1999. By the time the Working Group completed its work on Dynamic Configuration of IPv4 Link-Local Addresses and wrapped up in July 2003, IPv4LL was implemented and shipping in Mac OS (9 & X), Microsoft Windows (98, ME, 2000, XP, 2003), in every network printer from every major printer vendor, and in many assorted network devices from a variety of vendors. IPv4LL is available for Linux and for embedded operating systems. If you’re making a networked device today, there’s no excuse not to include IPv4 Link-Local Addressing.
The specification for IPv4 Link-Local Addressing is complete, but the work to improve network ease-of-use (Zero Configuration Networking) continues. That means making it possible to take two laptop computers, and connect them with a crossover Ethernet cable, and have them communicate usefully using IP, without needing a man in a white lab coat to set it all up for you. Zeroconf is not limited to networks with just two hosts, but as we scale up our technologies to larger networks, we always have to be sure we haven’t forgotten the two-devices (and no DHCP server) case.
Historically, AppleTalk handled this very well. Back in the 1980s if you took a group of Macs and connected them together with LocalTalk cabling, you had a working AppleTalk network, without any expert intervention, without needing to set up special servers like a DHCP server or a DNS server. In the 1990s the same was true using Ethernet — if you took a group of Macs and plugged them into an Ethernet hub, you had a working AppleTalk network, using AppleTalk-over-Ethernet. Now that it’s common for computers to have IEEE 802.11 (“AirPort”) networking built-in, you don’t even need cables or a hub.
On Windows PCs, Microsoft NETBIOS and Novell IPX provided similar ease-of-use on small networks.
One major problem with using IP for wide-area communication and AppleTalk, NETBIOS, or something else for local communication, was that it required application developers to support multiple different protocols with different semantics, conventions, and operational models. For example, a game developer writing a multi-player game would usually support IP to allow game-play across the Internet. However, a developer selling a game for $50 doesn’t have the technical support budget to provide telephone support for people trying to configure their own “Net 10” IP network at home, so for the sake of ease-of-use, that developer also had to support AppleTalk (in the Macintosh version) and NETBIOS or IPX (in the Windows version) for people to play network games at home. Unfortunately, even after doing all that work the developers still hadn’t really solved their problem, because if someone with a Mac laptop wanted to play a network game with a friend with a Windows laptop, they were still in the position of having to set up their own IP network, because IP is the only cross-platform protocol their two machines had in common. It was clear that what the world needed was the ease-of-use of AppleTalk, applied to IP, the ubiquitous platform-agnostic communications protocol.
To achieve AppleTalk ease-of-use in IP, there are four main requirements:
- Allocate addresses without a DHCP server (IPv4 Link-Local Addressing)
- Translate between names and IP addresses without a DNS server (Multicast DNS)
- Find services, like printers, without a directory server (DNS Service Discovery)
- Allocate IP Multicast addresses without a MADCAP server (future work)
A final requirement is that the solutions in the four areas must coexist gracefully with larger configured networks. Zeroconf protocols MUST NOT cause harm to the network when a Zeroconf-capable machine is connected to a large network.
It is important to understand that the purpose of Zero Configuration Networking is not solely to make current personal computer networking easier to use, though this is certainly a useful benefit. The long-term goal of Zero Configuration Networking is to enable the creation of entirely new kinds of products that make use of IP networking, such as ubiquitous IP-based home automation and smart home products. In 1999, prior to the Zeroconf work, these products would simply not have been commercially viable because of the inconvenience and support costs involved in educating customers about setting up, configuring, operating, and maintaining a network to allow those products to operate.
- Zeroconf Requirements (draft-ietf-zeroconf-reqts-12.txt) defines the protocol requirements for zero configuration networking. This document was never published by the IETF, but the draft is made available here for historical interest.
- Zeroconf Host Profile (draft-ietf-zeroconf-host-prof-01.txt) outlines which protocols are available that could meet the requirements specified in the requirements document. In effect this draft is the embyonic form of a possible future RFC which could become an update to RFC 1122 (Host Requirements). This document was never published by the IETF, but the draft is made available here for historical interest.
- IPv4 Address Conflict Detection (RFC 5227) describes how a host can detect when some other host on the same link is trying to use the same IP address (a Bad Thing). This is the same mechanism used for Link-Local Addresses, but it is equally useful and applicable no matter how an address was configured, whether via manual entry by a human user, via information received from a DHCP server, or via any other source of configuration information.
Configuration of IPv4 Link-Local Addresses (RFC 3927)
specifies how IP hosts can assign addresses in the absence of outside configuration information. That means assigning addresses without depending on information entered by a human user, and without depending on information obtained over the network from a special server, such as a DHCP server.
- Zeroconf Multicast Address Allocation Protocol (ZMAAP) (draft-ietf-zeroconf-zmaap-02.txt) defines how IP hosts can allocate multicast addresses in the absence of outside configuration information. This document was never published by the IETF, but the draft is made available here for historical interest.
- Simple IPv4LL implementation from Arthur van Hoff. For platforms that don’t already have IPv4LL support built-in, there are various third-party implementations, but they tend to rely on existing libraries which may not be present on all platforms. This version is just 380 lines, and is self-contained and doesn’t depend on things like libpcap or similar packet capture libraries.
- Multicast DNS provides name-to-address translation and other DNS-like operations in the absence of a conventional DNS server.
- DNS Service Discovery uses DNS SRV records to provide simple service discovery (network browsing), and works with both conventional unicast DNS and with multicast DNS.
- May 2002:
Apple announced their Zero Configuration Networking solution under the product name
Rendezvous. Apple is keen to leave AppleTalk behind and move to all-IP networking, and Rendezvous makes that possible. Rendezvous is now used by iChat, iTunes, iPhoto, Safari, file sharing, printing, and just about every other piece of software that does networking on a Mac, including trusty old favorites like telnet, ssh, and ftp.
- April 2005:
Apple announces Bonjour, its new name for “Rendezvous 2”, including wide-area service registration and browsing, extending Rendezvous beyond the local link, inbound NAT traversal (with compatible NAT gateways), new programming APIs for Java programmers, and all of the above for Windows too. The iFelix technical suport pages include a good “HowTo” page including four step-by-step screen shots on Printing from Windows XP using Bonjour. (Actually, the first screen shot is the “Welcome” screen, and the last is the “Congratulations printer set up is complete” screen, so actually there are only two real steps — pick the printer, and verify that the Wizard picked the right driver.)
- December 2005:
Zero Configuration Networking: The Definitive Guide
by Daniel Steinberg and Stuart Cheshire, published by O’Reilly Media. There’s a wealth of information on the Web about Zeroconf, perhaps so much that it can be overwhelming. This book gathers the essential material into a single convenient source, describing how the protocols work, and giving programming examples in C, Java, Python, and Ruby. Whether you’re programming for Mac OS X, Windows, Linux, Solaris, FreeBSD (or any of the other supported Unix variants), or building a hardware device running an embedded OS like VxWorks, the cross-platform programming examples in this book will show you what you need to know to create a great Zeroconf product.
- June 2006: With the help of Apple’s Bonjour, setting up Windows XP to generate PDF from any Windows application that supports printing takes less than a minute and a half from startup. See the video on YouTube.
- June 2009: The Bonjour Sleep Proxy wakes your Mac automatically when you access it over the network.
- October 2013: Presto from Collobos Software is an AirPrint-compatible IPP print server that also implements enough of a DNS server to answer unicast DNS-SD queries for the print services it is offering, making it a Wide-Area AirPrint Server. This means that the printers it offers are visible to iOS AirPrint clients anywhere on a university or enterprise campus (and even remote clients connected via VPN), in contrast to conventional multicast-only AirPrint services, which are visible only to clients on the same local link.
Page maintained by Stuart Cheshire