[Search] [txt|pdf|bibtex] [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 January 2001                                 July 14, 2000


                         Zeroconf Requirements
                    draft-ietf-zeroconf-reqts-04.txt

Status of This Memo

   This document is a submission by the Zeroconf Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be
   submitted to the zeroconf@merit.edu mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC 2026].  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF),
   its areas, and its working groups.  Note that other groups may
   also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at:
     http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at:
      http://www.ietf.org/shadow.html.

Abstract

   Many common TCP/IP protocols such as DHCP, DNS, MADCAP, and LDAP
   must be configured and maintained by an administrative staff. This
   is unacceptable for emerging networks such as home networks, small
   office networks, automobile networks, airplane networks, or adhoc
   networks at conferences, emergency relief stations, and many
   others. For these networks, an administrative staff will not exist
   and the users of these networks neither have the time nor
   inclination to learn network administration skills. Instead, these
   networks need protocols that require zero user configuration and
   administration. This document is part of an effort to define such
   zero configuration (zeroconf) protocols.

   Before embarking on defining zeroconf protocols, protocol
   requirements are needed. This document states zeroconf protocol
   requirements for four protocol areas; this document does not


   Hattig                                                  [Page 1]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   define specific protocols. The four areas are: IP host
   configuration, domain name to IP address resolution, IP multicast
   address allocation, and service discovery. The requirements for
   these four areas result from examining everyday use or scenarios
   of these protocols.

                           Table of Contents

   1 Introduction................................................2
   1.1 Reading This Document.....................................3
   1.2 Zeroconf Protocols........................................3
   2 Scenarios & Requirements....................................7
   2.1 IP Host Configuration.....................................8
   2.2 Domain Name to IP Address Resolution Scenarios...........10
   2.3 IP Multicast Address Allocation Scenarios................13
   2.4 Service Discovery Scenarios..............................16
   3 Security Considerations & Requirements.....................19
   3.1 IP Host Configuration....................................19
   3.2 Domain Name to IP Address Resolution.....................20
   3.3 IP Multicast Address Allocation..........................20
   3.4 Service Discovery........................................20
   3.5 IPv6 Considerations......................................21
   4 IANA Considerations........................................21
   5 Full Copyright Statement...................................21
   6 Acknowledgements...........................................21
   7 References.................................................22

1  Introduction

   This document presents requirements for zeroconf protocols in four
   areas: IP host configuration, domain name to IP address
   resolution, IP multicast address allocation, and service
   discovery. Security issues and the transitions between a zeroconf
   protocol and a non-zeroconf protocol are also discussed within
   each protocol area.

   The major sections in this document are the Introduction,
   Scenarios & Requirements, and Security Considerations &
   Requirements. The introduction provides the background
   information, references, terms, and assumptions to ensure a clear
   understanding of the subsequent sections. The Scenarios &
   Requirements section walks through protocol scenarios and then
   lists the requirements of the protocol needed to accomplish the
   scenario. The Security section lists threats and security
   requirements.

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


   Hattig                                                  [Page 2]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000



1.1 Reading This Document

   Most of the document can be read selectively based on the reader's
   protocol area of interest. To encourage this, much of the document
   is organized around the four protocol areas:
   - IP host configuration
   - Domain name to IP address resolution
   - IP multicast address allocation
   - Service discovery

1.2 Zeroconf Protocols

   Below are strict definitions of a zeroconf protocol and a non-
   zeroconf protocol. Also discussed are the transitions between a
   zeroconf protocol and non-Zeroconf. Finally, a section discusses
   how protocols with a centralized server may be zeroconf protocols.

1.2.1  Definitions

   A zeroconf protocol requires no user configuration.

   A non-zeroconf protocol requires user configuration.

   [Editor's Note: The definition of a ZC protocol is a key output of
   this document. Be aware that the definition has changed from the
   previous version of this document. This change prompted section
   1.3.5 Centralized Servers. This editor's note will be removed in
   the next version of this draft.]

1.2.2  Transitions

   Transition is the act of determining when to change from using the
   zeroconf protocol to the non-zeroconf protocol, or vice-versa.
   Transition support is not required of a zeroconf protocol nor does
   a device require transition support if the device supports the
   zeroconf protocol. Below is a discussion of three possible
   transitions that a host SHOULD consider when using a zeroconf
   protocol.

   The first transition is a zeroconf to non-zeroconf transition.
   This type of transition may occur either if a host moves to a new
   network that does not use a zeroconf protocol when the old network
   used a zeroconf protocol. Or if the host stays on the same network
   but a new server comes online within that network. For example, if
   a DHCP server comes online after hosts are configured with a
   zeroconf IP host configuration protocol then hosts MUST re-
   configure with DHCP.




   Hattig                                                  [Page 3]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   The second transition is the opposite of the first; it is a non-
   zeroconf to zeroconf transition. This may occur if a host moves
   between networks or when a server goes offline within a network.

   The third transition occurs if a device moves from one network to
   another network when both networks use a zeroconf protocol. For
   example, if a person is using a laptop in her home network with a
   zeroconf protocol, then she takes that laptop to her neighbor's
   home network that uses the same zeroconf protocol: the laptop must
   automatically adapt to the new network.

   Another subtle example of this third of transition is if the
   network topology changes significantly as when a bridge gets
   installed between two existing networks. In this case, if the
   networks are utilizing a zeroconf IP host configuration protocol,
   the protocol SHOULD allow the hosts to detect addressing conflicts
   and possibly reconfigure.

1.2.3  Coexistence

   A zeroconf protocol in one area MUST be able to coexist with a
   non-zeroconf protocol in another area.

   To illustrate this point, suppose there are standard zeroconf and
   non-zeroconf protocols for IP host configuration and domain name
   to IP address resolution.

   For IP host configuration, the zeroconf protocol is "protocol-A."
   The non-zeroconf protocol is "protocol-B", supported by a fully
   conformant "protocol-B" server.

   For domain name to IP address resolution, the zeroconf protocol is
   "protocol-C".  The non-zeroconf protocol is "protocol-D" supported
   by a fully conformant "protocol-D" server.

   Within a single network, the IP host configuration zeroconf
   protocol-A MUST be able to coexist with the domain name to IP
   address resolution non-zeroconf protocol-D.

   In contrast, zeroconf and non-zeroconf protocols from a single
   area MUST NOT be able to coexist during normal operation. They MAY
   coexist during a transition, but the coexistence period MUST be
   minimal.

1.2.4  Scalability

   Scalability is not of great concern because it is expected that
   zeroconf protocols will operate in networks of limited size. In
   addition, it is likely that as a network grows, the owners of that
   network will migrate to using non-zeroconf protocols before


   Hattig                                                  [Page 4]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   scalability becomes an issue. For this reason, this document
   mentions little of scalability requirements.

1.2.5  Centralized Servers

   This subsection illustrates how a protocol that takes advantage of
   a centralized server may be a zeroconf protocol. This is
   illustrated using DHCP in a home network.

   Centralized servers such as DHCP servers are being deployed in
   home networks to relieve user configuration. However, networks
   accidentally operating with multiple DHCP servers present new
   configuration challenges. Today's solution is for a person to
   configure one of the DHCP servers to stop operating; since a user
   must do something (turn off a DHCP server) this is a non-zeroconf
   solution.

   In order for a centralized server protocol to be zeroconf while
   operating with multiple servers, there must be mechanisms to
   ensure all clients use the appropriate server. Of course, these
   mechanisms must operate without any user configuration.

1.2.6  IP Host Configuration

   IP host configuration is the configuration of an interface on an
   IP host, which always includes an IP address and sometimes an
   netmask and default route. IP host configuration is required
   before almost any IP communication can take place.

   DHCP is the common IP host configuration solution deployed today.
   Zeroconf IP host configuration schemes MUST peacefully coexistence
   with DHCP.

   The definitions needed for the IP host configuration scenarios
   are:

   IP subnet - a single logic IP network that may span multiple link
     layer networks.

   internet - multiple IP subnets connected by routers.

   Network - general term that may apply to link layer, IP subnet, or
     internet.

1.2.7  Domain name to IP address resolution

   DNS is the common way to resolve names to IP addresses. Zeroconf
   domain name to IP address resolution protocols MUST peacefully
   coexistence with DNS.



   Hattig                                                  [Page 5]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   It is assumed that sub-domain delegation is not done within the
   zone that a zeroconf domain name to IP address resolution protocol
   is performed. In other words, a zeroconf zone contains all of the
   names in its domain.

   In addition, it is assumed a zeroconf domain name to IP address
   resolution protocol will only be used if a DNS server is not
   present or a host is not configured with the IP address of a DNS
   server. It is also assumed that TCP/IP networking connectivity to
   other zones MAY exist and those other zones have DNS servers.
   Furthermore, it is assumed that a special device or application
   exists at the edge of these two zones and is able to convert
   between the zeroconf and non-zeroconf domain name to IP address
   resolution protocols.

1.2.8  IP Multicast Address Allocation

   IP multicast is used to conserve bandwidth and reduce complexity
   in the multicast source. MADCAP is the default IP multicast
   address allocation protocol. Zeroconf IP multicast address
   allocation protocols MUST peacefully coexist with MADCAP.

   Zeroconf solutions are only concerned with IP multicast addresses
   scoped as Local (i.e. 239.255.0.0/16), link-local, node-local, and
   Single-source IP multicast addresses of any scope. It is assumed
   that a boundary router (as described in RFC 2365) is present to
   appropriately control multicast packets from entering and leaving
   the scope boundaries.

1.2.9  Service Discovery

   Service discovery protocols have proven to be critical to the
   usability of networks. AppleTalk/NBP, NetBIOS/SMB and IPX/SAP have
   improved the utility services from printing to gaming are easily
   found on these networks. Service Location Protocol version 2
   (SLPv2) is defined in Standards Track RFC 2608, and an Internet-
   Draft defines Simple Service Discovery Protocols (SSDP).

   Service discovery definitions are:

   Process - A process is an implementation of an algorithm in
   software, hardware, or a combination of software and hardware.

   Registry - A process that acts as an intermediary between
   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.




   Hattig                                                  [Page 6]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   Registry update - A message that contains updated registry
   information. It may cause one or more registry entries to be
   deleted, added, or modified.

   Server - A process that offers services to clients.  A server can
   make its service(s) known to clients by means of a service
   discovery protocol.

   Service - A service is a set of processes that utilize a
   particular protocol. Services range from printing to transferring
   a file to providing on-line pizza order and delivery.

   Service Advertisement Packet - An unsolicited packet issued by a
   server or registry. The advertisement provides the service
   identifier and possibly service characteristics.

   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
   a client (or clients) to discover a server (or servers) of a
   particular service. A service discovery protocol is an application
   layer protocol that relies on network and transport protocol
   layers.

   Service Identifier - A service identifier allows clients, servers,
   advertisers, discoverers, and registries to uniquely identify an
   instance of a service.

   Service Protocol - A service protocol is used between the client
   and the server after service discovery is complete.

   Service Solicitation - A request packet made by a client to obtain
   a response packet that indicates a service is present. The
   response may come from a service or a registry.

   Service Type - A service type allows clients, servers,
   advertisers, discoverers, and registries to uniquely identify a
   type of service such as a printer service.

2  Scenarios & Requirements

   This section lists zeroconf scenarios that lead to requirements
   for protocols. There is a subsection for each of the four protocol
   areas. Within each protocol area representative scenarios are
   discussed and requirements are identified. It is possible to state
   an endless number of scenarios but unless those scenarios yield


   Hattig                                                  [Page 7]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   additional requirements, there is no point of discussing such
   scenarios. Also, within each area is a summary of the requirements
   and an IPv6 considerations section.

2.1 IP Host Configuration

   DHCP is the non-zeroconf IP Host configuration protocol. The
   problems preventing DHCP from being a zeroconf protocol are: the
   DHCP server may not be present and if multiple DHCP servers are
   present they may provide conflicting configuration.

   The scenarios in this section are ping and bridge install. Since
   DHCP is the non-zeroconf IP host configuration protocol, the
   Zeroconf and non-Zeroconf Transitions section discusses
   transitioning between zeroconf IP host configuration and DHCP.

2.1.1  Ping

   Ping consists of one host sending an ICMP echo request to another
   host, then the other host replying with an ICMP echo reply. Ping
   has two sub-scenarios: ping to a host on local IP subnet and ping
   to a host off the local IP subnet.

   When sending a ping (or any other IP packet for that matter), a
   host performs the AND operation on the netmask and the destination
   IP address then compares that result with the result of an AND
   operation on the host's IP address and netmask.

   ((HostIPAddr & netmask) == (DestIPAddr & netmask))

   If the result of this compare is FALSE, then the host forwards the
   packet to the default router because the destination address is
   off the local IP subnet. If the result is TRUE, then the host
   sends an ARP request to resolve the destination IP address to a
   hardware address within the local IP subnet.

   These steps are important to show the expected utilization and
   values of a netmask and the default route. Specifically, the
   values for the IP address, netmask, and default route within a
   host must be chosen such that the following statements are true:
   - All hosts on an IP subnet have a common netmask.
   - When a host computes (HostIPAddr & netmask) the result is
     identical for all hosts on a single IP subnet.
   - When a host computes (HostIPAddr & ~netmask) (inverse netmask)
     the result is unique for all hosts on an IP subnet.
   - All hosts get a default route that is used for communication
     with other IP hosts off the local subnet.

   In addition IP subnets must somehow be unique on different IP
   subnets within an internet over which the zeroconf IP host


   Hattig                                                  [Page 8]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   configuration protocol is operating; this insures unique IP
   addresses (regardless of the value of the host portion of the IP
   address) across the entire internet.

   The zeroconf IP host configuration protocol only defines packets
   sent over a wire and the associated semantics. Here are zeroconf
   IP host configuration protocol requirements to satisfy ping:
   - The ability to determine the netmask for an IP subnet.
   - The ability to determine the default route for an IP subnet.
   - The ability to have unique IP addresses within an IP subnet.
   - The ability to have unique IP subnets within an internet.

2.1.2  Bridge Installed

   This scenario starts with two completely operational standalone
   networks in which IP host configuration was completed with
   zeroconf IP host configuration protocols. These two networks
   become one after a bridge is installed between them.

   This creates two problems. First, hosts may have duplicate IP
   addresses. Second, there may be competing netmask and default
   route values that disrupt communication.

   The bridge scenario results in the following protocol
   requirements:
   - The ability to avoid or resolve contention among netmasks.
   - The ability to avoid or resolve contention among default routes.
   - The ability to avoid or resolve duplicate IP addresses within a
     subnet.
   - The ability to avoid or resolve duplicate IP subnets within an
     internet.

2.1.3  Zeroconf and non-Zeroconf Transitions

   DHCP is the non-zeroconf IP Host configuration protocol. Here are
   examples of intermittent connectivity between zeroconf hosts and
   DHCP servers that show the need for IP host configuration
   transitions:
   - DHCP servers in a PC that gets regularly power-cycled.
   - A zeroconf capable device introduced into a network that has a
     DHCP server.
   - A zeroconf capable device removed from a network that has a DHCP
     server.

   These scenarios require the periodic actions as well as specific
   actions at startup. The action is the same whether it be periodic
   or at startup. The action is an attempt to discover a DHCP server.
   If the DHCP server is discovered the host uses DHCP, otherwise the
   host uses the zeroconf IP host configuration protocol.



   Hattig                                                  [Page 9]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   IP host configuration zeroconf and non-zeroconf transitions
   necessitate the following protocol requirements:
   - The ability to detect the presence or absence of a DHCP server
     at startup of a device and periodically after a devices starts.

2.1.4  Requirements Summary

   Zeroconf IP host configuration protocol requirements are:
   - The ability to determine the netmask for an IP subnet.
   - The ability to determine the default route for an IP subnet.
   - The ability to have unique IP addresses within an IP subnet.
   - The ability to have unique IP subnets within an internet.
   - The ability to avoid or resolve contention among netmasks.
   - The ability to avoid or resolve contention among default routes.
   - The ability to avoid or resolve duplicate IP addresses within a
     subnet.
   - The ability to avoid or resolve duplicate IP subnets within an
     internet.
   - The ability to detect the presence or absence of a DHCP server
     at startup of a device and periodically after a devices starts.

2.1.5  IPv6 Considerations

   IPv6 allows a host to select an appropriate IP address, netmask,
   and find a default route, thus if a network is using IPv6, there
   already exists a zeroconf IP host configuration solution.

2.2 Domain Name to IP Address Resolution Scenarios

   DNS is the non-zeroconf domain name to IP address resolution
   protocol. The problems with DNS preventing DNS from being a
   zeroconf protocol are: user configuration of the IP address of a
   DNS server in a client machine, user entering DNS resource records
   in the DNS server, devices having unique names, and a DNS server
   may not be accessible.

   The scenarios in this section are web browsing, domain name
   selection, and bridge install. Additional, transition scenarios
   list requirements for transitioning between using DNS and using
   the zeroconf domain name to IP address resolution protocol.

2.2.1  Web Browsing

   Users browsing the WEB typically enter the name of a web server.
   This name MUST be resolved to an IP address before any actual web
   browsing occurs. The web server may be within the same domain as
   the web browser or within a different domain.

   The zeroconf domain name to IP address resolution protocol MUST
   resolve a name to an IP address without a host being configured


   Hattig                                                  [Page 10]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   with the IP address of a DNS server. This includes names within
   the same domain as the host that is using the zeroconf protocol as
   well as names within other domains.

   The domain name to IP address resolution protocol requirements for
   web browsing are:
   - The ability to resolve a name to an IP address without the user
     configuring the IP address of a DNS server.
   - The user must not be required to enter a mapping of a domain
     name to IP address into the DNS database.

2.2.2  Domain Name Selection

   A domain name consists of a host name and the name of the domain
   itself. A host has control over its host name, but some other
   entity configures or determines the name of the domain. In fact
   the name of the domain may not be available. A protocol is needed
   to maintain unique host portions of a domain name and to possibly
   learn the name of the domain.

   Note that it may be desirable to have duplicate host names. Such
   cases include server farms with load-balanced servers meant to
   provide consistent response times during periods of high volume.

   Here are the requirements for a name selection protocol:
   - The ability to ensure a unique host name (assuming unique names
     are desired) is selected.
   - The ability to learn the name of the domain (assuming the name
     of the domain is known).

2.2.3  Bridge Install

   This scenario starts with two completely operational standalone
   networks. After name selection is complete, these two networks
   become one when a bridge is installed between the networks.

   The bridge scenario results in the following protocol
   requirements:
   - The ability to periodically ensure the uniqueness of a selected
     host name.

2.2.4  Zeroconf and non-Zeroconf Transitions

   DNS is the non-zeroconf domain name to IP address resolution
   protocol. There are four transitional cases to consider. Note that
   unless a host is configured with the IP address of the DNS server,
   none of these transitions can occur.

   The first is a zeroconf to non-zeroconf transition that occurs
   when the host is first configured with the IP address of the DNS


   Hattig                                                  [Page 11]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   server and the host can actually reach the DNS server (i.e. the
   DNS server responds to requests).

   The second is a non-zeroconf to zeroconf transition that occurs
   when for some reason the DNS server can no longer be reached. One
   such reason may be that the host is moved to a network without
   connectivity to the DNS server. In this case the zeroconf domain
   name to IP address resolution protocol MUST be invoked.

   The third transition is from zeroconf back to non-zeroconf. This
   occurs when the DNS server becomes reachable again. Following the
   above example, the host is moved back to the original network with
   connectivity to the DNS server.

   The final transition is a non-zeroconf to zeroconf transition that
   occurs when the IP address of the DNS server is removed from the
   host.

   These transitions generate the following requirements:
   - The ability to detect the presences or absence of DNS server
     (applies only if the host is configured with the IP address of
     the DNS server). The host must use DNS when the DNS server is
     present and zeroconf domain name to IP address resolution when
     the DNS server is not present.

2.2.5  Requirements Summary

   The domain name to IP address resolution protocol requirements
   are:
   - The ability to resolve a name to an IP address without the user
     configuring the IP address of a DNS server. This includes names
     within the same domain as the requesting host as well as names
     outside the domain as the requesting host.
   - The user must not be required to enter a mapping of a domain
     name to IP address.
   - The ability to ensure a unique host name (assuming unique names
     are desired) is selected.
   - The ability to learn the name of the domain (assuming the name
     of the domain is known).
   - The ability to periodically ensure the uniqueness of a selected
     host name.
   - The ability to detect the presences or absence of DNS server
     (applies only if the host is configured with the IP address of
     the DNS server). The host must use DNS when the DNS server is
     present and zeroconf domain name to IP address resolution when
     the DNS server is not present.

2.2.6  IPv6 Considerations




   Hattig                                                  [Page 12]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   Domain name to IP address resolution protocols has no zeroconf
   related differences for IPv4 and IPv6.

2.3 IP Multicast Address Allocation Scenarios

   MADCAP is the non-zeroconf IP Multicast Address Allocation
   protocol. The problems preventing MADCAP from being a zeroconf
   protocol are: the MADCAP server may not be present and if multiple
   MADCAP servers are present they may provide conflicting
   configuration.

   All IP multicast addresses allocated are from the scopes of Local
   (i.e. 239.255.0.0/16), link-local, node-local, and Single-source
   IP multicast addresses of any scope. Descriptions of "Scope
   Enumeration" and "Allocate Node-scoped or Single-Source Global IP
   multicast address" do not result in requirements but do provide
   important information about IP multicast operations. The scenarios
   of "Allocate Link-scoped or Local-Scope IP multicast", "Allocate
   IP Multicast Address Used by Multiple Sources", then the
   transitions between zeroconf and MADCAP generate protocol
   requirements.

2.3.1  Scope Enumeration

   Applications that leave the choice of scope up to the user require
   the ability to enumerate what scopes the host is within [RFC
   2771].

   In addition, services that are assigned relative addresses [RFC
   2365] require the ability to enumerate what scopes the host is
   within, then a host is able to apply the relative address to a
   scope.

   When enumerating scopes, the following scopes may be assumed to
   exist in all cases (assuming well-known ranges have been reserved
   by IANA).
   - Node-Local
   - Link-Local
   - Local (i.e., the Zeroconf area)
   - Single-source global

   The zeroconf IP multicast address allocation protocol requirements
   are:
   - The ability for a host to obtain the set of scope names, for all
     scopes it is within.
   - The ability for a host able to obtain the set of address ranges
     for all scopes it is within.





   Hattig                                                  [Page 13]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


2.3.2  Allocate Node-scoped or Single-Source Global IP multicast
       address

   Each host is always responsible for allocating its own Node-scoped
   and Single-source Global multicast addresses, regardless of
   whether it is use of zeroconf protocols since there is no
   coordination between devices for such allocation, no protocol is
   involved, and there are no protocol requirements.

   Allocating (global) single-source addresses is only possible if
   the host has already acquired a global unicast IP address.

   To date, no range has been reserved for dynamic allocation of
   Single-source addresses in IPv6.  Hence, until such a range is
   reserved, dynamic allocation of Single-source addresses applies
   only to IPv4.

2.3.3  Allocate Link-scoped or Local-Scope IP multicast address

   Address allocation at the Link and larger scopes requires
   coordination to avoid address collisions.  To allocate an address,
   the host specifies a given scope, the number of addresses it
   desires, and the lifetime for which it desires.

   To date, no range has been reserved for dynamic allocation of
   Link-scoped addresses in IPv4.  Hence, unless such a range is
   reserved, dynamic allocation of Link-scoped addresses applies only
   to IPv6.

   Collision detection must span the entire Link for Link-scope
   allocations, and must span the entire locally scoped internet for
   Local-scope allocations. The protocol should include the ability
   for a host to choose addresses, determine if they are in use, and
   choose different addresses if so.

   The collision detection protocol must become active at various
   times such as when previously disconnected yet operational
   networks now become connected by the installation of a router or
   bridge.

   The zeroconf IP multicast address allocation protocol requirements
   are:
   - The ability for a host to select a multicast address with a
     given scope and lifetime.
   - The ability for a host to determine if the address has been
     allocated by another host.
   - The ability for a host to defend the addresses it allocates.
   - The ability for a host to determine if another host has
     allocated an address that has been allocated by itself; this
     SHOULD be done periodically.


   Hattig                                                  [Page 14]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   - The protocol MUST be routable to ensure it spans the entire
     local scope.

2.3.4  Multiple Source

   An intercom system inside a home is an example of a multiple
   source IP multicast application. In this type of application,
   several sources may be sending packets destined to the same IP
   multicast address.

   Here, the first source that needs the IP address MUST allocate the
   address, yet it may not be the host that deallocates the multicast
   address. This is because the first source may leave the multicast
   group before all the other sources stop sending packets to that IP
   multicast address. This requires, the last source using the IP
   multicast address to deallocate the IP multicast address after it
   is done sending.

   The zeroconf IP multicast address allocation protocol requirements
   are:
   - The ability for the last host acting as a source to deallocate
     the IP multicast address.

2.3.5  Zeroconf and non-Zeroconf Transitions

   MADCAP is the non-zeroconf IP multicast address allocation
   protocol. Hosts MUST be able to transition between MADCAP and the
   zeroconf IP multicast address allocation protocol by detecting (or
   not detecting) the presences of a MADCAP server.

   If MADCAP is detected while using zeroconf IP multicast address
   allocation, the host must start utilizing MADCAP. If MADCAP is no
   longer detected while using MADCAP, the host must start utilizing
   the zeroconf IP multicast address allocation protocol.

   The transition requirements are:
   - The ability to detect the presence or absence of a MADCAP server
     at startup of a device and periodically after a device starts.

2.3.6  Requirements Summary

   Zeroconf IP multicast address allocation protocol requirements
   are:
   - The ability for a host to obtain the set of scope names, for all
     scopes it is within.
   - The ability for a host able to obtain the set of address ranges
     for all scopes it is within.
   - The ability for a host to select a multicast address with a
     given scope and lifetime.



   Hattig                                                  [Page 15]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   - The ability for a host to determine if the address has been
     allocated by another host.
   - The ability for a host to defend the addresses it allocates.
   - The ability for a host to determine if another host has
     allocated an address that has been allocated by itself; this
     SHOULD be done periodically.
   - The protocol MUST be routable to ensure it spans the entire
     local scope.
   - The ability for the last host acting as a source to deallocate
     the IP multicast address.
   - The ability to detect the presence or absence of a MADCAP server
     at startup of a device and periodically after a device starts.

2.3.7  IPv6 Considerations

   To date, no range has been reserved for dynamic allocation of
   Single-source addresses in IPv6.  Hence, until such a range is
   reserved, dynamic allocation of Single-source addresses applies
   only to IPv4.

   To date, no range has been reserved for dynamic allocation of
   Link-scoped addresses in IPv4.  Hence, unless such a range is
   reserved, dynamic allocation of Link-scoped addresses applies only
   to IPv6.

2.4 Service Discovery Scenarios

   As stated earlier, there is no non-zeroconf service discovery
   protocol, thus there are no particular zeroconf problems with an
   zeroconf protocol. In addition, there are no zeroconf to non-
   zeroconf transition scenarios.

   The scenarios are the discovery of a simple printer service and
   the discovery of a printer manager that consolidates many printer
   services.

2.4.1  Printer Service

   Networked enabled printers allow various networked clients to
   submit print jobs.  A service discovery protocol MUST allow a
   printing client to discover the printer service. This requires a
   service type as well as a service identifier to distinguish
   instances of a single service type.

   Printers vary in their characteristics such as location, status,
   dots per inch, drivers, etc. Discovering these characteristics
   SHOULD be part of the service discovery protocol. Some service
   specific protocols allow the client and server to negotiate the
   use of these characteristics after the service is found; thus,
   alleviating the need for the service discovery protocol to


   Hattig                                                  [Page 16]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   discover by characteristic. However, characteristic discovery
   SHOULD be part of the service discovery protocol for those
   services without capability negotiation.

   Discovery MUST be possible by either the client actively
   soliciting the service or by the service advertising then the
   client passively listening for the advertisements. Once a client
   finds the printer, it can utilize different printing protocols
   such as raw tcp, lpd, and ipp.

   Within a short number of seconds after activating a print server,
   a user who is actively browsing for a printer MUST be able to see
   the device appear in a browser window, or a user application such
   as a spreadsheet MUST be able to begin using the print service.
   This requires the service discovery to be timely.

   In the case of a printer service, a printer may be temporarily
   taken off-line for repair or everyday maintenance. This requires
   clients to be able to rediscover a service.

   The zeroconf service discovery protocol requirements for this
   scenario are:
   - The protocol MUST allow the client to discover a service via
     service identifier and/or service type.
   - The protocol SHOULD allow the client to discover a service by
     characteristics.
   - The protocol MUST allow the client to discovery a service by
     actively soliciting the service.
   - The protocol MUST allow the client to discover a service by the
     client passively listening for advertisements.
   - The protocol MUST allow clients to rediscover a service.
   - Discovery MUST be timely (within seconds) when a service comes
     on line.
   - The protocol SHOULD allow services that are no longer active to
     notify clients in a time (within seconds) manner.
   - A service discovery protocol itself MUST NOT require
     configuration.
   - The protocol MUST be independent from any particular service.


2.4.2  Printer Manager

   A printer manager acts as a proxy to various printers. A printer
   manager improves scalability by providing a single location from
   which clients can find all printers.

   In addition, a printer manager provides an evolutionary path for
   service discovery deployment. For example, if an existing printer
   does not support the zeroconf service discovery protocol, the
   printer manager can use a legacy printer specific protocol to


   Hattig                                                  [Page 17]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   learn the existence and characteristics of a printer then expose
   that printer and its characteristics through the zeroconf service
   discovery protocol. This allows new printer clients that support
   the service discovery protocol to discover legacy printers that do
   not support the zeroconf service discovery protocol.

   A print manager requires a registry to cache information about
   services and characteristics of services. Clients MUST be able to
   extract data from the registry without knowledge that they are
   talking to a registry. In other words, the client and server sides
   of the service discovery protocol MUST NOT be any different
   whether a registry is involved or not. Registry updates that
   maintain the registry are required of the service discovery
   protocol but are optionally implemented for a particular service;
   this allows legacy protocols or the zeroconf service discovery
   protocol to update and maintain the registry.

   The zeroconf service discovery protocol requirements for printer
   manager scenario are:
   - The protocol SHOULD allow for registry to cache information
     about services and characteristics of services.
   - The ability for clients to extract data from the registry
     without knowledge that it is talking to a registry.
   - A registry MUST not be required for all services.

2.4.3  Requirements Summary

   Zeroconf service discovery protocol requirements are:
   - The protocol MUST allow the client to discover a service via
     service identifier and/or service type.
   - The protocol SHOULD allow the client to discover a service by
     characteristics.
   - The protocol MUST allow the client to discovery a service by
     actively soliciting the service.
   - The protocol MUST allow the client to discover a service by the
     client passively listening for advertisements.
   - The protocol MUST allow clients to rediscover a service.
   - Discovery MUST be timely (within seconds) when a service comes
     on line.
   - The protocol SHOULD allow services that are no longer active to
     notify clients in a time (within seconds) manner.
   - A service discovery protocol itself MUST NOT require
     configuration.
   - The protocol MUST be independent from any particular service. -
     The protocol SHOULD allow for registry to cache information
     about services and characteristics of services.
   - The ability for clients to extract data from the registry
     without knowledge that it is talking to a registry.
   - A registry MUST not be required for all services.



   Hattig                                                  [Page 18]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


2.4.4  IPv6 Considerations

   Service discovery protocols have no zeroconf related differences
   for IPv4 and IPv6.

3  Security Considerations & Requirements

   By definition security requires configuration. Security examples
   include a configured key for payload encryption, user entered
   passwords for conditional access, and an administrator configures
   port mappings to enable a protocol to traverse a firewall. The
   configuration required by security is in direct conflict with the
   design goals of zeroconf protocols; however, security requirements
   take precedence over zeroconf protocol design goals.

   Given this reality, this section focuses on the minimal
   configuration necessary to make zeroconf protocols secure. In
   addition, this section describes types of general threats and how
   those general threats apply to each protocol area.

   The general threats are:

   Hoarding: Hosts claim all available resources, whether they plan
   to use them or not.  This is a form of denial of service attack.

   Masquerading: Hosts can respond to requests that they should not
   so they can masquerade as another host.

   Antagonistic Server: A server could offer support for a critical
   service but intentionally misconfigure hosts on the network.

3.1 IP Host Configuration

   Threats include:
   - A host could hoard IP addresses.

   If secure zeroconf IP host configuration is required, all hosts
   MUST be certifiable as valid participants. In addition, a host
   MUST be configured with some security information. Furthermore,
   some security information must be part of every zeroconf IP host
   configuration packet.

   Here is an example to illustrate: All hosts are registered as
   valid security participants by the manufactures before the product
   ships. In addition the product is shipped with a private key.
   Before the secure device communicates with another secure device
   it gets the other device's registered info, then submits that
   registered info to the registration authority to get the devices
   public key. Of course this request is encrypted. From that point
   on all packets are encrypted using a public key and a private key.


   Hattig                                                  [Page 19]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000



3.2 Domain Name to IP Address Resolution

   Potential threats include:
   - A host could masquerade by responding to names requests
     illegitimately.
   - A host could hoard names by responding to all 'claim' requests.

   Hosts MUST be able to be configured to use a zeroconf protocol for
   domain name to IP address resolution securely.  For example, a
   'reply' from the resolution protocol could be accompanied by
   a 'signature' that 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' that could only be produced if in possession of the
   configuration data.

3.3 IP Multicast Address Allocation

   Potential threats include:
   - A host could hoard multicast addresses by denying others the
     ability to obtain them.
   - A host could snoop to learn all used IP multicast addresses in
     use then reconfigure the border router to allow IP multicast
     data to go beyond the desired boundary.

   Hosts MUST be able to be configured to use a zeroconf protocol for
   multicast address allocation securely.  For example, a claim and
   defend protocol used for multicast address allocation would have
   to include security data with all messages.  A host in the
   zeroconf network could verify that another host's claim was
   legitimate or not.

3.4 Service Discovery

   Potential threats include:
   - Servers could masquerade by responding to service discovery
     requests that they shouldn't respond to.
   - A host could pose as an antagonistic service discovery
     'infrastructure element.' Some service discovery protocols
     offer a 'registry', 'directory', 'proxy' or other
     infrastructure element for scalability.

   The service discovery protocol MUST provide mechanisms that allow
   a client to determine if both the service it discovers and the
   service discovery protocol infrastructure it uses to discover
   services are 'legitimate.'

   The service discovery protocol MUST provide mechanisms that allow
   a client to determine if both the service it discovers and the


   Hattig                                                  [Page 20]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   service discovery protocol infrastructure it uses to discover
   services are 'legitimate.'

3.5 IPv6 Considerations

   IPv6 has built in security, thus if a network is using IPv6, there
   already exists a security solution.

4  IANA Considerations

   There are no known IANA considerations arising 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 first BOF
   that was the catalyst to forming the Zeroconf Working Group, which
   is responsible for this document.

   Thanks to Erik Guttman and Stuart Cheshire for forming and
   chairing the Zeroconf Working Group.


   Hattig                                                  [Page 21]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000



   Thanks to Erik Guttman for providing key input to the service
   discovery and the security sections.

   Thanks to Dave Thaler for providing key input to the IP multicast
   address allocation sections.

   Additional recognition goes the following people for their
   influential contributions to this document and its predecessors:
   Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob
   Quinn, John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl
   Auerbach, Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland,
   and Bernard Aboba.

   Editor:

   Myron Hattig
   Intel Corporation
   3585 SW 198th Avenue
   Hillsboro, OR 97124
   myron.hattig@intel.com


7  References

   [STD 3]      R. Braden  Requirements for Internet Hosts --
                Communication Layers  RFC 1122, STD 3, October 1989

   [STD 4]      R. Braden, Requirements for Internet Hosts --
                Application and Support RFC 1123, STD 4 October 1989

   [RFC 1001]   PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP
                TRANSPORT: CONCEPTS AND METHODS, RFC 1001 March, 1987

   [RFC 1002]   PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP
                TRANSPORT: DETAILED SPECIFICATIONS, RFC 1002, March
                1987

   [RFC 1034]   P. Mockapetris, Domain Names - Concepts and
                Facilities, RFC 1034, November 1987

   [RFC 1035]   P. Mockapetris, Domain Names - Implementations and
                Specifications, 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



   Hattig                                                  [Page 22]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   [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

   [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



   Hattig                                                  [Page 23]


   Internet Draft      draft-ietf-zeroconf-reqts-04.txt    July 2000


   [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]       www.upnp.org

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

   [DNSEXT WG]  DNS Extension WG,
                http://www.ietf.org/html.charters/dnsext-charter.html

   [MALLOC WG]  Multicast Allocation WG Charter,
                www.ietf.org/html.charters/malloc-charter.html.
























   Hattig                                                  [Page 24]