Zeroconf

Zeroconf or Zero Configuration Networking is the name for a set of technologies to allow two or more computers to communicate with each other without any external configuration. A typical usage scenario would involve two laptops connected with a cross-over Ethernet cable or ad-hoc wireless network.

The goal is thus to obtain a functioning IP networking, without dependence on infrastructure (DHCP server, DNS server, etc.) or expert knowledge (e.g. RFC 1918 addressing). Zeroconf was initially pioneered by now Apple-employee Stuart Cheshire as part of Apple's transition from AppleTalk to IP; it is now adopted by many makers of network devices. One good example is network printers. Many printers have no screen or keyboard for users to enter IP addresses and subnet masks, so they often have to set themselves up automatically if normal humans are to use them. Many network printers and network storage devices available today implement some form of Zeroconf-compatible networking.

Contents

1 Components 1.1 Dynamic allocation of IP addresses 1.2 Name resolving without DNS server 1.3 Service Discovery 1.4 Allocate IP Multicast addresses 2 Standardization 3 Implementations 3.1 Apple Bonjour 3.2 Link-Local IPv4 Addresses 3.3 Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD) 4 References

Components

Zeroconf tackles four separate issues:

• Allocate dynamic IP addresses without a DHCP server.
• Translate between names and IP addresses without a DNS server.
• Find services, like printers, without a directory server.
• Allocate IP Multicast addresses without a MADCAP server.

Dynamic allocation of IP addresses

For IPv4, there is one standard to handle automatic allocation of link-local IPv4 addresses in the 169.254.0.0/16 range. The official Ipv4 Link-local draft was published as RFC 3927 in March 2005.

IPv6 supports dynamic allocation of IP address by design.

Name resolving without DNS server

For name resolving, there are two competing solutions:

• Multicast DNS (mDNS)
• Link-local Multicast Name Resolution (LLMNR)

mDNS is propagated by Apple Computer (Stuart Cheshire), and has working implementations. LLMNR is promoted by Microsoft (Bernard Aboba), and is still discussed within the IETF. However, LLMNR has no implementations yet. In general, mDNS has better software backup, but LLMNR has more standards track backup. Though the protocols are very similar, they are not compatible.

On a technical level, both protocols work by specifying a specific IP multicast address, where all computers listen and respond to. Each host picks a hostname in the .local (dotlocal) domain, and announces this on the IP multicast address. A conflict resolution mechanism prevents collisions. Technically, mDNS and LLMNR do not depend on link-local IPv4 addresses, but they can be used in conjunction. The differences between mDNS and LLMNR are very minor, and handle for example the way the TTL (time to live) parameter of the IP packets are set.

Service Discovery

To make things even worse, there are at least three competing, non-compatible solutions to tackle service discovery:

• DNS Service Discovery (DNS-SD)
• Service Location Protocol (SLP)
• Simple Service Discovery Protocol (SSDP) as used in Universal plug-and-play (UPnP)

Beside these three protocols, which are primarily focused on discovery of services in a link-local (or at least confined) network, there are also protocols which are designed for service discovery in other areas, like UDDI for Webservices and Jini for Java objects. Though it falls within the realm of Service Discovery, it falls outside the realm of Zeroconf networking.

For comparison of these protocols, you should not just look at each of the specifications, but rather who is promoting or actually using them (and in what circumstances) and try to assess the reasons (both technical and commercial) for that choice.

In short, DNS-SD is implemented and promoted by Apple, and is a light-weight protocol. It is implemented by some vendors, including multiple printer vendors, as well. SSDP is the direct competitor of DNS-SD, and is promoted by the UPnP Forum and supported (among others) by Microsoft. Microsoft implemented UPnP in Windows XP. It is implemented by some vendors, including multiple vendors of network devices, as well.

SLP is the only official standard (RFC 2608, created by the IETF srvloc working group), and there is an open source implementation available, called OpenSLP. However, the large vendors seem to move away from SLP.

SSDP is considered to be more complex then DNS-SD, since SSDP uses HTTP messages and DNS-SD uses DNS message. A major difference between UPnP and DNS-SD is that UPnP is more formalized, which may be an advantage or a disadvantage depending on your point of view.

On a technical level, DNS-SD uses DNS SRV records (as described in RFC 2782) as well as DNS TXT and DNS PTR records to find out which services are running on which hosts, and to get specific details for those services. Services in DNS-SD are specified using their Service Instance Name (SIN), which is a combination of Instance, Service Type, and Domain name. SSDP uses HTTP notification announcements to discover services as identified by a unique combination of a service type URI and a Unique Service Name (USN).

The Device Control Protocols (DCP) as used by SSDP are supervised by the Universal Plug and Play Steering Committee, while DNS-SD uses an informal first-come-first-serve registration for DNS SRV Service Types.

Allocate IP Multicast addresses

There are no known standards or implementations which handle the automatic allocation of IP Multicast address in a Zeroconfig environment without a MADCAP server.

Standardization

The IETF Zeroconf working group was chartered to handle the first of these issues. [1] (http://www.ietf.org/html.charters/OLD/zeroconf-charter.html) This effort, by Sun, Apple and Microsoft, was concluded in August 2004, and in March 2005 they published RFC 3927.

The IETF vision furthermore envisioned the use of Link-Local Multicast Name Resolution (LLMNR) for name resolving without DNS server. This work is carried out in the IETF DNS Extension (dnsext) working group [2] (http://www.ietf.org/html.charters/dnsext-charter.html)

Last, the concluded IETF Service Location (srcloc) working group defined the Service Location Protocol (SLP) to handle Service Discovery. [3] (http://www.ietf.org/html.charters/OLD/svrloc-charter.html)

Implementations

Apple Bonjour

Despite the attempt at standardization, the most widely adopted Zeroconf solution is Bonjour from Apple Computer, which does not follow the IETF standards, but uses a combination of IPv4 link-local IP address, Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD).

Up till Mac OS 10.1, Apple supported SLP, but they abandoned that in favour of mDNS and DNS-SD starting with Mac OS 10.2.

Link-Local IPv4 Addresses

There are some implementations available:

• Microsoft Windows and Mac OS have both supported link-local IPv4 addresses out of the box since 1998. Apple released it's implementation as Open Source in the bootp package of Darwin (http://www.opensource.apple.com/darwinsource/).
• zcip (http://zeroconf.sourceforge.net/) (Zero-Conf IP) implements it. The package was pulled temporarily due to concerns about potential conflict with Apple IP, but has been re-posted recently on SourceForge.
• zeroconf (http://www.progsoc.uts.edu.au/~wildfire/zeroconf/), a package based on Simple IPv4LL (http://www.zeroconf.org/AVH-IPv4LL.c), a short implementation by Arthur van Hoff.

Not all implementations implement the full specification. For example, broadcasting ARP replies or the graceful transistion from a link-local address to a DHCP address as soon as one is found.

Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD)

mDNS and DNS-SD often seem to be implemented together. The most often used version by programmers of Applications seems to be Apple's mDNSResponder implementation, which is available on Mac OS X, Windows and Linux, and has interfaces for C and Java. [4] (http://developer.apple.com/darwin/projects/rendezvous/) [5] (http://www.macdevcenter.com/pub/a/mac/2004/08/31/osx_java.html)

Other implementations are:

• JmDNS (http://jmdns.sourceforge.net/) - Java implementation by Arthur van Hoff
• pyZeroConf (http://sourceforge.net/projects/pyzeroconf/) - Python Multicast DNS Service Discovery
• mdnsd (http://www.dotlocal.org/mdnsd/) - embeddable Multicast DNS Daemon (no DNS-SD)
• Liaison (http://www.acm.uiuc.edu/signet/liaison/)
• Howl (http://www.porchdogsoft.com/products/howl/)

References

• Template:Journal reference
• Heath Johns. (20 Dec 2002). "Understanding Zeroconf and Multicast DNS (http://www.oreillynet.com/pub/a/wireless/2002/12/20/zeroconf.html)". O'Reilly Network - The article is still mostly accurate, despite it being over 2 years old.

• http://ietf.org/html.charters/dnsext-charter.html -- Charter of the DNSEXT working group, which is co-ordinates the LLMNR standarization work.
• http://www.dotlocal.org/ explains more about .local addresses (which are not yet standardized by IANA, but actively used in mDNS implementations)
• LLMNR is described in http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-38.txt (Work in Progress, link may expire)
• http://www.upnp.org/ -- Industry consortium for UPnP
• http://developer.apple.com/darwin/projects/bonjour/ - Implementation of DNS-SD by Apple Computer
• RFC 2608 - Service Location Protocol, Version 2

de:Zeroconf it:Zeroconf fr:Zeroconf