Zeroconf WG M. Hattig Internet Engineering Task Force Editor INTERNET DRAFT Intel Corp. Expires September 2000 March 10, 2000 Zeroconf Requirements draft-ietf-zeroconf-reqts-03.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 presents requirements for zeroconf protocols in four areas: IP host configuration, domain Hattig [Page 1] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 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. An additional part of the overall zeroconf protocol effort includes a separate profiles document that is a companion to this requirements document. The profile document matches existing protocols with the requirements. If existing protocols do not meet the requirements then new zeroconf protocols must be created. Table of Contents 1 Introduction................................................2 1.1 Reading This Document.....................................3 1.2 Background Information....................................3 1.3 Zeroconf Protocols........................................4 2 Scenarios & Requirements....................................9 2.1 IP Host Configuration.....................................9 2.2 Domain Name to IP Address Resolution Scenarios...........12 2.3 IP Multicast Address Allocation Scenarios................15 2.4 Service Discovery Scenarios..............................18 3 Security Considerations & Requirements.....................20 3.1 IP Host Configuration....................................21 3.2 Domain Name to IP Address Resolution.....................21 3.3 IP Multicast Address Allocation..........................22 3.4 Service Discovery........................................22 3.5 IPv6 Considerations......................................22 4 IANA Considerations........................................22 5 Full Copyright Statement...................................22 6 Acknowledgements...........................................23 7 References.................................................24 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 to this requirements document are the Introduction, Scenarios & Requirements, and Security Considerations & Requirements. The introduction provides the background information, terms, and assumptions so the scenarios can be understood. The Scenarios & Requirements section lists requirements that result from examining everyday usage scenarios of protocols. The security section lists threats and security requirements for all four protocol areas. Hattig [Page 2] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 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.1 Reading This Document Because this document deals with four distinct protocol areas, many sections are divided into these areas. These areas are: - IP host configuration - Domain name to IP address resolution - IP multicast address allocation - Service discovery With the exception of the introduction, a reader only interested in particular areas only needs to read about those areas. However, all readers should read the introduction to understand the flow of the document and various global assumptions. Specifically, the introduction provides the necessary background information to support the scenarios and requirements sections. This introduction includes reference information, restrictions, assumptions, and terms. The Scenarios & Requirements section is divided into protocol areas. Within each area is a representative set of everyday usage scenarios that generate unique requirements. A summary of all requirements finishes each protocol area subsection. The Security Considerations & Requirements section lists threats and security requirements for each protocol area. 1.2 Background Information The below references are divided by protocol area with additional references for security and general knowledge. Note that some IETF working groups are listed because they specify protocols that impact zeroconf protocols. All readers should be familiar with the general knowledge references. IP host configuration: - [AutoNet] Ipv4 Auto-Configuration I-D - [MiniDHCP] Auto-Addressing in Multi-segment Networks I-D - [RFC 1918] RFC 1918 Private Addresses - [RFC 2131] RFC 2131 DHCP - [RFC 2132] RFC 2132 DHCP Options - [RFC 2462] IPv6 Auto-Configuration - [RFC 2461] IPv6 Neighbor Discovery - [IPv6 WG] Next Generation (Ipv6) WG Hattig [Page 3] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 - [DHC WG] Dynamic Host Configuration WG Domain name to IP address resolution: - [Mcast DNS] Multicast DNS I-D - [RFC 1001] NETBIOS: CONCEPTS AND METHODS - [RFC 1002] NETBIOS: DETAILED SPECIFICATIONS - [RFC 1034] RFC 1034 DNS - [DNSEXT WG] DNS Extension WG Multicast address allocation: - [AutoMcast] Multicast Address Allocation in Auto-Configured Networks I-D - [RFC 2730] RFC 2730 MADCAP - [RFC 2365] RFC 2365 Administratively Scoped Multicast Address - [MALLOC WG] Multicast Address Allocation WG Service discovery: - [SSDP] Simple Service Discovery Protocol I-D - [RFC 2608] RFC 2608 Service Location Protocol v2 - [RFC 2609] RFC 2609 SLP Schemes Security: - [RFC 2316] RFC 2316, IAB Security Architecture Workshop - [RFC 2401] RFC 2401, Security Architecture for IP - [RFC 2411] RFC 2411, IP Security Document Roadmap - [RFC 2504] RFC 2504, User's Security Handbook General knowledge: - [STD3] RFC 1122 Requirements for Internet Hosts - Comm Layers - [STD4] RFC 1123 Requirements for Internet Hosts - App Layers - [RFC 1458] RFC 1458 Requirements for Multicast Protocols - [RFC 1812] RFC 1812 Requirements for Internet Gateways 1.3 Zeroconf Protocols Below are strict definitions of zeroconf protocol and a non- zeroconf protocol. Also discussed are how a host transitions between a zeroconf protocol and non-Zeroconf protocol within a single area as well as coexistence of protocols in different areas. Then, additional subsections state the assumptions and restrictions for each protocol area. 1.3.1 Definitions A zeroconf protocol requires no user configuration and does not rely on information received from a centralized server. A non-zeroconf protocol requires user configuration or relies on information received from a centralized server. Hattig [Page 4] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 1.3.2 Transitions Below is a discussion of three possible transitions that a host SHOULD consider when using a zeroconf protocol. Basically, the host must be able to determine when to change from using the zeroconf protocol to the non-zeroconf protocol, or vice-versa. In addition, if the host moves from one network to another network and both networks are using a zeroconf protocol, the host must know to re-initialize or restart the 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 non-zeroconf 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. The second transition is the opposite of the first; it is a non- zeroconf to zeroconf transition. This may occur if a host moves to a different network or when a non-zeroconf server goes offline within a network. The third transition occurs if a host 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, then the laptop must automatically adapt to the zeroconf protocol operating in 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 MUST allow the hosts to detect addressing conflicts and possibly reconfigure. 1.3.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. Hattig [Page 5] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 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.3.4 IP Host Configuration In this document, IP host configuration really is the configuration of an interface on an IP host. That is, IP host configuration is complete when a host is able to use an IP address, netmask, and default route on an interface. IP host configuration is required before almost any IP communication can take place through a single interface on a host. DHCP is the common IP host configuration solution deployed today. DHCP consists of servers and clients. The client discovers the server, and then the server offers configuration parameters to clients. It is assumed that all zeroconf IP host configuration schemes will coexistence with DHCP. DHCP is the non-zeroconf solution for IP host configuration. The definitions needed for the IP host configuration scenarios are: IP subnet û a single logic IP network that may span multiple layer 2 networks. All hosts on a single logical IP network have the identical result when performing the following operations (HostIPAddr & netmask). In addition, all hosts on the single logical subnet have a unique result when performing the following operation (HostIPAddr & ~netmask) (inverse netmask). internet - multiple IP subnets connected by routers. This may be the global Internet or a private internet. Network - general term that may apply to IP subnet, internet, Internet, or a layer 2 network. The context in which this term is used defines its meaning. Hattig [Page 6] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 1.3.5 Domain name to IP address resolution Web browsing to an URL utilizes domain name to IP address resolution. When a user enters a host name to download a file with FTP, the entered name is resolved to an IP address. Domain name to IP address resolution allows applications and users to remain blissfully unaware of IP addresses. DNS is the common way to resolve names. DNS consists of servers that maintain resource records; a record maps a domain name to an IP address. In addition, resolvers (i.e. clients) on hosts query the DNS servers for the information in resource records. Name servers have authority for particular zones. A zone covers a complete set or a subset of a domain. If a server cannot directly resolve a name, it passes the request onto another DNS server or returns the IP address of another DNS server back to the resolver so the resovler can query the DNS server it just learned about. DNS is the non-zeroconf solution for domain name to IP address resolution. 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 zone includes 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 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, this also assumes that a special router 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. A default domain is the domain considered ôlocalö to a host. 1.3.6 IP Multicast Address Allocation Examples of emerging multicast applications include audio/video (e.g. TV), bulk news, and intra-home intercom system. These applications require an IP multicast address prior to sending IP multicast packets. In most cases, the IP multicast address is unique per application source. The scope of the multicast address determines if a multicast packet gets transmitted beyond certain administrative domains, which are separated by a boundary router as defined in RFC 2365. MADCAP is the non-Zeroconf IP multicast address allocation solution. MADCAP is a client/server protocol that operates much like DHCP. In addition, the client may define a range from which Hattig [Page 7] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 the IP multicast address is allocated by passing a scope along with the clientÆs allocation request. Zeroconf solutions are only concerned with IP multicast addresses scoped as Local (i.e. 239.255.0.0/16), link-local, node-local, and any scope of single-source IP multicast addresses. It is assumed that an RFC 2365 defined boundary router appropriately controls multicast packets from physically entering and leaving scope boundaries. 1.3.7 Service Discovery Service discovery protocols have proven to be critical to the usability of networks. AppleTalk/NBP, NetBIOS/SMB and IPX/SAP are good real-world examples of this. Services from printing to gaming are easily found on these networks. Unlike the other protocol areas in this document, service discovery will not likely have separate zeroconf and non-zeroconf protocols; one protocol will serve both. Also unlike the other protocol areas, no service discovery protocol has been as widely deployed as DNS or DHCP. Service Location Protocol version 2 (SLPv2) is defined in Standards Track RFC 2608. An Internet-Draft defines Simple Service Discovery Protocols (SSDP), which is another service discovery protocol. 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 a client and a server. Servers 'register' service advertisements and other pertinent information (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 set of processes that utilize a particular protocol. Services range from printing to transferring a file to providing on-line pizza order and delivery. Hattig [Page 8] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 Service Advertisement Packet - An unsolicited packet issued by a server or registry. The advertisement provides the service identifier, service type, and possibly service characteristics. Service Characteristics û Characteristics provide a finer granularity of description by which 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 type. 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 everyday usage scenarios that lead to requirements for zeroconf protocols. There is a subsection for each of the four protocol areas. Within each protocol area representative scenarios are discussed and requirements are identified. Also, within each area is a summary of the requirements and an IPv6 considerations section. 2.1 IP Host Configuration IP Host configuration determines the appropriate values for an IP interface's IP address, netmask, and default route. Then the host must operate with those values. The scenarios in this section are ping, bridge install, and transitions between zeroconf IP host configuration and DHCP. 2.1.1 Ping Hattig [Page 9] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 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, 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. Here is representative C code: ((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 that a ping to a host on a local IP subnet presents different requirements than a ping to a host on a non-local IP subnet. The zeroconf IP host configuration MUST allow ping to succeed in either case if it is possible within the TCP/IP connectivity provided by a given network. The specific protocol requirements follow: Netmask requirements: - All hosts on an IP subnet MUST have a common netmask. IP address requirements: - The result of (HostIPAddr & netmask) must be the same value for all hosts on an IP subnet - The result of (HostIPAddr & ~netmask) (inverse netmask) must be unique for all hosts on an IP subnet Default route requirements: - A default route is not required for communication within the local subnet. - A default route is required for communication off the local subnet. Note that by definition, IP subnet numbers must be unique within an internet, thus no address duplication between hosts on different subnets can exist. Managing IP subnet numbers is not the function of an IP host configuration protocol; it is the function of a router or another entity aware of an entire internet. Zeroconf IP Host configuration does not include configuration of routers; however, zeroconf IP host configuration MAY utilize a configured router to retrieve the default route or the netmask. Hosts could subsequently determine the IP subnet number with the netmask. Hattig [Page 10] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 Note that a ping from a host using a private address (as defined in RFC 1918) to a globally unique IP address on the Internet does not add additional requirements to the zeroconf IP host configuration protocol. Instead, it places additional requirements on the specialized router that sits between the internet using the private address space and the global Internet. The requirements of this specialized router are outside the scope of this document. 2.1.2 Bridge Installed This scenario starts with two completely operational standalone networks. After initial IP host configuration with zeroconf protocols, these two networks become one when a bridge gets installed between them. Two problems arise. The first is that hosts now may have duplicate IP addresses. Note, that this is not considered a major problem because the occurrence of duplicate addresses can be made statically improbably if the netmask is the same for all networks and allows for a large number of hosts (e.g. netmask of 255.255.0.0). Another problem is that the hosts on the two networks are not using the same netmask or that all hosts do not have the same result of (HostIPAddr & netmask) operation as was shown to be a requirement for ping. Note this assumes that a network with multiple IP subnets operating over a single layer-2 network is not desirable. These problems create unique requirements for the bridge install scenario. Specifically, the zeroconf IP host configuration protocol MUST provide hosts with the ability to detect duplicate IP addresses even after initial configuration. Once detected, one of the hosts must choose a new IP address and ensure that the new IP address is unique. In addition, the protocol MUST consolidate two IP subnets into a single IP subnet. 2.1.3 Zeroconf and non-Zeroconf Transitions DHCP is the non-zeroconf IP host configuration protocol. Hosts MUST be able to transition between DHCP and the zeroconf IP host configuration protocol by detecting the presences or absence of a DHCP server. Barring any new DHCP option, the most likely mechanism is a DHCP discovery message. If DHCP is detected while using zeroconf IP host configuration, the host must start utilizing DHCP. If DHCP is no longer detected while using DHCP, the host must start utilizing the zeroconf IP host configuration protocol. Hattig [Page 11] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 2.1.4 Requirements Summary Zeroconf IP host configuration protocol requirements are: - The protocol MUST allow all hosts on an IP subnet to have a common netmask. - The protocol MUST allow all hosts on an IP subnet to choose an IP address such that the result of the (HostIPAddr & netmask) operation is the same value for all hosts on an IP subnet. - The protocol MUST allow all hosts on an IP subnet to choose an IP address such that the result of the (HostIPAddr & ~netmask) operation (inverse netmask) is unique among all hosts on an IP subnet. - The protocol MUST allow hosts to operate without choosing a default route to communicate with other hosts on their local subnet. - The protocol MUST allow hosts to choose a default route if it is available. - The protocol MUST allow the host to defend the address it chooses. - The protocol MUST provide hosts the ability to detect duplicate IP addresses after initial configuration. - The protocol MUST be able to consolidate two IP subnets into a single IP subnet. - The protocol MUST allow a host to detect that DHCP is and is not in use. - The protocol MUST allow a host to transition from the zeroconf protocol to DHCP if DHCP is detected while using zeroconf IP host configuration. - The protocol MUST allow a host to transition from DHCP to the zeroconf protocol if while using DHCP the DHCP server is no longer detected. 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 Domain name to IP address resolution consists of a host making a query that contains a host name, and then the response to the query contains the IP address to complete the resolution. The zeroconf problem with DNS is that the host must be configured with the IP address of a DNS server. This allows the host to send a unicast DNS request to a DNS server, then its simplest form, the DNS server responds with the IP address. Hattig [Page 12] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 The zeroconf goal for domain name to IP address resolution is to remove the need for the host to configure the IP address of a DNS server. The first scenarios are to resolve a name of a host that resides within the zeroconf domain and then to resolve a name that resides outside the zeroconf domain. Another scenario below is a host determining its name and default domain. Once a name is selected, the host must ensure the name is unique within its default domain. This is an ancillary issue for domain name to IP address resolution that will most likely result in a protocol that is independent from protocols that resolve domain names to IP addresses. The final scenarios are transitions between using DNS and the zeroconf domain name to IP address resolution protocol. 2.2.1 Name Resolution The zeroconf domain name to IP address resolution protocol MUST resolve a name to an IP address without a host being configured 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. 2.2.2 Name and default domain selection A name selection protocol is necessary so that all host within a domain have unique names. Once a host chooses a name, it MUST then determine if the name is in use. If the host requires a unique name, the host selects a different name and again determines if the name is unique. This process continues until the host has a name that is unique within a domain. A host MUST determine its default domain and the default domain MUST be the same for all hosts within the domain. The zeroconf name resolution protocol must become active periodically to check the validity of name. One example of when this is necessary is when previously disconnected yet operational networks now become connected by the installation of a router or a bridge. 2.2.3 Zeroconf and non-Zeroconf Transitions DNS is the non-zeroconf domain name to IP address resolution protocol. There are four transitional cases to consider. Hattig [Page 13] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 The first is a zeroconf to non-zeroconf transition that occurs when the host is first configured with the IP address of the DNS 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 zeroconf protocol MUST operate when a host is not configured to use a DNS server. - If configured to use DNS the host MUST be able to detect the presence and the absence of a DNS server. - If the DNS server becomes absent after configuration, the host MUST use the zeroconf protocol. - If the DNS server becomes present after being absent, the host MUST use DNS. 2.2.4 Requirements Summary Zeroconf Domain name to IP address protocol requirements are: - The protocol MUST resolve a name to an IP address without a host being configured 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 protocol MUST allow the host to defend the name it chooses. - The protocol MUST operate when a host is not configured to use a DNS server. - If configured to use DNS the host MUST be able to detect the presence and the absence of a DNS server. - If the DNS server becomes absent after configuration, the host MUST use the zeroconf protocol. - If the DNS server becomes present after being absent, the host MUST use DNS. Zeroconf name selection protocol requirements are: Hattig [Page 14] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 - Processing within a host is responsible for choosing a host name. This includes selecting the initial name as well as selecting subsequent names if a name proves to be a duplicate. - The protocol MUST allow the host to determine if the name is in use by another host within the default domain. At various times a host MUST actively determine if another host is using its name. - The protocol MUST remain within the domain of the hosts using the protocol. - The protocol MUST allow hosts to create or determine the existence of a default domain. - The protocol MUST ensure all hosts operating within a domain use the same default domain. 2.2.5 IPv6 Considerations Domain name to IP address resolution protocols as well as name and default domain selection have no zeroconf related differences for IPv4 and IPv6. 2.3 IP Multicast Address Allocation Scenarios IP multicast is used to conserve bandwidth and reduce complexity in the source. Bandwidth is conserved because a sender only sends a single packet, then a large number of receivers receive that packet. The unicast alternative requires the source to send individual packets to each destination; this consumes more bandwidth. In addition, unicasting increases the complexity of the source because the source must maintain a list of the individual destinations. 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 requirement 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] also require the ability to enumerate what scopes the host Hattig [Page 15] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 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: - A host MUST be able to obtain the set of scope names, for all scopes it is within. - A host MUST be able to obtain the set of address ranges for all scopes it is within. 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 Hattig [Page 16] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 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: - A host that wishes to allocate a multicast address with a given scope and lifetime MUST select an address. - A host MUST determine if the address has been allocated by another host. - A host MUST participate to defend the addresses it allocates. - At various times a host MUST actively determine if another host has allocated an address it has allocated. - Routers MUST route this protocol 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: - When more than one source uses an IP multicast address, the last host acting as a source for the IP multicast address MUST 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. Hattig [Page 17] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 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. 2.3.6 Requirements Summary Zeroconf IP multicast address allocation protocol requirements are: - A host that wishes to allocate a multicast address with a given scope and lifetime MUST select an address. - A host MUST determine if the address has been allocated by another host. - A host MUST participate to defend the addresses it allocates. - At various times a host MUST actively determine if another host has allocated an address it has allocated. - Routers MUST route this protocol to ensure it spans the entire locally scoped internet. - The protocol MUST allow the last source that uses a multicast address to deallocate the multicast address regardless of which node allocated the address. - 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. 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 [MODIFY MODIFY MODIFY ] As stated earlier, there is not really a non-zeroconf service discovery protocol; instead, the service discovery protocol must scale to larger networks. For this reason there are no transitional scenarios related to service discovery. The scenarios are the discovery of a simple printer service and the discovery of a printer manager that consolidates many printer services. Hattig [Page 18] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 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. Discovery MUST be possible by either the client actively soliciting the server or by the server 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. Printers vary in their characteristics such as location, status, dots per inch, drivers, etc. Discovering these characteristics MUST 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 discover by characteristic. However, characteristic discovery MUST be part of the service discovery protocol for those services without capability negotiation. 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. A discovery protocol itself MUST NOT require configuration. Note that configuration of the service discovery protocol is not to be confused with the configuration of the client or server protocol which places no requirements on the service discover protocol. 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 Hattig [Page 19] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 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. 2.4.3 Requirements Summary Zeroconf service discovery protocol requirements are: - The protocol MUST allow a client to discover the service by a service type, service identifier, and service characteristics. - The protocol MUST support solicitations and advertisements. - The protocol MUST be independent from any particular service. - The protocol MUST allow timely discovery of a service. - The protocol MUST allow clients to rediscover a service. - The protocol MUST NOT require user configuration. - The protocol MUST allow for registry. - The protocol MUST allow the client and server sides of the protocol to interact identically with and without a registry. - The protocol MUST include optional mechanisms to update a registry. 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 Hattig [Page 20] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 addition, this section describes four 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. 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' which 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' which could only be produced if in possession of the configuration data. Hattig [Page 21] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 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 service discovery protocol infrastructure it uses to discover services are 'legitimate.' 3.5 IPv6 Considerations [TBD] 4 IANA Considerations There are no known IANA considerations arising from this document. 5 Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise Hattig [Page 22] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 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 for hosting the first 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. 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 Hattig [Page 23] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 2111 NE 25th Ave. JF3 206 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 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 [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 Hattig [Page 24] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 [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 [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] Y. Goland et al, Simple Service Discovery Protocol, draft-cai-ssdp-v1-02.txt, June 1999, A work in progress. [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. Hattig [Page 25] Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000 [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 26]