Bonjour: What’s behind the zeroconf implementation

For devices in a network to be able to communicate with each other, they first have to build a connection with each other. To establish contact, you don’t need the name of the device, but rather the IP or MAC address, which is typically assigned automatically to users in larger networks by a central DHCP server (Dynamic Host Configuration Protocol). This does the work of the DNS server, which is responsible for the conversation of the domain name into an IP address or the IP address into a domain name. The alternative to this automatic address assignment is to adapt the host files of all network participants and enter the names and IP addresses manually – an undertaking that is almost impossible to accomplish on a large network.

Neither path is deal when setting up a local network: On the one hand, the configuration of DHCP and DNS servers takes a certain amount of effort and know-how. But on the other hand, the manual option requires the adaptation of all host files if, for example, a new device is added to the network or changes are made to previously integrated systems. The solution to the problem carries the name Zero Configuration Networking – or zeroconf for short – and refers to the idea of an IP network that connects devices to one another without manual configuration. The network concept, whose development kept a task force of the IETF (Internet Engineering Task Force) busy between 1999 and 2003, is realized in the implementations Bonjour and Avahi, among others.

When the Internet Engineering Task Force began the Zero Configuration Networking project in 1999, the following features were set as the goal for the “configuration-free network”:

• Integrated name resolution
• Automatic assignment of subnet masks, individual IP addresses, and routers
• Search function to find available network services
• Automatic distribution of multicast addresses for multi-point connections
• Same level of security as networks without zeroconf

But the IETF task force couldn’t reach a consensus, which is why it didn’t publish a document with the requirements of Zero Configuration Networking at the end of the project period. Instead, it was decided, together with Apple, Microsoft, and Sun Microsystems, to develop a specification for internet protocol, which was published in 2005 under the name “Dynamic Configuration of IPv4 Link-Local Addresses” (RFC 3927). IPv4LL automatically assigned random IP addresses with the prefix 169.254/16 from the range 169.254.0.x to 169.254.255.x, with the first and last 256 addresses reserved for future applications. The RFC standard also assumes that the random number generator incorporates computer-specific information, such as the MAC address of the network interface, when generating the internet addresses – which minimizes the probability that two devices will be given the same IP.

How automatic address assignment works in IPv4

For automatic address assignment without the DHCP protocol, IPv4 uses the Address Resolution Protocol (ARP), which has been replaced by the Neighbor Discovery Protocol (NDP) in IPv6. With this, the allocation process runs through multiple steps in order to avoid conflicts between the IP addresses of the participating network devices.

1. First the IP address is generated.
2. Then IPv4LL provides so-called ARP samples, which are used to check whether the generated IP address is already being used in the network. To do this, three ARP packets with the sender address 0.0.0.0 and the address to be verified are sent as receivers.
3. If an ARP packet is received during this period in which the sender address corresponds to the generated IP address, then it’s already assigned in the network and the IP generation process starts again.
4. If a foreign ARP sample is received which is marked with the address to be tested, then at least one other device is trying to join the network with this IP, and the generation process is also repeated from step 1 on.
5. If no conflicts arise, then the connecting device successfully uses the address for itself and sends out two so-called ARP announcements in which sender and recipient addresses correspond to the generated IP.

Since the assigned IP address is dynamic, it’s rechecked after each restart, wake-up from sleep mode, plugging into the Ethernet cable, or logging into the wifi. For a high number of conflicts not to overload the network, for example, if lots of devices want to connect to the network at the same time, then the number of retries per device is automatically reduced to one check per minute after ten conflicts.

Zeroconf: Name resolution and automatic device recognition

Together with the DNS Extensions task force, the Zeroconf team also developed solutions for automatic address translation and device management in the configuration-free IPv4 networks. Instead of designing and entirely new protocol, they decided to provide the functions by simply modifying the default DNS protocol. The project teams worked closely with Apple, since the electronics company already had appropriate solutions for its own devices with its company-owned protocol collection AppleTalk, which were merely transferred to the internet protocol family. The results were the specifications Multicast DNS (RFC 6762) and DNS-Based Service Discovery (RFC 6763).

Multicast DNS (mDNS) describes how devices can send DNS queries to IP multicast addresses. To do this, the top level domain .local is defined in the mDNS protocol as link-local. In addition, all requests that end in .local have to be sent to the IPv4LL multicast address 224.0.0.251 (the address is FF02::FB in IPv6). All DNS requests that don’t end in .local also reach the multicast address if the network isn’t available over a DNS server. In general, mDNS messages can be transferred over both UDP and TCP. Here, the multicast port 5353 is used instead of the usual port 53. If a network device now wants to resolve the host name of another network participant, it sends it an mDNS request asking for identification. The target device answers with a multicast packet that discloses its IP address. All network devices contain this information and automatically include them in their DNS cache.

DNS-Based Service Discovery (DNS-SD) defines how services can be visible and made available in a zeroconf network for all participants. For reconciliation purposes, it’s necessary to first register the service with the IANA (Internet Assigned Numbers Authority) to obtain a uniquely assigned service name. The respective names are then shared by the network users via multicast notification, and there’s no problem when multiple devices offer the same service: In this case, the network client simply has the option to choose between the hosts.

Both RFCs were first officially published by the IETF in February 2013, but Apple had already started to integrate the standards into its devices as an initiator in 2002. The software developed for this occasion, which is now known under the name Bonjour (formerly Rendezvous), is open source and doubtlessly one of the most-used zeroconf solutions. The configuration-free network architecture is available not only for macOS and iOS, but also for Windows.

When Apple switched to the hybrid XNU kernel with Mac OS X 10.0 in 2001, they decided not to port the typical AppleTalk network protocol group to the new operating system. The fact that the electronics giant didn’t intend to develop an adequate successor didn’t suit the Mac user Stuart Cheshire in the least, so he set up an e-mail discussion board in which he addressed the weaknesses of the necessary manual network configuration together with other users. This got Apple to rethink their decision: Without delay, Stuart Cheshire was introduced and commissioned to develop a protocol variant for the new operating system, which resulted in the aforementioned cooperation with the Internet Engineering Task Force.

With Mac OS X 10.2, Apple published the first version of the new protocol specification in August 2002 under the name Rendezvous. Due to legal problems, they were forced to find a new title for the project, which is why the network software has had the name Bonjour since Version 10.4. The main component of the packet is the mDNSResponder, a program that begins on start-up and runs in the background, and implements Multicast DNS and DNS-Based Service Discovery. The internet protocol specification IPv4LL (or IPv6LL) is of course also one of the main components. With it, the Apple solution covers the three elementary areas of the configuration-free network:

• Addressing
• Name resolution
• Network service identification

Thanks to this architecture, you can easily connect to other components in local networks that are also based on Bonjour – regardless of whether it’s a PC, printer, or some other application. For example, the Apple music service iTunes uses the technology to automatically find other users who are sharing their music on the network. On common macOS and iOS systems, the Bonjour software is automatically installed. Windows users can either download a specific version for printing services or install an application whose environment contains the software. These include, among others, the previously mentioned iTunes, Skype, and Adobe Photoshop (CS3 and higher).

An alternative to Apple’s zeroconf solution that functions on Linux systems as well, installed by default on Debian and Ubuntu and available under the free license LGPL, is Avahi. The implementation initially received support from the non-profit initiative freedesktop.org, but has now developed into an independent project.