Todays networks are becoming increasingly dynamic in their configuration. With the emergence of wireless LANs a modern network can expect to have devices removed and added frequently. Naturally these networks rely on common TCP/IP protocols such as DNS, DHCP, MADCAP and LDAP, which in turn require an administrative staff. For increasingly popular ad-hoc and small home networks, the technical knowledge of end-users is often limited and administrative skill can be lacking. In a world where networks are beginning to connect not only computer users of varying technical skill but also a huge variety of personal digital devices (everything from PDAs to toasters), the end-user can't always be expected to have the time, desire, or knowledge to configure their network.

From hotel rooms to airplanes, cars, and campuses computer users are routinely connecting to networks of which they have no knowledge of services (LDAP and printing, for example) or the primary hosts on the network (DHCP or DNS servers, for example). In situations where there are no administrators either because they are unavailable or don't exist all, these networks need protocols that require zero configuration and administration. Zeroconf is a collection of such protocols.

Zeroconf has four main protocol areas:

• IP address configuration
• Translation between host name and IP addresses
• Service discovery

Zeroconf defines a protocol analogous to a decentralized, server-less DHCP service. With Zeroconf, if no IP configuration information is availible the connecting device randomly chooses an IP address in the range from 169.254.1.0 to 169.254.254.255, which is reserved for link-local communication. The device then "probes" the network by broadcasting two ARP packets across the local subnet containing the IP address it intends to use. The device then waits a specified amount of time (generally less than 10 seconds) for a reply. If another device on the network has that same address, it is the responsibility of that second device to then broadcast back a packet, effectively announcing that the address is in use. The original device then tries again with a different address. If no reply is received, the original devices sends another ARP packet announcing it has selected an address.

There are other situations in which two devices could configure themselves with the same address. In situations where an IP address was never negotiated for (ie. one of the devices had an IP hard-coded in), Zeroconf detects the IP collision and reconfigures itself with a new IP immediately.

It is important to note that since Zeroconf uses link-local addresses, they are not globally unique. These addresses are only effective for intranet communication, and routers are configured not to forward 169.* packets to larger networks. One would not be able to, say, request a webpage from a foreign server using a link-local address. NAT or a similar routing scheme would typically be used in addition to Zeroconf to fix this problem.

DNS is perhaps the most-used and most important service used on most networks. Unfortunately, it relies heavily on a client-server model. On many networks DHCP helps with DNS configurations, but as mentioned above, Zeroconf is designed to work in networks with no centralized server systems, DNS being one of them.

Instead of designing a new protocol, Zeroconf uses a variant of DNS known as Multicast DNS (mDNS). This protocol's API works exactly like DNS, so using Zeroconf should be transparent to application-level processes. Devices can assign themselves their own names, ending with a ".local" suffix.

When prompted to resolve a name, Zerconf sends a packet containing the requested name to the multicast broadcast address (224.0.0.251). The packet is then sent across the subnet, and each connected device checks if the packet's requested name matches their own. If a devices finds a packet with its own name, it replies with another multicast packet containing its own IP, and the name is resolved.

It's interesting that the second device sends a multicast reply when, in an attempt to save network traffic, it could simply send a unicast packet back to the original sender and the name would still be resolved with less "noise". The reason mDNS uses multicast reply packets is so that third party devices on the network can observe name resolution requests and cache the results. In other words, the collective intelligence of the entire network is raised each time a device makes a DNS request since that information can be used by other devices later on who heard the "conversation". This concept of collective resolution is common thread in all Zeroconf protocols, and also helps to make the system especially robust against outages.

Zeroconf uses the Service Location Protocol (SLP). Much like the mDNS system, devices looking for a service send out multicast requests containing the type of service required and the service attributes. Devices which can fulfill such requests then send a multicast reply. Like mDNS, third party devices can also cache this information to use later on.

Apple currently has their own implementation of Zeroconf, marketed by them as Rendevous. It works in many of their programs, including Safari, iTunes, and iChat. The main page for the Zeroconf project containing specifications and more information can be found here at zeroconf.org.

http://en.wikipedia.org/wiki/Zeroconf
http://www.multicastdns.org/
http://www.zeroconf.org/