Zeroconf WG M. Hattig Internet Engineering Task Force Editor INTERNET DRAFT Intel Corp. Expires July 2000 January 10, 2000 Zeroconf Requirements draft-ietf-zeroconf-reqts-02.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 for an adhoc purpose. Zeroconf networks do not have and should not be expected to have user configurable network infrastructure such as DHCP, 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 and the transitions between a Zeroconf protocol and a non-Zeroconf protocol are also discussed within each protocol area. Table of Contents Hattig [Page 1] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 1 Overview....................................................2 2 Introduction................................................3 2.1 Reading This Document.....................................3 2.2 Zeroconf Protocols........................................4 2.3 Zeroconf Networks........................................10 3 Scenarios..................................................16 3.1 IP Host Configuration Scenarios..........................16 3.2 Domain Name to IP Address Resolution Scenarios...........18 3.3 IP Multicast Address Allocation Scenarios................19 3.4 Service Discovery Scenarios..............................19 3.5 Additional Scenarios.....................................25 4 Security Requirements......................................25 4.1 ZeroConf Security Threat Analysis........................25 4.2 Security Requirements....................................26 5 Additional Considerations..................................28 5.1 IANA Considerations......................................28 5.2 Internationalization Considerations......................28 5.3 Security Considerations..................................28 6 Full Copyright Statement...................................28 7 Acknowledgements...........................................29 8 References.................................................30 1 Overview [Editor's Note: Most of the effort that has gone into version 02 has been devoted to section 2. With the exception of service discovery I believe section 2 is 95% done and hope that we'll close on all section 2 issues in the next few weeks. This should put us well on the way to finish by March 10th, which is the submission deadline for the next IETF meeting.] 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 for an adhoc purpose. Zeroconf networks typically do not have and should not be expected to have user configurable network infrastructure such as DHCP, 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 and the transitions between a Zeroconf protocol and a non-Zeroconf protocol are also discussed within each protocol area. This Zeroconf requirements document is a companion to a Zeroconf profile document. This requirements document lists requirements Hattig [Page 2] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 for protocols. The profile document relates the protocol requirements to actual protocols. In some cases, a protocol may meet all requirements to become one of the required protocols 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. The major sections to this requirements document are the Introduction, Scenarios, and Security. The introduction provides the background information to enable concise scenario discussions. Scenarios must be concise in definition and scope to generate useful protocol requirements. The security section lists threats and security requirements all four protocol areas. 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 presents how to best read this document and provides restrictions, assumptions, and terms. 2.1 Reading This Document This Introduction provides the necessary information to have a concise scenario discussion. This includes reference information, restrictions, assumptions, and terms. All readers should read the entire introduction. Of the scenarios listed in the Scenario section, different scenarios generate unique requirements but are not the only scenarios that could possibly generate those unique requirements. Each scenario has an overview, key points, and protocol requirements. The Security section lists threats and security requirements for each protocol area. Because this document deals four distinct protocol areas, many sections are divided into those areas. They are: - IP host configuration - Domain name to IP address resolution - IP multicast address allocation - Service discovery The below references follow this division with additional references for security and general knowledge. Note that some Hattig [Page 3] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 working groups are listed because they specify protocols that impact Zeroconf protocols. 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 - [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 - [DNS WG] DNS Update 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 All readers should be familiar with the general knowledge references. 2.2 Zeroconf Protocols Hattig [Page 4] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 A subsection below defines what "Zeroconf protocol" means. Then, additional subsections state the assumptions and restrictions of each protocol area. 2.2.1 Zeroconf Protocol Below is a definition of a Zeroconf protocol and a non-Zeroconf protocol. Additional discussions describe a host transitioning between Zeroconf and non-Zeroconf protocols, then the coexistence of these protocols. 2.2.1.1 Definitions A Zeroconf protocol requires no user configuration and does not rely on the existence of a centralized server. A non-Zeroconf protocol requires user configuration or relies on a centralized server. 2.2.1.2 Transitions A host using a Zeroconf protocol must easily transition in three ways: 1. from a Zeroconf protocol to a non-Zeroconf protocol, 2. from a non-Zeroconf protocol to a Zeroconf protocol, and 3. from a Zeroconf protocol back to a Zeroconf protocol (possibly with new values). The Zeroconf to non-Zeroconf transition occurs when either a host moves to a different network or when a server becomes accessible on the network. For example, if a DHCP server comes on-line after hosts are configured with [AutoNet], then hosts must re-configure with DHCP. The non-Zeroconf to Zeroconf transition occurs when either a device moves to a different network or when a server is no longer accessible. For example, if a DHCP server is no longer on the network then IP hosts must re-configure with [AutoNet]. The third transition occurs when a device moves from one Zeroconf network to another Zeroconf network or when the Zeroconf network topology changes significantly. For example, if a bridge is installed between two networks where hosts were already configured using [AutoNet], then hosts must re-configure with [AutoNet] to ensure duplicate IP addresses do not exist. A host can determine a transition is necessary by two methods: the host periodically checking if a transition is needed or by receiving a proactive mechanism from some entity that knows a transition is underway. Solutions SHOULD have both a periodic Hattig [Page 5] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 checking and a proactive mechanism (assuming the proactive mechanism uses an unacknowledged packet such as IP broadcast). Periodic checking ensures a host transitions even when that host does not receive the packet carrying the proactive mechanism. A proactive mechanism allows the time between periodic checks to be greater; thus the checking will not consume excessive bandwidth or processing resources. For example if the DHCP server broadcasts an "DHCPAck" with a new "I'm Here" option or "I'm Leaving" option as the proactive mechanism, then [AutoNet] must still send a periodic DCHPDiscover message. Note, the DHCP and [AutoNet] examples have no bearing on the stated requirements in this document. These examples were chosen simply because they are illustrative. 2.2.1.3 Coexistence A Zeroconf protocol in one area may 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 (two of the four protocol areas). 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 non-Zeroconf protocol-B (with its server) may coexist with the Zeroconf protocol-C. Alternately, Zeroconf and non-Zeroconf protocols from a single area SHOULD not coexist during normal operation. They may coexist during a transition, but the coexistence period SHOULD be minimal. 2.2.2 IP Host Configuration IP host configuration is required before virtually any IP communication can take place. In most cases, IP host configuration is complete when there is a known IP address, netmask, and default route for an interface on a host. DHCP is the common host configuration solution deployed today. DHCP consists of servers and clients. The client discovers the Hattig [Page 6] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 server, and then the server offers configuration parameters to clients. It is assumed that all Zeroconf IP host configuration schemes will co-existence with DHCP. In other words DHCP is the non-Zeroconf solution for IP host configuration. 2.2.3 Domain name to IP address resolution Web browsing to an URL utilizes domain name to IP resolution. This resolution capability allows applications (and sometimes 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 on hosts query the DNS servers for the information in resource records. DNS is the non-Zeroconf solution for domain name to IP address resolution. 2.2.4 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 the multicasted packets get transmitted beyond certain administrative domains (e.g. through a RFC 2365 boundary router). MADCAP is the non-Zeroconf IP multicast address allocation solution. MADCAP is a server-client protocol where clients request IP multicast addresses from a server. MADCAP operates much like DHCP. Zeroconf solutions are only concerned with IP multicast address scoped as site-local (i.e. 239.255.0.0/16). A boundary router (as described in [RFC 2365]) must be present to appropriately control multicast packets from entering and leaving the Zeroconf network. 2.2.5 Service Discovery Service discovery protocols have proven to be critical to the usability of networks. AppleTalk/NBP, NetBIOS/SMB and IPX/SAP are perfect examples in that they greatly improved the utility of their respective network architectures. 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 purposes. Hattig [Page 7] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 Also, unlike the other protocol areas, no incumbent service discovery protocol exists. Service Location Protocol version 2 (SLPv2) is defined in Standards Track RFC 2609. An Internet-Draft defines Simple Service Discovery Protocols (SSDP), which is another service discovery protocol. Considerable service discovery terminology is necessary to have a service discovery scenario discussion. The terms below are categorized into basic, processes, packet types, actions, then alphabetized within those categories. Following the terms is a list of service discovery protocol assumed requirements. Basic Terms: Process - A process is an implementation of an algorithm in software, hardware, or a combination of software and hardware. Service - A service is set of processes that do a wide range of network related things. Services range from printing to transferring a file to providing on-line pizza order and delivery service. A service may find some network management information, perform some action, control some resource, or perform just about any network-related function. Service Characteristics - Characteristics differentiate services. They may differential the same type of service in terms of capabilities (e.g. color printing vs black and white), state (e.g. printer ready vs paper jam), physical location (e.g. my office vs my home), and many other things. Characteristic may include service-unique information such as access information, version numbers, contact information, 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, but does not interact with, network and transport protocol layers. Service Identifier - A service may be identified by general service type as well as service characteristics. Clients, servers, advertisers, discoverers, and registries use service identifiers. Service Protocol - A service protocol is used between the client and the server after service discovery is complete. Processes: Advertiser - A process that advertises a service using a service discovery protocol. A server generally activates the advertiser. Hattig [Page 8] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 Client - A process that uses a service discovery protocol to discover a service. Discoverer - A process that discovers a service using a service discovery protocol. A client generally activates the discoverer. Registry - A process that acts as an intermediary between discoverers and advertisers. Servers 'register' service advertisements and other pertinent (e.g. authentication info, announcement criteria) with registries, then the service may be discovered from the registry instead of from a server. The registry may be centralized for a group of clients to access or cached within a single client. A registry reduces the number of queries to enhance the scalability of a service discovery protocol. Peer - A process that is both a client and service for a specific service protocol. Server - A process that offers a service to clients through a service discovery protocol. Packets Types: Service Advertisement - A solicited response issued by a server or registry. The advertisement provides the service identifier and possibly service characteristics. Service Solicitation - A request made by a client to obtain service advertisements. Service Announcement - An unsolicited informative message issued by a server or registry. The announcement provides the service identifier and possibly service characteristics. Registry update - A message that contains updated a registry information. It may cause one or more registry entries to be deleted, added, or modified. Actions: Client-Server negotiation: The act of a client using the service protocol to negotiate with a server after the service has been discovered with the service discovery protocol. Registry cleanup: An internal process of the registry to remove unwanted information. Service discovery: The act of a client discovering a service. Hattig [Page 9] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 Utilizing a service: The act of a client using a service after the service has been discovered. Assumed Service Discovery Protocol Requirements: A service discovery protocol MUST allow a client to discover then utilize a service. A discovery protocol itself MUST require no configuration. (Clients must know what they need and services must know what they are, but this is a service installation and configuration issue, not a service discovery issue.) A service discovery protocol SHOULD allow a client to use Solicitation messages with specific characteristics. This enables a client to avoid complex client-server negotiations that may occur after service discovery. Characteristics also allow human users to determine which service to use (browse). A service discovery protocol SHOULD limit the use of Service Announcement messages so as to not flood the network unnecessarily and most importantly not cause 'broadcast storms'. A service discovery protocol SHOULD automatically sense when it must stop multicasting requests from Discoverers to Advertisers and instead employ a Registry of some sort. A service discovery protocol MUST not cause scalability or operational problems in larger non-Zeroconf networks if clients and servers somehow transition to such networks. A service discovery protocol MUST be rich enough in its semantics to be able to represent a wide range of services. 2.3 Zeroconf Networks A Zeroconf network is a network that at some point in time has one or more Zeroconf protocols. By this definition, almost all networks are Zeroconf networks. This definition is intentionally broad to avoid mandating a network to be Zeroconf or exclude another network from using a Zeroconf protocol. The Internet and corporate LANs are considered non-Zeroconf networks because, today, these networks have little use for Zeroconf protocols. This section describes the existing Internet network model, the Zeroconf topologies, and a summary of the key points. 2.3.1 Existing Internet Model Hattig [Page 10] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 All networks in this document follow the Internet Model as described in [RFC 1812]. Specifically, networks consist of bridges, routers, hosts, link layer networks, and IP networks to form internets. A summary of the terms from [RFC 1812] that apply to this document are: - Bridge: a device that routes link layer packets (e.g. Ethernet packets) between link layer networks (e.g. Ethernet) based on the destination link layer addresses (e.g. 48-bit Ethernet address) of a packet. - Router: a devices that routes IP packets between IP networks based on the destination IP address of an IP packet. - IP network: a network that consists of hosts with interfaces that share the same network portion of their IP addresses. 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. - internet: a network that consists of multiple IP networks connected by routers. 2.3.2 Isolated Single IP Network In an isolated single IP network topology, hosts connect directly to each other without routers. This implies no connectivity to non-Zeroconf networks. Enabling isolated single IP networks is one of the primary motivations behind this document. Two instances of single IP-network topologies are shown in Figure 1 and Figure 2. ***************************************************** * Zeroconf Network * * * * ------ crossover cable ------- * * | | * * | | * * +------+ +------+ * * | Host | | Host | * * +------+ +------+ * * * ***************************************************** Figure 1. Cross-over cable Ethernet network The Zeroconf network in Figure 1 has two hosts connected through a crossover Ethernet cable. Infrared or other point-to-point wireless technologies are similar examples. These networks can be Hattig [Page 11] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 created and torn down on an adhoc basis for seminars, conferences, hour-long meetings, or for many other reasons. ***************************************************** * Zeroconf Network * * * * -------[ HUB ]------- * * | | | * * | | | * * +------+ +------+ +------+ * * | Host | | Host | | Host | * * +------+ +------+ +------+ * * * ***************************************************** Figure 2. Hosts connected by Ethernet Hub The Figure 2 Zeroconf network has a small number of hosts connected through an Ethernet hub. This may be a small office network or a gaming network. In this topology, IP broadcast packets reach all hosts and no routing takes place, thus a default route is not a needed configuration parameter. A host sending an IP packet SHOULD not AND the netmask with the destination IP address to determine whether to forward the IP packet to the default router or to send an ARP packet to resolve the destination IP address to a hardware address. Instead, hosts SHOULD always opt to use ARP; a default route existing or not existing in the IP host configuration determines this. 2.3.3 Single IP Network with a Gateway A specialized router called a gateway resides between the Zeroconf and non-Zeroconf networks. The single IP network within the Zeroconf network connects directly to the gateway. The gateway is a specialized router in that it restricts the routing of IP packets between the Zeroconf and non-Zeroconf networks. This restriction ensures autonomy of the Zeroconf network and avoids many security problems. In addition, the gateway acts as a multicast boundary router as defined in RFC 2365. Enabling single IP networks with a gateway is one of the primary motivations behind this document. Figure 3 shows the single IP network with a gateway topology. *************************** Hattig [Page 12] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 * * * non-Zeroconf * * Network * * * *************************** | | | +----------------+ **********************| Gateway |************************* * Zeroconf Network +----------------+ * * | * * | * * | IP Network * * ------------------------|----------------------------- * * | | | | | * * | | | | | * * | | | | | * * +------+ +------+ +------+ +------+ +------+ * * | Host | | Host | | Host | | Host | | Host | * * +------+ +------+ +------+ +------+ +------+ * * * ***************************************************************** Figure 3. Single IP Network with a Gateway Examples of this topology include a typical small business network with remote-access router and a single Ethernet segment. Another common example is a home network with an ADSL-modem and a single Home Phonewire Network Alliance (HomePNA) link connecting a few PCs. In this topology, broadcast packets reach all hosts and routing only occurs to communicate between Zeroconf and non-Zeroconf networks. All hosts SHOULD rely on netmask and the default route as a normal IP host does when determining to ARP or to forward packets to the default route. 2.3.4 Multiple IP Networks through a Gateway In this topology, all IP networks within the Zeroconf network connect directly to the gateway. Enabling this topology is a goal for this document. Figure 4 shows the general form of this topology. *************************** * * * Non-Zeroconf * Hattig [Page 13] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 * Network * * * *************************** | | | +----------------+ **********************| Gateway |************************* * Zeroconf Network +----------------+ * * | | | * * | | | * * | | | * * | | | * * IP network A | | | IP network B * * ------------------| | |---------------------- * * | | | | | * * | | | IP network C | | * * | | | | | * * +------+ +------+ +------+ +------+ +------+ * * | Host | | Host | | Host | | Host | | Host | * * +------+ +------+ +------+ +------+ +------+ * * * ***************************************************************** Figure 4. Multiple IP Networks through a Gateway The primary example of this topology is a future home network with many link layers such as HomePNA, HomeRF, IEEE 802.11, and IEEE 1394-1995. These link layers are installed because they either require no new wires (e.g. phone line, wireless, powerline) or provide some special function such as the ability to roam (e.g. wireless) or to carry high-quality video streams (e.g. IEEE 1394- 1995). Communication between IP networks within the Zeroconf network and between the Zeroconf and non-Zeroconf networks is achieved by utilizing the routing capability in the gateway; therefore all hosts SHOULD be configured with netmask and default route. Broadcasts do not reach all hosts within the Zeroconf Network; therefore, multicasting is the best solution to reach all hosts. In order for multicast packets to reach all hosts, the gateway must be a multicast router and act as a boundary router (as defined in RFC 2365) to restrict certain multicast packets from leaving the Zeroconf network. 2.3.5 Networks with Routers and Gateways In this topology, routers connect IP Networks within the Zeroconf network and gateways connect the Zeroconf network to the non- Zeroconf network. Hattig [Page 14] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 Supporting this topology is not a goal of this document because it would require router auto-configuration, router pre-configuration, or some router-to-router communication to somehow enable router configuration; this document in no way precludes such work in other documents. Zeroconf protocols that communicate between a host and a router to configure the host MAY be considered. Figure 5 shows a sample network with routers and gateways. ************************************* * * * Internet * * * ************************************* | | | | | | +----------------+ +------------+ *******************| Gateway |****| Gateway |*********** * Zeroconf Network +----------------+ +------------+ * * | | | IP network D * * | | | * * IP network A +--------+ | | IP network C +--------+ * * -----------| Router |---| |--------------| Router | * * | | +--------+ | | +--------+ * * | | |IP network B | | * * | | | | | * * +------+ +------+ +------+ +------+ +------+ * * | Host | | Host | | Host | | Host | | Host | * * +------+ +------+ +------+ +------+ +------+ * * * ****************************************************************** Figure 5. Routers and Gateways Network This topology is only applicable in a medium to large business; generally, these are not Zeroconf networks. 2.3.6 Summary The purpose of showing topologies is to make this document concise. The purpose is not to mandate some networks as Zeroconf and others as non-Zeroconf. The gateway is a specialized router. It restricts packets that pass between the Zeroconf and non-Zeroconf networks to ensure autonomy of the Zeroconf network and to avoid many security Hattig [Page 15] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 problems. The gateway SHOULD act as a boundary router as defined in RFC 2365. All Zeroconf protocols MUST operate in single IP networks (isolated and connected) and SHOULD operate in networks with multiple IP networks with a single gateway. It is beneficial, but not required, for Zeroconf protocols to operate in networks with multiple gateways and multiple routers. 3 Scenarios This section lists Zeroconf scenarios that lead to requirements for protocols. Specific protocols are not discussed. Each scenario begins with an explanation or overview. Then, the key points of the scenario are identified along with requirements. Each scenario has the following outline: - Overview - Key Points - Protocol Requirements The scenarios are grouped by IP host configuration, domain name to IP address resolution, IP multicast address allocation, and service discovery. The scenarios take place within a Zeroconf network unless otherwise stated. 3.1 IP Host Configuration Scenarios 3.1.1 Isolated Single IP Network Communication 3.1.1.1 Overview Hosts on a single IP network communicate to each other. 3.1.1.2 Key Points This scenario applies to single IP network topologies (isolated or with a gateway). Only the IP address must be configured. The netmask can be configured to a value or assumed to be 255.255.255.255. No default route is needed. 3.1.1.3 Protocol Requirements - IP hosts MUST configure an IP address. - IP hosts MUST configure a netmask or assume 255.255.255.255. - The host number of an IP address MUST be unique within a single IP network. Hattig [Page 16] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 - The network number of an IP address MUST equal the network number of other IP addresses within a single IP network. 3.1.2 Multiple IP Network Communication All the networks in this section are isolated from non-Zeroconf networks. 3.1.2.1 Overview Hosts on multiple IP networks within a Zeroconf network communicate to each other. 3.1.2.2 Key Points This scenario is important for star topologies and ad-hoc topologies. 3.1.2.3 Protocol Requirements - IP hosts MUST configure an IP address. - IP hosts MUST configure a netmask. - IP hosts MUST configure a default route. - The host number of an IP address MUST be unique within a single IP network. - The network number of an IP address MUST equal the network number of other IP addresses within a single IP network. - Network numbers of IP addresses MUST be unique within the entire Zeroconf network. - IP address MUST be routable within the Zeroconf network. 3.1.3 Bridge Installed 3.1.3.1 Overview Between two operational IP networks, a bridge (or hub) is installed. Now, two hosts on the newly formed IP network may 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. 3.1.3.2 Key Points 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. Hattig [Page 17] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 3.1.3.3 Protocol Requirements - Hosts MUST be able to re-configure their IP address and netmask after networks are connected. There is an addition requirment to your "periodic conflict detection" requirement. It is an active mechanism to restart conflict detction. This is needed in case the period is too large for a hosts needs. - All requirements in section 3.1.1.3. 3.1.4 Router Installed 3.1.4.1 Overview 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. 3.1.4.2 Key Points 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. 3.1.4.3 Protocol Requirements - Hosts MUST re-configure IP address, net mask, and default route at various times after the initial configuration. - All requirements in section 3.1.2.3. 3.2 Domain Name to IP Address Resolution Scenarios 3.2.1 Resolve Non-Fully Qualified Name 3.2.1.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. 3.2.1.2 Key Points Name resolution must span the entire Zeroconf network, but be limited by the gateway from leaving or entering the Zeroconf Hattig [Page 18] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 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. 3.2.1.3 Protocol Requirements - A host that wishes to be addressable by 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 the 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. 3.2.2 Resolve Fully Qualified Name [TBD] 3.2.2.1 Overview 3.2.2.2 Key Points 3.2.2.3 Protocol Requirements 3.3 IP Multicast Address Allocation Scenarios [TBD] 3.3.1 Allocate XX Scoped IP multicast address [TBD, one XX for each relevant scope.] 3.4 Service Discovery Scenarios 3.4.1 Discover Printer 3.4.1.1 Overview Networked enabled printers allow various clients to submit print jobs. There are different printing protocols possible (raw tcp, lpd, ipp, etc.) Further, printers vary in a number of ways (their location, status and capabilities). Printer discovery is Hattig [Page 19] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 important for both printing clients as well as 'printing managers' - that is, software which manages all printers of a particular kind on the network. 3.4.1.2 Key Points Printer discovery must allow a printing client to discover the location of a printer and enough information about the print job submission protocol to be able to submit jobs. Further printer discovery must discriminate between printers which are useful and those which are not. A printer which is located in a remote facility (across a continent) is not useful, nor is a printer which can't print in color, on transparencies, etc. if that is what the client needs to do. Printer discovery has to be timely - so that when a printer comes on line, a print client or a print manager application can discover the printer in a timely way. 3.4.1.3 Protocol Requirements Printer discovery implies the following requirements for service discovery. - The service discovery mechanism has to allow for discriminating queries. A client has to be able to discover a printer for which it has a driver, for instance. - Service discovery has to be able to discover the characteristics of an advertised service. A print client or a print manager has to be able to find out the configuration and possibly even status of the printer to be able to adequately provide information to the print client or print manager which is searching for appropriate print servers. This information may be used for a user interface or by a program so the format of the information has to be standardized. - Service discovery has to be able to be done in a 'timely way.' That is, within a short number of seconds after activating a print server, a user who is actively browsing for printer should be able to see the device appear in a browser window, or a printer manager should be able to begin managing the print server. 3.4.2 Discover File Access Server 3.4.2.1 Overview File sharing is done using different protocols. A file sharing client is only interested in file sharing services which use the access protocol it is capable of. File sharing is typically done by human users - in this case attributes of the file access server Hattig [Page 20] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 have to be discovered so the human user can select which server to access. File sharing is done on a 'session basis' so timely rediscovery of selected file servers is necessary. 3.4.2.2 Key Points File sharing is a key application of personal computing. There are a variety of file access protocols available (NFS, Novell file access protocol (?), AppleShare, NetBIOS/SMB, etc.) A client must be able to discover those file systems which exist on a network, which the client can get access to, that support the file access protocol the client is capable of using. Further, existing service discovery mechanisms for file access servers (from Novell, Apple and Microsoft proprietary protocols) allow the user to discover something about the file system they would access. This include the name of the file system, a human readable description of it as well as a 'group' or 'groups' that the file system was shared to. Since there may be many 'peers' in a network of personal computing devices, it is critical that some grouping is possible, so that users can locate file access servers that are meaningful to them (located nearby, shared by colleagues close to them in the organization, shared by those who will allow the user access to the files, file systems whose content is of a general kind, etc.) Further, grouping file access servers is important to allow the service discovery activity to be scalable in a network containing many systems capable of (or actively) providing file access service. This scalability consideration is different than the previous point (where grouping services prevents too much information to select from). In this case, scalability implies that requests will only be received and processed by a subset of the file access servers which advertise their services (or by a subset of the 'service discovery protocol infrastructure' to be more general). This will prevent service discovery from being a burden to the network. This is an extremely important point: Experience has shown that service discovery for services which are shared by many personal computers in larger networks can have disastrous effects. AppleTalk, Novell networks and Microsoft networks all suffer in performance for this reason. Finally, file access is typically done on a 'session' basis. That is, when a user decides to access a file system, he or she wants access to it over time. If the file system is not available for a time, the user wants to get access to it again when the file system is again available. If the client system is moved or deactivated, the user wants to be able to discover the same file system again when the client device Hattig [Page 21] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 is again able to locate the previously discovered and selected file access server. 3.4.2.3 Protocol Requirements File access server discovery implies the following requirements: - Clients can discover the location of file access servers which support the file access protocol they support. - Clients can discover only those file access servers which are in a 'group' they are interested in. This grouping has to be possible along a variety of different conceptual lines location, organizational - like which department, or functional - like a general description of the servers such as "reference library" or "mailing list archives".) This is possible in Novell, AppleTalk and Microsoft networks. It should be possible on IP networks in general. - The groupings listed above must be able to limit the effects of the file access protocol on the network. This allows for scalable service discovery in a larger network. - Clients can discover some information about file systems that they could choose to access (the name of the file system, a description of it and whether the user has access permission, at the very least). - Clients should be able to rediscover the file system over time so that the user can discover the same file access service even if that service goes down and comes back up, or if the client device moves or goes down, then is once again on a network where the file access server is present. 3.4.3 Discover Manageable Device 3.4.3.1 Overview One important application of service discovery is the discovery of manageable devices by a 'management' system. Conversely, manageable devices may need to discover their manager. The relationship between manager and managed system is different than is the case in most service discovery applications since the manageable device is in many respects a service with respect to the manager, but there is usually only one manager and many manageable systems. 3.4.3.2 Key Points Hattig [Page 22] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 The management system (manager) needs to be able to discover devices which support appropriate management services (management agents). Currently this discovery is done in many networks by having the manager scan all addresses in order to determine the location and existence of all agents. This does not scale well to larger address spaces. Managers need to discover agents in a timely way. That is, when an agent is activated, a manager needs to be able to discover it within a short number of seconds. Managers often need to discover a set of agents which have a certain configuration. For instance, only those agents running on a certain hardware platform, with a certain software version. This allows the manager to determine the population of agents which need an upgrade immediately. This is not to say that the service discovery mechanism should replace the management protocol (whereby the manager can interrogate the agent and obtain or set specific management information). The facility to find only specific agents allows the manager to discriminate among agents on the network so that it can interrogate only that subset that are relevent. This is important for scaling management software to larger networks where there may be many agents. This is even important on smaller networks where a specialized manager is only able to manager a very specific subset of all devices. 3.4.3.3 Protocol Requirements The service discovery mechanisms for managers to find agents (and thereby manageable devices) require the following: - Managers have to be able to find all agents they can manage. - Managers have to have the ability to discover agents shortly after they are activated. - Managers have to be able to discover only the subset of agents that are relevant. This means that managers have to be able to discover agents on the basis of their hardware, software or there device specification or status. To some extent the service discovery protocol has to return information about the agent to the manager, but this enhances the manager-agent relationship. It does not replace the management protocol which can do specific management operations (including very specific structured queries of an agent by a manager). 3.4.4 Discover Service Discovery Infrastructure 3.4.4.1 Overview Hattig [Page 23] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 Service discovery protocols have two modes: The first is used in a zeroconf environment. The protocol in this case may not scale very well in a larger environment. The second mode is to be used in a configured network. In this case, the service discovery protocol must scale well. Clients discovering services and servers offering services have to be able to discover 'service discovery infrastructure' when it is present and transition to its use. Further, configuration must be able to be supplied to clients and servers so that they will use the service discovery infrastructure scalably and appropriately. 3.4.4.2 Key Points Service discovery infrastructure has to be able to be discovered quickly, and by all clients and servers which are using a service discovery protocol. This allows for a transition from an ad hoc (multicast or broadcast based protocol) to one which is suitable for larger networks. This service discovery infrastructure provides a concentration of service discovery information so that point to point messages can be exchanged instead of all service discovery messages having to be either multicasted (either solicitations or advertisements). Clients and servers using a service discovery protocol in a zeroconf environment have to be able to obtain configuration. This configuration will enable the clients and servers to use specific portions of the service discovery infrastructure, or to use it in a particular way. This allows, for instance, services to be advertised according to a particular policy, as belonging to a particular department, in a particular location or network, etc. Similarly, clients obtaining configuration will only discover services which they are directed to, such as services in their department, hotel room, etc. 3.4.4.3 Protocol Requirements Requirements arising from discovery of service discovery infrastructure include: - Service discovery infrastructure provides a transition from zeroconf service discovery protocol use to scalable and configured service discovery protocol use. - Service discovery infrastructure has to be discoverable by clients and servers which use a service discovery protocol automatically, and reasonably quickly. The clients and servers have to use this infrastructure if it becomes available to ensure scalable behavior. Hattig [Page 24] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 - Configuration of clients and servers using a service discovery protocol has to be able to be done dynamicly. This way clients and servers will obtain the necessary configuration to operate effectively in larger networks according to the service deployment policy employed in the network the system is present in. 3.5 Additional Scenarios [EDITOR'S NOTE: Please post additional scenarios for discussion to Zeroconf@merit.edu. Eventually this section will be removed.] 4 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. 4.1 ZeroConf Security Threat Analysis 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. 4.1.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. 4.1.2 Domain name to IP address resolution Hattig [Page 25] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 Potential threats include: - A host could masquerade, responding to names requests illegitimately. - 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. 4.1.3 Multicast Address Allocation Potential threats include: - A host could hoard multicast addresses, denying others the ability to obtain them. 4.1.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. 4.2 Security Requirements Protocols designed for host configuration, name resolution, service discovery and multicast address allocation include security mechanisms. These protocols have been designed for use in configured networks. The same security mechanisms appropriate in a configured network is not useful in a ZeroConf network. ZeroConf requirements will not specify that all security threats be addressed by ZeroConf protocols since it would be inappropriate to do so. Security always requires configuration. For that reason, no secure operation will be possible on a network which has absolutely no configuration. That is not the same as saying that ZeroConf requirements are silent with respect to security. When configuration is added to a host using ZeroConf protocols, the host transitions to another mode of operation. In this case, the host which is appropriately configured may be able to counter threats posed to systems using ZeroConf protocols. The ZeroConf requirements specify the transition from insecure to secure operation. A host fulfilling ZeroConf requirements will be capable of secure operation in each protocol area, if it is Hattig [Page 26] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 supplied with appropriate security configuration (such as cryptographic keys.) 4.2.1 IP Host Configuration Hosts MUST be able to be configured to use DHCP authentication. Option 1: No provision is made for securing IP Host Configuration using the ZeroConf protocol for IP Host Configuration. Option 2: Hosts MUST be able to be configured to use a ZeroConf protocol for host configuration securely. For example, a claim and defend protocol used for host configuration 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. 4.2.2 Domain name to IP address resolution Hosts MUST be able to be configured to use DNS Security. Option 1: No provision is made for securing the ZeroConf Domain Name to IP address resolution protocol. Option 2: 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. 4.2.3 Multicast Address Allocation Hosts MUST be able to be configured to use MADCAP security. Option 1: No provision is made for securing the ZeroConf protocol for multicast address allocation. Option 2: Hattig [Page 27] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 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. 4.2.4 Service Discovery Both clients and servers MUST be able to be configured to use security mechanisms offered by the Service Discovery Protocol. These mechanisms 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 so that a server can use security configuration to advertise service information in a way that clients can verify. The service discovery protocol MUST provide mechanisms so that a client can use security configuration to verify service information it obtains. The client is essentially verifying that the server had possession of certain secrets. The client trusts that only 'legitimate' servers would possess these secrets. 5 Additional Considerations 5.1 IANA Considerations There are no known IANA considerations arising from this document. 5.2 Internationalization Considerations Zeroconf protocols may exchange human readable strings. Human readable strings may need to be internationalized. 5.3 Security Considerations Zeroconf security considerations are in Section 5 of this document. 6 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, Hattig [Page 28] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 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." 7 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 much of the text relating to service discovery and the security requirements. 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, Bernard Aboba, and David Thaler. Editor: Myron Hattig Intel Corporation 2111 NE 25th Ave. JF3 206 Hillsboro, OR 97124 myron.hattig@intel.com Hattig [Page 29] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 8 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 [RFC 2411] R. Thayer, IP Security Document Roadmap, RFC 2411, Nov 1998 Hattig [Page 30] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 [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. [NAT WG] Network Address Translation WG, www.ietf.org/html.charters/nat-charter.html. Hattig [Page 31] Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000 [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 32]