[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  July 2000                                January 10, 2000


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

Status of This Memo

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

   Distribution of this memo is unlimited.

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

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

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

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

Abstract

   Zero Configuration (Zeroconf) Networks are a particular class of
   TCP/IP networks that may be established in the home, in small
   offices or even for an adhoc purpose. Zeroconf networks do not
   have and should not be expected to have user configurable network
   infrastructure such as DHCP, DNS and other administered services.
   This is because typical Zeroconf network users neither have the
   skill nor desire to configure, administer, or manage a network.

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



   Hattig                                                  [Page 1]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000



   1 Overview....................................................2
   2 Introduction................................................3
   2.1 Reading This Document.....................................3
   2.2 Zeroconf Protocols........................................4
   2.3 Zeroconf Networks........................................10
   3 Scenarios..................................................16
   3.1 IP Host Configuration Scenarios..........................16
   3.2 Domain Name to IP Address Resolution Scenarios...........18
   3.3 IP Multicast Address Allocation Scenarios................19
   3.4 Service Discovery Scenarios..............................19
   3.5 Additional Scenarios.....................................25
   4 Security Requirements......................................25
   4.1 ZeroConf Security Threat Analysis........................25
   4.2 Security Requirements....................................26
   5 Additional Considerations..................................28
   5.1 IANA Considerations......................................28
   5.2 Internationalization Considerations......................28
   5.3 Security Considerations..................................28
   6 Full Copyright Statement...................................28
   7 Acknowledgements...........................................29
   8 References.................................................30

1  Overview

   [Editor's Note: Most of the effort that has gone into version 02
   has been devoted to section 2. With the exception of service
   discovery I believe section 2 is 95% done and hope that we'll
   close on all section 2 issues in the next few weeks. This should
   put us well on the way to finish by March 10th, which is the
   submission deadline for the next IETF meeting.]

   Zero Configuration (Zeroconf) Networks are a particular class of
   TCP/IP networks. These networks may be established in a home, in a
   small office or even for an adhoc purpose.  Zeroconf networks
   typically do not have and should not be expected to have user
   configurable network infrastructure such as DHCP, DNS and other
   administered services. This is because typical Zeroconf network
   users neither have the skill nor desire to configure, administer,
   or manage a network.

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

   This Zeroconf requirements document is a companion to a Zeroconf
   profile document. This requirements document lists requirements



   Hattig                                                  [Page 2]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   for protocols. The profile document relates the protocol
   requirements to actual protocols. In some cases, a protocol may
   meet all requirements to become one of the required protocols for
   Zeroconf networks. When protocols are insufficient or multiple
   protocols are competing, the profile document states the
   requirements of the protocol and the relationship of the
   requirements to the existing protocols.

   The major sections to this requirements document are the
   Introduction, Scenarios, and Security. The introduction provides
   the background information to enable concise scenario discussions.
   Scenarios must be concise in definition and scope to generate
   useful protocol requirements. The security section lists threats
   and security requirements all four protocol areas.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
   in this  document are to be interpreted as described in [RFC
   2119].

2  Introduction

   This introduction presents how to best read this document and
   provides restrictions, assumptions, and terms.

2.1 Reading This Document

   This Introduction provides the necessary information to have a
   concise scenario discussion. This includes reference information,
   restrictions, assumptions, and terms. All readers should read the
   entire introduction.

   Of the scenarios listed in the Scenario section, different
   scenarios generate unique requirements but are not the only
   scenarios that could possibly generate those unique requirements.
   Each scenario has an overview, key points, and protocol
   requirements.

   The Security section lists threats and security requirements for
   each protocol area.

   Because this document deals four distinct protocol areas, many
   sections are divided into those areas. They are:
   - IP host configuration
   - Domain name to IP address resolution
   - IP multicast address allocation
   - Service discovery

   The below references follow this division with additional
   references for security and general knowledge. Note that some



   Hattig                                                  [Page 3]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   working groups are listed because they specify protocols that
   impact Zeroconf protocols.

   IP host configuration:
   - [AutoNet] Ipv4 Auto-Configuration I-D
   - [MiniDHCP] Auto-Addressing in Multi-segment Networks I-D
   - [RFC 1918] RFC 1918 Private Addresses
   - [RFC 2131] RFC 2131 DHCP
   - [RFC 2132] RFC 2132 DHCP Options
   - [RFC 2462] IPv6 Auto-Configuration
   - [RFC 2461] IPv6 Neighbor Discovery
   - [IPv6 WG] Next Generation (Ipv6) WG
   - [DHC WG] Dynamic Host Configuration WG

   Domain name to IP address resolution:
   - [Mcast DNS] Multicast DNS I-D
   - [RFC 1001] NETBIOS: CONCEPTS AND METHODS
   - [RFC 1002] NETBIOS: DETAILED SPECIFICATIONS
   - [RFC 1034] RFC 1034 DNS
   - [DNS WG] DNS Update WG

   Multicast address allocation:
   - [AutoMcast] Multicast Address Allocation in Auto-Configured
     Networks I-D
   - [RFC 2730] RFC 2730 MADCAP
   - [RFC 2365] RFC 2365 Administratively Scoped Multicast Address
   - [MALLOC WG] Multicast Address Allocation WG

   Service discovery:
   - [SSDP] Simple Service Discovery Protocol I-D
   - [RFC 2608] RFC 2608 Service Location Protocol v2
   - [RFC 2609] RFC 2609 SLP Schemes

   Security:
   - [RFC 2316] RFC 2316, IAB Security Architecture Workshop
   - [RFC 2401] RFC 2401, Security Architecture for IP
   - [RFC 2411] RFC 2411, IP Security Document Roadmap
   - [RFC 2504] RFC 2504, User's Security Handbook

   General knowledge:
   - [STD3] RFC 1122 Requirements for Internet Hosts - Comm Layers
   - [STD4] RFC 1123 Requirements for Internet Hosts - App Layers
   - [RFC 1458] RFC 1458 Requirements for Multicast Protocols
   - [RFC 1812] RFC 1812 Requirements for Internet Gateways

   All readers should be familiar with the general knowledge
   references.

2.2 Zeroconf Protocols




   Hattig                                                  [Page 4]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   A subsection below defines what "Zeroconf protocol" means. Then,
   additional subsections state the assumptions and restrictions of
   each protocol area.

2.2.1  Zeroconf Protocol

   Below is a definition of a Zeroconf protocol and a non-Zeroconf
   protocol. Additional discussions describe a host transitioning
   between Zeroconf and non-Zeroconf protocols, then the coexistence
   of these protocols.

2.2.1.1   Definitions

   A Zeroconf protocol requires no user configuration and does not
   rely on the existence of a centralized server.

   A non-Zeroconf protocol requires user configuration or relies on a
   centralized server.

2.2.1.2   Transitions

   A host using a Zeroconf protocol must easily transition in three
   ways:
   1. from a Zeroconf protocol to a non-Zeroconf protocol,
   2. from a non-Zeroconf protocol to a Zeroconf protocol, and
   3. from a Zeroconf protocol back to a Zeroconf protocol (possibly
     with new values).

   The Zeroconf to non-Zeroconf transition occurs when either a host
   moves to a different network or when a server becomes accessible
   on the network. For example, if a DHCP server comes on-line after
   hosts are configured with [AutoNet], then hosts must re-configure
   with DHCP.

   The non-Zeroconf to Zeroconf transition occurs when either a
   device moves to a different network or when a server is no longer
   accessible. For example, if a DHCP server is no longer on the
   network then IP hosts must re-configure with [AutoNet].

   The third transition occurs when a device moves from one Zeroconf
   network to another Zeroconf network or when the Zeroconf network
   topology changes significantly. For example, if a bridge is
   installed between two networks where hosts were already configured
   using [AutoNet], then hosts must re-configure with [AutoNet] to
   ensure duplicate IP addresses do not exist.

   A host can determine a transition is necessary by two methods: the
   host periodically checking if a transition is needed or by
   receiving a proactive mechanism from some entity that knows a
   transition is underway. Solutions SHOULD have both a periodic



   Hattig                                                  [Page 5]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   checking and a proactive mechanism (assuming the proactive
   mechanism uses an unacknowledged packet such as IP broadcast).
   Periodic checking ensures a host transitions even when that host
   does not receive the packet carrying the proactive mechanism. A
   proactive mechanism allows the time between periodic checks to be
   greater; thus the checking will not consume excessive bandwidth or
   processing resources.

   For example if the DHCP server broadcasts an "DHCPAck" with a new
   "I'm Here" option or "I'm Leaving" option as the proactive
   mechanism, then [AutoNet] must still send a periodic DCHPDiscover
   message.

   Note, the DHCP and [AutoNet] examples have no bearing on the
   stated requirements in this document. These examples were chosen
   simply because they are illustrative.

2.2.1.3   Coexistence

   A Zeroconf protocol in one area may coexist with a non-Zeroconf
   protocol in another area.

   To illustrate this point, suppose there are standard Zeroconf and
   non-Zeroconf protocols for IP host configuration and domain name
   to IP address resolution (two of the four protocol areas).

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

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

   Within a single network, the non-Zeroconf protocol-B (with its
   server) may coexist with the Zeroconf protocol-C.

   Alternately, Zeroconf and non-Zeroconf protocols from a single
   area SHOULD not coexist during normal operation. They may coexist
   during a transition, but the coexistence period SHOULD be minimal.

2.2.2  IP Host Configuration

   IP host configuration is required before virtually any IP
   communication can take place. In most cases, IP host configuration
   is complete when there is a known IP address, netmask, and default
   route for an interface on a host.

   DHCP is the common host configuration solution deployed today.
   DHCP consists of servers and clients. The client discovers the



   Hattig                                                  [Page 6]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   server, and then the server offers configuration parameters to
   clients. It is assumed that all Zeroconf IP host configuration
   schemes will co-existence with DHCP. In other words DHCP is the
   non-Zeroconf solution for IP host configuration.

2.2.3  Domain name to IP address resolution

   Web browsing to an URL utilizes domain name to IP resolution. This
   resolution capability allows applications (and sometimes users) to
   remain blissfully unaware of IP addresses.

   DNS is the common way to resolve names. DNS consists of servers
   that maintain resource records; a record maps a domain name to an
   IP address. In addition, resolvers on hosts query the DNS servers
   for the information in resource records. DNS is the non-Zeroconf
   solution for domain name to IP address resolution.

2.2.4  IP Multicast Address Allocation

   Examples of emerging multicast applications include audio/video
   (e.g. TV), bulk news, and intra-home intercom system. These
   applications require an IP multicast address prior to sending IP
   multicast packets. In most cases, the IP multicast address is
   unique per application source. The scope of the multicast address
   determines if the multicasted packets get transmitted beyond
   certain administrative domains (e.g. through a RFC 2365 boundary
   router).

   MADCAP is the non-Zeroconf IP multicast address allocation
   solution. MADCAP is a server-client protocol where clients request
   IP multicast addresses from a server. MADCAP operates much like
   DHCP.

   Zeroconf solutions are only concerned with IP multicast address
   scoped as site-local (i.e. 239.255.0.0/16). A boundary router (as
   described in [RFC 2365]) must be present to appropriately control
   multicast packets from entering and leaving the Zeroconf network.

2.2.5  Service Discovery

   Service discovery protocols have proven to be critical to the
   usability of networks. AppleTalk/NBP, NetBIOS/SMB and IPX/SAP are
   perfect examples in that they greatly improved the utility of
   their respective network architectures. Services from printing to
   gaming are easily found on these networks.

   Unlike the other protocol areas in this document, service
   discovery will not likely have separate Zeroconf and non-Zeroconf
   protocols; one protocol will serve both purposes.




   Hattig                                                  [Page 7]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   Also, unlike the other protocol areas, no incumbent service
   discovery protocol exists. Service Location Protocol version 2
   (SLPv2) is defined in Standards Track RFC 2609. An Internet-Draft
   defines Simple Service Discovery Protocols (SSDP), which is
   another service discovery protocol.

   Considerable service discovery terminology is necessary to have a
   service discovery scenario discussion. The terms below are
   categorized into basic, processes, packet types, actions, then
   alphabetized within those categories. Following the terms is a
   list of service discovery protocol assumed requirements.

   Basic Terms:

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

   Service - A service is set of processes that do a wide range of
   network related things. Services range from printing to
   transferring a file to providing on-line pizza order and delivery
   service. A service may find some network management information,
   perform some action, control some resource, or perform just about
   any network-related function.

   Service Characteristics - Characteristics differentiate services.
   They may differential the same type of service in terms of
   capabilities (e.g. color printing vs black and white), state (e.g.
   printer ready vs paper jam), physical location (e.g. my office vs
   my home), and many other things. Characteristic may include
   service-unique information such as access information, version
   numbers, contact information, etc.

   Service Discovery Protocol - A service discovery protocol enables
   a client (or clients) to discover a server (or servers) of a
   particular service. A service discovery protocol is an application
   layer protocol that relies on, but does not interact with, network
   and transport protocol layers.

   Service Identifier - A service may be identified by general
   service type as well as service characteristics. Clients, servers,
   advertisers, discoverers, and registries use service identifiers.

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

   Processes:

   Advertiser - A process that advertises a service using a service
   discovery protocol. A server generally activates the advertiser.




   Hattig                                                  [Page 8]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   Client - A process that uses a service discovery protocol to
   discover a service.

   Discoverer - A process that discovers a service using a service
   discovery protocol. A client generally activates the discoverer.

   Registry - A process that acts as an intermediary between
   discoverers and advertisers.  Servers 'register' service
   advertisements and other pertinent (e.g. authentication info,
   announcement criteria) with registries, then the service may be
   discovered from the registry instead of from a server. The
   registry may be centralized for a group of clients to access or
   cached within a single client. A registry reduces the number of
   queries to enhance the scalability of a service discovery
   protocol.

   Peer - A process that is both a client and service for a specific
   service protocol.

   Server - A process that offers a service to clients through a
   service discovery protocol.

   Packets Types:

   Service Advertisement - A solicited response issued by a server or
   registry. The advertisement provides the service identifier and
   possibly service characteristics.

   Service Solicitation - A request made by a client to obtain
   service advertisements.

   Service Announcement - An unsolicited informative message issued
   by a server or registry. The announcement provides the service
   identifier and possibly service characteristics.

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

   Actions:

   Client-Server negotiation: The act of a client using the service
   protocol to negotiate with a server after the service has been
   discovered with the service discovery protocol.

   Registry cleanup: An internal process of the registry to remove
   unwanted information.

   Service discovery: The act of a client discovering a service.




   Hattig                                                  [Page 9]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   Utilizing a service: The act of a client using a service after the
   service has been discovered.

   Assumed Service Discovery Protocol Requirements:

   A service discovery protocol MUST allow a client to discover then
   utilize a service.

   A discovery protocol itself MUST require no configuration.
   (Clients must know what they need and services must know what they
   are, but this is a service installation and configuration issue,
   not a service discovery issue.)

   A service discovery protocol SHOULD allow a client to use
   Solicitation messages with specific characteristics. This enables
   a client to avoid complex client-server negotiations that may
   occur after service discovery. Characteristics also allow human
   users to determine which service to use (browse).

   A service discovery protocol SHOULD limit the use of Service
   Announcement messages so as to not flood the network unnecessarily
   and most importantly not cause 'broadcast storms'.

   A service discovery protocol SHOULD automatically sense when it
   must stop multicasting requests from Discoverers to Advertisers
   and instead employ a Registry of some sort.

   A service discovery protocol MUST not cause scalability or
   operational problems in larger non-Zeroconf networks if clients
   and servers somehow transition to such networks.

   A service discovery protocol MUST be rich enough in its semantics
   to be able to represent a wide range of services.

2.3 Zeroconf Networks

   A Zeroconf network is a network that at some point in time has one
   or more Zeroconf protocols. By this definition, almost all
   networks are Zeroconf networks. This definition is intentionally
   broad to avoid mandating a network to be Zeroconf or exclude
   another network from using a Zeroconf protocol. The Internet and
   corporate LANs are considered non-Zeroconf networks because,
   today, these networks have little use for Zeroconf protocols.

   This section describes the existing Internet network model, the
   Zeroconf topologies, and a summary of the key points.

2.3.1  Existing Internet Model





   Hattig                                                  [Page 10]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   All networks in this document follow the Internet Model as
   described in [RFC 1812]. Specifically, networks consist of
   bridges, routers, hosts, link layer networks, and IP networks to
   form internets. A summary of the terms from [RFC 1812] that apply
   to this document are:
   - Bridge: a device that routes link layer packets (e.g. Ethernet
     packets) between link layer networks (e.g. Ethernet) based on
     the destination link layer addresses (e.g. 48-bit Ethernet
     address) of a packet.
   - Router: a devices that routes IP packets between IP networks
     based on the destination IP address of an IP packet.
   - IP network: a network that consists of hosts with interfaces
     that share the same network portion of their IP addresses. A
     single IP network may physically consist of several link layer
     networks connected by a bridge, but it is one logical IP
     network; the hosts remain unaware of the bridge or multiple
     link layer networks.
   - internet: a network that consists of multiple IP networks
     connected by routers.

2.3.2  Isolated Single IP Network

   In an isolated single IP network topology, hosts connect directly
   to each other without routers. This implies no connectivity to
   non-Zeroconf networks.

   Enabling isolated single IP networks is one of the primary
   motivations behind this document.

   Two instances of single IP-network topologies are shown in Figure
   1 and Figure 2.

        *****************************************************
        * Zeroconf Network                                  *
        *                                                   *
        *            ------ crossover cable -------         *
        *            |                            |         *
        *            |                            |         *
        *         +------+                    +------+      *
        *         | Host |                    | Host |      *
        *         +------+                    +------+      *
        *                                                   *
        *****************************************************

                 Figure 1. Cross-over cable Ethernet network

   The Zeroconf network in Figure 1 has two hosts connected through a
   crossover Ethernet cable. Infrared or other point-to-point
   wireless technologies are similar examples. These networks can be




   Hattig                                                  [Page 11]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   created and torn down on an adhoc basis for seminars, conferences,
   hour-long meetings, or for many other reasons.

        *****************************************************
        * Zeroconf Network                                  *
        *                                                   *
        *            -------[ HUB ]-------                  *
        *            |         |         |                  *
        *            |         |         |                  *
        *         +------+  +------+  +------+              *
        *         | Host |  | Host |  | Host |              *
        *         +------+  +------+  +------+              *
        *                                                   *
        *****************************************************

                 Figure 2. Hosts connected by Ethernet Hub

   The Figure 2 Zeroconf network has a small number of hosts
   connected through an Ethernet hub. This may be a small office
   network or a gaming network.

   In this topology, IP broadcast packets reach all hosts and no
   routing takes place, thus a default route is not a needed
   configuration parameter. A host sending an IP packet SHOULD not
   AND the netmask with the destination IP address to determine
   whether to forward the IP packet to the default router or to send
   an ARP packet to resolve the destination IP address to a hardware
   address. Instead, hosts SHOULD always opt to use ARP; a default
   route existing or not existing in the IP host configuration
   determines this.

2.3.3  Single IP Network with a Gateway

   A specialized router called a gateway resides between the Zeroconf
   and non-Zeroconf networks. The single IP network within the
   Zeroconf network connects directly to the gateway.

   The gateway is a specialized router in that it restricts the
   routing of IP packets between the Zeroconf and non-Zeroconf
   networks. This restriction ensures autonomy of the Zeroconf
   network and avoids many security problems. In addition, the
   gateway acts as a multicast boundary router as defined in RFC
   2365.

   Enabling single IP networks with a gateway is one of the primary
   motivations behind this document.

   Figure 3 shows the single IP network with a gateway topology.

                    ***************************



   Hattig                                                  [Page 12]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


                    *                         *
                    *      non-Zeroconf       *
                    *         Network         *
                    *                         *
                    ***************************
                                 |
                                 |
                                 |
                         +----------------+
   **********************|     Gateway    |*************************
   * Zeroconf Network    +----------------+                        *
   *                             |                                 *
   *                             |                                 *
   *                             |    IP Network                   *
   *     ------------------------|-----------------------------    *
   *     |       |               |                  |         |    *
   *     |       |               |                  |         |    *
   *     |       |               |                  |         |    *
   *  +------+  +------+     +------+           +------+  +------+ *
   *  | Host |  | Host |     | Host |           | Host |  | Host | *
   *  +------+  +------+     +------+           +------+  +------+ *
   *                                                               *
   *****************************************************************

              Figure 3. Single IP Network with a Gateway

   Examples of this topology include a typical small business network
   with remote-access router and a single Ethernet segment. Another
   common example is a home network with an ADSL-modem and a single
   Home Phonewire Network Alliance (HomePNA) link connecting a few
   PCs.

   In this topology, broadcast packets reach all hosts and routing
   only occurs to communicate between Zeroconf and non-Zeroconf
   networks. All hosts SHOULD rely on netmask and the default route
   as a normal IP host does when determining to ARP or to forward
   packets to the default route.

2.3.4  Multiple IP Networks through a Gateway

   In this topology, all IP networks within the Zeroconf network
   connect directly to the gateway.

   Enabling this topology is a goal for this document.

   Figure 4 shows the general form of this topology.

                    ***************************
                    *                         *
                    *       Non-Zeroconf      *



   Hattig                                                  [Page 13]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


                    *         Network         *
                    *                         *
                    ***************************
                                 |
                                 |
                                 |
                         +----------------+
   **********************|     Gateway    |*************************
   * Zeroconf Network    +----------------+                        *
   *                       |     |      |                          *
   *                       |     |      |                          *
   *                       |     |      |                          *
   *                       |     |      |                          *
   *        IP network A   |     |      |     IP network B         *
   *     ------------------|     |      |----------------------    *
   *     |       |               |                  |         |    *
   *     |       |               | IP network C     |         |    *
   *     |       |               |                  |         |    *
   *  +------+  +------+     +------+           +------+  +------+ *
   *  | Host |  | Host |     | Host |           | Host |  | Host | *
   *  +------+  +------+     +------+           +------+  +------+ *
   *                                                               *
   *****************************************************************

            Figure 4. Multiple IP Networks through a Gateway

   The primary example of this topology is a future home network with
   many link layers such as HomePNA, HomeRF, IEEE 802.11, and IEEE
   1394-1995. These link layers are installed because they either
   require no new wires (e.g. phone line, wireless, powerline) or
   provide some special function such as the ability to roam (e.g.
   wireless) or to carry high-quality video streams (e.g. IEEE 1394-
   1995).

   Communication between IP networks within the Zeroconf network and
   between the Zeroconf and non-Zeroconf networks is achieved by
   utilizing the routing capability in the gateway; therefore all
   hosts SHOULD be configured with netmask and default route.
   Broadcasts do not reach all hosts within the Zeroconf Network;
   therefore, multicasting is the best solution to reach all hosts.
   In order for multicast packets to reach all hosts, the gateway
   must be a multicast router and act as a boundary router (as
   defined in RFC 2365) to restrict certain multicast packets from
   leaving the Zeroconf network.

2.3.5  Networks with Routers and Gateways

   In this topology, routers connect IP Networks within the Zeroconf
   network and gateways connect the Zeroconf network to the non-
   Zeroconf network.



   Hattig                                                  [Page 14]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000



   Supporting this topology is not a goal of this document because it
   would require router auto-configuration, router pre-configuration,
   or some router-to-router communication to somehow enable router
   configuration; this document in no way precludes such work in
   other documents.

   Zeroconf protocols that communicate between a host and a router to
   configure the host MAY be considered.

   Figure 5 shows a sample network with routers and gateways.

                    *************************************
                    *                                   *
                    *               Internet            *
                    *                                   *
                    *************************************
                                 |                |
                                 |                |
                                 |                |
                      +----------------+    +------------+
   *******************|     Gateway    |****|   Gateway  |***********
   * Zeroconf Network +----------------+    +------------+          *
   *                             |   |               | IP network D *
   *                             |   |               |              *
   * IP network A   +--------+   |   | IP network C +--------+      *
   *     -----------| Router |---|   |--------------| Router |      *
   *     |       |  +--------+   |                | +--------+      *
   *     |       |               |IP network B    |        |        *
   *     |       |               |                |        |        *
   *  +------+  +------+     +------+         +------+  +------+    *
   *  | Host |  | Host |     | Host |         | Host |  | Host |    *
   *  +------+  +------+     +------+         +------+  +------+    *
   *                                                                *
   ******************************************************************

                          Figure 5. Routers and Gateways Network

   This topology is only applicable in a medium to large business;
   generally, these are not Zeroconf networks.

2.3.6  Summary

   The purpose of showing topologies is to make this document
   concise. The purpose is not to mandate some networks as Zeroconf
   and others as non-Zeroconf.

   The gateway is a specialized router. It restricts packets that
   pass between the Zeroconf and non-Zeroconf networks to ensure
   autonomy of the Zeroconf network and to avoid many security



   Hattig                                                  [Page 15]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   problems. The gateway SHOULD act as a boundary router as defined
   in RFC 2365.

   All Zeroconf protocols MUST operate in single IP networks
   (isolated and connected) and SHOULD operate in networks with
   multiple IP networks with a single gateway. It is beneficial, but
   not required, for Zeroconf protocols to operate in networks with
   multiple gateways and multiple routers.

3  Scenarios

   This section lists Zeroconf scenarios that lead to requirements
   for protocols. Specific protocols are not discussed.

   Each scenario begins with an explanation or overview. Then, the
   key points of the scenario are identified along with requirements.
   Each scenario has the following outline:
   - Overview
   - Key Points
   - Protocol Requirements

   The scenarios are grouped by IP host configuration, domain name to
   IP address resolution, IP multicast address allocation, and
   service discovery.

   The scenarios take place within a Zeroconf network unless
   otherwise stated.

3.1 IP Host Configuration Scenarios

3.1.1  Isolated Single IP Network Communication

3.1.1.1   Overview

   Hosts on a single IP network communicate to each other.

3.1.1.2   Key Points

   This scenario applies to single IP network topologies (isolated or
   with a gateway). Only the IP address must be configured. The
   netmask can be configured to a value or assumed to be
   255.255.255.255. No default route is needed.

3.1.1.3   Protocol Requirements

   - IP hosts MUST configure an IP address.
   - IP hosts MUST configure a netmask or assume 255.255.255.255.
   - The host number of an IP address MUST be unique within a single
     IP network.




   Hattig                                                  [Page 16]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   - The network number of an IP address MUST equal the network
     number of other IP addresses within a single IP network.

3.1.2  Multiple IP Network Communication

   All the networks in this section are isolated from non-Zeroconf
   networks.

3.1.2.1   Overview

   Hosts on multiple IP networks within a Zeroconf network
   communicate to each other.

3.1.2.2   Key Points

   This scenario is important for star topologies and ad-hoc
   topologies.

3.1.2.3   Protocol Requirements

   - IP hosts MUST configure an IP address.
   - IP hosts MUST configure a netmask.
   - IP hosts MUST configure a default route.
   - The host number of an IP address MUST be unique within a single
     IP network.
   - The network number of an IP address MUST equal the network
     number of other IP addresses within a single IP network.
   - Network numbers of IP addresses MUST be unique within the entire
     Zeroconf network.
   - IP address MUST be routable within the Zeroconf network.

3.1.3  Bridge Installed

3.1.3.1   Overview

   Between two operational IP networks, a bridge (or hub) is
   installed. Now, two hosts on the newly formed IP network may share
   the same IP address. In addition, hosts on different link layer
   networks may not have been using the same network number and now
   they must share the same network number.

3.1.3.2   Key Points

   This is a special case of a previous scenario when IP hosts first
   communicate on the same IP network. All the key points and
   requirements to the previous scenario apply. In addition, host
   must have the ability to re-configure their IP address and net
   mask.





   Hattig                                                  [Page 17]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


3.1.3.3   Protocol Requirements

   - Hosts MUST be able to re-configure their IP address and netmask
     after networks are connected.

   There is an addition requirment to your "periodic conflict
     detection" requirement. It is an active mechanism to restart
     conflict detction. This is needed in case the period is too
     large for a hosts needs.

   - All requirements in section 3.1.1.3.

3.1.4  Router Installed

3.1.4.1   Overview

   Within a Zeroconf network, a router is installed after IP hosts
   have been configured to communicate throughout the Zeroconf
   network. Multiple IP networks within the Zeroconf network may now
   share the same IP network number.

3.1.4.2   Key Points

   This is a special case of a previous scenario when hosts on a
   multiple IP networks within a Zeroconf network communicate. All
   the key points and requirements to the previous scenario apply. In
   addition, host must have the ability to re-configure their IP
   address, net mask, and default route.

3.1.4.3   Protocol Requirements

   - Hosts MUST re-configure IP address, net mask, and default route
     at various times after the initial configuration.
   - All requirements in section 3.1.2.3.

3.2 Domain Name to IP Address Resolution Scenarios

3.2.1  Resolve Non-Fully Qualified Name

3.2.1.1   Overview

   Domain names within the Zeroconf network must be resolved to IP
   addresses. This enables one of the most basic of TCP/IP networking
   paradigms of applications only being aware of host names and not
   IP addresses.

3.2.1.2   Key Points

   Name resolution must span the entire Zeroconf network, but be
   limited by the gateway from leaving or entering the Zeroconf



   Hattig                                                  [Page 18]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   network. This protocol should include the ability for a host to
   choose a name, determine if the name is in use, and then choose a
   different name if it is re-used.

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

3.2.1.3   Protocol Requirements

   - A host that wishes to be addressable by name MUST select a
     domain name.
   - A host MUST determine if the domain name is in use by another
     host.
   - A host MUST participate to defend the name it uses.
   - A host MUST be able to reconfigure its name in the case it was
     unable to successfully defend the name it previously used.
   - At various times a host MUST actively determine if another host
     is using its name.
   - Gateways MUST restrict this protocol from leaving or entering
     the Zeroconf network.
   - Routers MUST route this protocol to ensure it spans the entire
     Zeroconf network.

3.2.2  Resolve Fully Qualified Name

   [TBD]

3.2.2.1   Overview
3.2.2.2   Key Points
3.2.2.3   Protocol Requirements

3.3 IP Multicast Address Allocation Scenarios

   [TBD]

3.3.1  Allocate XX Scoped IP multicast address

   [TBD, one XX for each relevant scope.]

3.4 Service Discovery Scenarios

3.4.1  Discover Printer

3.4.1.1   Overview

   Networked enabled printers allow various clients to submit print
   jobs.  There are different printing protocols possible (raw tcp,
   lpd, ipp, etc.)  Further, printers vary in a number of ways (their
   location, status and capabilities).  Printer discovery is



   Hattig                                                  [Page 19]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   important for both printing clients as well as 'printing managers'
   - that is, software which manages all printers of a particular
   kind on the network.

3.4.1.2   Key Points

   Printer discovery must allow a printing client to discover the
   location of a printer and enough information about the print job
   submission protocol to be able to submit jobs.  Further printer
   discovery must discriminate between printers which are useful and
   those which are not.  A printer which is located in a remote
   facility (across a continent) is not useful, nor is a printer
   which can't print in color, on transparencies, etc. if that is
   what the client needs to do.  Printer discovery has to be timely -
   so that when a printer comes on line, a print client or a print
   manager application can discover the printer in a timely way.

3.4.1.3   Protocol Requirements

   Printer discovery implies the following requirements for service
   discovery.

   - The service discovery mechanism has to allow for discriminating
     queries.  A client has to be able to discover a printer for
     which it has a driver, for instance.

   - Service discovery has to be able to discover the characteristics
     of an advertised service.  A print client or a print manager
     has to be able to find out the configuration and possibly even
     status of the printer to be able to adequately provide
     information to the print client or print manager which is
     searching for appropriate print servers.  This information may
     be used for a user interface or by a program so the format of
     the information has to be standardized.

   - Service discovery has to be able to be done in a 'timely way.'
     That is, within a short number of seconds after activating a
     print server, a user who is actively browsing for printer
     should be able to see the device appear in a browser window, or
     a printer manager should be able to begin managing the print
     server.

3.4.2  Discover File Access Server

3.4.2.1   Overview

   File sharing is done using different protocols.  A file sharing
   client is only interested in file sharing services which use the
   access protocol it is capable of. File sharing is typically done
   by human users - in this case attributes of the file access server



   Hattig                                                  [Page 20]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   have to be discovered so the human user can select which server to
   access.  File sharing is done on a 'session basis' so timely
   rediscovery of selected file servers is necessary.

3.4.2.2   Key Points

   File sharing is a key application of personal computing.  There
   are a variety of file access protocols available (NFS, Novell file
   access protocol (?), AppleShare, NetBIOS/SMB, etc.) A client must
   be able to discover those file systems which exist on a network,
   which the client can get access to, that support the file access
   protocol the client is capable of using.

   Further, existing service discovery mechanisms for file access
   servers (from Novell, Apple and Microsoft proprietary protocols)
   allow the user to discover something about the file system they
   would access.  This include the name of the file system, a human
   readable description of it as well as a 'group' or 'groups' that
   the file system was shared to.

   Since there may be many 'peers' in a network of personal computing
   devices, it is critical that some grouping is possible, so that
   users can locate file access servers that are meaningful to them
   (located nearby, shared by colleagues close to them in the
   organization, shared by those who will allow the user access to
   the files, file systems whose content is of a general kind, etc.)
   Further, grouping file access servers is important to allow the
   service discovery activity to be scalable in a network containing
   many systems capable of (or actively)  providing file access
   service.  This scalability consideration is different than the
   previous point (where grouping services prevents too much
   information to select from).  In this case, scalability implies
   that requests will only be received and processed by a subset of
   the file access servers which advertise their services (or by a
   subset of the 'service discovery protocol infrastructure' to be
   more general).  This will prevent service discovery from being a
   burden to the network.  This is an extremely important point:
   Experience has shown that service discovery for services which are
   shared by many personal computers in larger networks can have
   disastrous effects.

   AppleTalk, Novell networks and Microsoft networks all suffer in
   performance for this reason. Finally, file access is typically
   done on a 'session' basis.  That is, when a user decides to access
   a file system, he or she wants access to it over time.  If the
   file system is not available for a time, the user wants to get
   access to it again when the file system is again available.  If
   the client system is moved or deactivated, the user wants to be
   able to discover the same file system again when the client device




   Hattig                                                  [Page 21]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   is again able to locate the previously discovered and selected
   file access server.

3.4.2.3   Protocol Requirements

   File access server discovery implies the following requirements:

   - Clients can discover the location of file access servers which
     support the file access protocol they support.

   - Clients can discover only those file access servers which are in
     a 'group' they are interested in.  This grouping has to be
     possible along a variety of different conceptual lines
     location, organizational - like which department, or functional
     - like a general description of the servers such as "reference
     library" or "mailing list archives".)  This is possible in
     Novell, AppleTalk and Microsoft networks.  It should be
     possible on IP networks in general.

   - The groupings listed above must be able to limit the effects of
     the file access protocol on the network.  This allows for
     scalable service discovery in a larger network.

   - Clients can discover some information about file systems that
     they could choose to access (the name of the file system, a
     description of it and whether the user has access permission,
     at the very least).

   - Clients should be able to rediscover the file system over time
     so that the user can discover the same file access service even
     if that service goes down and comes back up, or if the client
     device moves or goes down, then is once again on a network
     where the file access server is present.

3.4.3  Discover Manageable Device

3.4.3.1   Overview

   One important application of service discovery is the discovery of
   manageable devices by a 'management' system.  Conversely,
   manageable devices may need to discover their manager.  The
   relationship between manager and managed system is different than
   is the case in most service discovery applications since the
   manageable device is in many respects a service with respect to
   the manager, but there is usually only one manager and many
   manageable systems.

3.4.3.2   Key Points





   Hattig                                                  [Page 22]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   The management system (manager) needs to be able to discover
   devices which support appropriate management services (management
   agents). Currently this discovery is done in many networks by
   having the manager scan all addresses in order to determine the
   location and existence of all agents.  This does not scale well to
   larger address spaces.

   Managers need to discover agents in a timely way.  That is, when
   an agent is activated, a manager needs to be able to discover it
   within a short number of seconds.

   Managers often need to discover a set of agents which have a
   certain configuration.  For instance, only those agents running on
   a certain hardware platform, with a certain software version.
   This allows the manager to determine the population of agents
   which need an upgrade immediately.  This is not to say that the
   service discovery mechanism should replace the management protocol
   (whereby the manager can interrogate the agent and obtain or set
   specific management information). The facility to find only
   specific agents allows the manager to discriminate among agents on
   the network so that it can interrogate only that subset that are
   relevent.  This is important for scaling management software to
   larger networks where there may be many agents.  This is even
   important on smaller networks where a specialized manager is only
   able to manager a very specific subset of all devices.

3.4.3.3   Protocol Requirements

   The service discovery mechanisms for managers to find agents (and
   thereby manageable devices) require the following:

   - Managers have to be able to find all agents they can manage.

   - Managers have to have the ability to discover agents shortly
     after they are activated.

   - Managers have to be able to discover only the subset of agents
     that are relevant.  This means that managers have to be able to
     discover agents on the basis of their hardware, software or
     there device specification or status.  To some extent the
     service discovery protocol has to return information about the
     agent to the manager, but this enhances the manager-agent
     relationship.  It does not replace the management protocol
     which can do specific management operations (including very
     specific structured queries of an agent by a manager).

3.4.4  Discover Service Discovery Infrastructure

3.4.4.1   Overview




   Hattig                                                  [Page 23]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   Service discovery protocols have two modes:  The first is used in
   a zeroconf environment.  The protocol in this case may not scale
   very well in a larger environment.  The second mode is to be used
   in a configured network.  In this case, the service discovery
   protocol must scale well.  Clients discovering services and
   servers offering services have to be able to discover 'service
   discovery infrastructure' when it is present and transition to its
   use.  Further, configuration must be able to be supplied to
   clients and servers so that they will use the service discovery
   infrastructure scalably and appropriately.

3.4.4.2   Key Points

   Service discovery infrastructure has to be able to be discovered
   quickly, and by all clients and servers which are using a service
   discovery protocol.   This allows for a transition from an ad hoc
   (multicast or broadcast based protocol) to one which is suitable
   for larger networks.

   This service discovery infrastructure provides a concentration of
   service discovery information so that point to point messages can
   be exchanged instead of all service discovery messages having to
   be either multicasted (either solicitations or advertisements).

   Clients and servers using a service discovery protocol in a
   zeroconf environment have to be able to obtain configuration.
   This configuration will enable the clients and servers to use
   specific portions of the service discovery infrastructure, or to
   use it in a particular way. This allows, for instance, services to
   be advertised according to a particular policy, as belonging to a
   particular department, in a particular location or network, etc.
   Similarly, clients obtaining configuration will only discover
   services which they are directed to, such as services in their
   department, hotel room, etc.

3.4.4.3   Protocol Requirements

   Requirements arising from discovery of service discovery
   infrastructure include:

     - Service discovery infrastructure provides a transition from
     zeroconf service discovery protocol use to scalable and
     configured service discovery protocol use.

     - Service discovery infrastructure has to be discoverable by
     clients and servers which use a service discovery protocol
     automatically, and reasonably quickly.  The clients and servers
     have to use this infrastructure if it becomes available to
     ensure scalable behavior.




   Hattig                                                  [Page 24]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


     - Configuration of clients and servers using a service discovery
     protocol has to be able to be done dynamicly.  This way clients
     and servers will obtain the necessary configuration to operate
     effectively in larger networks according to the service
     deployment policy employed in the network the system is present
     in.

3.5  Additional Scenarios

   [EDITOR'S NOTE: Please post additional scenarios for discussion to
   Zeroconf@merit.edu. Eventually this section will be removed.]

4  Security Requirements

   The principal goal of security requirements for ZeroConf
   networking is to not make IP networking less secure than it is
   without the use of ZeroConf protocols.  This is challenging since
   ZeroConf provides the ability for any host to obtain host
   configuration, to discover and to use network resources.  In the
   case where ZeroConf access media is physically accessible (e.g.
   wireless, powerline) or routed to additional network segments,
   there is no longer any physical security.

   The following sections are security considerations for the four
   areas which this document addresses.

4.1 ZeroConf Security Threat Analysis

   The threats fall into three broad categories:

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

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

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

4.1.1  IP Host Configuration

   Potential threats include:
   - A host could hoard IP addresses, denying others access to the
     network.

   - A host could pose as an antagonistic DHCP server and
     misconfigure other hosts on the network.

4.1.2  Domain name to IP address resolution




   Hattig                                                  [Page 25]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   Potential threats include:
   - A host could masquerade, responding to names requests
     illegitimately.
   - A host could hoard names, responding to all 'claim' requests.
   - A host could pose as an antagonistic DNS server and fail to
     resolve names correctly, or intentionally resolve them
     incorrectly.

4.1.3  Multicast Address Allocation

   Potential threats include:
   - A host could hoard multicast addresses, denying others the
     ability to obtain them.

4.1.4  Service Discovery

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

4.2 Security Requirements

   Protocols designed for host configuration, name resolution,
   service discovery and multicast address allocation include
   security mechanisms. These protocols have been designed for use in
   configured networks. The same security mechanisms appropriate in a
   configured network is not useful in a ZeroConf network.

   ZeroConf requirements will not specify that all security threats
   be addressed by ZeroConf protocols since it would be inappropriate
   to do so.

   Security always requires configuration.  For that reason, no
   secure operation will be possible on a network which has
   absolutely no configuration.

   That is not the same as saying that ZeroConf requirements are
   silent with respect to security.  When configuration is added to a
   host using ZeroConf protocols, the host transitions to another
   mode of operation. In this case, the host which is appropriately
   configured may be able to counter threats posed to systems using
   ZeroConf protocols.

   The ZeroConf requirements specify the transition from insecure to
   secure operation.  A host fulfilling ZeroConf requirements will be
   capable of secure operation in each protocol area, if it is



   Hattig                                                  [Page 26]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   supplied with appropriate security configuration (such as
   cryptographic keys.)

4.2.1  IP Host Configuration

   Hosts MUST be able to be configured to use DHCP authentication.

   Option 1:

   No provision is made for securing IP Host Configuration using
   the ZeroConf protocol for IP Host Configuration.

   Option 2:

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

4.2.2  Domain name to IP address resolution

   Hosts MUST be able to be configured to use DNS Security.

   Option 1:

   No provision is made for securing the ZeroConf Domain Name to IP
   address resolution protocol.

   Option 2:

   Hosts MUST be able to be configured to use a ZeroConf protocol for
   Domain name to IP address resolution securely.  For example,
   a 'reply' from the resolution protocol could be accompanied by
   a 'signature' which could be verified before being accepted.
   The security configuration would have to provide the server
   portion of the protocol with the data needed to produce a
   'signature' which could only be produced if in possession of the
   configuration data.

4.2.3  Multicast Address Allocation

   Hosts MUST be able to be configured to use MADCAP security.

   Option 1:

   No provision is made for securing the ZeroConf protocol for
   multicast address allocation.

   Option 2:



   Hattig                                                  [Page 27]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000



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

4.2.4  Service Discovery

   Both clients and servers MUST be able to be configured to use
   security mechanisms offered by the Service Discovery Protocol.

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

   The service discovery protocol MUST provide mechanisms so that a
   server can use security configuration to advertise service
   information in a way that clients can verify.

   The service discovery protocol MUST provide mechanisms so that a
   client can use security configuration to verify service
   information it obtains.  The client is essentially verifying that
   the server had possession of certain secrets.  The client trusts
   that only 'legitimate' servers would possess these secrets.

5  Additional Considerations

5.1 IANA Considerations

   There are no known IANA considerations arising from this document.

5.2 Internationalization Considerations

   Zeroconf protocols may exchange human readable strings. Human
   readable strings may need to be internationalized.

5.3 Security Considerations

   Zeroconf security considerations are in Section 5 of this
   document.

6  Full Copyright Statement

   Copyright (C) The Internet Society (1997). All Rights Reserved.

   This document and translations of it may be copied and furnished
   to others, and derivative works that comment on or otherwise
   explain it or assist in its implementation may be prepared,



   Hattig                                                  [Page 28]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   copied, published and distributed, in whole or in part, without
   restriction of any kind, provided that the above copyright notice
   and this paragraph are included on all such copies and derivative
   works. However, this document itself may not be modified in any
   way, such as by removing the copyright notice or references to the
   Internet Society or other Internet organizations, except as needed
   for the purpose of developing Internet standards in which case the
   procedures for copyrights defined in the Internet Standards
   process must be followed, or as required to translate it into
   languages other than English.

   The limited permissions granted above are perpetual and will not
   be revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on
   an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE."

7  Acknowledgements


   Thanks to Peter Ford for hosting the first BOF that was the
   catalyst to forming the Zeroconf Working Group.

   Thanks to Erik Guttman and Stuart Cheshire for forming and
   chairing the Zeroconf Working Group which is responsible for this
   document.

   Thanks to Erik Guttman for providing much of the text relating to
   service discovery and the security requirements.

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

   Editor:

   Myron Hattig
   Intel Corporation
   2111 NE 25th Ave.  JF3 206
   Hillsboro, OR 97124
   myron.hattig@intel.com




   Hattig                                                  [Page 29]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000



8  References

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

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

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

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

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

   [RFC 1458]   R. Braudes, Requirements for Multicast Protocols, RFC
                1458, May 1993

   [RFC 1918]   D. Karrenberg, et al, Address Allocation for Private
                Internets, RFC 1918, Feb 1996

   [RFC 2026]   S. Bradner, The Internet Standards Process --
                Revision 3, RFC 2026 Oct 1996

   [RFC 2119]   S. Bradner.  Key words for use in RFCs to Indicate
                Requirement Levels.  RFC 2119, March 1997.

   [RFC 2131]   R. Droms.  Dynamic Host Configuration Protocol.  RFC
                2131, March 1997.

   [RFC 2132]   S. Alexander, R. Droms  DHCP Options and BOOTP Vendor
                Extension RFC 2132, March 1997.

   [RFC 2316]   S. Bellovin, Report of the IAB Security Architecture
                Workshop, RFC 2316, April 1998

   [RFC 2365]   D. Meyer  Administratively Scoped Multicast Address
                RFC 2365,July 1998.

   [RFC 2401]   S. Kent, Security Architecture for the Internet
                Protocol, RFC 2401, Nov 1998

   [RFC 2411]   R. Thayer, IP Security Document Roadmap, RFC 2411,
                Nov 1998





   Hattig                                                  [Page 30]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   [RFC 2461]   T. Narten, E. Nordmark, W. Simpson  Neighbor
                Discovery for IP Version 6 (IPv6)  RFC 2461, December
                1998.

   [RFC 2462]   S. Thomson, T. Narten  IPv6 Address Autoconfiguration
                RFC 2462, December 1998.

   [RFC 2504]   E. Guttman, Users' Security Handbook, RFC 2504, Feb.
                1999

   [RFC 2608]   E. Guttman, C. Perkins, J. Veizades, and M. Day.
                Service Location Protocol version 2.  RFC 2608, June
                1999.

   [RFC 2609]   E. Guttman, C. Perkins, J. Kempf  Service Templates
                and service: Schemes,  RFC 2609, June 1999.


   [RFC 2730]   iS. Hanna, B. Patel, M. Shah,  Multicast Address
                Dynamic Client Allocation Protocol (MADCAP)  draft-
                ietf-malloc-madcap-05.txt Dec 1999.

   [AutoMcast]  D. Thaler, B. Adoba, Multicast Address Allocation in
                Auto-Configured Networks, draft-thaler-zeroconf-
                multicast-00.txt, Oct 1999. A work in progress

   [AutoNet]    R. Troll  Automatically Choosing an IP Address in an
                Ad-Hoc IPv4 Network  draft-ietf-dhc-ipv4-autoconfig-
                04.txt  April, 1999. A work in progress.

   [MCAST DNS]  B. Woodcock, B. Manning  Multicast Discovery of DNS
                Services draft-manning-multicast-dns-01.txt
                December, 1998. A work in progress.

   [MiniDHCP]   Bernard Aboba, Auto-Addressing in Multi-segment
                Networks, draft-aboba-zeroconf-multi-00.txt, Oct
                1999. A work in progress.
   [SSDP]       Y. Goland et al, Simple Service Discovery Protocol,
                draft-cai-ssdp-v1-02.txt, June 1999,  A work in
                progress.

   [IPv6 WG]    IP Next Generation WG,
                www.ietf.org/html.charters/ipngwg-charter.html.

   [DHC WG]     Dynamic Host Configuration WG,
                www.ietf.org/html.charters/dhc-charter.html.

   [NAT WG]     Network Address Translation WG,
                www.ietf.org/html.charters/nat-charter.html.




   Hattig                                                  [Page 31]


   Internet Draft      draft-ietf-zeroconf-reqts-02.txt     Jan 2000


   [DNS WG]     DNS Update WG, www.ietf.org/html.charters/dnsind-
                charter.html

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
















































   Hattig                                                  [Page 32]