TCP/IP networking has been deployed in many environments and has been especially successful in large networks such as those in universities, corporations, and government agencies. Operating an IP network requires specialized technical skills. For this reason, IP networking has not been especially well suited for smaller networks (such as in the home, in small businesses, for impromptu networks in conference rooms or construction sites), where capable network administration is not feasible. Currently developments in the computer industry as well as in the Internet Engineering Task Force (IETF) hold out the promise that it will soon be possible to deploy and use IP-based hosts in environments completely lacking in administration and infrastructure. This article explains why static IP network configuration is difficult, describes the current dynamic configuration mechanisms used to overcome those difficulties, and explores a rapidly emerging new set of automatic configuration capabilities.
The evolution of the IP standards suite has concentrated on achieving a reliable and scalable networking architecture. Emphasis has always been placed on mechanisms that allow decentralized administration. Individual networks have been operated with local configuration, while Internetwide configuration has been coordinated through different agencies handling registration of domain names, network numbers, and other parameters.
Network operation requires consistent configuration of all hosts and servers and normally requires centralized, knowledgeable network administration and increasingly complex configuration management services.
It is important to note that there are other networking protocol suites with different priorities and deployment characteristics. In particular the AppleTalk Protocol Suite is simple to operate in small networks, though it requires system administration in larger deployments. Automatic configuration and ease of deployment were of primary importance to AppleTalk's designers. As a consequence, AppleTalk networks can be and are used in homes, schoolrooms, small offices, and conference rooms. In short, AppleTalk is successful in environments where IP networks have been absent, since IP networks have been too complicated and costly to administer. One advantage AppleTalk has over IP is that it functions even in networks where no services have been deployed.
As computers become cheaper and more pervasive, the obvious thing to do is network them together. Many companies are investigating adding features to their products to allow communication between consumer electronics, home appliances, personal computers, telecommunications devices, and more. Until the IP suite becomes as easy to operate as the AppleTalk Protocol Suite, the notion of a networked home or office using IP is impractical. There are many new networking protocols that offer easy deployment (for devices using that technology) in very simple network topologies. This diversity complicates the integration of communicating entities into a single network -- precisely what the IP suite is supposed to achieve.
Several computer software companies have taken the initiative to enhance the IP suite to address this challenge. The IETF has begun work on zero configuration networking for IP. The goal is to allow hosts to communicate using IP without requiring any prior configuration or the presence of network services. True to the traditional architectural principals of the IP suite, care is being taken to ensure that zero configuration networking protocols and operation do not detract from the scalability of larger configured networks with fully administered services.
This paper discusses the services and configuration essential for IP networking and surveys the IP suite standards for providing configuration to IP-enabled devices. The central topic of this paper is the emergence of protocols for operation without services or configuration. Work in the area of zero configuration protocols has been motivated by new demands in the marketplace. Some architectural principles are generally agreed upon and undergird the development of standards in this area. Finally, the paper summarizes the status of this work and concludes by discussing implications for the future.
An IP network is composed of devices that have interfaces that allow them to access one or more networks. A IP host is a device that is capable of sending and receiving IP datagrams using these interfaces. An IP host that forwards packets it receives from one interface onto another of its interfaces is called a router.
In Figure 1, host A can communicate with B directly but requires the router to communicate with host C, since host C is on a different network.
This paper concerns host configuration and operation exclusively. Zero configuration mechanisms could be deployed on networks with routers, but how the routers themselves are configured is beyond the scope of this document.
The essential configuration required by an IP host is the following:
In summary, there are two essential networking services: routers and DNS servers. Without routers, only IP hosts that have interfaces on the same network are reachable. Without DNS servers, hosts have to be configured with the IP addresses of hosts they will communicate with. IP addresses are very poor persistent identifiers to use for configuring hosts. Hosts may be moved (given new addresses) or replaced by other hosts with the same addresses. Using domain names allows a host to obtain destination addresses on demand based on a permanent name. This allows resilient and consistent operation.
The parameters listed above are essential; without them hosts would not be able to communicate. These parameters may be assigned in three ways:
The primary mechanism used to provide IP host configuration on IP-based networks today is the dynamic host configuration protocol (DHCP). This protocol is specifically designed to allow hosts to discover a DHCP server or relay and obtain the essential network configuration described in the previous section. DHCP can also be used to deliver other configuration parameters.
IP Version 6 (IPv6) provides automatic network configuration mechanisms. Hosts are able to obtain a link local address (useful only on a single network) using address autoconfiguration and a routable address by discovering routers, using Neighbor Discovery. While there is work under way to provide DHCP for IPv6, one of the distinct advantages of IPv6 is that hosts do not need as much configuration to operate. That being said, the problems discussed in the remainder of this paper exist equally for both IP Version 4 and IP Version 6.
Figure 2 illustrates the different kinds of configuration discussed in this paper. This figure shows hosts configured with IPv4 addresses and domain names. Other configuration is not shown (subnet mask, default router, DNS server). Host A obtains its configuration from a file. Host B gets its configuration using IPv4 auto configuration. Host C gets its configuration from the DHCP server. Both IPv4 automatic configuration and DHCP are discussed further below.
Assuming that A and C share the same subnet mask, they share the same network number, too. They will communicate with each other directly; without attempting to forward traffic by means of their default router.
B has a different address -- from the link-local address range. Since it is in this range, a router will not forward traffic from B to other networks. Since B has a different network number, A and C would assume they would have to forward messages to it through a router, not knowing that B is on the same physical network. In the future, when support for IPv4 link local addresses is more pervasive, hosts with non-link-local addresses may recognize link-local destinations and attempt to send messages directly to hosts that have them.
Note that in Figure 2, B only gets an address. IPv4 auto configuration provides only address and subnet mask configuration, not domain name, default router, or DNS server configuration.
Another important aspect of network configuration is obtaining the address (or location) of other hosts on the network. Client applications on IP hosts require this information to communicate with servers.
In order for an IP host S to communicate with another host D, S needs to obtain D's address. This address may be obtained in the following ways, each of which requires S to have some initial configuration:
DHCP may provide the address of certain services on the network.
Additionally, the DNS SRV resource record allows IP hosts that support this feature to request the domain name of a service in a specific domain. In each case, the IP host needs to be configured with only the type of service required.
The service location protocol (SLP) also allows the location of servers to be discovered. Unlike DHCP and DNS SRV resource record mechanisms, SLP allows services to be discovered by query, that is, SLP obtains the location of services that meet the client's requirements. For example, a client may be able to use only a server with a certain software version, a server on which the client's user has an account, or a server in a particular physical location.
The lightweight directory access protocol (LDAP) could be used to store various network configurations. IP hosts, upon discovery of an LDAP server, could request and obtain all further parameters from the directory. An example of how such a directory could be organized is documented in an experimental RFC.
Note that neither DNS SRV RRs, SLP, nor LDAP can substitute for the host configuration mechanisms described in the previous section. An IP host requires host configuration in order to be able to communicate at all, let alone use DNS, SLP, or LDAP.
The IETF has already produced standards to provide automatic host configuration (for IPv6) and for service discovery (SLP, DNS SRV resource records, and DHCP service configuration options).
Automatic host configuration features are lacking in IPv4. These features are so useful, vendors are starting to add them. (Notably, Microsoft and Apple have included automatic host configuration for IPv4 in their latest operating system releases.) The stateless address autoconfiguration mechanism for IPv4 is different from that for IPv6 since IPv4's address space is much more constrained (4 bytes instead of 16). Thus, the potential of contention for the same address is much larger and the address that is arrived at cannot be used in any simple way to derive a globally routable address, as it can in IPv6.
Operating system vendors with proprietary networking protocols (like Apple and Microsoft) are planning to phase out their proprietary network protocols. To do this, the IP suite must support the facilities that one finds in AppleTalk or NetBIOS. This interest has added impetus to provide solutions within the IETF.
The facilities that are lacking are automatic host configuration and service discovery (both of which have already been discussed) and, additionally, name resolution without name servers and zero configuration multicast address allocation. The latter two features will be discussed in the section on ongoing work.
Zero configuration networking must operate under certain constraints. From these we can better understand the overarching goals as well as the hurdles that must be overcome to standardize this technology.
The primary motivation for zero configuration is ease of use. Ideally this means that adding IP hosts to the network will be as easy as plugging into a power socket. This creates the possibility of networking together devices for which no manual configuration is possible, ever, such as embedded controllers. It also facilitates commodification of IP-enabled devices.
There are two aspects to scalability.
The first is scaling up. Zero configuration networking protocols need to operate in a variety of networks. They may be used in isolation, where the network consists of only two IP connected hosts. Or they may be on a network with tens of thousands of systems (such as a high-tech vehicle with networked transducers all over the place). Zero configuration protocols cannot preclude deployment of networks with many hosts. That is not to say that these networks have to scale to be the size of the Internet. At a certain point it will make sense to add configuration and hire administrators to manage and plan network operations. Zero configuration protocols must present a scalability problem in configured networks (see below).
The other extreme is scaling down. Zero configuration protocols have to be extremely simple and require little computing and memory resources to run. That is because they will likely be implemented in constrained devices.
It is expected that hosts may sometimes be on zero configuration and other times be on configured networks. It is therefore vital that zero configuration protocols have a simple automatic mechanism to detect the transition between the two states. Further, the transition has to be smooth. For example, service discovery and name resolution services have to obtain the same results whether zero configuration or configured protocols are available.
It may be the case that zero configuration protocols are always available for communicating with local hosts, using local names and addresses, as long as this doesn't interfere with communication and operation of fully configured networks.
It is vital that system administrators be able to turn off zero configuration behavior in certain circumstances.
It is also advantageous if zero configuration protocols can become available in the case when network services fail. This increases the robustness of the network.
The use of zero configuration protocols cannot make the IP protocol suite less secure than it would be otherwise. Since automatic host configuration allows any IP host to easily make use of network resources without any administrative intervention, this is challenging. New wireless network access technology makes physical security impossible. In an apartment building, neighbors would be able to eavesdrop on each other's data communications and perhaps even use their unprotected resources without permission. It might be possible to turn down the volume of a neighbor's network-enabled radio, for instance, if safeguards are not in place to prevent it.
A lot of software exists for IP hosts that runs over traditional IP networking system software. This software should run the same way "over" zero configuration protocols. The system interfaces that exist today should not need to be changed -- only the underlying networking system software. Equally important, the behavior of zero configuration networking protocols should be the same as their "configured" network equivalent.
Zero configuration networking should not be all or nothing. A network may, for example, have a DHCP server but lack a DNS server. In that case, host configuration will be available, but hosts will be able to use the zero configuration protocol for DNS name resolution.
The Zero Configuration Working Group in the IETF has been chartered to produce a requirements specification for zero configuration networking for both IPv4 and IPv6. These requirements will set the goals for the subsequent product, a profile document. These documents are works in progress. Links can be found to them off of the ZEROCONF Working Group charter page.
The zero configuration profile is in a sense a supplement to the document discussing host requirements for IP. Section 1.2.4 of that document reads:
It would be ideal if a host implementation of the Internet protocol suite could be entirely self-configuring. This would allow the whole suite to be implemented in ROM or cast into silicon, it would simplify diskless workstations, and it would be an immense boon to harried LAN administrators as well as system vendors. We have not reached this ideal; in fact, we are not even close.
The profile document will list standards for tracking IETF protocols and indicate whether their use is recommended, required, or mandatory. The profile document will also specify mechanisms for transitioning from zero configuration to configured behavior for each protocol area under consideration.
The working group is currently working to produce the requirements specification and making good progress.
The zero configuration protocol areas under consideration for the working group are:
The current understanding of the requirements and initial ideas for the profile document are summarized below.
The requirements include the ability to configure the essential parameters described above as well as a unique address. Address autoconfiguration for IPv6 satisfies these requirements. There is ongoing work on address autoconfiguration for IPv4. Eventually a specification will be published by the IETF.
An open issue in automatic host configuration is handling two or more zero configuration networks "fusing together." In that case, claim-and-defend protocols are insufficient: reclaiming is required to maintain uniqueness. A claim-and-defend protocol requires a host to broadcast (or multicast) a claim, like "My address is 10.0.0.1." All other hosts have to defend their own claims, so if another host has already claimed that address, that must be detected, and the duplicate claims must be retracted. The complication is that the network definition (the periphery) is not static. Distinct "consistent" populations may merge, potentially creating conflicts that can be resolved only by a new round of claims every once in a while.
It is clear that DHCP will be used as the "transition" mechanism out of automatic host configuration mode, for IPv4 hosts to obtain dynamic configuration. For IPv6, the presence of IPv6 routers is sufficient to provide a further host configuration.
Service discovery requirements include the ability of clients to discover services without the need for prior configuration or any "service discovery" servers being present. Queries are sent via multicast by clients to discover servers on the network. Replies must be swift (i.e., after an acceptably short delay after a request is issued). The service discovery protocol must not cause broadcast storms or other unscalable behavior. (This is a real risk, as many existing service discovery protocols require an inordinate amount of network resources).
SLP can be used in IPv4 and IPv6 networks. SLP has its own mechanisms to transition from zero configuration peer-to peer-operation to a highly scalable client/server operation. All that is required is that an SLP "server" be deployed. All configuration of SLP agents is done automatically.
Although SLP is a standards track protocol in the IETF that meets the criteria of zero configuration service discovery requirements (as they are presently formulated), there is dissent. Other protocols are being developed or discussed that could be alternatives to SLP for service discovery in the zero configuration profile.
The zero configuration requirement for this protocol area is to be able to resolve domain names using multicast in the absence of a DNS server. In order to support this requirement, an IP host will also have to listen for such requests and respond when the request corresponds to the host's own name. This mechanism will form the basis of a claim-and-defend mechanism allowing hosts to select unique domain names and maintain their uniqueness over time. Multicast is required so that requests can span the entire zero configuration network.
There are two ongoing efforts in the IETF related to this function. The first is multicast DNS, which involves multicasting DNS queries to the network instead of unicasting them to a DNS server. The second is an Internet control message protocol (ICMP) based multicast name resolution protocol called "IPv6 Node Information Queries." This protocol is being developed in the IPNG Working Group, and a reference to the current version of the specification is available from the charter page.
In both cases, each host would run a "stub" naming service, which would listen for requests for the host's own name and respond. The reason this name service is considered a stub is that the host's name service would neither provide name-to- address resolution for other hosts nor necessarily participate in the hierarchical global DNS at all.
In any case, it is clear that when a DNS server is present, it should be used (at least for names outside of the zero configuration network). It is not clear how the transition from zero configuration name resolution to normal DNS operation will work.
There has been some discussion of using multicast DNS in conjunction with DNS SRV resource records for service discovery. There is debate over whether this protocol would present scalability problems and whether it has enough features to provide an adequate service discovery protocol.
Automatic multicast address allocation allows a host to obtain an address allocation for a multicast group for the host's own purposes. This prevents different applications from colliding, that is, using the same multicast group for different purposes. A multicast address allocation architecture is being developed for allocation of global, administratively local addresses.
The list of requirements for this protocol is still under development, but it is clear that it will involve a claim-and-defend mechanism similar to IP address autoconfiguration. It is not clear whether a new address space (the zero configuration multicast address scope) is necessary.
Just as DHCP is the obvious transition mechanism from IP address autoconfiguration, multicast address dynamic allocation profile (MADCAP) is the obvious protocol for making a transition from automatic to dynamic multicast address allocation.
Security requires configuration; there is no getting around that fact. Zero configuration networking security is an oxymoron.
Security configuration constitutes a transition from zero configuration operation. It is such a vital transition that it must be worked out in detail, so that every protocol in the zero configuration profile will have a "required to implement" security configuration component. Ideally, this configuration will be simple, and one solution (indeed, one configured item) will work for all zero configuration protocols.
An increasing number of zero configuration features will be available in networking products. As IP host software becomes cheaper and consumer devices include the software, these features will make a tremendous, though silent, impact. Ideally, the owners and operators will not know there is a data network at all, in the same way they are oblivious to the power network.
IP networks will be possible in settings where they are currently unthinkable, such as inside computers or in emergency shelters (where there's no time, let alone expertise, to configure a network).
The challenge for the future is to push zero configuration as far as possible. It is theoretically possible to deploy extremely large networks that use zero configuration protocols. Large networks include routers to interconnect smaller networks. These routers currently requires considerable configuration. Perhaps that too will be addressed with automatic configuration mechanisms.
As data communication becomes more pervasive, network security will change in status. Currently it is a preventive measure with no apparent positive gain. Since one normally isn't aware of attacks, network security seems almost superfluous. That will not be the case if networking touches every aspect of our lives. It has become inconceivable to live without a lock on the doors of our homes to prevent theft. In the future we will have to secure items within our homes, as thieves won't necessarily have to physically enter our homes to make off with or misuse our belongings.
 The status of the IP suite is given in Reynolds, J., and Braden, R., Editors, "Internet Official Protocol Standards," RFC 2500, June 1999.
 Sidhu, G., Andrews, R., and Oppenheimer, A., "Inside Appletalk, Second Edition," Addison Wesley, 1990.
 While there were clearly many good technical reasons for IEEE 1394, USB, BlueTooth and other protocols, it is clear that IP was not an option, since it doesn't provide automatic addressing and operation without a name server.
 Mockapetris, P., "Domain Names: Concepts and Facilities," RFC 1034, November 1987.
 Droms, R., "Dynamic Host Configuration Protocol," RFC 2131, March 1997.
 Deering, S., and Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460, December 1998.
 Thomson, S., and Narten, T., "IPv6 Stateless Address Autoconfiguration," RFC 2462, December 1998.
 Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998.
 Gulbrandsen, A., Vixie, P., and Esibov, L., "A DNS RR for Specifying the Location of Services (DNS SRV)," RFC 2782, February 2000.
 Guttman, E., Perkins, C., Veizades, J., and Day, M., "Service Location Protocol, Version 2," RFC 2608, June 1999.
 Wahl, M., Howes, T., and Kille, S., "Lightweight Directory Access Protocol (v3)," RFC 2251, December 1997.
 Howard, L. "An Approach for Using LDAP as a Network Information Service," RFC 2307, March 1998.
 The protocol is partially documented in Troll, R., "DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients," RFC 2563, May 1999. A formal specification for address autoconfiguration for IPv4 has not yet been published.
 Auerbach, K., "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods," RFC 1001, March 1987.
 The multicast address allocation architecture is still a work in progress. The current specification can be seen by visiting the Multicast-Address Allocation Working Group charter page.
 Zero Configuration Working Group charter page.
 Braden, R., Editor, "Requirements for Internet Hosts: Communication Layers," RFC 1122, October 1989.
 Multicast DNS is first mentioned on page 76 of Braden, R., "Requirements for Internet Hosts: Application and Support," RFC 1123, October 1989.
 IPNG Working Groupcharter page.
 Hanna, S., Patel, B., and Shah, M., "Multicast Address Dynamic Allocation Protocol (MADCAP)," RFC 2730, December 1999.
Erik Guttman is a Senior Staff Engineer in the Sun Microsystems Laboratories Networking and Security Center and lives in Germany. His main professional interests are automatic network configuration and practical network security. He is the chairman of the Service Location Protocol IETF Working Group and cochairman of the Zero Configuration IETF Working Group.