[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12

Zeroconf WG                                                    M. Hattig
Internet Engineering Task Force                                   Editor
INTERNET DRAFT                                               Intel Corp.
Expires Nov 2001                                            May 23, 2001

                         Zeroconf Requirements

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

   The list of current Internet-Drafts can be accessed at:

   The list of Internet-Draft Shadow Directories can be accessed at:


   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)

   Hattig                                                  [Page 1]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

   Before embarking on defining zeroconf protocols, protocol
   requirements are needed. This document states the zeroconf
   protocol 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...............................................3
   1.5 Routable Protocol Requirement.............................4
   1.6 Conflicts and State Changes Requirement...................4
   2 Scenarios & Requirements....................................4
   2.1 IP Interface Configuration................................4
   2.2 Translation between Host name and IP Address Scenarios....6
   2.3 IP Multicast Address Allocation Scenarios.................7
   2.4 Service Discovery Scenarios...............................9
   3 Security Considerations....................................10
   3.1 IP interface configuration...............................11
   3.2 Name to Address Resolution...............................12
   3.3 Multicast Address Allocation.............................12
   3.4 Service Discovery........................................13
   4 IANA Considerations........................................13
   5 Full Copyright Statement...................................13
   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. One possible exception is the use of MAC addresses
   (i.e. layer two addresses) as parameters in zeroconf protocols.

   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

   Hattig                                                  [Page 2]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

   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
   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.

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.

   Hattig                                                  [Page 3]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

1.5 Routable Protocol Requirement

   If a protocol is intended to span multiple IP subnets it SHOULD
   NOT use broadcasts or link-local addressing.

   - Protocols intended to span multiple IP subnets SHOULD 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.

   - MUST respond to state changes and resolve conflicts in a timely

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.

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 (e.g. default route). IP interface configuration
   is needed before almost any IP communication can take place.


     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

   Hattig                                                  [Page 4]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

     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.

   - MUST configure an appropriate netmask.
   - MUST have unique IP addresses within an IP subnet.
   - MUST have some routing information
     (for the internetwork scenario).
   - MUST have unique IP subnets within an internetwork
     (only for the internetwork scenario).

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
   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 from the installation of a bridge or a router may
   create the following problems: multiple default routes that cause
   dial out lines to be used instead of broadband connections,
   duplicate IP addresses within an IP subnet, or duplicate IP
   subnets within an internetwork.

   - 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, netmask,
   and routing information, thus if a host is using IPv6, a zeroconf
   IP interface configuration solution already exists.

   Hattig                                                  [Page 5]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

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.


     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

   An URL typically contains the name of a Web server. When a user
   enters an URL into a Web browser, the name must be translated to
   an IP address before any actual Web browsing occurs. Web servers
   often record log files of accesses, and wish to map the client's
   IP address back to a human-readable name for recording in the log
   file. Thus, a mechanism to translate the IP address to a name is

   - MUST translate a name to an IP address.
   - MUST translate an IP address to a name.

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.


   - 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.

   Hattig                                                  [Page 6]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

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 to

   [RFC 2365] defined multicast scopes are:
     node-local (unspecified for IPv4)
     link-local (
     local      (
     site-local (unspecified for IPv4)
     organizational-local (
     global (

   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, is reserved for relative allocations.

   Source-Specific Multicast [SSM] addresses are to

   - 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

   Hattig                                                  [Page 7]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

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.

   - 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.

   - 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.

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.

   - A host other than the allocating host MUST be able to defend
     or otherwise maintain the allocation of a multicast address.

   Hattig                                                  [Page 8]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

2.3.4  IPv6 Considerations

   To date, no range has been reserved for source-specific addresses
   in IPv6.  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 to select services and/or
   hosts by a name that is discovered dynamically, rather than requiring
   that the user know the name in advance and type it in correctly.


     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
     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.

   Hattig                                                  [Page 9]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

   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.

   - 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
   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.

   Hattig                                                  [Page 10]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

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

   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
   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.

   The IPv4 interface configuration protocol MAY omit security
   mechanisms if and only if that protocol is not used for IPv6 and
   cannot be extended to support IPv6.  It is strongly recommended that
   it include security mechanisms, because many protocols are extended
   later in ways not anticipated by the original developer(s).

   Hattig                                                  [Page 11]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

   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]

3.3 Multicast Address Allocation

   The zeroconf multicast address allocation protocol MUST NOT be
   less secure than MADCAP [RFC 2730] and AAP [AAP].  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.

   Hattig                                                  [Page 12]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

   Neither AAP nor MADCAP include mechanisms for protecting message
   integrity or endpoint authentication.  These protocols suggest the
   use of IPsec for this purpose, as AAP and MADCAP are 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)

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 printed upon paper appears.)
   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

   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
   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

   Hattig                                                  [Page 13]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

   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

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

   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.

   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.

   Hattig                                                  [Page 14]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001


   Myron Hattig
   Intel Corporation
   3585 SW 198th Avenue
   Aloha, OR 97007

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 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.

   [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.

   Hattig                                                  [Page 15]

   Internet Draft    draft-ietf-zeroconf-reqts-08.txt     May 2001

   [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, "Source-Specific Multicast for IP",
                draft-holbrook-ssm-00.txt, March 2000. A work in

   [AAP]       M. Handley, S. Hanna, "Multicast Address Allocation
                Protocol (AAP)", draft-ietf-malloc-aap-04.txt, June
                2000. A work in progress.

   Hattig                                                  [Page 16]

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/