Zeroconf WG M. Hattig Internet Engineering Task Force Editor INTERNET DRAFT Intel Corp. Expires March 2001 September 18, 2000 Zeroconf Requirements draft-ietf-zeroconf-reqts-05.txt Status of This Memo This document is a submission by the Zeroconf Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the zeroconf@merit.edu mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC 2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract Many common TCP/IP protocols such as DHCP [RFC 2131], DNS [RFC 1034, RFC 1035], MADCAP [RFC 2730], and LDAP [RFC 1487] must be configured and maintained by an administrative staff. This is unacceptable for emerging networks such as home networks, automobile networks, airplane networks, or adhoc networks at conferences, emergency relief stations, and many others. Such networks may be nothing more than two isolated laptop PCs connected via a wireless LAN. For all these networks, an administrative staff will not exist and the users of these networks neither have the time nor inclination to learn network administration skills. Instead, these networks need protocols that require zero user configuration and administration. This document is part of an effort to define such zero configuration (zeroconf) protocols. Hattig [Page 1] Internet Draft draft-ietf-zeroconf-reqts-05.txt Sept 2000 Before embarking on defining zeroconf protocols, protocol requirements are needed. This document states the zeroconf protocol requirements for four protocol areas; this document does not define specific protocols. The four areas are: IP host configuration, host name to IP address resolution, IP multicast address allocation, and service discovery. The requirements for these four areas result from examining everyday use or scenarios of these protocols. Table of Contents 1 Introduction................................................2 1.1 Key words.................................................3 1.2 Reading This Document.....................................3 1.3 Zeroconf Coexistence......................................3 1.4 Scalability...............................................3 1.5 Routable Protocol Requirement.............................3 1.6 Conflicts and State Changes Requirement...................4 2 Scenarios & Requirements....................................4 2.1 IP Host Configuration.....................................4 2.2 Host name to IP Address Resolution Scenarios..............5 2.3 IP Multicast Address Allocation Scenarios.................7 2.4 Service Discovery Scenarios...............................9 3 Security Considerations....................................11 3.1 IPv6 Considerations......................................12 4 IANA Considerations........................................13 5 Full Copyright Statement...................................13 6 Acknowledgements...........................................13 7 References.................................................14 1 Introduction A zeroconf protocol is able to operate correctly in the absence of either user configuration or external configuration from infrastructure services such as conventional DHCP [RFC 2131] or DNS [RFC 1034, RFC 1035] servers. Zeroconf protocols may use configuration, when it is available, but do not rely on it being present. The benefits of zeroconf protocols over existing configured protocols are an increase in the ease-of-use for end-users and a reduction of the infrastructure necessary to operate. This document discusses requirements for zeroconf protocols in four areas: - IP host configuration - Host name to IP address resolution - IP multicast address allocation - Service discovery Hattig [Page 2] Internet Draft draft-ietf-zeroconf-reqts-05.txt Sept 2000 Security considerations are also discussed. 1.1 Key words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 1.2 Reading This Document Introduction, Scenarios & Requirements, and Security Considerations are the major sections of this document. The Scenarios & Requirements section walks through protocol scenarios and then lists the requirements of the protocol needed to accomplish the scenario. The Security Consideration section lists security issues with zeroconf protocols. Requirements dispersed throughout this document begin with the text "Requirements:" or "Requirement:" on a single line, which is followed by a bulleted list of requirements. 1.3 Zeroconf Coexistence It is not necessary to always use zeroconf protocols in all four areas. For example, it might make sense on some networks to provide a DHCP server for configured address allocation, but perform host name to IP address resolution using a zeroconf protocol. 1.4 Scalability Zeroconf protocols are not intended to replace or compete with non-zeroconf protocols deployed in today's large-scale networks. Instead, zeroconf protocols are expected to operate in small networks. As a network grows, the administrators of that network should consider migrating away from zeroconf protocols before scalability becomes an issue. That being said, a zeroconf protocol SHOULD be scalable. 1.5 Routable Protocol Requirement Zeroconf protocols have no specific topological restrictions or requirements; networks may consist of multiple IP subnets or a single IP subnet; networks may be isolated or connected to larger networks (e.g. Internet). However, there is a conditional requirement. The condition exists if a protocol is targeted to Hattig [Page 3] Internet Draft draft-ietf-zeroconf-reqts-05.txt Sept 2000 operate in multiple IP subnet topologies. The requirement is the protocol MUST be routable. For example, a protocol MUST use IP multicast and not use IP broadcast. Requirement: - If a protocol is to operate in multiple IP subnet topologies, the protocol MUST be routable. 1.6 Conflicts and State Changes Requirement Spurious topology changes or other events such adding and removing hosts may cause conflicts and state changes within a protocol. Zeroconf protocols must be able to resolve conflicts and state changes caused by topology changes or other events. The scenario in the 2.1.2 Bridge Installed section is the only scenario that illustrates the need for this requirement, thus the below require is duplicated in section 2.1.2. However, this requirement applies to all protocol areas. Requirement: - MUST resolve conflicts and state changes in a timely manner. 2 Scenarios & Requirements This section lists scenarios that lead to zeroconf protocol requirements. A subsection exists for each of the four protocol areas. Within each protocol area, terms and assumptions are followed by specific scenarios. The scenarios lead to a list of zeroconf protocol requirements. Each scenario is representative of many potential scenarios of which all yield an identical set of requirements. Each subsection ends with an IPv6 considerations section. 2.1 IP Host Configuration In this document, configuration of an IP interface on a host is IP host configuration. IP host configuration always includes the configuration of an IP address and netmask; it may include a default route. IP host configuration is needed before almost any IP communication can take place. Terms: IP subnet - A single logical IP network that may span multiple link layer networks. internet - Multiple IP subnets connected by routers. network - context sensitive term that may apply to one or more the terms link layer network, IP subnet, or internet. Hattig [Page 4] Internet Draft draft-ietf-zeroconf-reqts-05.txt Sept 2000 IP host configuration scenarios are ICMP echo request/reply scenarios and a bridge install scenario. 2.1.1 ICMP Echo Request/Reply There are two brief ICMP echo request/reply scenarios. In the first, both the sender of the ICMP echo request and sender of the ICMP echo reply are on the IP subnet. In the second, the two senders are on different IP subnets within an internet. Requirements: - MUST determine the netmask for an IP subnet. - MUST have unique IP addresses within an IP subnet. - MUST have a default route (only for the internet scenario). - MUST have unique IP subnets within an internet (only for the internet scenario). 2.1.2 Bridge Installed This scenario starts with two completely operational standalone networks in which IP host configuration was completed with a zeroconf protocol on each network. These two networks become one after a newly installed bridge connects them. Individual hosts have no indication that the topology has changed. Topology changes may create any of the following problems: conflict among netmasks, conflict among default routes, duplicate IP addresses within an IP subnet, or duplicate IP subnets within an internet. Note that default routes and duplicate IP subnets are not issues for single IP subnet networks. Requirement: - MUST resolve conflicts and state changes in a timely manner. 2.1.3 IPv6 Considerations IPv6 allows a host to select an appropriate IP address, netmask, and find a default route, thus if a network is using IPv6, a zeroconf IP host configuration solution already exists. 2.2 Host name to IP Address Resolution Scenarios Host names allow users to refer to hosts by name instead of IP addresses. This is among the most fundamental, thus most important, usage paradigms in TCP/IP networking. Terms: host name - One or more strings separated by dots that identify a host. Hattig [Page 5] Internet Draft draft-ietf-zeroconf-reqts-05.txt Sept 2000 domain name - One or more strings separated by dots that identify a DNS domain. resolver - The host needing a name resolved to an IP address. Assumptions: - Support for multiple hosts with the same name is not a requirement. The scenarios for host name to IP address resolution are Web browsing and host name selection. 2.2.1 Web Browsing Users browsing the Web typically enter the name of a Web server. This name must be resolved to an IP address before any actual Web browsing occurs. The Web server may be within the same domain along with the resolver or may be part of some other domain. Requirement: - MUST resolve a host name to an IP address whether the name of the resolver and host name are in the same DNS domain or in different DNS domains. 2.2.2 Host Name Selection How the host gets its name (or Domain Name [RFC 1034]) is part of some other configuration protocol or user configuration, but is not part of this zeroconf scenario. This scenario only deals with learning of other host names on the network. The goal is to allow hosts to notify the user or configuration protocol that a duplicate name exists. Thus allowing the user or configuration protocol to attempt to use a different and hopefully unique name so that once operational, all devices within a domain have unique names. Requirement: - MUST allow a host to determine if it has a unique name. - MUST be able to determine if subsequently chosen names are unique, if the first name is not. - If a domain name and host name exist as separate configuration parameters, additional checks for uniqueness SHOULD be performed on the combined host name and domain name. 2.2.3 IPv6 Considerations Host name to IP address resolution protocols have no zeroconf related differences for IPv4 and IPv6. Hattig [Page 6] Internet Draft draft-ietf-zeroconf-reqts-05.txt Sept 2000 2.3 IP Multicast Address Allocation Scenarios IP Multicast is used for multi-receiver bulk-delivery applications, such as audio, video, or news to conserver bandwidth. IP multicast addresses range from 224.0.0.0 to 239.255.255.255. [RFC 2365] defined scopes are: node-local (unspecified) link-local (224.0.0.0/24) local (239.255.0.0/16) site-local (unspecified)_ organizational-local (239.192.0.0/14) global (224.0.1.0-238.255.255.255) A relative assignment is an integer offset from the highest address in the scope and represents a 32-bit address. For example, within the local scope, 239.255.255.0/24 is reserved for relative allocations. Source-Specific Multicast [SSM] addresses are 232.0.0.0 to 232.255.255.255. Assumptions: - The node-scoped and SSM addresses require no protocol or interaction between multiple hosts, thus are not mentioned further in this document. - Global and organizational scoped addresses are meant for networks of a greater scale than zeroconf protocols, thus are not mentioned further in this document. - Only local, link-local and site-local scopes are considered further in this document. - A boundary router, as described in [RFC 2365], is present to appropriately control multicast packets from entering and leaving multicast scope boundaries when necessary. Scenarios are scope enumeration, address allocation, and multiple sources. 2.3.1 Scope Enumeration Applications that leave the choice of scope up to the user require the ability to enumerate what scopes the host is operating within. In addition, services that are assigned relative addresses require the ability to enumerate what scopes the host is within, only then will a host be able to apply the relative address to a scope. Requirements: Hattig [Page 7] Internet Draft draft-ietf-zeroconf-reqts-05.txt Sept 2000 - MUST list which of the scopes (only local, link-local, or site- local) are available for hosts. - MUST list per-scope address ranges that may be allocated. 2.3.2 Address Allocation IP multicast address allocation (only local, link-local and site- local scopes only) requires coordination among hosts to avoid address collisions. To allocate an address, the host specifies a given scope, the number of addresses it desires, and the lifetime for which it desires. Address collision detection must span the entire scope respective to a particular address. The protocol should include the ability for a host to choose addresses, determine if they are in use, and if used, choose different addresses. Requirements: - MUST select a multicast address with a given scope and lease time. - MUST determine if the address has been allocated within a scope. - MUST defend an allocated address within a scope. 2.3.3 Multiple Source An intercom system inside a home is an example of a multiple source IP multicast application. In this type of application, several sources may be sending packets destined to the same IP multicast address. The first host that needs the IP multicast address allocates the address, but some other host may deallocate the address. This is because the first host may leave the multicast group before all the other host leave the group. This requires the last host using the IP multicast address to deallocate the IP multicast address. Requirements: - The first host to use the IP multicast address MUST allocate the address. - The last host to use the IP multicast address MUST deallocate the address. 2.3.4 IPv6 Considerations To date, no range has been reserved for dynamic allocation of source-specific addresses in IPv6. Hence, until such a range is reserved, dynamic allocation of Single-source addresses applies only to IPv4. To date, no range has been reserved for dynamic allocation of Link-scoped addresses in IPv4. Hence, unless such a range is Hattig [Page 8] Internet Draft draft-ietf-zeroconf-reqts-05.txt Sept 2000 reserved, dynamic allocation of Link-scoped addresses applies only to IPv6. 2.4 Service Discovery Scenarios Service discovery protocols allow users to select services and/or hosts by a name that is discovered dynamically, rather than the user having to know the name in advance and type it in correctly. Terms: process - A process is an implementation of an algorithm in software, hardware, or a combination of software and hardware. registry - A process that acts as an intermediary between discoverers and advertisers. Servers 'register' service advertisements and other pertinent (e.g. authentication info, announcement criteria) with registries, then the service may be discovered from the registry instead of from a server. registry update - A message that contains updated registry information. It may cause one or more registry entries to be deleted, added, or modified. server - A process that offers services to clients. A server can make its service(s) known to clients by means of a service discovery protocol. service - A service is a set of processes that utilize a particular protocol. Services range from printing to transferring a file to providing on-line pizza order and delivery. service advertisement packet - An unsolicited packet issued by a server or registry. The advertisement provides the service identifier and possibly service characteristics. service characteristics - Characteristics provide a finer granularity of description to differentiate services beyond just the service type. For example if the service type is printer, the characteristics may be color, pages printed per second, location, etc. service discovery protocol - A service discovery protocol enables a client (or clients) to discover a server (or servers) of a particular service. A service discovery protocol is an application layer protocol that relies on network and transport protocol layers. Hattig [Page 9] Internet Draft draft-ietf-zeroconf-reqts-05.txt Sept 2000 service identifier - A service identifier allows clients, servers, advertisers, discoverers, and registries to uniquely identify an instance of a service. service protocol - A service protocol is used between the client and the server after service discovery is complete. service solicitation - A request packet made by a client to obtain a response packet that indicates a service is present. The response may come from a service or a registry. service type - A service type allows clients, servers, advertisers, discoverers, and registries to uniquely identify a type of service such as a printer service. The scenarios are the discovery of a simple printer service and the discovery of a printer manager that consolidates many printer services. 2.4.1 Printer Service Networked enabled printers allow various networked clients to submit print jobs. A service discovery protocol MUST allow a printing clients to discover the printer service. This requires a service type as well as a service identifier to distinguish instances of a single service type. Printers vary in their characteristics such as location, status, dots per inch, drivers, etc. Discovering these characteristics SHOULD be part of the service discovery protocol. Alternatively, the client and server MAY negotiate the use of these characteristics after the service is found. Discovery SHOULD be possible by either the client actively soliciting the service or by the service advertising then the client passively listening for the advertisements. At least one method MUST be available. Once a client finds the printer, it can utilize different printing protocols such as raw tcp, lpd, and ipp. In the case of a printer service, a printer may be temporarily taken off-line for repair or everyday maintenance. This requires clients to be able to rediscover a service. Service discovery MUST complete in a timely (10s of seconds) manner. Requirements: - MUST discover via service identifier and/or service type. Hattig [Page 10] Internet Draft draft-ietf-zeroconf-reqts-05.txt Sept 2000 - SHOULD discover via characteristics or negotiate characteristics. - MUST allow discovery by client actively soliciting the service or by the client passively listening for advertisements. Both methods SHOULD be available. - MUST allow clients to rediscover a service. - MUST be independent from any particular service. - MUST complete in a timely (10s of seconds) manner. 2.4.2 Printer Manager A printer manager acts as a proxy to various printers. A printer manager improves scalability by providing a single location from which clients can find all printers. In addition, a printer manager provides an evolutionary path for service discovery deployment. For example, if an existing printer does not support the zeroconf service discovery protocol, the printer manager can use a legacy printer specific protocol to learn the existence and characteristics of a printer then expose that printer and its characteristics through the zeroconf service discovery protocol. This allows new printer clients that support the service discovery protocol to discover legacy printers that do not support the zeroconf service discovery protocol. If a print manager uses a registry to cache information about services and characteristics of services, clients MUST be able to extract data from the registry without knowledge that they are talking to a registry. In other words, the client and server sides of the service discovery protocol MUST NOT be any different whether a registry is involved or not. Registry updates that maintain the registry are required of the service discovery protocol but are optionally implemented for a particular service; this allows legacy protocols or the zeroconf service discovery protocol to update and maintain the registry. Requirements: - SHOULD allow for a registry to cache information about services and characteristics of services. - SHOULD allow for clients to extract data from the registry without knowledge that they are talking to a registry. - A registry MUST NOT be required. 2.4.3 IPv6 Considerations Service discovery protocols have no zeroconf related differences for IPv4 and IPv6. 3 Security Considerations Hattig [Page 11] Internet Draft draft-ietf-zeroconf-reqts-05.txt Sept 2000 This document is only concerned with security as it relates to the four protocol areas. While link layer encryption, firewalls, password/login protected applications, and user-privilege-access to resources are important security topics, these topics do not relate directly to the four protocol areas; thus, these topics are not considered by this document. Existing protocols have on-going work related to security; this document does not duplicate or attempt to extend this on-going work. The security threats considered are sniffing (data hijacking) and denial of service attacks. These attacks MUST be considered for each protocol area. Sniffing can be deterred with encryption of the data. This may require user to enter some type of key or may only require a simple answer to a question of whether a protocol should encrypt its data or not. Experience may show that encryption is not necessary as long as other security measures such as link layer encryption and firewalls are used. Denial of service attacks are the biggest threat to zeroconf protocols. These attacks include: - Hoarding: A host claims all available resources, whether it plans to use them or not. - Masquerading: A host responds to requests that it should not by masquerading as another host. - Antagonistic Server: A server could offer support for a critical service but intentionally misconfigure hosts on the network. Without having zeroconf protocols defined, it is difficult to analyze how these security threats may affect zeroconf protocols. It is known that most, and possibly all, the security methods require some user configuration. This presents a direct conflict with the basic principle of zeroconf protocols -- no configuration. This is an exception that zeroconf protocols must deal with. Hopefully, best known methods develop along with deployment experience. 3.1 IPv6 Considerations IPv6 has built in security, thus if a network is using IPv6, a security solution already exists. Hattig [Page 12] Internet Draft draft-ietf-zeroconf-reqts-05.txt Sept 2000 4 IANA Considerations No known IANA considerations arise from this document. 5 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 6 Acknowledgements Thanks to Peter Ford and Stuart Cheshire for hosting the NITS (Networking In The Small) BOF that was the catalyst to forming the Zeroconf Working Group. Thanks to Erik Guttman and Stuart Cheshire for forming and chairing the Zeroconf Working Group, which is responsible for this document. Thanks to Erik Guttman for providing key input to the service discovery and the security sections. Thanks to Dave Thaler for providing key input to the IP multicast address allocation sections. Hattig [Page 13] Internet Draft draft-ietf-zeroconf-reqts-05.txt Sept 2000 Thanks to Stuart Cheshire for providing key input to the introduction and IP host configuration sections. Additional recognition goes the following people for their influential contributions to this document and its predecessors: Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob Quinn, John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl Auerbach, Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland, and Bernard Aboba. Editor: Myron Hattig Intel Corporation 3585 SW 198th Avenue Aloha, OR 97007 myron.hattig@intel.com 7 References [RFC 1034] P. Mockapetris, Host names - Concepts and Facilities, RFC 1034, November 1987 [RFC 1035] P. Mockapetris, Host names - Implementations and Specifications, RFC 1034, November 1987 [RFC 1487] Yeong, W., Howes, T., and S. Kille, Lightweight Directory Access Protocol, RFC 1487, July 1993. [RFC 2026] S. Bradner, The Internet Standards Process -- Revision 3, RFC 2026 Oct 1996 [RFC 2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, March 1997. [RFC 2131] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March 1997. [RFC 2365] D. Meyer Administratively Scoped Multicast Address RFC 2365,July 1998. [RFC 2730] S. Hanna, B. Patel, M. Shah, Multicast Address Dynamic Client Allocation Protocol (MADCAP), RFC 2730, Dec 1999. [SSM] H. Holbrook, Source-Specific Multicast for IP, draft- holbrook-ssm-00.txt, March 2000. A work in progress. Hattig [Page 14]