Zeroconf WG M. Hattig Internet Engineering Task Force Editor INTERNET DRAFT Intel Corp. Expires January 2001 July 14, 2000 Zeroconf Requirements draft-ietf-zeroconf-reqts-04.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, DNS, MADCAP, and LDAP must be configured and maintained by an administrative staff. This is unacceptable for emerging networks such as home networks, small office networks, automobile networks, airplane networks, or adhoc networks at conferences, emergency relief stations, and many others. For 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. Before embarking on defining zeroconf protocols, protocol requirements are needed. This document states zeroconf protocol requirements for four protocol areas; this document does not Hattig [Page 1] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 define specific protocols. The four areas are: IP host configuration, domain 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 Reading This Document.....................................3 1.2 Zeroconf Protocols........................................3 2 Scenarios & Requirements....................................7 2.1 IP Host Configuration.....................................8 2.2 Domain Name to IP Address Resolution Scenarios...........10 2.3 IP Multicast Address Allocation Scenarios................13 2.4 Service Discovery Scenarios..............................16 3 Security Considerations & Requirements.....................19 3.1 IP Host Configuration....................................19 3.2 Domain Name to IP Address Resolution.....................20 3.3 IP Multicast Address Allocation..........................20 3.4 Service Discovery........................................20 3.5 IPv6 Considerations......................................21 4 IANA Considerations........................................21 5 Full Copyright Statement...................................21 6 Acknowledgements...........................................21 7 References.................................................22 1 Introduction This document presents requirements for zeroconf protocols in four areas: IP host configuration, domain name to IP address resolution, IP multicast address allocation, and service discovery. Security issues and the transitions between a zeroconf protocol and a non-zeroconf protocol are also discussed within each protocol area. The major sections in this document are the Introduction, Scenarios & Requirements, and Security Considerations & Requirements. The introduction provides the background information, references, terms, and assumptions to ensure a clear understanding of the subsequent sections. The Scenarios & Requirements section walks through protocol scenarios and then lists the requirements of the protocol needed to accomplish the scenario. The Security section lists threats and security requirements. 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]. Hattig [Page 2] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 1.1 Reading This Document Most of the document can be read selectively based on the reader's protocol area of interest. To encourage this, much of the document is organized around the four protocol areas: - IP host configuration - Domain name to IP address resolution - IP multicast address allocation - Service discovery 1.2 Zeroconf Protocols Below are strict definitions of a zeroconf protocol and a non- zeroconf protocol. Also discussed are the transitions between a zeroconf protocol and non-Zeroconf. Finally, a section discusses how protocols with a centralized server may be zeroconf protocols. 1.2.1 Definitions A zeroconf protocol requires no user configuration. A non-zeroconf protocol requires user configuration. [Editor's Note: The definition of a ZC protocol is a key output of this document. Be aware that the definition has changed from the previous version of this document. This change prompted section 1.3.5 Centralized Servers. This editor's note will be removed in the next version of this draft.] 1.2.2 Transitions Transition is the act of determining when to change from using the zeroconf protocol to the non-zeroconf protocol, or vice-versa. Transition support is not required of a zeroconf protocol nor does a device require transition support if the device supports the zeroconf protocol. Below is a discussion of three possible transitions that a host SHOULD consider when using a zeroconf protocol. The first transition is a zeroconf to non-zeroconf transition. This type of transition may occur either if a host moves to a new network that does not use a zeroconf protocol when the old network used a zeroconf protocol. Or if the host stays on the same network but a new server comes online within that network. For example, if a DHCP server comes online after hosts are configured with a zeroconf IP host configuration protocol then hosts MUST re- configure with DHCP. Hattig [Page 3] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 The second transition is the opposite of the first; it is a non- zeroconf to zeroconf transition. This may occur if a host moves between networks or when a server goes offline within a network. The third transition occurs if a device moves from one network to another network when both networks use a zeroconf protocol. For example, if a person is using a laptop in her home network with a zeroconf protocol, then she takes that laptop to her neighbor's home network that uses the same zeroconf protocol: the laptop must automatically adapt to the new network. Another subtle example of this third of transition is if the network topology changes significantly as when a bridge gets installed between two existing networks. In this case, if the networks are utilizing a zeroconf IP host configuration protocol, the protocol SHOULD allow the hosts to detect addressing conflicts and possibly reconfigure. 1.2.3 Coexistence A zeroconf protocol in one area MUST be able to coexist with a non-zeroconf protocol in another area. To illustrate this point, suppose there are standard zeroconf and non-zeroconf protocols for IP host configuration and domain name to IP address resolution. For IP host configuration, the zeroconf protocol is "protocol-A." The non-zeroconf protocol is "protocol-B", supported by a fully conformant "protocol-B" server. For domain name to IP address resolution, the zeroconf protocol is "protocol-C". The non-zeroconf protocol is "protocol-D" supported by a fully conformant "protocol-D" server. Within a single network, the IP host configuration zeroconf protocol-A MUST be able to coexist with the domain name to IP address resolution non-zeroconf protocol-D. In contrast, zeroconf and non-zeroconf protocols from a single area MUST NOT be able to coexist during normal operation. They MAY coexist during a transition, but the coexistence period MUST be minimal. 1.2.4 Scalability Scalability is not of great concern because it is expected that zeroconf protocols will operate in networks of limited size. In addition, it is likely that as a network grows, the owners of that network will migrate to using non-zeroconf protocols before Hattig [Page 4] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 scalability becomes an issue. For this reason, this document mentions little of scalability requirements. 1.2.5 Centralized Servers This subsection illustrates how a protocol that takes advantage of a centralized server may be a zeroconf protocol. This is illustrated using DHCP in a home network. Centralized servers such as DHCP servers are being deployed in home networks to relieve user configuration. However, networks accidentally operating with multiple DHCP servers present new configuration challenges. Today's solution is for a person to configure one of the DHCP servers to stop operating; since a user must do something (turn off a DHCP server) this is a non-zeroconf solution. In order for a centralized server protocol to be zeroconf while operating with multiple servers, there must be mechanisms to ensure all clients use the appropriate server. Of course, these mechanisms must operate without any user configuration. 1.2.6 IP Host Configuration IP host configuration is the configuration of an interface on an IP host, which always includes an IP address and sometimes an netmask and default route. IP host configuration is required before almost any IP communication can take place. DHCP is the common IP host configuration solution deployed today. Zeroconf IP host configuration schemes MUST peacefully coexistence with DHCP. The definitions needed for the IP host configuration scenarios are: IP subnet - a single logic IP network that may span multiple link layer networks. internet - multiple IP subnets connected by routers. Network - general term that may apply to link layer, IP subnet, or internet. 1.2.7 Domain name to IP address resolution DNS is the common way to resolve names to IP addresses. Zeroconf domain name to IP address resolution protocols MUST peacefully coexistence with DNS. Hattig [Page 5] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 It is assumed that sub-domain delegation is not done within the zone that a zeroconf domain name to IP address resolution protocol is performed. In other words, a zeroconf zone contains all of the names in its domain. In addition, it is assumed a zeroconf domain name to IP address resolution protocol will only be used if a DNS server is not present or a host is not configured with the IP address of a DNS server. It is also assumed that TCP/IP networking connectivity to other zones MAY exist and those other zones have DNS servers. Furthermore, it is assumed that a special device or application exists at the edge of these two zones and is able to convert between the zeroconf and non-zeroconf domain name to IP address resolution protocols. 1.2.8 IP Multicast Address Allocation IP multicast is used to conserve bandwidth and reduce complexity in the multicast source. MADCAP is the default IP multicast address allocation protocol. Zeroconf IP multicast address allocation protocols MUST peacefully coexist with MADCAP. Zeroconf solutions are only concerned with IP multicast addresses scoped as Local (i.e. 239.255.0.0/16), link-local, node-local, and Single-source IP multicast addresses of any scope. It is assumed that a boundary router (as described in RFC 2365) is present to appropriately control multicast packets from entering and leaving the scope boundaries. 1.2.9 Service Discovery Service discovery protocols have proven to be critical to the usability of networks. AppleTalk/NBP, NetBIOS/SMB and IPX/SAP have improved the utility services from printing to gaming are easily found on these networks. Service Location Protocol version 2 (SLPv2) is defined in Standards Track RFC 2608, and an Internet- Draft defines Simple Service Discovery Protocols (SSDP). Service discovery definitions are: 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. Hattig [Page 6] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 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. 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. 2 Scenarios & Requirements This section lists zeroconf scenarios that lead to requirements for protocols. There is a subsection for each of the four protocol areas. Within each protocol area representative scenarios are discussed and requirements are identified. It is possible to state an endless number of scenarios but unless those scenarios yield Hattig [Page 7] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 additional requirements, there is no point of discussing such scenarios. Also, within each area is a summary of the requirements and an IPv6 considerations section. 2.1 IP Host Configuration DHCP is the non-zeroconf IP Host configuration protocol. The problems preventing DHCP from being a zeroconf protocol are: the DHCP server may not be present and if multiple DHCP servers are present they may provide conflicting configuration. The scenarios in this section are ping and bridge install. Since DHCP is the non-zeroconf IP host configuration protocol, the Zeroconf and non-Zeroconf Transitions section discusses transitioning between zeroconf IP host configuration and DHCP. 2.1.1 Ping Ping consists of one host sending an ICMP echo request to another host, then the other host replying with an ICMP echo reply. Ping has two sub-scenarios: ping to a host on local IP subnet and ping to a host off the local IP subnet. When sending a ping (or any other IP packet for that matter), a host performs the AND operation on the netmask and the destination IP address then compares that result with the result of an AND operation on the host's IP address and netmask. ((HostIPAddr & netmask) == (DestIPAddr & netmask)) If the result of this compare is FALSE, then the host forwards the packet to the default router because the destination address is off the local IP subnet. If the result is TRUE, then the host sends an ARP request to resolve the destination IP address to a hardware address within the local IP subnet. These steps are important to show the expected utilization and values of a netmask and the default route. Specifically, the values for the IP address, netmask, and default route within a host must be chosen such that the following statements are true: - All hosts on an IP subnet have a common netmask. - When a host computes (HostIPAddr & netmask) the result is identical for all hosts on a single IP subnet. - When a host computes (HostIPAddr & ~netmask) (inverse netmask) the result is unique for all hosts on an IP subnet. - All hosts get a default route that is used for communication with other IP hosts off the local subnet. In addition IP subnets must somehow be unique on different IP subnets within an internet over which the zeroconf IP host Hattig [Page 8] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 configuration protocol is operating; this insures unique IP addresses (regardless of the value of the host portion of the IP address) across the entire internet. The zeroconf IP host configuration protocol only defines packets sent over a wire and the associated semantics. Here are zeroconf IP host configuration protocol requirements to satisfy ping: - The ability to determine the netmask for an IP subnet. - The ability to determine the default route for an IP subnet. - The ability to have unique IP addresses within an IP subnet. - The ability to have unique IP subnets within an internet. 2.1.2 Bridge Installed This scenario starts with two completely operational standalone networks in which IP host configuration was completed with zeroconf IP host configuration protocols. These two networks become one after a bridge is installed between them. This creates two problems. First, hosts may have duplicate IP addresses. Second, there may be competing netmask and default route values that disrupt communication. The bridge scenario results in the following protocol requirements: - The ability to avoid or resolve contention among netmasks. - The ability to avoid or resolve contention among default routes. - The ability to avoid or resolve duplicate IP addresses within a subnet. - The ability to avoid or resolve duplicate IP subnets within an internet. 2.1.3 Zeroconf and non-Zeroconf Transitions DHCP is the non-zeroconf IP Host configuration protocol. Here are examples of intermittent connectivity between zeroconf hosts and DHCP servers that show the need for IP host configuration transitions: - DHCP servers in a PC that gets regularly power-cycled. - A zeroconf capable device introduced into a network that has a DHCP server. - A zeroconf capable device removed from a network that has a DHCP server. These scenarios require the periodic actions as well as specific actions at startup. The action is the same whether it be periodic or at startup. The action is an attempt to discover a DHCP server. If the DHCP server is discovered the host uses DHCP, otherwise the host uses the zeroconf IP host configuration protocol. Hattig [Page 9] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 IP host configuration zeroconf and non-zeroconf transitions necessitate the following protocol requirements: - The ability to detect the presence or absence of a DHCP server at startup of a device and periodically after a devices starts. 2.1.4 Requirements Summary Zeroconf IP host configuration protocol requirements are: - The ability to determine the netmask for an IP subnet. - The ability to determine the default route for an IP subnet. - The ability to have unique IP addresses within an IP subnet. - The ability to have unique IP subnets within an internet. - The ability to avoid or resolve contention among netmasks. - The ability to avoid or resolve contention among default routes. - The ability to avoid or resolve duplicate IP addresses within a subnet. - The ability to avoid or resolve duplicate IP subnets within an internet. - The ability to detect the presence or absence of a DHCP server at startup of a device and periodically after a devices starts. 2.1.5 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, there already exists a zeroconf IP host configuration solution. 2.2 Domain Name to IP Address Resolution Scenarios DNS is the non-zeroconf domain name to IP address resolution protocol. The problems with DNS preventing DNS from being a zeroconf protocol are: user configuration of the IP address of a DNS server in a client machine, user entering DNS resource records in the DNS server, devices having unique names, and a DNS server may not be accessible. The scenarios in this section are web browsing, domain name selection, and bridge install. Additional, transition scenarios list requirements for transitioning between using DNS and using the zeroconf domain name to IP address resolution protocol. 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 as the web browser or within a different domain. The zeroconf domain name to IP address resolution protocol MUST resolve a name to an IP address without a host being configured Hattig [Page 10] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 with the IP address of a DNS server. This includes names within the same domain as the host that is using the zeroconf protocol as well as names within other domains. The domain name to IP address resolution protocol requirements for web browsing are: - The ability to resolve a name to an IP address without the user configuring the IP address of a DNS server. - The user must not be required to enter a mapping of a domain name to IP address into the DNS database. 2.2.2 Domain Name Selection A domain name consists of a host name and the name of the domain itself. A host has control over its host name, but some other entity configures or determines the name of the domain. In fact the name of the domain may not be available. A protocol is needed to maintain unique host portions of a domain name and to possibly learn the name of the domain. Note that it may be desirable to have duplicate host names. Such cases include server farms with load-balanced servers meant to provide consistent response times during periods of high volume. Here are the requirements for a name selection protocol: - The ability to ensure a unique host name (assuming unique names are desired) is selected. - The ability to learn the name of the domain (assuming the name of the domain is known). 2.2.3 Bridge Install This scenario starts with two completely operational standalone networks. After name selection is complete, these two networks become one when a bridge is installed between the networks. The bridge scenario results in the following protocol requirements: - The ability to periodically ensure the uniqueness of a selected host name. 2.2.4 Zeroconf and non-Zeroconf Transitions DNS is the non-zeroconf domain name to IP address resolution protocol. There are four transitional cases to consider. Note that unless a host is configured with the IP address of the DNS server, none of these transitions can occur. The first is a zeroconf to non-zeroconf transition that occurs when the host is first configured with the IP address of the DNS Hattig [Page 11] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 server and the host can actually reach the DNS server (i.e. the DNS server responds to requests). The second is a non-zeroconf to zeroconf transition that occurs when for some reason the DNS server can no longer be reached. One such reason may be that the host is moved to a network without connectivity to the DNS server. In this case the zeroconf domain name to IP address resolution protocol MUST be invoked. The third transition is from zeroconf back to non-zeroconf. This occurs when the DNS server becomes reachable again. Following the above example, the host is moved back to the original network with connectivity to the DNS server. The final transition is a non-zeroconf to zeroconf transition that occurs when the IP address of the DNS server is removed from the host. These transitions generate the following requirements: - The ability to detect the presences or absence of DNS server (applies only if the host is configured with the IP address of the DNS server). The host must use DNS when the DNS server is present and zeroconf domain name to IP address resolution when the DNS server is not present. 2.2.5 Requirements Summary The domain name to IP address resolution protocol requirements are: - The ability to resolve a name to an IP address without the user configuring the IP address of a DNS server. This includes names within the same domain as the requesting host as well as names outside the domain as the requesting host. - The user must not be required to enter a mapping of a domain name to IP address. - The ability to ensure a unique host name (assuming unique names are desired) is selected. - The ability to learn the name of the domain (assuming the name of the domain is known). - The ability to periodically ensure the uniqueness of a selected host name. - The ability to detect the presences or absence of DNS server (applies only if the host is configured with the IP address of the DNS server). The host must use DNS when the DNS server is present and zeroconf domain name to IP address resolution when the DNS server is not present. 2.2.6 IPv6 Considerations Hattig [Page 12] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 Domain name to IP address resolution protocols has no zeroconf related differences for IPv4 and IPv6. 2.3 IP Multicast Address Allocation Scenarios MADCAP is the non-zeroconf IP Multicast Address Allocation protocol. The problems preventing MADCAP from being a zeroconf protocol are: the MADCAP server may not be present and if multiple MADCAP servers are present they may provide conflicting configuration. All IP multicast addresses allocated are from the scopes of Local (i.e. 239.255.0.0/16), link-local, node-local, and Single-source IP multicast addresses of any scope. Descriptions of "Scope Enumeration" and "Allocate Node-scoped or Single-Source Global IP multicast address" do not result in requirements but do provide important information about IP multicast operations. The scenarios of "Allocate Link-scoped or Local-Scope IP multicast", "Allocate IP Multicast Address Used by Multiple Sources", then the transitions between zeroconf and MADCAP generate protocol requirements. 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 within [RFC 2771]. In addition, services that are assigned relative addresses [RFC 2365] require the ability to enumerate what scopes the host is within, then a host is able to apply the relative address to a scope. When enumerating scopes, the following scopes may be assumed to exist in all cases (assuming well-known ranges have been reserved by IANA). - Node-Local - Link-Local - Local (i.e., the Zeroconf area) - Single-source global The zeroconf IP multicast address allocation protocol requirements are: - The ability for a host to obtain the set of scope names, for all scopes it is within. - The ability for a host able to obtain the set of address ranges for all scopes it is within. Hattig [Page 13] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 2.3.2 Allocate Node-scoped or Single-Source Global IP multicast address Each host is always responsible for allocating its own Node-scoped and Single-source Global multicast addresses, regardless of whether it is use of zeroconf protocols since there is no coordination between devices for such allocation, no protocol is involved, and there are no protocol requirements. Allocating (global) single-source addresses is only possible if the host has already acquired a global unicast IP address. To date, no range has been reserved for dynamic allocation of Single-source addresses in IPv6. Hence, until such a range is reserved, dynamic allocation of Single-source addresses applies only to IPv4. 2.3.3 Allocate Link-scoped or Local-Scope IP multicast address Address allocation at the Link and larger scopes requires coordination 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. To date, no range has been reserved for dynamic allocation of Link-scoped addresses in IPv4. Hence, unless such a range is reserved, dynamic allocation of Link-scoped addresses applies only to IPv6. Collision detection must span the entire Link for Link-scope allocations, and must span the entire locally scoped internet for Local-scope allocations. The protocol should include the ability for a host to choose addresses, determine if they are in use, and choose different addresses if so. The collision detection protocol must become active at various times such as when previously disconnected yet operational networks now become connected by the installation of a router or bridge. The zeroconf IP multicast address allocation protocol requirements are: - The ability for a host to select a multicast address with a given scope and lifetime. - The ability for a host to determine if the address has been allocated by another host. - The ability for a host to defend the addresses it allocates. - The ability for a host to determine if another host has allocated an address that has been allocated by itself; this SHOULD be done periodically. Hattig [Page 14] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 - The protocol MUST be routable to ensure it spans the entire local scope. 2.3.4 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. Here, the first source that needs the IP address MUST allocate the address, yet it may not be the host that deallocates the multicast address. This is because the first source may leave the multicast group before all the other sources stop sending packets to that IP multicast address. This requires, the last source using the IP multicast address to deallocate the IP multicast address after it is done sending. The zeroconf IP multicast address allocation protocol requirements are: - The ability for the last host acting as a source to deallocate the IP multicast address. 2.3.5 Zeroconf and non-Zeroconf Transitions MADCAP is the non-zeroconf IP multicast address allocation protocol. Hosts MUST be able to transition between MADCAP and the zeroconf IP multicast address allocation protocol by detecting (or not detecting) the presences of a MADCAP server. If MADCAP is detected while using zeroconf IP multicast address allocation, the host must start utilizing MADCAP. If MADCAP is no longer detected while using MADCAP, the host must start utilizing the zeroconf IP multicast address allocation protocol. The transition requirements are: - The ability to detect the presence or absence of a MADCAP server at startup of a device and periodically after a device starts. 2.3.6 Requirements Summary Zeroconf IP multicast address allocation protocol requirements are: - The ability for a host to obtain the set of scope names, for all scopes it is within. - The ability for a host able to obtain the set of address ranges for all scopes it is within. - The ability for a host to select a multicast address with a given scope and lifetime. Hattig [Page 15] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 - The ability for a host to determine if the address has been allocated by another host. - The ability for a host to defend the addresses it allocates. - The ability for a host to determine if another host has allocated an address that has been allocated by itself; this SHOULD be done periodically. - The protocol MUST be routable to ensure it spans the entire local scope. - The ability for the last host acting as a source to deallocate the IP multicast address. - The ability to detect the presence or absence of a MADCAP server at startup of a device and periodically after a device starts. 2.3.7 IPv6 Considerations To date, no range has been reserved for dynamic allocation of Single-source 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 reserved, dynamic allocation of Link-scoped addresses applies only to IPv6. 2.4 Service Discovery Scenarios As stated earlier, there is no non-zeroconf service discovery protocol, thus there are no particular zeroconf problems with an zeroconf protocol. In addition, there are no zeroconf to non- zeroconf transition scenarios. 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 client 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. Some service specific protocols allow the client and server to negotiate the use of these characteristics after the service is found; thus, alleviating the need for the service discovery protocol to Hattig [Page 16] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 discover by characteristic. However, characteristic discovery SHOULD be part of the service discovery protocol for those services without capability negotiation. Discovery MUST be possible by either the client actively soliciting the service or by the service advertising then the client passively listening for the advertisements. Once a client finds the printer, it can utilize different printing protocols such as raw tcp, lpd, and ipp. Within a short number of seconds after activating a print server, a user who is actively browsing for a printer MUST be able to see the device appear in a browser window, or a user application such as a spreadsheet MUST be able to begin using the print service. This requires the service discovery to be timely. 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. The zeroconf service discovery protocol requirements for this scenario are: - The protocol MUST allow the client to discover a service via service identifier and/or service type. - The protocol SHOULD allow the client to discover a service by characteristics. - The protocol MUST allow the client to discovery a service by actively soliciting the service. - The protocol MUST allow the client to discover a service by the client passively listening for advertisements. - The protocol MUST allow clients to rediscover a service. - Discovery MUST be timely (within seconds) when a service comes on line. - The protocol SHOULD allow services that are no longer active to notify clients in a time (within seconds) manner. - A service discovery protocol itself MUST NOT require configuration. - The protocol MUST be independent from any particular service. 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 Hattig [Page 17] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 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. A print manager requires 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. The zeroconf service discovery protocol requirements for printer manager scenario are: - The protocol SHOULD allow for registry to cache information about services and characteristics of services. - The ability for clients to extract data from the registry without knowledge that it is talking to a registry. - A registry MUST not be required for all services. 2.4.3 Requirements Summary Zeroconf service discovery protocol requirements are: - The protocol MUST allow the client to discover a service via service identifier and/or service type. - The protocol SHOULD allow the client to discover a service by characteristics. - The protocol MUST allow the client to discovery a service by actively soliciting the service. - The protocol MUST allow the client to discover a service by the client passively listening for advertisements. - The protocol MUST allow clients to rediscover a service. - Discovery MUST be timely (within seconds) when a service comes on line. - The protocol SHOULD allow services that are no longer active to notify clients in a time (within seconds) manner. - A service discovery protocol itself MUST NOT require configuration. - The protocol MUST be independent from any particular service. - The protocol SHOULD allow for registry to cache information about services and characteristics of services. - The ability for clients to extract data from the registry without knowledge that it is talking to a registry. - A registry MUST not be required for all services. Hattig [Page 18] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 2.4.4 IPv6 Considerations Service discovery protocols have no zeroconf related differences for IPv4 and IPv6. 3 Security Considerations & Requirements By definition security requires configuration. Security examples include a configured key for payload encryption, user entered passwords for conditional access, and an administrator configures port mappings to enable a protocol to traverse a firewall. The configuration required by security is in direct conflict with the design goals of zeroconf protocols; however, security requirements take precedence over zeroconf protocol design goals. Given this reality, this section focuses on the minimal configuration necessary to make zeroconf protocols secure. In addition, this section describes types of general threats and how those general threats apply to each protocol area. The general threats are: Hoarding: Hosts claim all available resources, whether they plan to use them or not. This is a form of denial of service attack. Masquerading: Hosts can respond to requests that they should not so they can masquerade as another host. Antagonistic Server: A server could offer support for a critical service but intentionally misconfigure hosts on the network. 3.1 IP Host Configuration Threats include: - A host could hoard IP addresses. If secure zeroconf IP host configuration is required, all hosts MUST be certifiable as valid participants. In addition, a host MUST be configured with some security information. Furthermore, some security information must be part of every zeroconf IP host configuration packet. Here is an example to illustrate: All hosts are registered as valid security participants by the manufactures before the product ships. In addition the product is shipped with a private key. Before the secure device communicates with another secure device it gets the other device's registered info, then submits that registered info to the registration authority to get the devices public key. Of course this request is encrypted. From that point on all packets are encrypted using a public key and a private key. Hattig [Page 19] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 3.2 Domain Name to IP Address Resolution Potential threats include: - A host could masquerade by responding to names requests illegitimately. - A host could hoard names by responding to all 'claim' requests. Hosts MUST be able to be configured to use a zeroconf protocol for domain name to IP address resolution securely. For example, a 'reply' from the resolution protocol could be accompanied by a 'signature' that could be verified before being accepted. The security configuration would have to provide the server portion of the protocol with the data needed to produce a 'signature' that could only be produced if in possession of the configuration data. 3.3 IP Multicast Address Allocation Potential threats include: - A host could hoard multicast addresses by denying others the ability to obtain them. - A host could snoop to learn all used IP multicast addresses in use then reconfigure the border router to allow IP multicast data to go beyond the desired boundary. Hosts MUST be able to be configured to use a zeroconf protocol for multicast address allocation securely. For example, a claim and defend protocol used for multicast address allocation would have to include security data with all messages. A host in the zeroconf network could verify that another host's claim was legitimate or not. 3.4 Service Discovery Potential threats include: - Servers could masquerade by responding to service discovery requests that they shouldn't respond to. - A host could pose as an antagonistic service discovery 'infrastructure element.' Some service discovery protocols offer a 'registry', 'directory', 'proxy' or other infrastructure element for scalability. The service discovery protocol MUST provide mechanisms that allow a client to determine if both the service it discovers and the service discovery protocol infrastructure it uses to discover services are 'legitimate.' The service discovery protocol MUST provide mechanisms that allow a client to determine if both the service it discovers and the Hattig [Page 20] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 service discovery protocol infrastructure it uses to discover services are 'legitimate.' 3.5 IPv6 Considerations IPv6 has built in security, thus if a network is using IPv6, there already exists a security solution. 4 IANA Considerations There are no known IANA considerations arising 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 first BOF that was the catalyst to forming the Zeroconf Working Group, which is responsible for this document. Thanks to Erik Guttman and Stuart Cheshire for forming and chairing the Zeroconf Working Group. Hattig [Page 21] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 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. 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 Hillsboro, OR 97124 myron.hattig@intel.com 7 References [STD 3] R. Braden Requirements for Internet Hosts -- Communication Layers RFC 1122, STD 3, October 1989 [STD 4] R. Braden, Requirements for Internet Hosts -- Application and Support RFC 1123, STD 4 October 1989 [RFC 1001] PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS, RFC 1001 March, 1987 [RFC 1002] PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS, RFC 1002, March 1987 [RFC 1034] P. Mockapetris, Domain Names - Concepts and Facilities, RFC 1034, November 1987 [RFC 1035] P. Mockapetris, Domain Names - Implementations and Specifications, RFC 1034, November 1987 [RFC 1458] R. Braudes, Requirements for Multicast Protocols, RFC 1458, May 1993 [RFC 1918] D. Karrenberg, et al, Address Allocation for Private Internets, RFC 1918, Feb 1996 Hattig [Page 22] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 [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 2132] S. Alexander, R. Droms DHCP Options and BOOTP Vendor Extension RFC 2132, March 1997. [RFC 2316] S. Bellovin, Report of the IAB Security Architecture Workshop, RFC 2316, April 1998 [RFC 2365] D. Meyer Administratively Scoped Multicast Address RFC 2365,July 1998. [RFC 2401] S. Kent, Security Architecture for the Internet Protocol, RFC 2401, Nov 1998 [RFC 2411] R. Thayer, IP Security Document Roadmap, RFC 2411, Nov 1998 [RFC 2461] T. Narten, E. Nordmark, W. Simpson Neighbor Discovery for IP Version 6 (IPv6) RFC 2461, December 1998. [RFC 2462] S. Thomson, T. Narten IPv6 Address Autoconfiguration RFC 2462, December 1998. [RFC 2504] E. Guttman, Users' Security Handbook, RFC 2504, Feb. 1999 [RFC 2608] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service Location Protocol version 2. RFC 2608, June 1999. [RFC 2609] E. Guttman, C. Perkins, J. Kempf Service Templates and service: Schemes, RFC 2609, June 1999. [RFC 2730] iS. Hanna, B. Patel, M. Shah, Multicast Address Dynamic Client Allocation Protocol (MADCAP) draft- ietf-malloc-madcap-05.txt Dec 1999. [AutoMcast] D. Thaler, B. Adoba, Multicast Address Allocation in Auto-Configured Networks, draft-thaler-zeroconf- multicast-00.txt, Oct 1999. A work in progress Hattig [Page 23] Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000 [AutoNet] R. Troll Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network draft-ietf-dhc-ipv4-autoconfig- 04.txt April, 1999. A work in progress. [MCAST DNS] B. Woodcock, B. Manning Multicast Discovery of DNS Services draft-manning-multicast-dns-01.txt December, 1998. A work in progress. [MiniDHCP] Bernard Aboba, Auto-Addressing in Multi-segment Networks, draft-aboba-zeroconf-multi-00.txt, Oct 1999. A work in progress. [SSDP] www.upnp.org [IPv6 WG] IP Next Generation WG, www.ietf.org/html.charters/ipngwg-charter.html. [DHC WG] Dynamic Host Configuration WG, www.ietf.org/html.charters/dhc-charter.html. [NAT WG] Network Address Translation WG, www.ietf.org/html.charters/nat-charter.html. [DNSEXT WG] DNS Extension WG, http://www.ietf.org/html.charters/dnsext-charter.html [MALLOC WG] Multicast Allocation WG Charter, www.ietf.org/html.charters/malloc-charter.html. Hattig [Page 24]