Bonjour: What’s behind the zeroconf im­ple­ment­a­tion

For devices in a network to be able to com­mu­nic­ate with each other, they first have to build a con­nec­tion 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 auto­mat­ic­ally to users in larger networks by a central DHCP server (Dynamic Host Con­fig­ur­a­tion Protocol). This does the work of the DNS server, which is re­spons­ible for the con­ver­sa­tion of the domain name into an IP address or the IP address into a domain name. The al­tern­at­ive to this automatic address as­sign­ment is to adapt the host files of all network par­ti­cipants and enter the names and IP addresses manually – an un­der­tak­ing that is almost im­possible to ac­com­plish on a large network.

Neither path is deal when setting up a local network: On the one hand, the con­fig­ur­a­tion of DHCP and DNS servers takes a certain amount of effort and know-how. But on the other hand, the manual option requires the ad­apt­a­tion of all host files if, for example, a new device is added to the network or changes are made to pre­vi­ously in­teg­rated systems. The solution to the problem carries the name Zero Con­fig­ur­a­tion Net­work­ing – or zeroconf for short – and refers to the idea of an IP network that connects devices to one another without manual con­fig­ur­a­tion. The network concept, whose de­vel­op­ment kept a task force of the IETF (Internet En­gin­eer­ing Task Force) busy between 1999 and 2003, is realised in the im­ple­ment­a­tions Bonjour and Avahi, among others.

When the Internet En­gin­eer­ing Task Force began the Zero Con­fig­ur­a­tion Net­work­ing project in 1999, the following features were set as the goal for the “con­fig­ur­a­tion-free network”:

• In­teg­rated name res­ol­u­tion
• Automatic as­sign­ment of subnet masks, in­di­vidu­al IP addresses, and routers
• Search function to find available network services
• Automatic dis­tri­bu­tion of multicast addresses for multi-point con­nec­tions
• 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 re­quire­ments of Zero Con­fig­ur­a­tion Net­work­ing at the end of the project period. Instead, it was decided, together with Apple, Microsoft, and Sun Mi­crosys­tems, to develop a spe­cific­a­tion for internet protocol, which was published in 2005 under the name “Dynamic Con­fig­ur­a­tion of IPv4 Link-Local Addresses” (RFC 3927). IPv4LL auto­mat­ic­ally 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 ap­plic­a­tions. The RFC standard also assumes that the random number generator in­cor­por­ates computer-specific in­form­a­tion, such as the MAC address of the network interface, when gen­er­at­ing the internet addresses – which minimises the prob­ab­il­ity that two devices will be given the same IP.

How automatic address as­sign­ment works in IPv4

For automatic address as­sign­ment without the DHCP protocol, IPv4 uses the Address Res­ol­u­tion Protocol (ARP), which has been replaced by the Neighbor Discovery Protocol (NDP) in IPv6. With this, the al­loc­a­tion process runs through multiple steps in order to avoid conflicts between the IP addresses of the par­ti­cip­at­ing 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 cor­res­ponds to the generated IP address, then it’s already assigned in the network and the IP gen­er­a­tion 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 gen­er­a­tion process is also repeated from step 1 on.
5. If no conflicts arise, then the con­nect­ing device suc­cess­fully uses the address for itself and sends out two so-called ARP an­nounce­ments in which sender and recipient addresses cor­res­pond 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 auto­mat­ic­ally reduced to one check per minute after ten conflicts.

Zeroconf: Name res­ol­u­tion and automatic device re­cog­ni­tion

Together with the DNS Ex­ten­sions task force, the Zeroconf team also developed solutions for automatic address trans­la­tion and device man­age­ment in the con­fig­ur­a­tion-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 elec­tron­ics company already had ap­pro­pri­ate solutions for its own devices with its company-owned protocol col­lec­tion AppleTalk, which were merely trans­ferred to the internet protocol family. The results were the spe­cific­a­tions 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 trans­ferred 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 par­ti­cipant, it sends it an mDNS request asking for iden­ti­fic­a­tion. The target device answers with a multicast packet that discloses its IP address. All network devices contain this in­form­a­tion and auto­mat­ic­ally 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 par­ti­cipants. For re­con­cili­ation purposes, it’s necessary to first register the service with the IANA (Internet Assigned Numbers Authority) to obtain a uniquely assigned service name. The re­spect­ive names are then shared by the network users via multicast no­ti­fic­a­tion, 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 of­fi­cially 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 Ren­dez­vous), is open source and doubt­lessly one of the most-used zeroconf solutions. The con­fig­ur­a­tion-free network ar­chi­tec­ture 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 elec­tron­ics 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 dis­cus­sion board in which he addressed the weak­nesses of the necessary manual network con­fig­ur­a­tion together with other users. This got Apple to rethink their decision: Without delay, Stuart Cheshire was in­tro­duced and com­mis­sioned to develop a protocol variant for the new operating system, which resulted in the afore­men­tioned co­oper­a­tion with the Internet En­gin­eer­ing Task Force.

With Mac OS X 10.2, Apple published the first version of the new protocol spe­cific­a­tion in August 2002 under the name Ren­dez­vous. 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 mDNS­Respon­der, a programme that begins on start-up and runs in the back­ground, and im­ple­ments Multicast DNS and DNS-Based Service Discovery. The internet protocol spe­cific­a­tion IPv4LL (or IPv6LL) is of course also one of the main com­pon­ents. With it, the Apple solution covers the three ele­ment­ary areas of the con­fig­ur­a­tion-free network:

• Ad­dress­ing
• Name res­ol­u­tion
• Network service iden­ti­fic­a­tion

Thanks to this ar­chi­tec­ture, you can easily connect to other com­pon­ents in local networks that are also based on Bonjour – re­gard­less of whether it’s a PC, printer, or some other ap­plic­a­tion. For example, the Apple music service iTunes uses the tech­no­logy to auto­mat­ic­ally find other users who are sharing their music on the network. On common macOS and iOS systems, the Bonjour software is auto­mat­ic­ally installed. Windows users can either download a specific version for printing services or install an ap­plic­a­tion whose en­vir­on­ment contains the software. These include, among others, the pre­vi­ously mentioned iTunes, Skype, and Adobe Photoshop (CS3 and higher).

An al­tern­at­ive 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 im­ple­ment­a­tion initially received support from the non-profit ini­ti­at­ive freedesktop.org, but has now developed into an in­de­pend­ent project.