Zeroconf WG M. Hattig Internet Engineering Task Force Editor INTERNET DRAFT Intel Corp. August 31, 2001 Expires in six months Zeroconf IP Host Requirements draft-ietf-zeroconf-reqts-09.txt Status of This Memo This document is a submission by the Zeroconf Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the zeroconf@merit.edu mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC 2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract Many common TCP/IP protocols such as DHCP [RFC 2131], DNS [RFC 1034, RFC 1035], MADCAP [RFC 2730], and LDAP [RFC 2251] must be configured and maintained by an administrative staff. This is unacceptable for emerging networks such as home networks, automobile networks, airplane networks, or ad hoc networks at conferences, emergency relief stations, and many others. Such networks may be nothing more than two isolated laptop PCs connected via a wireless LAN. For all these networks, an administrative staff will not exist and the users of these networks neither have the time nor inclination to learn network administration skills. Instead, these networks need protocols that require zero user configuration and administration. This document is part of an effort to define such zero configuration (zeroconf) protocols. Before embarking on defining zeroconf protocols, protocol requirements are needed. This document states the zeroconf protocol Hattig Expires: February 2002 [Page 1] Internet Draft Zeroconf IP Host Requirements August 2001 requirements for four protocol areas; they are: IP interface configuration, translation between host name and IP address, IP multicast address allocation, and service discovery. This document does not define specific protocols, just requirements. The requirements for these four areas result from examining everyday use or scenarios of these protocols. Table of Contents 1 Introduction................................................2 1.1 Key Words.................................................3 1.2 Reading This Document.....................................3 1.3 Zeroconf Coexistence......................................3 1.4 Scalability...............................................4 1.5 Routable Protocol Requirement.............................4 1.6 Conflicts and State Changes Requirement...................4 2 Scenarios & Requirements....................................4 2.1 IP Interface Configuration................................5 2.1.1 IP Packet-Sending.......................................5 2.1.2 Bridge Installed........................................5 2.1.3 IPv6 Considerations.....................................6 2.2 Translation between Host name and IP Address Scenarios....6 2.2.1 Web Browsing............................................6 2.2.2 Host name Selection.....................................7 2.2.3 IPv6 Considerations.....................................7 2.3 IP Multicast Address Allocation Scenarios.................7 2.3.1 Scope Enumeration.......................................8 2.3.2 Address Selection.......................................8 2.3.3 Multiple Source.........................................9 2.3.4 IPv6 Considerations.....................................9 2.4 Service Discovery Scenarios...............................9 2.4.1 Printer Service........................................10 2.4.2 IPv6 Considerations....................................10 3 Security Considerations....................................10 3.1 IP interface configuration...............................11 3.2 Name to Address Resolution...............................12 3.3 Multicast Address Allocation.............................13 3.4 Service Discovery........................................13 4 IANA Considerations........................................14 5 Full Copyright Statement...................................14 6 Acknowledgements...........................................14 7 References.................................................15 1 Introduction A zeroconf protocol is able to operate correctly in the absence of configured information from either a user or infrastructure services such as conventional DHCP [RFC 2131] or DNS [RFC 1034, RFC 1035] servers. Zeroconf protocols may use configured information, when it is available, but do not rely on it being present. The use Hattig Expires: February 2002 [Page 2] Internet Draft Zeroconf IP Host Requirements August 2001 of MAC addresses (i.e. layer two addresses) as parameters in zeroconf protocols is generally acceptable because they are globally unique and readily available on most devices of interest. The benefits of zeroconf protocols over existing configured protocols are an increase in the ease-of-use for end-users and a simplification of the infrastructure necessary to operate protocols. This document discusses requirements for zeroconf protocols in four areas: - IP interface configuration - Translation between host name and IP address - IP multicast address allocation - Service discovery Security considerations are also discussed. 1.1 Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 1.2 Reading This Document Introduction, Scenarios & Requirements, and Security Considerations are the major sections of this document. The Scenarios & Requirements section walks through protocol scenarios and then lists the requirements of the protocol needed to accomplish the scenario. The Security Consideration section lists security issues with zeroconf protocols. Requirements dispersed throughout this document begin with the text "Requirements:" or "Requirement:" on a single line, which is followed by a bulleted list of requirements. 1.3 Zeroconf Coexistence It is not necessary to simultaneously use zeroconf protocols in all four areas (i.e. IP interface configuration, translation between host name and IP address, IP multicast address allocation, service discovery). For example, it might make sense on some networks to provide a DHCP server for configured IP interface configuration, but perform translation between host name and IP address using a zeroconf protocol. Hattig Expires: February 2002 [Page 3] Internet Draft Zeroconf IP Host Requirements August 2001 1.4 Scalability The primary reasons to deploy Zeroconf protocols are simplicity and ease-of-use. Scalability is important but it is a secondary goal. Thus, scalability should not detract from the primary goals of simplicity and ease-of-use. 1.5 Routable Protocol Requirement If a protocol is intended to span multiple IP subnets it MUST NOT use broadcasts or link-local addressing. Requirement: - Protocols intended to span multiple IP subnets MUST NOT use broadcasts or link-local addressing. 1.6 Conflicts and State Changes Requirement Topology changes or other events such as adding and removing hosts may cause conflicts and state changes within a protocol. Zeroconf protocols must be able to resolve conflicts and state changes caused by topology changes or other events. The scenario in the 2.1.2 Bridge Installed section is the only scenario that illustrates the need for this requirement, thus the below requirement is duplicated in section 2.1.2. However, this requirement applies to all protocol areas. Address configuration detects and eliminates duplicate addresses. Name resolution allows resolution of names which could not previously be resolved. In particular, if a host wishes to resolve its own name to determine if it unique, it will be able to detect if responder indicates that it is not. Service discovery allows discovery of previously undiscovered services. Multicast address allocation detects and eliminates duplicate address allocations. Requirement: - MUST respond to state changes and resolve conflicts in a timely manner. 2 Scenarios & Requirements This section contains a subsection for each of the four protocol areas. Within each subsection, terms and assumptions are followed by specific representative scenarios that lead to zeroconf protocol requirements in that area. Each subsection ends with IPv6 considerations. Hattig Expires: February 2002 [Page 4] Internet Draft Zeroconf IP Host Requirements August 2001 2.1 IP Interface Configuration In this document, IP interface configuration always includes the configuration of an IP address and netmask; it may include some routing information (such as default route). IP interface configuration is needed before almost any IP communication can take place. Terms: IP subnet - A single logical IP network that may span multiple link layer networks. All IP hosts on the IP subnet communicate without any layer 3 forwarding device (e.g. router). internetwork - Multiple IP subnets connected by routers. network - context sensitive term that may apply to one or more of the terms: a link layer network, an IP subnet, or an internetwork. bridge - a networking device that connects two link layer networks by using only link-layer protocols (e.g. Ethernet). The IP interface configuration scenarios are two IP packet-sending scenarios and a bridge install scenario. 2.1.1 IP Packet-Sending These scenarios consist of sending an IP packet from one host to another. These scenarios apply to any IP packets with a unicast destination IP address. There are two sub-scenarios. In the first, both the sender of the IP packet and the receiver of the IP packet are on the same IP subnet. In the second, the two senders are on different IP subnets within an internetwork. Requirements: - MUST configure an appropriate netmask. - MUST have unique IP addresses within an IP subnet. - MUST allow configuration of zero or more gateways (for the internetwork scenario). - MUST have unique IP subnets within an internetwork (This is only for the case when there is one or more router attached in the network where autoconfigured hosts. How routers obtain their configuration is beyond of the scope of this document.) 2.1.2 Bridge Installed This scenario starts with two completely operational link-layer networks with two distinct IP networks in which IP interface configuration was completed with a zeroconf protocol on each network. These two link-layer networks logically become a single Hattig Expires: February 2002 [Page 5] Internet Draft Zeroconf IP Host Requirements August 2001 link-layer network after a newly installed bridge connects them. Somehow the hosts operating on the two IP networks must now configure themselves to operate as a single IP network. Since the bridge connects the networks at the link-layer, there is no change in link status from off to on, which is the usual signal used in Ethernet networks for IP hosts to configure. Topology changes or other events such as adding and removing hosts may cause changes to the overall system state, invalidate assumptions made by some protocols, and lead to incorrect or undesirable operating states. Zeroconf protocols must be able to detect and resolve conflicts and state changes caused by topology changes or other events in some cases. The scenario in the 2.1.2 Bridge Installed section is the only scenario that illustrates the need for this requirement, thus the below requirement is duplicated in section 2.1.2. However, this requirement applies to all protocol areas. Requirement: - MUST resolve conflicts and state changes in a timely manner. 2.1.3 IPv6 Considerations IPv6 allows a host to select an appropriate IP address and netmask, using available routing information, thus if a host is using IPv6, a zeroconf IP interface configuration solution already exists. 2.2 Translation between Host name and IP Address Scenarios Host names allow users to refer to hosts using names instead of IP addresses. This is among the most fundamental, thus most important, usage paradigms in TCP/IP networking. Terms: host name - A textual name that allows a user to refer to a host by name rather than IP address. domain name - Zero or more textual labels, separated by dots, that identify a DNS domain [RFC 1034] [RFC 1035]. resolver - The host needing a name to IP address translation. The scenario for translation between host name and IP address is Web browsing. In addition, host name selection is discussed. 2.2.1 Web Browsing Applications, such as web browsers, make extensive use of DNS resolver functions. A mechanism to support DNS resolver interfaces in the zero configuration environement is required. Hattig Expires: February 2002 [Page 6] Internet Draft Zeroconf IP Host Requirements August 2001 Requirement: - MUST support DNS application layer interfaces as described in RFC 1123, section 6.1. [RFC 1123] 2.2.2 Host Name Selection How the host is administratively assigned a domain name is determined by some other configuration protocol or user configuration, and is not part of this zeroconf scenario. A protocol must allow a host to determine if its name is unique. If the name is not unique, the protocol must notify the user or some IP interface configuration software to select another name then repeat the process of verifying the uniqueness of the name. Requirement: - MUST allow a host to determine if its name is unique. Then if not unique, notify the user or configuration software so that another name may be chosen and similarly verified. 2.2.3 IPv6 Considerations Protocols to perform translation between host name and IP address have no zeroconf-related differences for IPv4 and IPv6. 2.3 IP Multicast Address Allocation Scenarios IP Multicast is used to conserve bandwidth for multi-receiver bulk-delivery applications, such as audio, video, or news. IP Multicast is also used to perform a logical addressing function. For example, when a host needs to communicate with local routers, it can send packets to the all-routers multicast address without having to know in advance the IP address(es) of the router(s). IPv4 multicast addresses range from 224.0.0.0 to 239.255.255.255. [RFC 2365] defined multicast scopes are: node-local (unspecified for IPv4) link-local (224.0.0.0/24) local (239.255.0.0/16) site-local (unspecified for IPv4) organizational-local (239.192.0.0/14) global (224.0.1.0-238.255.255.255) A relative assignment is an integer offset from the highest address in the scope and represents a 32-bit address. For example, within the local scope, 239.255.255.0/24 is reserved for relative allocations. Source-Specific Multicast [SSM] addresses are 232.0.0.0 to 232.255.255.255. Hattig Expires: February 2002 [Page 7] Internet Draft Zeroconf IP Host Requirements August 2001 Unicast-prefix-based IPv6 multicast addresses are defined, as well as source-specific multicast addresses for IPv6, in [SS6]. Assumptions: - The node-local and SSM addresses require no protocol or interaction between multiple hosts, thus are not mentioned further in this document. - Global and organizational scoped addresses are meant for networks of a greater scale than zeroconf protocols, thus are not mentioned further in this document. - Only local, link-local and site-local scopes are considered further in this document. - If it is desirable to restrict multicast packets from entering and leaving a multicast scope boundary, it is assumed that the router at the boundary is a "boundary router" as described in [RFC 2365]. Scenarios are scope enumeration, address allocation, and multiple sources. 2.3.1 Scope Enumeration Applications that leave the choice of scope up to the user require the ability to enumerate what scopes the host is operating within. In addition, services that are assigned relative addresses require the ability to enumerate what scopes the host is within; only then will a host be able to apply the relative address to a scope. Requirements: Application support software used to autoconfigure multicast addresses - MUST list which of the scopes (local, link-local, or site-local) are available for hosts. - MUST list per-scope address ranges that may be allocated. 2.3.2 Address Allocation IP multicast address allocation (local, link-local and site-local scopes only) requires an application to be able to request the use of a suitable multicast address. Coordination among applications must occur to avoid conflicting allocations of the same address. This coordination must span the entire scope respective to the address. When an allocated address is no longer required, that address MUST become available for use again. Requirements: - MUST select a multicast address. - MUST prevent conflicting allocations of the same address. - MUST allow the multicast address to become available after the address is no longer in use. Hattig Expires: February 2002 [Page 8] Internet Draft Zeroconf IP Host Requirements August 2001 2.3.3 Multiple Source An intercom system inside a home is an example of a multiple source IP multicast application. In this type of application, several sources may be sending packets destined to the same IP multicast address. This multiple source example illustrates the problem that a particular address may continue to be valid, even after the host that initially allocated the address is no longer present; the zeroconf multicast address allocation must correctly support this type of operation. In other words, if a host allocates a multicast address, then leaves the multicast group, some other host must defend the address. Requirements: - A host other than the allocating host MUST be able to defend or otherwise maintain the allocation of a multicast address. 2.3.4 IPv6 Considerations To date, no range has been reserved for source-specific addresses in IPv6. See [SS6]. Hence, until such a range is reserved, dynamic allocation of source-specific addresses applies only to IPv4. To date, no range has been reserved for dynamic allocation of Link-scoped addresses in IPv4. Hence, unless such a range is reserved, dynamic allocation of link-scoped addresses applies only to IPv6. 2.4 Service Discovery Scenarios Service discovery protocols allow users or software to discover and select among available services. This removes the requirement that the user or client software know a server's location in advance in order for the cleint to communicate with the server. Terms: service - a particular logical function that may be invoked via some network protocol, such as printing, storing a file on a remote disk, or even perhaps requesting delivery of a pizza. service characteristics - Characteristics provide a finer granularity of description to differentiate services beyond just the service type. For example if the service type is printer, the characteristics may be color, pages printed per second, location, etc. service discovery protocol - A service discovery protocol enables clients to discover servers (or peers to find other Hattig Expires: February 2002 [Page 9] Internet Draft Zeroconf IP Host Requirements August 2001 peers) of a particular service. A service discovery protocol is an application layer protocol that relies on network and transport protocol layers. service protocol - A service protocol is used between the client and the server after service discovery is complete. The scenarios are the discovery of a simple printer service. 2.4.1 Printer Service Network-enabled printers allow various network clients to submit print jobs. A service discovery protocol MUST allow a printer service to be discovered by devices needing to print. This requires a service type as well as a service identifier to distinguish instances of a single service type. Service discovery MUST be independent from any particular printing protocol such as lpd, raw-tcp, ipp. Printers vary in their characteristics such as location, status, dots per inch, etc. Discovering a service based on these characteristics SHOULD be part of the service discovery protocol. Service discovery MUST complete in a timely (10s of seconds) manner. Requirements: - MUST allow a service to be discovered. - MUST discover via service identifier and/or service type. - MUST discover services without use of a service-specific protocol. - SHOULD discover via service characteristics. - MUST complete in a timely (10s of seconds) manner. 2.4.2 IPv6 Considerations Service discovery protocols have no zeroconf related differences for IPv4 and IPv6. 3 Security Considerations The principal goal of Zero Configuration protocols is to provide network configuration where existing configuration and configuration services are unavailable. This is at odds with secure operation since security mechanisms generally require some pre-configuration (such as keys, certificates, etc.). Generally speaking, security mechanisms in IETF protocols are mandatory to implement. A particular implementation might permit a network administrator to turn off a particular security mechanism operationally. However, implementations should be "secure out of the box" and have a safe default configuration. Zeroconf protocols MUST NOT be any less secure than related Hattig Expires: February 2002 [Page 10] Internet Draft Zeroconf IP Host Requirements August 2001 current IETF-Standard protocols. This consideration overrides the goal of allowing systems to obtain configuration automatically. This section explicitly describes what this requires of each protocol area. Security threats to be considered include both active attacks (e.g. denial of service) and passive attacks (e.g. eavesdropping). Protocols that require confidentiality and/or integrity should include integrated confidentiality and/or integrity mechanisms or should specify the use of existing standards-track security mechanisms (e.g. TLS [RFC 2246], ESP [RFC 1827], AH [RFC 2402]) appropriate to the threat. 3.1 IP interface configuration Specific risks arise due to not securing IP interface configuration. An active attacker could completely or selectively prevent hosts from being properly configured. If an attacker 'hoards' all IP addresses, inappropriately claiming to be configured with them, this would prevent other hosts from effectively participating in IP interface configuration. An active attacker could be more selective and instead of claiming it has all IP addresses, it could claim this only in response to requests from a specific host (or hosts) to deny them service. It might also be possible that an active attacker could partially misconfigure one or more victims to cause these nodes to have partial (but not full) use of the network service. IP communication relies on lower level address resolution protocols (ARP [RFC 826] or IPv6 Neighbor Discovery [RFC 2461]). In the case of ARP and its cousins (e.g. inverse ARP, reverse ARP, proxy ARP), there is no standard security mechanism. Neither the integrity of the message is checked nor is the identity of the message source authenticated. This makes it possible for an active attack to subvert these protocols. Since the scope of these protocols is limited to a single broadcast network, the potential range of the risk due to this attack is limited. The effect of the attack, however, is to potentially disrupt all communication on the local link. It is appropriate not to require IP interface configuration protocols to implement security mechanisms when these hosts (and others) will then proceed to perform subsequent communication using insecure mechanisms such as ARP. Thus hosts using insecure IP interface configuration are ultimately no more vulnerable to attack than other hosts on the network configured using some other more secure mechanism. The security requirements demand that zeroconf protocols MUST NOT compromise security if security is deployed. In the case of IPv4, it is acceptable (though not desirable) for interface configuration to fail to defend against attack from other hosts on the same physical link, since these Hattig Expires: February 2002 [Page 11] Internet Draft Zeroconf IP Host Requirements August 2001 hosts are already in a position to subvert IPv4 ARP anyway, so securing the interface configuration protocol would not prevent them disrupting subsequent IPv4 communications. For that reason the IPv4 interface configuration protocol MAY include no defence against attack from other hosts on the same physical link. Since ARP is insecure, dynamic configuration of IPv4 link-local addresses MAY be, as well. IPv6 datagrams may be transported over IPv4 so care is needed to not compromise security requirements for IPv6 in this case. In the case of IPv6 Neighbor Discovery, this protocol can be secured as it uses ICMPv6 messages, which run over IP. IPv6 Neighbor Discovery messages can thus be protected for integrity and endpoint authentication using IP Security. [RFC 2401, 2402, 2403, 2404] 3.2 Name to Address Resolution The security implications of this zeroconf protocol must be compared against the DNS protocol. DNS is a client-server protocol. The zeroconf name to address translation protocol will likely use multicast so that any host may respond to queries. This broadens the possibility that host authentication in the form of hostname-IP address mappings may be compromised, since all hosts effectively may behave as DNS servers. Currently it is possible to subvert DNS in various ways, unless DNSsec [RFC 2535, RFC 2931] is used. For example: - A client may be configured with the address of an attacker's DNS server. For example, an active attacker on the same subnet as the client may respond to DHCP DHCPDISCOVER messages and deliberately configure the client to use a compromised DNS server. - An active attack against a DNS client is possible - where an attacker unicasts a DNS reply to a client request that arrives at the client before the legitimate server's response. DNSsec protects against such attacks as the client can verify that the data it retrieves using the DNS has been signed from a source that the client has been configured to accept. A zeroconf name to address resolution protocol MUST be compatible with the use of DNSsec. Therefore it MUST be possible for a host running a zeroconf protocol to use DNS and DNSsec for authenticated name resolution if that host (or its administrator) chooses to do so. [RFC 2541] Hattig Expires: February 2002 [Page 12] Internet Draft Zeroconf IP Host Requirements August 2001 3.3 Multicast Address Allocation The zeroconf multicast address allocation protocol MUST NOT be less secure than MADCAP [RFC 2730]. These are the IETF standards track protocols for Multicast Address Allocation. The threat of using an insecure Multicast Address Allocation protocol is that an active attacker could 'hoard' all multicast addresses - inappropriately claiming to have allocated them. This would prevent other hosts from effectively participating in the Multicast Address Allocation protocol. This could be done to stop all participation or selectively, to prevent particular hosts from allocating addresses. MADCAP does not include mechanisms for protecting message integrity or endpoint authentication. This protocol suggests the use of IPsec for this purpose, as MADCAP is compatible with the IP Authentication Header. A zeroconf multicast address allocation protocol MUST either be compatible with IP AH or provide another mechanism for optional-to-use (but mandatory to implement) authentication. 3.4 Service Discovery The zeroconf service discovery protocol MUST NOT be less secure than the IETF standard service discovery protocol: The Service Location Protocol, Version 2 [RFC 2608] (SLPv2). The threat posed by using an insecure service discovery protocol is that unauthorized entities may participate. A client may be misled to communicate with a host that has been compromised or that offers an antagonistic server that the client did not intend to use. This might be easy to detect (e.g. after attempting to use a printer that doesn't exist, no paper will appear.) This may also be difficult to detect (e.g. an illegitimate server copies all data for an attacker's subsequent perusal and the user has no way of knowing). A client could still detect that it is communicating with an unauthorized server, but that would require authentication and authorization mechanisms at a higher level (the client-server protocol). SLPv2 protects against the threat of discovery of unauthorized services. SLPv2 messages that contain an answer may include an associated authorization block. This allows a client receiving a message to verify the answer, using digital signatures and a certificate-based system as the basis for authorization. Other mechanisms are possible. A zeroconf service discovery protocol MUST allow a client to verify that a service advertisement sent by a server was created Hattig Expires: February 2002 [Page 13] Internet Draft Zeroconf IP Host Requirements August 2001 by an authorized source. 4 IANA Considerations No known IANA considerations arise from this document. 5 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 6 Acknowledgements Thanks to Peter Ford and Stuart Cheshire for hosting the NITS (Networking In The Small) BOF that was the catalyst to forming the Zeroconf Working Group. Thanks to Erik Guttman and Stuart Cheshire for forming and chairing the Zeroconf Working Group, which is responsible for this document. Thanks to Erik Guttman for providing key input to the service discovery and the security sections. Thanks to Dave Thaler for providing key input to the IP multicast address allocation sections. Hattig Expires: February 2002 [Page 14] Internet Draft Zeroconf IP Host Requirements August 2001 Thanks to Stuart Cheshire for providing key input to the introduction and IP interface configuration sections. Additional recognition goes the following people for their influential contributions to this document and its predecessors: Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob Quinn, John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl Auerbach, Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland, and Bernard Aboba, Ran Atkinson. Editor: Myron Hattig Intel Corporation 3585 SW 198th Avenue Aloha, OR 97007 myron.hattig@intel.com 7 References [RFC 826] D. Plummer, "An Ethernet Address Resolution Protocol", RFC 826, November 1982. [RFC 1034] P. Mockapetris, "Host names - Concepts and Facilities", RFC 1034, November 1987 [RFC 1035] P. Mockapetris, "Host names - Implementations and Specifications", RFC 1034, November 1987 [RFC 1123] B. Braden, "Requirements for Internet Hosts -- Application and Support", RFC 1123, October 1989 [RFC 1827] R. Atkinson, "IP Encapsulating Security Payload", RFC 1827, Aug 1995 [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 2246] T. Dierks, C. Allen, "Transport Layer Security", RFC 2246, Jan 1999. [RFC 2251] M. Wahl, T. Howes, and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, Dec 1997. Hattig Expires: February 2002 [Page 15] Internet Draft Zeroconf IP Host Requirements August 2001 [RFC 2365] D. Meyer, "Administratively Scoped Multicast Address", RFC 2365,July 1998. [RFC 2401] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401 November 1998 [RFC 2402] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402 November 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 Stateless Address Autoconfiguration", RFC 2462, December 1998 [RFC 2535] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC 2541] D. Eastlake, "DNS Security Operational Considerations", RFC 2541, March 1999 [RFC 2608] E. Guttman, et al, "Service Location Protocol, Version 2", RFC 2608, June 1999 [RFC 2730] S. Hanna, B. Patel, M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, Dec 1999. [RFC 2931] D. Eastlake, "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000 [SSM] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", draft-holbrook-ssm-arch-02.txt, March 2001. A work in progress. [SS6] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", draft-ietf-ipngwg-uni-based- mcast-02.txt, June 2001, A work in progress. Hattig Expires: February 2002 [Page 16]