Autoconfiguration for IP Networking: Enabling Local Communication

On the Wire Autoconfiguration for IP Networking: Enabling Local Communication

Erik Guttman Sun Microsystems, Germany

It would be ideal if a host implementation of the devices via IP. In this tutorial, I examine the back- Internet protocol suite could be entirely self-con- ground, current status, and future prospects for figuring. This would allow the whole suite to be zero configuration networking. implemented in ROM or cast into silicon, it would simplify diskless workstations, and it would be an Zero Configuration Networking immense boon to harried LAN administrators as Automatic configuration parameters have different well as system vendors. We have not reached this properties from those assigned by static and ideal; in fact, we are not even close. —RFC 11221 dynamic configuration. They are ephemeral; they will likely be different each time they are obtained P hosts and network infrastructure have histor- and might even change at any time. Automatical- ically been difficult to configure—requiring net- ly configured hosts actively participate in assign- I work services and relying on highly trained net- ing and maintaining their configuration parame- work administrators—but emerging networking ters, which have only local significance. Autonomy protocols promise to enable hosts to establish IP net- from network services implies that hosts must networks without prior configuration or network ser- work configuration. vices. Even very simple devices with few computing In direct contrast, normal IP configuration is resources will be able to communicate via standards- persistent (especially for servers), or at the very track protocols wherever they are attached. Current least, stable. The IP protocol suite aims at scala- IETF standardization efforts, such as those in the bility, especially with respect to configuration. Zeroconf working group, aim to make this form of Addresses and names often have global signifi- networking simple and inexpensive. cance, which has proven essential for enabling Hosts that are permanently connected to an Internet growth. Obtaining and managing global administered network are usually assigned static addresses and names requires a great deal of network configurations by network administrators. administrative work, however. These processes are Other hosts are attached to administered networks not at all automatic and likely never will be. (such as corporate local-area networks or dial-in Despite these differences, the essential zero con- accounts) using dynamic network configuration. figuration networking protocols really imply In these, all necessary parameters are assigned to changes to only the lower layers of IP-enabled the host by a network configuration service, which devices. (See the sidebar “IP Host Layering” for an also requires configuration. In many situations— introduction to the terminology required for dis- impromptu meetings, administered network mis- cussing automatic configuration.) configurations, or network service failures, for Existing network-based applications will work example—establishing an IP network is desirable, without modification over enhanced network ser- but administering it can be impractical or impos- vice and application layers using standard interfaces. sible. In these cases, automatic network configu- Indeed, users should not even be aware that the net- ration of parameters is valuable for hosts. The IETF work service layer has been configured automati- Zeroconf WG’s real goal is to enable direct com- cally rather than statically or dynamically. munications between two or more computing Four functions will benefit from zero configu-

IEEE INTERNET COMPUTING 1089-7801/01/$10.00©2001 IEEE http://computer.org/internet/ MAY • JUNE 2001 81 Tutorial IP Host Layering features. Adopting emerging zero configuration Layering provides the foundation for numerous, stable extensible comput- protocol standards will let us retire proprietary net- ing platforms. Figure A depicts the pervasive layered architecture, often working—a move that has broad support. Even net- called the IP stack, which is used for Internet hosts.This roughly corre- work equipment vendors uniformly accept that sponds to the OSI seven-layer model.1 The figure excludes the OSI pre- proprietary network protocols have seen their day sentation and session layers. IP applications implement data presentation and should be replaced by IP standards. functions themselves. Session features such as encryption, compression, or For reasons of scalability and reducing impact persistence between protocol transactions are added in an ad hoc fashion on existing networks, the zero configuration pro- at various layers. tocols’ effect on the overall network must be lim- Each layer provides services to the layer above it through standard inter- ited. The algorithms used for zero configuration faces. If lower layers provide the same functionality using the same inter- protocols generally use multicast. In practice, these faces, services can be implemented in different ways; new mechanisms protocols are limited to either a single network link defined at the network services layer can thus support unmodified exist- (that is, routers do not forward these protocol mes- ing applications.Avoiding changes in upper layers eases the adoption of new sages) or to a set of networks (where some routers Internet technologies. Network service layer enhancements that require are configured as boundaries, over which protocol client applications (such as e-mail readers and Web browsers) to be upgrad- messages are not forwarded). ed are not broadly adopted. Each layer could be automati- Defining an Approach cally configured. In practice, the less Those working on IETF zero configuration proto- configuration required, the better, Application col standardization (currently in the Zeroconf, Ser- because simpler technology works vice Location Protocol, DNS Extensions, and IPng Transport service more predictably and eases deploy- working groups) have considered two main ment. The transport service, link Network service approaches to overcoming the differences between control, and media access layers configured and automatic operation. rarely require configuration in Link control The first strategy requires transitions between Internet hosts. By contrast, the local and global configuration and has been application and network service explored through consumer-oriented operating layers nearly always require config- Physical network system software since 1998. This strategy implies uration in order to operate at all. that hosts would support automatic configuration only for as long as they lacked global configura- References Figure A. Internet host layering. Zero tion. The two modes are exclusive, and the pres- 1. A.Tanenbaum, Computer Networks, Sec- configuration protocols will be implemented ence of a dynamic configuration service requires ond Edition, Prentice-Hall, Englewood at the application and network service a transition from automatic (local) to dynamic Cliffs, N. J., 1989. layers of the Internet protocol stack. (global) configuration. An example of this transition strategy is the network interface autoconfiguration protocol ration protocols, in the context of both IPv4 and adopted for desktop operating systems from Apple IPv6. With no modification to existing interfaces, and Microsoft. This protocol (which the IETF has zero configuration protocols will improve name- not yet standardized) enables a host to simply to-address translation (at the application level) and choose an unassigned IP address from a reserved IP interface configuration (at the network level). range. The host then attempts to obtain (global) IP Functions previously unavailable to IP hosts will configuration parameters from the network via the introduce new interfaces: service discovery at the Dynamic Host Configuration Protocol.2 The host application layer and multicast address allocation issues periodic DHCP requests, which will eventu- at the network layer. ally succeed in reaching a DHCP server if one ever These additional services will not disrupt exist- becomes available on the network. Once a DHCP ing applications. They will “raise the bar” by pro- server responds and offers IP configuration para- viding additional features long absent from the meters, these replace automatic configuration. Internet protocol suite, but (in the case of service This mechanism works fine for clients discovery) available in proprietary network proto- employing common client-server protocols col suites from Apple, Microsoft, and Novell. (See because very few make use of long-duration the sidebar “Early Autoconfiguration Efforts”, next connections. Individual network application page). These proprietary protocols continue to be operations result in distinct transactions even used only because of their ease-of-configuration when connections fail. If the client host experi-

82 MAY • JUNE 2001 http://computer.org/internet/ IEEE INTERNET COMPUTING On the Wire Early Autoconfiguration Efforts ences network reconfiguration, applications simply establish new connections. The Internet Protocol suite emerged as the data communication standard for If a server’s configuration changes, however, a network run by and for researchers.Their design goals were primarily inter- recovery is not so easy: Client applications cease operability, extensibility, and scalability. IP networks achieved growth and to function if they cannot find a server. Servers enabled global communication by using unique parameters (for naming, with dynamic addresses can only be located via addressing, and so on) and mechanisms for delegating their administration. a dynamic service discovery protocol, and very At the same time, network software (and equipment) vendors were few IP-based applications currently employ ser- developing proprietary protocol suites that stressed ease of use and vice discovery. deployment. The success of Apple’s AppleTalk,1 Novell’s IPX,2 and Server address reconfiguration can break server Microsoft’s NetBIOS/SMB3 arose from their automatic address configu- software, which typically binds to a (presumably ration capabilities, decentralized service discovery, and naming functions, immutable) address to accept incoming messages. which facilitated local communication and sharing of resources such as Moreover, when a server reconfigures via DHCP, it files and printers. can no longer communicate with clients that have Zero configuration will bridge the gap between these two distinct fam- not yet reconfigured. Conversely, if DHCP config- ilies of protocols. IP-enabled hosts and applications will be able to take ures client systems and then fails to configure a advantage of mechanisms similar to those provided by AppleTalk.It is not server (if the DHCP server becomes unreachable, possible, however,to completely automate the configuration of the Inter- for example), the clients with global parameters net. Zero configuration protocols allow local communication on networks will be unable to communicate with the server, of a limited scale (defined functionally rather than absolutely).When auto- which still has only local, automatic configuration. matic configuration no longer suffices, administrators must plan and deploy Finally, some extremely simple devices might scalable configured networks. support only local IP configuration and would be unable to communicate with hosts reconfigured References using DHCP. Very cheap appliances could be devel- 1. S. Gursharan et al., Inside AppleTalk,Addison-Wesley, Reading, Mass., 1990. oped to support remote monitoring and control 2. IPX RIP and SAP Router Specification, version 1.30, Part Number 107-000029-001, Novell services, for example, and clients would need local Inc., LOCATION?,May 1996. IP configuration in order to communicate with 3. SMB File Sharing Protocol Extensions 3.0, version 1.09, Microsoft Networks, Nov. 1989. these devices at all, unless additional network infrastructure is available. Given the problems that arise from IP configu- which the address will be used. A link-local ration transition, the Zeroconf WG now discour- address, for example, is configured to be unique ages the transitioning approach. Hosts should on the link. Address autoconfiguration require- either use automatic configuration alone, or in ments include allowing a host to addition to dynamic or static configuration. Two hosts attached to the same network implementing configure its interfaces with unique addresses; zero configuration protocols will be able to com- determine which subnet mask to use (the subnet municate regardless of whether DHCP or any other mask identifies the network address and, among servers are available. They will only need to recon- other things, allows an IP stack to determine figure their addresses (or possibly their names) in whether it can deliver a datagram directly); the event of a conflict. detect duplicate address assignment; and cope with collisions. Emerging Solutions The Zeroconf WG has defined requirements for The current IPv4 link-local autoconfiguration four zero configuration networking protocol areas. specification4 is backward compatible with Apple For further explanation and details, please refer to Macintosh and Microsoft Windows operating sys- the draft requirements document.3 Current IETF tem software with one exception: It recommends efforts have produced standards, or soon will, in maintaining autoconfigured addresses (even if an each of the following. interface is also configured with a global IPv4 address) rather than transitioning from local to Address Autoconfiguration global. The current specification also includes The first protocol area is address autoconfigura- guidelines to help disambiguate link-local address- tion. For an IP stack to deliver IP messages, each ing for hosts with more than one IP-enabled inter- communicating endpoint (source and destination) face. Link-local autoconfiguration for IPv6 is an requires a unique IP address within the scope in IETF draft standard.5

IEEE INTERNET COMPUTING http://computer.org/internet/ MAY • JUNE 2001 83 Tutorial

Host 1 Host 3 Host 4 determining the name associated with an IP Host 2 address. A B C D E Wireless link Wired link This latter feature facilitates communication with the client in the future and enables the server to Figure 1. IP address autoconfiguration. Host addresses (A through E) generate human-readable log entries. are unique for each shared wired or wireless link. Link-local multicast DNS6 is defined for use over IPv4 and IPv6 to locally resolve names using the "Molly" "Sally" DNS protocol, but without requiring a dedicated DNS IP host IP host server. The node information query protocol can also be used for name-to-address translation over IPv6.7 Figure 2 illustrates name-to-address resolution Client application using multicast DNS. A client application requests the address corresponding to the name “Sally,” mDNS resolver which can be translated to an address by issuing a DNS request to a well-known multicast IP address. Address X Each host listens for these requests and responds if (1) Query Name = "Sally" (2) Reply the interface on which the multicast DNS request Type = A (address) Address = X was received is configured with the name requested. Figure 2. Multicast DNS protocol interaction.The client obtains the IP address for the host named “Sally”by issuing a request to a well- Service Discovery known multicast address and awaiting a reply. The third zero configuration protocol area is service discovery. Clients should be able to discover services on the network without prior configura- Each interface of each device in Figure 1 can tion, and without any administered configuration obtain and maintain a unique address assignment. management services (such as directories) on the Host 1 and host 2 share a wireless link, upon which network. Furthermore, the service discovery pro- addresses A and B are distinct. Hosts 2, 3, and 4 tocol must not cause broadcast storms or other share a wired link upon which addresses C, D, and unscalable behavior. (Some existing service dis- E are unique. covery protocols—most notably the Service Adver- To reduce confusion, Host 2 will not allocate tising Protocol from the IPX protocol suite—require addresses that conflict with an assigned link-local inordinate network resources.) address on any link to which it is attached. Host Some services, such as generic Web proxies, 2 will not attempt to allocate address A on the DNS servers, or SMTP relays, are indistinct; that is, wired link because A has already been allocated any server of that type will perform the exact same on the wireless link. Because host 2 has no con- function. Other services, such as nonreplicated trol over others, such as hosts 1 and 3, address A databases, file servers, or IP-enabled printers, are could be the same as address D. Such a situation distinct in that each instance of the service is could lead to ambiguities for host 2. This compli- unique. The ability to distinguish between servers cates support for link-local address autoconfigu- of the latter type lets a client discover the server it ration of hosts with multiple interfaces. needs, rather than all the servers it can communicate with (most of which will be useless to it). Name-to-Address Translation The IETF has standardized two mechanisms for The second zero configuration protocol area is service discovery over IP networks. Version 2 of name-to-address translation. IP applications typi- the service location protocol8 (SLP) uses adminis- cally identify endpoints on the network by name trative-scope multicast because it was designed to rather than by address. This provides operational scale up to a single administration, (usually com- stability when an endpoint’s address changes prising an entire site, such as a campus or enter- because its name remains the same. A zero con- prise network). Most other zero configuration pro- figuration protocol for name-to-address transla- tocols are being defined for use with link-local tion requires mechanisms for: multicast. SLP provides service discovery both by service type and attribute, so a client can find a obtaining the IP address associated with a distinct server by specifying required characteris- name, and tics. SLP is defined for use over IPv4 and IPv6.9 (I

84 MAY • JUNE 2001 http://computer.org/internet/ IEEE INTERNET COMPUTING On the Wire

discussed SLP in greater detail in an earlier IC IP-based service "Foo" Client application IP-based service "Bar" article.10) The second IETF service-discovery mechanism SLPv2 service agent SLPv2 user agent SLPv2 service agent is the DNS SRV Resource Record,11 which allows clients to look up services via DNS. Clients specify the type of service, the transport protocol, and the (1) Service request: "Bar" (2) Service reply: URL domain name to look up. The reply to this query supplies a list of hosts that match the request. Figure 3. Service discovery using SLPv2. A client application requests Figure 3 illustrates service discovery using SLPv2. the location of a service “Bar,” and SLPv2 service agents respond with The client application requests the location of a ser- a service reply if they are advertising services that match the request. vice “Bar,” including the type of service and service attributes required. The SLPv2 user agent multicasts this request on behalf of the client. SLPv2 service resolution, and service discovery) remain insecure. agents respond with a service reply if they are adver- This has kept these protocol suites simple, but has tising services that match the request. also left them vulnerable to attack. Autoconfiguration can be dangerous. Without Multicast Address Allocation proper security mechanisms in place, anyone with The fourth protocol area the working group iden- access to a LAN can easily subvert the zero con- tified is multicast address allocation. Some multi- figuration protocols used there. As wireless net- cast-based applications need to obtain a unique working technology deployment and shared- multicast address to prevent other applications (or access networks expand across video cable, power sessions based on the same application) from con- line, and other residential-access media, unautho- flicting with them. A multicast address conflict can rized access becomes increasingly likely. cause applications to fail in an analogous way to Running counter to the basic goals of zero con- two hosts configured with the same IP address: figuration networking, security cannot be auto- Communication from the two distinct sessions matically configured, but it should still be simple could be delivered to incorrect destinations. to administer. The Zeroconf WG has identified a The zeroconf multicast address allocation pro- set of requirements to ensure that operation using tocol (ZMAAP)12 allows applications to zero configuration protocols will be no less secure than using their correlate configured IETF proto- allocate unique addresses and maintain them cols.3 Specific mechanisms for simply configuring over time; IP hosts to operate securely (fulfilling these prevent reallocation of assigned addresses; and requirements) have been discussed, but no speci- be notified of multicast allocation collision. fication has yet been proposed. An important area for further development is These requirements differ from those for address secure remote access to autoconfigured networks. autoconfiguration because multicast addresses are Many home networking products already offer a shared resource. In many cases, different proprietary solutions for remotely controlling or processes present across the network need shared monitoring devices in private networks. It might control of the allocation. The second and third be useful to establish a standardized gateway ZMAAP requirements enable any process to pro- mechanism that gives hosts on remote networks long a session and to discover whether the session access to locally configured devices. Further study is still valid. will also be required for creating easily adminis- The current version of a proposed protocol spec- tered and interoperable mechanisms for config- ification that fulfills these requirements can be uring security parameters in a group of devices. found at the Zeroconf working group page. Network Administration Securing Zeroconf Protocols Because zero configuration protocols allow hosts Proprietary autoconfiguration protocols provide to be configured automatically and administra- no mechanisms for securing their basic operation. tively at the same time, network administrators AppleTalk, IPX, and NetBIOS networking security could face several new issues. mechanisms provide applications with user and group-oriented access control, but the automatic IP hosts using locally assigned addresses and configuration protocols (address assignment, name names might be accessible only on a single

IEEE INTERNET COMPUTING http://computer.org/internet/ MAY • JUNE 2001 85 Tutorial

LAN. This contrasts with hosts configured with As I mentioned before, security mechanisms will addresses with a greater scope, such as global- require additional investigation, and new network ly unique IP addresses, which (ideally) are administration challenges will likely arise, but IETF accessible from any network in the Internet zero configuration protocols will soon be avail- (ignoring subtleties like firewalls). able; in fact, many already are. Administrators today expect network commu- nications to be constrained to hosts they con- References figure and control. In the future, much of the 1. R. Braden, “Requirements for Internet Hosts—Communica- communication on individual links might be tion Layers,” IETF RFC 1122, Oct. 1989; available at between devices with entirely local parameters— http://www.rfc-editor.org/rfc/rfc1122.txt. sometimes between devices that will never 2. R. Droms, “Dynamic Host Configuration Protocol,” RFC obtain administratively assigned parameters. 2131, Mar. 1997; available at http://www.rfc-editor. On networks without DHCP, users expect org/rfc/rfc2131.txt. administrators to enable networking through 3. M. Hattig, “ZeroConf Requirements,” Internet draft, Zero- configuration assignments. This will change as conf WG, Mar. 2001; work in progress. users become accustomed to automatically 4. S. Cheshire and B. Aboba, “Dynamic Configuration of IPv4 configured networks. Link-local Addresses,” Internet draft, Zeroconf WG, Mar. Users will want access to link-local configured 2001; work in progress. services from anywhere on the network. This 5. S. Thomson and T. Narten, “IPv6 Stateless Address Auto- will require either additional configuration for configuration,” RFC 2462, Dec. 1998; available at the services or application-layer gateways, http://www.rfc-editor.org/rfc/rfc2462.txt. proxies, or a more complex strategy involving 6. L. Ebisov et al., “Multicast DNS,” Internet draft, DNSEXT remote access to the network where link-local- WG, Nov. 2000; work in progress. only services reside. 7. M. Crawford, “IPv6 Node Information Query,” Internet draft, IPNGWG WG, Aug. 2000; work in progress. Zero configuration protocols will likely simplify 8. E. Guttman et al., “Service Location Protocol, Version 2,” network administration by reducing problems RFC 2608, June 1999; available at http://www.rfc-editor. with setting up and operating IP hosts for local org/rfc/rfc2608.txt. communication. At the same time, hosts will 9. E. Guttman, “Service Location Protocol Modifications for potentially have twice as many configurations IPv6,” Internet draft, Svrloc WG, Feb. 2001; work in progress. (local and global), which will give rise to com- 10. E. Guttman, “The Service Location Protocol,” IEEE Inter- plex situations. I have explored many of the net Computing, vol. 3, no. 4, July 2000, pp. 71-80. architectural issues of zero configuration net- 11. A. Gulbrandsen et al., “A DNS RR for specifying the loca- working further elsewhere.13 tion of services (DNS SRV),” RFC 2782, Feb. 2000; available at http://www.rfc-editor.org/rfc/rfc2782.txt. Future Prospects 12. O. Catrina et al., “Zeroconf Multicast Address Configura- The IETF will publish the zero configuration pro- tion Protocol (ZMAAP),” Internet draft, Zeroconf WG, tocol requirements specification and the emerging March 2001; work in progress. standards-track protocols soon. This will herald 13. E. Guttman, “Zero Configuration Networking,” Proc. INET the development of simple interoperable IP- 2000, Internet Society, Reston, VA; available at http:// enabled devices and greatly increase LAN stabili- www.isoc.org/inet2000/cdproceedings/3c/3c_3.htm. ty and usability. There is also discussion of creating a profile to To locate the latest version of an Internet draft, refer to IETF specify the set of zero configuration protocols that working group information pages at http://www.ietf.org/ conforming hosts implement. This approach, html.charters/wg-dir.html. inspired by the IP host requirements specification,1 would motivate vendors to implement a single set Erik Guttman is a senior staff engineer at Sun Microsystems, of protocols. The IETF generally avoids recom- living in Germany. His main professional interests are auto- mending or requiring specific protocols (nearly all matic network configuration and practical network secu- IETF standards are classified as elective). IP host rity. He is chair of the Service Location Protocol and requirements were published to describe prior cochair of the Zero Configuration IETF working groups. experience rather than to prescribe a future solu- tion. Thus, it is still unclear whether the Zeroconf working group will produce the profile document. Readers can contact the author at [email protected].

86 MAY • JUNE 2001 http://computer.org/internet/ IEEE INTERNET COMPUTING