Zero Configuration Networking (Zeroconf) (original) (raw)

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:

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.

Documents

Further Information

Page maintained by Stuart Cheshire