The Internet Protocol Journal - Volume 5, Number 4

Zero Configuration Networking

by Edgar Danielyan, Danielyan Consulting

Zero configuration networking may sound like an oxymoron to many who spend most of their time setting up and mending networks. But don't decide on a career change yet—although zero configuration networks exist and work, they don't work always and everywhere. In this article I describe the current state of the affairs in zero configuration IP networking, introduce Zeroconf, the suite of zero configuration IP protocols, and tell what they do and how they work. This article is only a brief introduction to zero configuration networking and Zeroconf, so if you are really interested in all the details, refer to the sources listed in the References section at the end of this article.

The best introduction to Zeroconf is the one from the Zeroconf Working Group of the Internet Engineering Task Force (IETF) [1]:
"The goal of the Zero Configuration Networking (Zeroconf) is to enable networking in the absence of configuration and administration. Zero configuration networking is required for environments where administration is impractical or impossible, such as in the home or small office, embedded systems 'plugged together' as in an automobile, or to allow impromptu networks as between the devices of strangers on a train.
Essentially, to reduce network configuration to zero (or near zero) in Internet Protocol (IP) networks, it is necessary, inter alia, to:
Distribute IP addresses (without a Dynamic Host Configuration Protocol [DHCP] server),
Provide name resolution (without a Domain Name System [DNS] server),
Find and list services (without a directory service), and
Distribute multicast IP addresses, if necessary (without a multicast server).

These and other requirements are defined in an Internet Draft titled "Requirements for Automatic Configuration of IP Hosts" by Aidan Williams [2]. This document does not define Zeroconf protocols themselves but instead spells out the requirements that should be met to achieve effective and useful zero configuration IP networking. One of the most important requirements for any Zeroconf protocol is that it should not interfere with other protocols and it must be able to exist on the same network with other non-Zeroconf protocols and devices. Another requirement is "no less" security— Zeroconf protocols should not be less secure than existing non-Zeroconf protocols—more on this later. Although IPv6 addresses some of the requirements of zero configuration networking (such as automatic allocation of link-local addresses), other requirements have yet to be met for both IPv4 and IPv6.

Zeroconf IETF Working Group
The Zeroconf Working Group of the IETF is chaired by Erik Guttman of Sun Microsystems and Stuart Cheshire from Apple Computer, with Thomas Narten (IBM) and Erik Nordmark (Sun) serving as area directors. It was chartered in September 1999 and had its first meeting at the 46th IETF in Washington, D.C., in November 1999. Those interested in the work of Zeroconf WG may find the mailing list archive of the working group at: http://www.merit.edu/mail.archives/zeroconf/

Where and When to Use Zeroconf
For a correct understanding of the applicability and usefulness of Zeroconf it is necessary to keep in mind that it is a link-local technology. Link-local addressing and naming are meaningful only in a particular network; link-local addresses and names are not global and are not unique globally. In this case it means that Zeroconf is intended for use in small wired or wireless local-area networks in situations and places where zero configuration is necessary. It is appropriate to use Zeroconf in such networks when there is no possibility (or it is inappropriate) to set up a working IP network using the traditional technologies such as DNS and DHCP. Zeroconf is not appropriate and should not be used in many cases, for example in:
Medium or large networks
Networks where a high degree of security and control is required
Large public access networks
Networks with low bandwidth and high latency (such as some wireless networks)

When inappropriately used, Zeroconf may bring more problems and headaches than it solves. In contrast, examples of correct and appropriate use would include:
Home and small office networks
Ad hoc networks at meetings and conferences (especially wireless networks)
Two devices needing to spontaneously share or exchange information

Likewise, Zeroconf advantages from one viewpoint may become annoying problems from another. Consider, for instance, the automatic distribution and configuration of link-local IP addresses. For a home network user this is a blessing—no longer do you have to spend time creating an addressing scheme and setting the IP addresses and netmasks on devices that should just work. But for an enterprise network (especially an incorrectly configured one), sudden appearance of nodes with (yet) unfamiliar and strange (this is not your regular 10.* or 192.168.* ) IP addresses may result in more than surprise and added workload for the network administrator.

Continuing in this manner, Multicast DNS (mDNS) that ends the misery of having to remember and type ftp 10.20.30.1 every time you need to transfer files from or to your PC named Bobo and replaces it with just ftp bobo may result in strange behavior on some networks. The bottom line? Zeroconf is not a one-size-fits-all solution; it wasn't designed to be one, and will not work as one.

Zeroconf and Security
Security should occupy an important place in the minds of all networking professionals, so an introduction to zero configuration networking would be incomplete without a mention of its security position. Security goals of Zeroconf are defined in section 4, Security Considerations, of "Requirements for Automatic Configuration of IP Hosts"[2]:
"Zeroconf protocols are intended to operate in a local scope, in networks containing one or more IP subnets, and potentially in parallel with standard configured network protocols. Application protocols running on networks employing zeroconf protocols will be subject to the same sets of security issues identified for standard configured networks. Examples are: denial of service due to the unauthenticated nature of IPv4 ARP and lack of confidentiality unless IPSec-ESP, TLS, or similar is used. However, networks employing zeroconf protocols do have different security characteristics, and the subsequent sections attempt to draw out some of the implications.

Security schemes usually rely on some sort of configuration. Security mechanisms for zeroconf network protocols should be designed in keeping with the spirit of zeroconf, thus making it easy for the user to exchange keys, set policy, etc. It is preferable that a single security mechanism be employed that will allow simple configuration of all the various security parameters that may be required. Generally speaking, security mechanisms in IETF protocols are mandatory to implement. A particular implementation might permit a network administrator to turn off a particular security mechanism operationally. However, implementations should be "secure out of the box" and have a safe default configuration.

Zeroconf protocols MUST NOT be any less secure than related current IETF-Standard protocols. This consideration overrides the goal of allowing systems to obtain configuration automatically. Security threats to be considered iclude both active attacks (e.g. denial of service) and passive attacks (e.g. eavesdropping). Protocols that require confidentiality and/or integrity should include integrated confidentiality and/or integrity mechanisms or should specify the use of existing standards-track security mechanisms (e.g. TLS (RFC 2246), ESP (RFC 1827), AH (RFC 2402) appropriate to the threat."
Although this document does not address each and every aspect of security issues with Zeroconf, it sets requirements for Zeroconf protocols. As is the case with traditional IPv4 and IPv6, use of such techniques as IP Security Architecture (IPSec) or Transport Layer Security (TLS) may be appropriate in some cases. However, the nonstatic (or one may say nondurable) nature of both IP addresses and names in Zeroconf environment may pose a problem for IPSec and TLS deployment.

Dynamic Configuration of IPv4 Link-Local Addresses
Generally speaking, the first requirement that should be fulfilled before any useful IP communication can occur are the IP addresses of sender and recipient. The IP addresses are usually either assigned and set manually or provided by some other means such as DHCP or the Point-to-Point Protocol (PPP). However, neither of these is possible in zero configuration networks. Therefore, an automatic mechanism for dynamic configuration of IP addresses without any manual intervention or dependence on third-party service (that is, DHCP) is necessary. This mechanism already exists in IPv6 but not in IPv4. In "Dynamic Configuration of IPv4 Link-Local Addresses" [3], Stuart Cheshire, Bernard Aboba, and Erik Guttman describe a method that may be used in IPv4 networks to automatically assign IPv4 addresses valid for local communication on a particular interface. A special network 169.254/16 is reserved with the Internet Assigned Numbers Authority (IANA) for this purpose. It is necessary to highlight that 169.254/16 addresses are reserved for link-local use only. The document also addresses such issues as support for multiple addresses and multiple interfaces, continuous address conflict detection, effects of joining previously not interconnected networks, and other considerations.

IPv4 Address Conflict Detection
Address conflicts in IP networks are annoying problems that (needlessly) take time and effort to detect and rectify, so a separate document on address conflict detection was deemed necessary. "IPv4 Address Conflict Detection" [4] by Stuart Cheshire presents two things: first, a way to prevent this unfortunate situation of conflicting IP addresses from happening, and second, a way to detect address conflicts if they do happen even after all the precautions. Both of these are accomplished using the Address Resolution Protocol (ARP). Interestingly, in the Security Considerations section of the document the author states:
"The ARP protocol [RFC 826] is insecure. A malicious host may send fraudulent ARP packets on the network, interfering with the correct operation of other hosts. For example, it is easy for a host to answer all ARP requests with responses giving its own hardware address, thereby claiming ownership of every address on the network.

This specification makes this existing ARP vulnerability no worse, and in some ways makes it better: Instead of failing silently with no indication why, hosts implementing this specification are required to either attempt to reconfigure automatically, or if not that, at least inform the human user of what is happening."
Although some may argue about the question of whether or not it is effective, appropriate, and useful to "inform the human user" in this case, this solution nevertheless follows the principle of at least not worsening the current security situation of an existing protocol.

Zeroconf Multicast Address Allocation Protocol
The Zeroconf Multicast Address Allocation Protocol (ZMAAP) defined in [5] specifies a method for peer-to-peer allocation of multicast addresses without a multicast (MADCAP) server in small zero configuration networks. The word "small" is important here because ZMAAP is not scalable beyond small networks (and is not designed to be).

Multicast DNS
"Performing DNS queries via IP Multicast" [6] by Stuart Cheshire suggests some very useful ideas on how to use mDNS with maximum benefit and minimum hassle in zero configuration networks. In my opinion, the best thing about this proposal is that it does not require any changes to the DNS protocol (messages, resource record types, etc.) itself. Instead it concentrates on the use of multicast for name resolution in environments where no DNS servers exist (and where one would not reasonably expect them to). The goal is to have a working name resolution service without name servers. The document proposes to use local.arpa (although the exact choice of this special domain is not the goal of this document) as the link-local domain (like the 169.254/16 network for dynamic allocation of IPv4 link-local addresses described earlier in this article). For reverse address resolution, 254.169.inaddr.arpa is also link-local. The multicast address 224.0.0.251 that is used for mDNS queries is registered by the IANA for this purpose. No delegation is performed within mDNS domain local.arpa . There is also no Start of Authority (SOA) record for the mDNS domain because of the nature of zero configuration networks where it is intended to be used—in particular, there is no mailbox responsible for the zone. Likewise, zone transfers are not applicable with mDNS zones. To summarize, any local link has its own local and private local.arpa and 254 254.169.in-addr.arpa zones, which have only link-local significance in the particular Zeroconf network.

DNS Service Discovery
Like the multicast DNS solution described previously, the DNS Service Discovery (DNS-SD) [7] does not require any changes to the existing DNS protocol; thus it is completely compatible with the existing DNS server and client software.

What DNS-SD proposes is a naming scheme for DNS Resource Records (RRs) to allow for service discovery using the existing DNS—either the traditional or multicast DNS described in the previous paragraph. DNS-SD uses the SRV and PTR resource records to provide the required functionality. To cite from [7]:
"Service discovery requires a central aggregation server. DNS already has one: It's called a DNS server.

Service discovery requires a service registration protocol. DNS already has one: It's called DNS Dynamic Update.

Service discovery requires a security model. DNS already has one: It's called DNSSEC.

Service discovery requires a query protocol. DNS already has one: It's called DNS."
It is necessary to note that DNS-SD is compatible with mDNS and vice versa, but neither requires the other one to function. However, it is practical to use mDNS for service discovery (using DNS-SD) to have a single protocol and interface and not have to implement another protocol just for service discovery.

Industry Support
Any new technology needs industry support to succeed, and Zeroconf is no exception. Several major vendors have announced plans to support or already support Zeroconf in their products, including Apple, Epson, Hewlett-Packard, Lexmark, Philips, Canon, Xerox, Sybase, and World-Book. One can expect that more companies will Zeroconf-enable their products as the technology itself matures and hopefully becomes standardized and widespread.

Rendezvous
Rendezvous is Apple Computer's implementation of Zeroconf in its Darwin 6 and Mac OS X 10.2 ("Jaguar") operating systems. Apple has stated its full support for the Zeroconf and intent to completely replace the aging AppleTalk with Zeroconf-enabled Macs, without sacrificing the ease of use and transparency to end users provided by AppleTalk networks. A good example of Zeroconf's use in OS X would be the iChat instant messaging (IM) client, which comes with the Version 10.2 of Mac OS X. It works not only with AOL Instant Messenger (AIM) and Mac networks but may also be used between Zeroconf-enabled Macs in a Zeroconf network.

Coupled with Apple's implementation of IEEE 802.11b ("WiFi") in ad hoc mode, it permits a wireless zero configuration network that just works without any configuration or additional hardware or software.

Apple has also made the source code for the mDNS Responder, a part of Rendezvous implementing mDNS, freely available through the Darwin Open Source Project. Mac OS X software developers are encouraged to use Zeroconf, and there are documentation and application examples to facilitate this. More information about Rendezvous and Zeroconf on Macs is available from Apple's Web sites [9].

Summary
With computers and computer networks becoming more and more complex and sophisticated, some people (including the author of this article) believe that care should be taken by those in the know not to create more problems than we solve using these computers and networks. Yes, we want more features—but we also need to remember that most users of these features do not have doctorates in computer science and (surprise, surprise) don't even wish to. Zero configuration networking would probably help in this regard, minimizing and even eliminating in some cases the need to configure and administer small networks. Let me conclude by quoting once more from the Zeroconf Working Group:
"It is important to understand that the purpose of Zeroconf is not solely to make current personal computer networking easier to use, though this is certainly a useful benefit. The long-term goal of Zeroconf is to enable the creation of entirely new kinds of networked products, products that today would simply not be commercially viable because of the inconvenience and support costs involved in setting up, configuring, and maintaining a network to allow them to operate."
References
[1] Zeroconf Working Group, Internet Engineering Task Force (IETF): http://www.ietf.org/html.charters/zeroconf-charter.html

[2] Aidan Williams, "Requirements for Automatic Configuration of IP Hosts," draft-ietf-zeroconf-reqts-12.txt

[3] Stuart Cheshire, Bernard Aboba, and Erik Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses," draft-ietf-zeroconf-ipv4-linklocal-07.txt

[4] Stuart Cheshire, "IPv4 Address Conflict Detection," draft-cheshire-ipv4-acd-02.txt

[5] Octavian Catrina, Dave Thaler, Bernard Aboba, and Erik Guttman, "Zeroconf Multicast Address Allocation Protocol (ZMAAP)," draft-ietf-zeroconf-zmaap-02.txt

[6] Stuart Cheshire, "Performing DNS Queries via IP Multicast," draft-cheshire-dnsext-multicastdns-00.txt

[7] Stuart Cheshire, "Discovering Named Instances of Abstract Services Using DNS," draft-cheshire-dnsext-nias-00.txt

[8] Zeroconf: http://www.zeroconf.org

[9] Rendezvous: http://developer.apple.com/macosx/rendezvous/
http://www.apple.com/macosx/jaguar/rendezvous.html

[10] Erik Guttman, "Autoconfiguration for IP Networking: Enabling Local Communication," IEEE Internet Computing , June 2001.

EDGAR DANIELYAN is a self-employed consultant, author, and editor specialising in UNIX, networking, and information security. In previous life he has been a cofounder of a national ISP and manager of a country TLD. He is currently working on his next book (WLAN Security ) which is due to be published in 2003. His previous book, Solaris 8 Security , was published by New Riders Publishing in 2001. He is also a member of IEEE, IEEE Standards Association, IEEE Computer Society, ACM, USENIX, and the SAGE. He is online at http://www.danielyan.com and can be reached by e-mail at edd@danielyan.com