ZeroConf WG M. Hattig Internet Engineering Task Force Editor INTERNET DRAFT Intel Corp. Expires April 2000 October 21, 1999 ZeroConf Requirements draft-ietf-zeroconf-reqts-00.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 Zero Configuration (ZeroConf) Networks are a particular class of TCP/IP networks that may be established in the home, in small offices or even on an impromptu basis. ZeroConf Networks do not have and should not be expected to have user configurable network infrastructure such as DHCP servers, DNS and other administered services. This is because typical ZeroConf network users neither have the skill nor desire to configure, administer, or manage a network. This document presents ZeroConf protocol requirements for four areas: IP host configuration, domain name to IP address resolution, IP multicast address allocation, and service discovery. Security issues overlay each area. ZeroConf protocols in each these areas must transition easily to and from administered protocols. Hattig [Page 1] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 Table of Contents 1 Overview....................................................2 2 Introduction................................................3 2.1 Areas of work.............................................3 2.2 Reading This Document.....................................4 2.3 General Considerations....................................5 3 ZeroConf Network Architecture...............................6 3.1 Topologies................................................6 3.2 ZeroConf and non-ZeroConf Protocols......................12 3.3 Assumptions and Restrictions.............................13 4 Scenarios..................................................14 4.1 Single IP Network Host Configuration.....................14 4.2 Multiple IP Network Host Configuration...................15 4.3 Bridge Install between already operational IP Hosts......16 4.4 Router Install between already operational IP Hosts......16 4.5 IP Host Configuration with DHCP server...................17 4.6 Domain Name Resolution within an IP network..............18 4.7 IP Multicast Address Allocation..........................18 4.8 Service Discovery........................................19 4.9 Additional Potential Scenarios...........................20 5 Security Requirements......................................21 5.1 IP Host Configuration....................................21 5.2 Domain name to IP address resolution.....................21 5.3 Multicast Address allocation.............................21 5.4 Service Discovery........................................22 6 Additional Considerations..................................22 6.1 IANA Considerations......................................22 6.2 Internationalization Considerations......................22 6.3 Is service discovery conclusive?.........................22 6.4 Security Considerations..................................22 7 Full Copyright Statement...................................22 8 Editor.....................................................23 9 References.................................................23 1 Overview Zero Configuration (ZeroConf) Networks are a particular class of TCP/IP networks. These networks may be established in a home, in a small office or even on an impromptu basis. ZeroConf networks typically do not have and should not be expected to have user configurable network infrastructure such as DHCP servers, DNS and other administered services. This is because typical ZeroConf network users neither have the skill nor desire to configure, administer, or manage a network. This document presents ZeroConf protocol requirements for four areas: IP host configuration, domain name to IP address resolution, IP multicast address allocation, and service Hattig [Page 2] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 discovery. Security issues overlay each area. ZeroConf protocols in each these areas must transition easily to and from administered protocols. This ZeroConf requirements document is a companion to a ZeroConf profile document. This requirements document lists requirements for protocols. The profile document relates the protocol requirements to actual protocols. In some cases, a protocol may meet all requirements to become the required protocol for ZeroConf networks. When protocols are insufficient or multiple protocols are competing, the profile document states the requirements of the protocol and the relationship of the requirements to the existing protocols. In addition, the profile document shows how ZeroConf protocols transition between operating in a ZeroConf network and operating in a Non-ZeroConf network. Such transitions may be heavily influenced by connectivity of the ZeroConf network to a non- ZeroConf network such as the global Internet. The major sections to this requirements document are the Introduction, ZeroConf Network Architecture, Scenarios, and Security sections. Since this document deals with so many aspects of TCP/IP networking (i.e. service discovery to IP host configuration), the introduction lists the necessary background information and provides ideas for readers who wish to focus on specific topics. The ZeroConf Network Architecture defines the network assumed throughout this document. The scenarios clarify the scope covered by the document and motivate particular requirements of ZeroConf protocols. 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]. 2 Introduction This introduction specifically defines the term "Area", presents how to best read this document (including references), and presents general considerations for implementers of ZeroConf protocols. 2.1 Areas of work Throughout this document, when the word Area is capitalized, the word is referring the four Areas of protocol work in which this document focuses. These protocol Areas are: - IP host configuration - Domain name to IP address resolution Hattig [Page 3] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 - IP multicast address - Service discovery 2.2 Reading This Document This document deals with a wide range of networking topics. All readers may not be interested in all Areas. To help the reader focus on particular interests, this section describes the organization of the document, the background information for each Area, and explains different types of requirements. 2.2.1 Organization The first major section of this document defines the ZeroConf Network Architecture assumed throughout this document and assumed throughout the profile document. The Scenarios Section scopes the overall ZeroConf problem space to provide the framework for requirements of protocols. This section identifies some but not all requirements of protocols. This section mentions very little about specific protocols. There is a common outline for each scenario. The Security section lists security issues and requirements to prevent security problems. 2.2.2 Background information This section lists the background reference information for general knowledge, IP host configuration, domain name to IP address resolution, IP multicast address allocation, service discovery, and security. All readers should be familiar with at least the general knowledge references before reading this document. All readers should be familiar with the following documents: - [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 IP host configuration: - [IPv4Auto] Ipv4 Auto-Configuration ID - [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 - [DHC WG] Dynamic Host Configuration WG Hattig [Page 4] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 Domain name to IP address resolution: - [Mcast DNS] Multicast DNS - [RFC 1034] RFC 1034 DNS - [DNS WG] DNS Update WG Multicast address allocation: - [MADCAP] Multicast Address Dynamic Client Alloc Protocol ID - [RFC 2365] RFC 2365, Administratively Scoped Multicast Address - [MALLOC WG] Multicast Address Allocation WG Service discovery: - [SSDP] Simple Service Discovery Protocol ID - [RFC 2608] RFC 2608 Service Location Protcol v2 - [RFC 2609] RFC 2609 SLP Schemes Security background information is: - [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 2.2.3 Requirements This document identifies scenarios that drive the requirements for protocols. The requirements for protocols then help identify specific protocols. The ZeroConf profile document discusses specific protocols; this ZeroConf requirements document only discusses the requirements for those specific protocols. Requirements for protocols may have device specific aspects. For example, a router may automatically forward IP packets with a particular UDP port number between IP networks to make sure client requests reach a server on another IP network. To provide the proper device context, device descriptions are given along with particular device requirements when appropriate. 2.3 General Considerations These considerations are for vendors of ZeroConf networking software. 2.3.1 Continuing ZeroConfig Network Evolution ZeroConf networks are in their infancy. Many people speculate about which link layer technologies will be the most important, which devices will be most widely deployed, which applications will be the "killer", etc. etc. Because of this broad speculation and unpredictability the ZeroConf WG has limited the complexity Hattig [Page 5] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 of the networks it will consider. For example, at most a single router is considered in a ZeroConf network. These limitations are a practical matter to allow the WG to make progress. Without such limitations, the load of speculation would prevent the working group from addressing even simple matters. Vendors should be aware of these limitations and implement in a flexible way to allow their implementations to someday go beyond the restrictions imposed by the ZeroConf WG. 2.3.2 Configuration, Administration, and Management Ideally, user configuration, administration, and management do not occur in a ZeroConf network; this is the primary goal of the ZeroConf WG. In other words, ZeroConf networks should be self- healing and self-correcting. Despite this, there may be cases where minimal user intervention is necessary; the key word in this sentence is "minimal". 2.3.3 Error Log Messages A goal of the ZeroConf requirements is to automate basic functions to the extent that they will be transparent to the user. This will minimize the requirement for the user to either enter information or be presented with and interpret error conditions. It is quite likely, however, that error logging, and network management may be implemented on hosts supporting ZeroConf protocols. Further discussion of network management and operational issues is beyond the scope of this requirements document. 3 ZeroConf Network Architecture This section describes network topologies considered by this document and states assumptions about the operation of protocols in the ZeroConf Network. 3.1 Topologies ZeroConf networks follow the Internet Model as described in STD4. Specifically, ZeroConf networks consist of bridges, routers (gateways), hosts, link layer networks, and IP networks to form internets. Here is a summary of the terms in [RFC 1812] that apply to the ZeroConf Network Architecture: - Bridges route link layer packets (e.g. Ethernet packets) between link layer networks (e.g. Ethernet) based on the Hattig [Page 6] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 destination link layer addresses (e.g. 48-bit Ethernet address) of a packet. - Routers (a.k.a. gateways) route IP packets between IP networks based on the destination IP address of a packet. - An IP network consists of hosts with interfaces that share the same network portion of the IP address. A single IP network may physically consist of several link layer networks connected by a bridge, but it is one logical IP network; the hosts remain unaware of the bridge or multiple link layer networks. - An internet consists of multiple IP networks connected by routers. - Autonomous Systems (AS) are internets with a single operational and management organization (a.k.a. administrator), and a common set of routing protocols among the routers. A ZeroConf network is a single Autonomous System (AS). This simple statement implies many things. For example, service discovery queries, IP multicast packets, and other IP packets must stay within a single autonomous system. Also, such packets must not enter autonomous system; this avoids security problems. For the rest of this document, the term ZeroConf Network equates to a network within a single autonomous system and all that that implies. RFC 1812 defines different types of routers (e.g. transparent, embedded). The ZeroConf Network Architecture has two different types of routers. Both types of routers pass packets between IP networks based on destination IP address (as one would expect). The primary difference is that one of these routers resides at the border between the ZeroConf and the Non-ZeroConf network; thus this router must impose the restrictions necessary for the ZeroConf network to remain a single autonomous system. This router is called a "gateway" throughout the rest of this document. The second type of router routes between IP networks within the ZeroConf Network. Thus, this router has no responsibilities related to restricting the communication between ZeroConf and Non-ZeroConf Networks. This device is simply called a "router" throughout the rest of this document. The ZeroConf Network Architecture is limited to at most one router and/or at most one gateway. Zero routers and/or zero gateways are also part of the ZeroConf Network Architecture. Hattig [Page 7] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 Figures 1 and 2 show the simplest of ZeroConf networks considered by this document. Enabling these types of simple TCP/IP networks is among the primary motivations for this document. ***************************************************** * ZeroConf Network * * * * -------crossover-cable-------- * * | | * * | | * * +------+ +------+ * * | Host | | Host | * * +------+ +------+ * * * ***************************************************** Figure 1. Two hosts connected with a crossover cable. This ZeroConf network has two hosts connected through a crossover cable. A crossover cable between two hosts is the most common impromptu ZeroConf network. ***************************************************** * ZeroConf Network * * * * -------[ HUB ]------- * * | | | * * | | | * * +------+ +------+ +------+ * * | Host | | Host | | Host | * * +------+ +------+ +------+ * * * ***************************************************** Figure 2. Three hosts connected with a network with hub This ZeroConf network has a small number of hosts connected through a hub. A hub between hosts is the most common fixed- location ZeroConf network. This is the canonical ZeroConf network. Hattig [Page 8] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 Figure 3, Figure 4, and Figure 5 are examples of ZeroConf Networks that highlight the difference between a router and a gateway. Figure 5 is an example of a network not considered by this document. All these figures include connectivity to non- ZeroConf Network. Examples of a non-ZeroConf network are the global Internet and a corporate LAN. *************************** * * * Non-ZeroConf Network * * * *************************** | | | +----------------+ **********************| Gateway |************************* * ZeroConf Network +----------------+ * * | * * | * * | +--------+ * * --------------------------------| Bridge |--------------- * * | | | +--------+ | | * * | | | | | * * | | | | | * * +------+ +------+ +------+ +------+ +------+ * * | Host | | Host | | Host | | Host | | Host | * * +------+ +------+ +------+ +------+ +------+ * * * ***************************************************************** Figure 3. Single Gateway and Single IP Network. Figure 3 shows a single gateway and single IP network in the ZeroConf Network. The gateway routes packets between the ZeroConf Network and the Non-ZeroConf Network. The single IP network consists of multiple link layer networks connected by a bridge. Hattig [Page 9] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 *************************** * * * Non-ZeroConf Network * * * *************************** | | | +----------------+ **********************| Gateway/Bridge |************************* * ZeroConf Network +----------------+ * * | | * * | | * * +--------+ | | * * -----------| Router |---| |-------------------- * * | | +--------+ | | | * * | | | | | * * | | | | | * * +------+ +------+ +------+ +------+ +------+ * * | Host | | Host | | Host | | Host | | Host | * * +------+ +------+ +------+ +------+ +------+ * * * ***************************************************************** Figure 4. Single Gateway, Single Router, and Two IP Networks. Figure 4 shows a ZeroConf Network with a single gateway, a single router, and two IP networks. The gateway/bridge device is a gateway and a bridge. The bridge portion routes layer 2 packets between the two link layer networks attached to the gateway (within the ZeroConf network); these two link layers represent a single IP network. The router routes IP packets between the two IP networks within the ZeroConf Network. Hattig [Page 10] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 *************************** * * * Non-ZeroConf Network * * * *************************** | | | +----------------+ **********************| Gateway/Router |************************* * ZeroConf Network +----------------+ * * | | | * * | | | * * | | | * * ------------------| | |---------------------- * * | | | | | * * | | | | | * * | | | | | * * +------+ +------+ +------+ +------+ +------+ * * | Host | | Host | | Host | | Host | | Host | * * +------+ +------+ +------+ +------+ +------+ * * * ***************************************************************** Figure 5. Single Gateway, Single Router, and Three IP Networks. Figure 5 shows a ZeroConf Network with a single gateway, a single router, and three IP networks. The gateway/router device is a gateway and a router. The router portion routes IP packets between the three IP networks within the ZeroConf Network. The gateway portion routes IP packets between the ZeroConf Network and the non-ZeroConf Network. In ZeroConf Networks, routers route within the ZeroConf; gateways route between a ZeroConf and a non- ZeroConf (which are different autonomous systems); this is the distinction between a router and a gateway. Hattig [Page 11] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 *************************** * * * Non-ZeroConf Network * * * *************************** | | | +----------------+ **********************| Gateway/Router |************************* * ZeroConf Network +----------------+ * * | | * * | | * * +---------+ | | * * -----------| Router |---| |------------------- * * | | +---------+ | | | * * | | | | | * * | | | | | * * +------+ +------+ +------+ ------+ +------+ * * | Host | | Host | | Host | | Host | | Host | * * +------+ +------+ +------+ +------+ +------+ * * * ***************************************************************** Figure 6. Single Gateway, Two Routers, and Three IP Networks. Figure 6. shows a network that is NOT considered by this document because two routers are present. The gateway/router device includes a gateway and a router as in Figure 5. In addition, there is a second router in the network. Multiple routers within a single autonomous system create requirements beyond the scope of the document. Such requirements are coordination between routers and auto-configuration of routers. There are no additional topological restrictions on the ZeroConf Network Architecture. That is, there are no restrictions on the number of hosts, number of host names, or the number of services. 3.2 ZeroConf and non-ZeroConf Protocols In this document the term ZeroConf is overloaded. In addition to ZeroConf (and non-ZeroConf) Networks, this document uses the terms ZeroConf protocols and non-ZeroConf protocols. ZeroConf Network is a concept, not really a physical entity. The concept is that at some point in time one or more protocols within a network are ZeroConf protocols. In addition, non-ZeroConf protocols may coexist in this network with ZeroConf protocols. That is, not ALL protocols in a ZeroConf Network are ZeroConf protocols. Hattig [Page 12] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 To illustrate this point, suppose there are standard protocols to support ZeroConf requirements for IP host configuration and domain name to IP address resolution. For IP host configuration, the ZeroConf protocol is 'protocol-h.' The non-ZeroConf protocol is DHCP, supported by a fully conformant DHCP server. For domain name to IP address resolution, the protocol is 'protocol-d.' The non-Zeroconf protocol is DNS supported by a fully conformant DNS server. In a ZeroConf Network, both ZeroConf and non-ZeroConf protocols may exist in separate Areas. For example, protocol-h may exist with DNS (and a DNS server). However, within a single Area only a ZeroConf or non-ZeroConf protocol is used at a given point in time. Preference is always given to the non-ZeroConf protocol if it is present. For example, a DNS server implemented on a PC in the den is only available when the PC is powered-up; hosts must detect when the DNS server is present then use it; otherwise, they must use protocol-d. The strict definition of a ZeroConf Network is a network that at some point in time has one or more ZeroConf protocols. 3.3 Assumptions and Restrictions The architectural assumptions and restrictions for the ZeroConf Network Architecture are bounded by ZeroConf topologies and by the protocols (ZeroConf and non-ZeroConf) that operate within the ZeroConf Network. Topological assumptions and restrictions are: - No more than a single router exists in the ZeroConf network; zero routers are acceptable but two routers are not. - No more than a single gateway exists in the ZeroConf network; zero gateways are acceptable but two gateways are not. - No restrictions on the number of hosts or the number services exist. - A gateway prevents ZeroConf protocols from leaving the ZeroConf network. - A gateway prevents ZeroConf protocols from entering the ZeroConf Network from a non-ZeroConf Network. - A router must route ZeroConf protocols if the protocol is required to span the entire ZeroConf network. - A bridge connects similar link layer networks (e.g. HomePNA, IEEE 802.11, HomeRF are similar because they are Ethernet-like) - A router connects dissimilar link layer networks. (e.g. IEEE 1394-1995 is dissimilar from Ethernet) Hattig [Page 13] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 - A gateway device includes a router or a bridge when necessary and feasible. However, this may not be feasible for some networking link layers that cannot span the entire distance between the gateway and link layer specific hosts (e.g. ADSL gateway in a den and IEEE 1394-1995 MP3 Player in a family room). Protocol assumptions within each Area of work are: - A ZeroConf protocol exists. - A non-ZeroConf protocol exists. - A ZeroConf protocol transitions to non-ZeroConf protocol on a well-defined trigger. - A Non-ZeroConf protocol transitions to ZeroConf protocol on a well-defined trigger. - ZeroConf protocols re-initialize themselves on a well-defined trigger. 4 Scenarios This section lists ZeroConf scenarios. This section does not discuss specific protocols. Instead this section lists scenarios that provide a framework to produce requirements for protocols. Each scenario begins with an explanation or overview of the scenario. Then, the key points of the scenario are identified. These key points help identify the most likely Area of work related to the scenario. To consistently provide this information, each scenario has the following outline: - Overview - Key Points - Protocol Requirements Temporary Note: These scenarios have not been agreed upon by the ZeroConf WG, thus they will likely change. For this reason, only the limited information is provided for each scenario in the current draft. 4.1 Single IP Network Host Configuration 4.1.1 Overview Hosts on a single IP network within the ZeroConf network communicate to each other. To do this, hosts must configure their IP address and net mask. This scenario is of utmost importance. This scenario is most applicable to networks shown in Figures 1 and 2. 4.1.2 Key Points Hattig [Page 14] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 This scenario deals with the Area of IP host configuration. This scenario requires a unique host portion of the IP address for each host. The network portion of the IP address must be the same for each host. 4.1.3 Protocol Requirements - Host numbers of IP addresses MUST be unique within a single IP network. - Network numbers of IP addresses MUST be equal within a single IP network. - IP addresses MUST be private and not globally routable such as those listed in RFC 1918. - IP address MAY be routable within the ZeroConf network, but this is not required. 4.2 Multiple IP Network Host Configuration 4.2.1 Overview This scenario does not include a DHCP server. Hosts on multiple IP networks within a ZeroConf network communicate to each other. To do this, hosts must configure their IP address, net mask, and default route. 4.2.2 Key Points This scenario deals with the Area of IP host configuration. This scenario requires a unique host portion of the IP address for each host on an IP network. The network number portion of an IP address must be the same for each host on a single IP network. The network number portion of the IP address must be the unique within the ZeroConf network for each IP network. Each host must be configured with a default route. 4.2.3 Protocol Requirements - Host numbers of IP addresses MUST be unique within a single IP network. - Network numbers of IP addresses MUST be equal within a single IP network. - IP addresses MUST be private and not globally routable such as those listed in RFC 1918. - IP address MUST be routable within the ZeroConf network. - IP network numbers MUST be unique within the entire ZeroConf network. - The host MUST configure a default route. Hattig [Page 15] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 4.3 Bridge Install between already operational IP Hosts 4.3.1 Overview This scenario does not include a DHCP server. Within a single IP network, a bridge (or hub) is installed after IP hosts have been configured to communicate on a single IP network. Two hosts on a single IP network may now share the same IP address. In addition, hosts on different link layer networks may not have been using the same network number and now they must share the same network number. 4.3.2 Key Points This scenario deals with the Area of IP host configuration. This is a special case of a previous scenario when IP hosts first communicate on the same IP network. All the key points and requirements to the previous scenario apply. In addition, host must have the ability to re-configure their IP address and net mask. 4.3.3 Protocol Requirements - Hosts MUST re-configure IP address and net mask at various times after initial configuration. - All requirements in section 4.1.3. 4.4 Router Install between already operational IP Hosts 4.4.1 Overview This scenario does not include a DHCP server. Within a ZeroConf network, a router is installed after IP hosts have been configured to communicate throughout the ZeroConf network. Multiple IP networks within the ZeroConf network may now share the same IP network number. 4.4.2 Key Points This scenario deals with the Area of IP host configuration. This is a special case of a previous scenario when hosts on a multiple IP networks within a ZeroConf network communicate. All the key points and requirements to the previous scenario apply. In addition, host must have the ability to re-configure their IP address, net mask, and default route. 4.4.3 Protocol Requirements Hattig [Page 16] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 - Hosts MUST re-configure IP address, net mask, and default route at various times after the initial configuration. - All requirements in section 4.2.3. 4.5 IP Host Configuration with DHCP server 4.5.1 Overview This scenario is for single IP network or multiple IP network ZeroConf networks. Hosts communicate to each other. To do this, hosts must get their IP address, net mask, and default route from a DHCP server. There is only one DHCP server. 4.5.2 Key Points This scenario deals with the Area of IP host configuration. DHCP servers in ZeroConf networks do not require user configuration. Servers allocate private addresses that are not globally routable. However, the addresses must be routable within the ZeroConf network. DHCP servers ensure a unique host portion of the IP address for each host on an IP network. The DHCP server ensures the network number portion of an IP address is the same for each host on a single IP network. The DHCP server must provide a default route to each host. All hosts must implement a DHCP client. This places unique requirements on DHCP servers as well as hosts. If previously operation hosts achieve connectivity to the DHCP server through the installation of a bridge or router, hosts must somehow determine or learn about the presents of the DHCP server and request the appropriate information from the DHCP server. 4.5.3 Protocol Requirements - A DHCP server MUST be accessible by all hosts on the network. - The DHCP server MUST require zero-configuration by a user. - The DHCP server MUST only allocate private addresses that are not globally routable such as those listed in RFC 1918. - The DHCP server MUST ensure host numbers of IP addresses are unique within a single IP network. - The DHCP server MUST ensure network numbers of IP addresses are equal within a single IP network. - The DHCP server MAY ensure IP addresses are routable within the ZeroConf network, but this is not required. - All hosts MUST implement a DHCP client to retrieve their IP address, net mask, and default route. - Routers MUST implement DHCP rely agents. Hattig [Page 17] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 4.6 Domain Name Resolution within an IP network 4.6.1 Overview Domain names within the ZeroConf network must be resolved to IP addresses. This enables one of the most basic of TCP/IP networking paradigms of applications only being aware of host names and not IP addresses. 4.6.2 Key Points This scenario deals with the Area of domain name to IP address resolution. Name resolution must span the entire ZeroConf network, but be limited by the gateway from leaving or entering the ZeroConf network. This protocol should include the ability for a host to choose a name, determine if the name is in use, and then choose a different name if it is re-used. The name resolution 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 a bridge. 4.6.3 Protocol Requirements - A host that wishes to be addressable by DNS name MUST select a domain name. - A host MUST determine if the domain name is in use by another host. - A host MUST participate to defend a name it uses. - A host MUST be able to reconfigure its name in the case it was unable to successfully defend the name it previously used. - At various times a host MUST actively determine if another host is using its name. - Gateways MUST restrict this protocol from leaving or entering the ZeroConf network. - Routers MUST route this protocol to ensure it spans the entire ZeroConf network. 4.7 IP Multicast Address Allocation 4.7.1 Overview Numerous protocols have a need for dynamically allocated IP multicast addresses. Traditionally these have been audio or video streaming protocols; however, of late, data applications such as stock quotes or hourly news are increasing sent encapsulated in packets destined to IP multicast addresses. Hattig [Page 18] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 4.7.2 Key Points This scenario deals with the Area of domain name to IP address resolution. IP multicast address allocation protocol must be routed through the entire ZeroConf network; however, the gateway limits this protocol from leaving or entering the ZeroConf network. In addition to limiting the multicast allocation protocol, the gateway limits the packets that utilize the allocated IP multicast addresses. 4.7.3 Protocol Requirements - All hosts MUST allocate IP multicast address from the same pool. - The pool of IP multicast addresses MUST NOT be globally accessible (e.g. Administratively scoped IP multicast addresses in [RFC 2365]) - Routers MUST route packets destined to this pool of IP multicast addresses. - Gateways MUST limit packets destined to this pool of IP multicast addresses from leaving or entering the ZeroConf network. - One and only one host MUST be identified as the owner of each allocated IP multicast address. - The owner MUST deallocate the IP multicast address whenever possible. - Allocated IP multicast addresses MUST automatically become deallocated if owner stops operating. - Ownership MUST be able to pass from one host to another, in the case the original owner wishes to stop participation in the use of the IP multicast address and another host wishes to continue participation in the use of the IP multicast address. 4.8 Service Discovery 4.8.1 Overview A key component to the ZeroConf network is service discovery without user-configured servers. This requires a common definition a service and common methods for clients (hosts wanting a service) to find service-specific servers (hosts providing a service). When multiple servers provide the same service, hosts and/or people must be able to pick a preferred server based on service specific attributes, connectivity, physical location of the server, or other metrics. For example, a small business may have a high quality color printer, a printer that prints a high number of pages per second, Hattig [Page 19] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 or a printer in a particular office. A person may want to print to the color printer, print to the fast printer, or the closest printer. Of course, many other metrics may exist. 4.8.2 Key Points This scenario deals with the Area of service discovery. A service must be identifiable and instrumentable. Instrumentation allows attributes to be identified and utilized by people or programs. Clients should be able to discover services through passive advertisements by the servers and through active queries by the client. 4.8.3 Protocol Requirements - A service MUST be identifiable. - A service MAY be instrumentable. - Servers MAY have the ability to advertise service. - Servers MAY have the ability to respond to client queries. - Clients MAY have the ability to use service advertisements. - Clients MAY have the ability to query for services. - Clients and servers MAY have the ability present the instrumentation of a service to people. - Clients and servers MAY have the ability to programmatically use instrumentation of a service. 4.9 Additional Potential Scenarios - A ZeroConf host accessing the global Internet through the gateway. - Multiple ZeroConf hosts simultaneously accessing the Internet through the gateway. - ZeroConf host accessing a corporate LAN through the gateway and a corporate firewall. - Allow access from the Internet to a ZeroConf server (e.g. household WEB server). - Allow access from the Internet to multiple ZeroConf servers (e.g. family WEB server and individual family-member WEB server). - Host connecting to another ZeroConf network through a non- ZeroConf network and a gateway at the border of each ZeroConf network. - Browsing and human friendly identifiers (service type name, internationalization, attributes) - Device Identification & Discovery - ZeroConf host interoperates with Ad Hoc host via MANET. - Behavior upon receiving router advertisements Hattig [Page 20] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 5 Security Requirements The principal goal of security requirements for ZeroConf networking is to not make IP networking less secure than it is without the use of ZeroConf protocols. This is challenging since ZeroConf provides the ability for any host to obtain host configuration, to discover and to use network resources. In the case where ZeroConf access media is physically accessible (e.g. wireless, powerline) or routed to additional network segments, there is no longer any physical security. The following sections are security considerations for the four Areas which this document addresses. The threats fall into three broad categories: 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. [TO DO: Add security requirements after potential threats have been identified and selected as requiring attention by the ZEROCONF Working Group.] 5.1 IP Host Configuration Potential threats include: - A host could hoard IP addresses, denying others access to the network. - A host could pose as an antagonistic DHCP server and misconfigure other hosts on the network. 5.2 Domain name to IP address resolution Potential threats include: - A host could masquerade, responding to names requests illigitimately. - A host could hoard names, responding to all 'claim' requests. - A host could pose as an antagonistic DNS server and fail to resolve names correctly, or intentionally resolve them incorrectly. 5.3 Multicast Address allocation Potential threats include: Hattig [Page 21] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 - A host could hoard multicast addresses, denying others the ability to obtain them. 5.4 Service Discovery Potential threats include: - Servers could masquerade by responding to service discovery requests which 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. 6 Additional Considerations 6.1 IANA Considerations There are no known IANA considerations arising from this document. 6.2 Internationalization Considerations ZeroConf protocols may exchange human readable strings. Human readable strings may need to be internationalized. 6.3 Is service discovery conclusive? When service discovery is successful, should the client be able to use the service, or do we assume that it may not be able to. In the former case service discovery finds only those services that match the client's capabilities and requirements. In the latter case the client may have to perform feature negotiation with the service - the result of which may be that the client is not able to use the service. 6.4 Security Considerations ZeroConf security considerations are in Section 5 of this document. 7 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 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 Hattig [Page 22] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 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." 8 Editor Myron Hattig Intel Corporation 2111 NE 25th Ave. Hillsboro, OR 97124 myron.hattig@intel.com 9 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 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. Hattig [Page 23] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 [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. [IPv4Auto] 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. [DisAuto] R. Troll, DHCP Option to Disable Stateless Auto- Configuration in IPv4 Clients draft-ietf- autoconfig-04.txt February, 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. [MADCAP] iS. Hanna, B. Patel, M. Shah Multicast Address Dynamic Client Allocation Protocol (MADCAP) draft- Hattig [Page 24] Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999 ietf-malloc-madcap-05.txt May 1999. A work in progress. [SSDP] Y. Goand 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. [NAT WG] Network Address Translation WG, www.ietf.org/html.charters/nat-charter.html. [DNS WG] DNS Update WG, www.ietf.org/html.charters/dnsind- charter.html [MALLOC WG] Multicast Allocation WG Charter, www.ietf.org/html.charters/malloc-charter.html. Hattig [Page 25]