[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [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 April 2000                                October 21, 1999


                         ZeroConf Requirements
                    draft-ietf-zeroconf-reqts-00.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 on an impromptu basis. ZeroConf Networks do not
   have and should not be expected to have user configurable network
   infrastructure such as DHCP servers, 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 overlay each area. ZeroConf protocols
   in each these areas must transition easily to and from
   administered protocols.



   Hattig                                                  [Page 1]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999



                           Table of Contents

   1 Overview....................................................2
   2 Introduction................................................3
   2.1 Areas of work.............................................3
   2.2 Reading This Document.....................................4
   2.3 General Considerations....................................5
   3 ZeroConf Network Architecture...............................6
   3.1 Topologies................................................6
   3.2 ZeroConf and non-ZeroConf Protocols......................12
   3.3 Assumptions and Restrictions.............................13
   4 Scenarios..................................................14
   4.1 Single IP Network Host Configuration.....................14
   4.2 Multiple IP Network Host Configuration...................15
   4.3 Bridge Install between already operational IP Hosts......16
   4.4 Router Install between already operational IP Hosts......16
   4.5 IP Host Configuration with DHCP server...................17
   4.6 Domain Name Resolution within an IP network..............18
   4.7 IP Multicast Address Allocation..........................18
   4.8 Service Discovery........................................19
   4.9 Additional Potential Scenarios...........................20
   5 Security Requirements......................................21
   5.1 IP Host Configuration....................................21
   5.2 Domain name to IP address resolution.....................21
   5.3 Multicast Address allocation.............................21
   5.4 Service Discovery........................................22
   6 Additional Considerations..................................22
   6.1 IANA Considerations......................................22
   6.2 Internationalization Considerations......................22
   6.3 Is service discovery conclusive?.........................22
   6.4 Security Considerations..................................22
   7 Full Copyright Statement...................................22
   8 Editor.....................................................23
   9 References.................................................23

1  Overview

   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 on an impromptu basis.  ZeroConf networks
   typically do not have and should not be expected to have user
   configurable network infrastructure such as DHCP servers, 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



   Hattig                                                  [Page 2]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


   discovery. Security issues overlay each area. ZeroConf protocols
   in each these areas must transition easily to and from
   administered protocols.

   This ZeroConf requirements document is a companion to a ZeroConf
   profile document. This requirements document lists requirements
   for protocols. The profile document relates the protocol
   requirements to actual protocols. In some cases, a protocol may
   meet all requirements to become the required protocol 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.

   In addition, the profile document shows how ZeroConf protocols
   transition between operating in a ZeroConf network and operating
   in a Non-ZeroConf network. Such transitions may be heavily
   influenced by connectivity of the ZeroConf network to a non-
   ZeroConf network such as the global Internet.

   The major sections to this requirements document are the
   Introduction, ZeroConf Network Architecture, Scenarios, and
   Security sections. Since this document deals with so many aspects
   of TCP/IP networking (i.e. service discovery to IP host
   configuration), the introduction lists the necessary background
   information and provides ideas for readers who wish to focus on
   specific topics. The ZeroConf Network Architecture defines the
   network assumed throughout this document. The scenarios clarify
   the scope covered by the document and motivate particular
   requirements of ZeroConf protocols.

   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 specifically defines the term "Area", presents
   how to best read this document (including references), and
   presents general considerations for implementers of ZeroConf
   protocols.

2.1 Areas of work

   Throughout this document, when the word Area is capitalized, the
   word is referring the four Areas of protocol work in which this
   document focuses. These protocol Areas are:
   - IP host configuration
   - Domain name to IP address resolution



   Hattig                                                  [Page 3]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


   - IP multicast address
   - Service discovery

2.2 Reading This Document

   This document deals with a wide range of networking topics. All
   readers may not be interested in all Areas. To help the reader
   focus on particular interests, this section describes the
   organization of the document, the background information for each
   Area, and explains different types of requirements.

2.2.1  Organization

   The first major section of this document defines the ZeroConf
   Network Architecture assumed throughout this document and assumed
   throughout the profile document.

   The Scenarios Section scopes the overall ZeroConf problem space
   to provide the framework for requirements of protocols. This
   section identifies some but not all requirements of protocols.
   This section mentions very little about specific protocols. There
   is a common outline for each scenario.

   The Security section lists security issues and requirements to
   prevent security problems.

2.2.2  Background information

   This section lists the background reference information for
   general knowledge, IP host configuration, domain name to IP
   address resolution, IP multicast address allocation, service
   discovery, and security. All readers should be familiar with at
   least the general knowledge references before reading this
   document.

   All readers should be familiar with the following documents:
   - [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

   IP host configuration:
   - [IPv4Auto] Ipv4 Auto-Configuration ID
   - [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



   Hattig                                                  [Page 4]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999



   Domain name to IP address resolution:
   - [Mcast DNS] Multicast DNS
   - [RFC 1034] RFC 1034 DNS
   - [DNS WG] DNS Update WG

   Multicast address allocation:
   - [MADCAP] Multicast Address Dynamic Client Alloc Protocol ID
   - [RFC 2365] RFC 2365, Administratively Scoped Multicast Address
   - [MALLOC WG] Multicast Address Allocation WG

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

   Security background information is:
   - [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

2.2.3  Requirements

   This document identifies scenarios that drive the requirements
   for protocols. The requirements for protocols then help identify
   specific protocols. The ZeroConf profile document discusses
   specific protocols; this ZeroConf requirements document only
   discusses the requirements for those specific protocols.

   Requirements for protocols may have device specific aspects. For
   example, a router may automatically forward IP packets with a
   particular UDP port number between IP networks to make sure
   client requests reach a server on another IP network. To provide
   the proper device context, device descriptions are given along
   with particular device requirements when appropriate.

2.3 General Considerations

   These considerations are for vendors of ZeroConf networking
   software.

2.3.1  Continuing ZeroConfig Network Evolution

   ZeroConf networks are in their infancy. Many people speculate
   about which link layer technologies will be the most important,
   which devices will be most widely deployed, which applications
   will be the "killer", etc. etc. Because of this broad speculation
   and unpredictability the ZeroConf WG has limited the complexity




   Hattig                                                  [Page 5]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


   of the networks it will consider. For example, at most a single
   router is considered in a ZeroConf network.

   These limitations are a practical matter to allow the WG to make
   progress. Without such limitations, the load of speculation would
   prevent the working group from addressing even simple matters.

   Vendors should be aware of these limitations and implement in a
   flexible way to allow their implementations to someday go beyond
   the restrictions imposed by the ZeroConf WG.

2.3.2  Configuration, Administration, and Management

   Ideally, user configuration, administration, and management do
   not occur in a ZeroConf network; this is the primary goal of the
   ZeroConf WG. In other words, ZeroConf networks should be self-
   healing and self-correcting. Despite this, there may be cases
   where minimal user intervention is necessary; the key word in
   this sentence is "minimal".

2.3.3  Error Log Messages

   A goal of the ZeroConf requirements is to automate basic
   functions to the extent that they will be transparent to the
   user. This will minimize the requirement for the user to either
   enter information or be presented with and interpret error
   conditions.  It is quite likely, however, that error logging, and
   network management may be implemented on hosts supporting
   ZeroConf protocols.  Further discussion of network management and
   operational issues is beyond the scope of this requirements
   document.

3  ZeroConf Network Architecture

   This section describes network topologies considered by this
   document and states assumptions about the operation of protocols
   in the ZeroConf Network.

3.1 Topologies

   ZeroConf networks follow the Internet Model as described in STD4.
   Specifically, ZeroConf networks consist of bridges, routers
   (gateways), hosts, link layer networks, and IP networks to form
   internets.

   Here is a summary of the terms in [RFC 1812] that apply to the
   ZeroConf Network Architecture:
   - Bridges route link layer packets (e.g. Ethernet packets)
     between link layer networks (e.g. Ethernet) based on the




   Hattig                                                  [Page 6]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


     destination link layer addresses (e.g. 48-bit Ethernet address)
     of a packet.
   - Routers (a.k.a. gateways) route IP packets between IP networks
     based on the destination IP address of a packet.
   - An IP network consists of hosts with interfaces that share the
     same network portion of the IP address. 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.
   - An internet consists of multiple IP networks connected by
     routers.
   - Autonomous Systems (AS) are internets with a single operational
     and management organization (a.k.a.  administrator), and a
     common set of routing protocols among the routers.

   A ZeroConf network is a single Autonomous System (AS). This
   simple statement implies many things. For example, service
   discovery queries, IP multicast packets, and other IP packets
   must stay within a single autonomous system. Also, such packets
   must not enter autonomous system; this avoids security problems.
   For the rest of this document, the term ZeroConf Network equates
   to a network within a single autonomous system and all that that
   implies.

   RFC 1812 defines different types of routers (e.g. transparent,
   embedded). The ZeroConf Network Architecture has two different
   types of routers. Both types of routers pass packets between IP
   networks based on destination IP address (as one would expect).

   The primary difference is that one of these routers resides at
   the border between the ZeroConf and the Non-ZeroConf network;
   thus this router must impose the restrictions necessary for the
   ZeroConf network to remain a single autonomous system. This
   router is called a "gateway" throughout the rest of this
   document.

   The second type of router routes between IP networks within the
   ZeroConf Network. Thus, this router has no responsibilities
   related to restricting the communication between ZeroConf and
   Non-ZeroConf Networks. This device is simply called a "router"
   throughout the rest of this document.

   The ZeroConf Network Architecture is limited to at most one
   router and/or at most one gateway. Zero routers and/or zero
   gateways are also part of the ZeroConf Network Architecture.








   Hattig                                                  [Page 7]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


   Figures 1 and 2 show the simplest of ZeroConf networks considered
   by this document. Enabling these types of simple TCP/IP networks
   is among the primary motivations for this document.

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

          Figure 1. Two hosts connected with a crossover cable.

   This ZeroConf network has two hosts connected through a crossover
   cable. A crossover cable between two hosts is the most common
   impromptu ZeroConf network.


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

        Figure 2. Three hosts connected with a network with hub

   This ZeroConf network has a small number of hosts connected
   through a hub. A hub between hosts is the most common fixed-
   location ZeroConf network.  This is the canonical ZeroConf
   network.












   Hattig                                                  [Page 8]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


   Figure 3, Figure 4, and Figure 5 are examples of ZeroConf
   Networks that highlight the difference between a router and a
   gateway. Figure 5 is an example of a network not considered by
   this document. All these figures include connectivity to non-
   ZeroConf Network. Examples of a non-ZeroConf network are the
   global Internet and a corporate LAN.

                    ***************************
                    *                         *
                    *   Non-ZeroConf Network  *
                    *                         *
                    ***************************
                                 |
                                 |
                                 |
                         +----------------+
   **********************| Gateway        |*************************
   * ZeroConf  Network   +----------------+                        *
   *                             |                                 *
   *                             |                                 *
   *                             |       +--------+                *
   *     --------------------------------| Bridge |--------------- *
   *     |       |                 |     +--------+ |         |    *
   *     |       |                 |                |         |    *
   *     |       |                 |                |         |    *
   *  +------+  +------+       +------+        +------+  +------+  *
   *  | Host |  | Host |       | Host |        | Host |  | Host |  *
   *  +------+  +------+       +------+        +------+  +------+  *
   *                                                               *
   *****************************************************************

                Figure 3. Single Gateway and Single IP Network.

   Figure 3 shows a single gateway and single IP network in the
   ZeroConf Network. The gateway routes packets between the ZeroConf
   Network and the Non-ZeroConf Network. The single IP network
   consists of multiple link layer networks connected by a bridge.
















   Hattig                                                  [Page 9]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999



                    ***************************
                    *                         *
                    *   Non-ZeroConf Network  *
                    *                         *
                    ***************************
                                 |
                                 |
                                 |
                         +----------------+
   **********************| Gateway/Bridge |*************************
   * ZeroConf Network    +----------------+                        *
   *                             |      |                          *
   *                             |      |                          *
   *                +--------+   |      |                          *
   *     -----------| Router |---|      |--------------------      *
   *     |       |  +--------+   |                |         |      *
   *     |       |               |                |         |      *
   *     |       |               |                |         |      *
   *  +------+  +------+     +------+         +------+  +------+   *
   *  | Host |  | Host |     | Host |         | Host |  | Host |   *
   *  +------+  +------+     +------+         +------+  +------+   *
   *                                                               *
   *****************************************************************

      Figure 4. Single Gateway, Single Router, and Two IP Networks.

   Figure 4 shows a ZeroConf Network with a single gateway, a single
   router, and two IP networks. The gateway/bridge device is a
   gateway and a bridge. The bridge portion routes layer 2 packets
   between the two link layer networks attached to the gateway
   (within the ZeroConf network); these two link layers represent a
   single IP network. The router routes IP packets between the two
   IP networks within the ZeroConf Network.



















   Hattig                                                  [Page 10]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999



                    ***************************
                    *                         *
                    *   Non-ZeroConf Network  *
                    *                         *
                    ***************************
                                 |
                                 |
                                 |
                         +----------------+
   **********************| Gateway/Router |*************************
   * ZeroConf Network    +----------------+                        *
   *                       |     |      |                          *
   *                       |     |      |                          *
   *                       |     |      |                          *
   *     ------------------|     |      |----------------------    *
   *     |       |               |                  |         |    *
   *     |       |               |                  |         |    *
   *     |       |               |                  |         |    *
   *  +------+  +------+     +------+           +------+  +------+ *
   *  | Host |  | Host |     | Host |           | Host |  | Host | *
   *  +------+  +------+     +------+           +------+  +------+ *
   *                                                               *
   *****************************************************************

   Figure 5. Single Gateway, Single Router, and Three IP Networks.

   Figure 5 shows a ZeroConf Network with a single gateway, a single
   router, and three IP networks. The gateway/router device is a
   gateway and a router. The router portion routes IP packets
   between the three IP networks within the ZeroConf Network. The
   gateway portion routes IP packets between the ZeroConf Network
   and the non-ZeroConf Network. In ZeroConf Networks, routers route
   within the ZeroConf; gateways route between a ZeroConf and a non-
   ZeroConf (which are different autonomous systems); this is the
   distinction between a router and a gateway.

















   Hattig                                                  [Page 11]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999



                    ***************************
                    *                         *
                    *   Non-ZeroConf Network  *
                    *                         *
                    ***************************
                                 |
                                 |
                                 |
                         +----------------+
   **********************| Gateway/Router |*************************
   * ZeroConf Network    +----------------+                        *
   *                              |      |                         *
   *                              |      |                         *
   *                +---------+   |      |                         *
   *     -----------| Router  |---|      |-------------------      *
   *     |       |  +---------+   |               |         |      *
   *     |       |                |               |         |      *
   *     |       |                |               |         |      *
   *  +------+  +------+      +------+         ------+  +------+   *
   *  | Host |  | Host |      | Host |        | Host |  | Host |   *
   *  +------+  +------+      +------+        +------+  +------+   *
   *                                                               *
   *****************************************************************
     Figure 6. Single Gateway, Two Routers, and Three IP Networks.

   Figure 6. shows a network that is NOT considered by this document
   because two routers are present. The gateway/router device
   includes a gateway and a router as in Figure 5. In addition,
   there is a second router in the network. Multiple routers within
   a single autonomous system create requirements beyond the scope
   of the document. Such requirements are coordination between
   routers and auto-configuration of routers.

   There are no additional topological restrictions on the ZeroConf
   Network Architecture. That is, there are no restrictions on the
   number of hosts, number of host names, or the number of services.

3.2 ZeroConf and non-ZeroConf Protocols

   In this document the term ZeroConf is overloaded. In addition to
   ZeroConf (and non-ZeroConf) Networks, this document uses the
   terms ZeroConf protocols and non-ZeroConf protocols. ZeroConf
   Network is a concept, not really a physical entity. The concept
   is that at some point in time one or more protocols within a
   network are ZeroConf protocols. In addition, non-ZeroConf
   protocols may coexist in this network with ZeroConf protocols.
   That is, not ALL protocols in a ZeroConf Network are ZeroConf
   protocols.




   Hattig                                                  [Page 12]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


   To illustrate this point, suppose there are standard protocols to
   support ZeroConf requirements for IP host configuration and
   domain name to IP address resolution.

   For IP host configuration, the ZeroConf protocol is
   'protocol-h.'  The non-ZeroConf protocol is DHCP, supported by a
   fully conformant DHCP server.

   For domain name to IP address resolution, the protocol is
   'protocol-d.'  The non-Zeroconf protocol is DNS supported by a
   fully conformant DNS server.

   In a ZeroConf Network, both ZeroConf and non-ZeroConf protocols
   may exist in separate Areas. For example, protocol-h may exist
   with DNS (and a DNS server).

   However, within a single Area only a ZeroConf or non-ZeroConf
   protocol is used at a given point in time. Preference is always
   given to the non-ZeroConf protocol if it is present. For example,
   a DNS server implemented on a PC in the den is only available
   when the PC is powered-up; hosts must detect when the DNS server
   is present then use it; otherwise, they must use protocol-d.

   The strict definition of a ZeroConf Network is a network that at
   some point in time has one or more ZeroConf protocols.

3.3 Assumptions and Restrictions

   The architectural assumptions and restrictions for the ZeroConf
   Network Architecture are bounded by ZeroConf topologies and by
   the protocols (ZeroConf and non-ZeroConf) that operate within the
   ZeroConf Network.

   Topological assumptions and restrictions are:
   - No more than a single router exists in the ZeroConf network;
     zero routers are acceptable but two routers are not.
   - No more than a single gateway exists in the ZeroConf network;
     zero gateways are acceptable but two gateways are not.
   - No restrictions on the number of hosts or the number services
     exist.
   - A gateway prevents ZeroConf protocols from leaving the ZeroConf
     network.
   - A gateway prevents ZeroConf protocols from entering the
     ZeroConf Network from a non-ZeroConf Network.
   - A router must route ZeroConf protocols if the protocol is
     required to span the entire ZeroConf network.
   - A bridge connects similar link layer networks (e.g. HomePNA,
     IEEE 802.11, HomeRF are similar because they are Ethernet-like)
   - A router connects dissimilar link layer networks. (e.g. IEEE
     1394-1995 is dissimilar from Ethernet)



   Hattig                                                  [Page 13]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


   - A gateway device includes a router or a bridge when necessary
     and feasible. However, this may not be feasible for some
     networking link layers that cannot span the entire distance
     between the gateway and link layer specific hosts (e.g. ADSL
     gateway in a den and IEEE 1394-1995 MP3 Player in a family
     room).

   Protocol assumptions within each Area of work are:
   - A ZeroConf protocol exists.
   - A non-ZeroConf protocol exists.
   - A ZeroConf protocol transitions to non-ZeroConf protocol on a
     well-defined trigger.
   - A Non-ZeroConf protocol transitions to ZeroConf protocol on a
     well-defined trigger.
   - ZeroConf protocols re-initialize themselves on a well-defined
     trigger.

4  Scenarios

   This section lists ZeroConf scenarios. This section does not
   discuss specific protocols. Instead this section lists scenarios
   that provide a framework to produce requirements for protocols.

   Each scenario begins with an explanation or overview of the
   scenario. Then, the key points of the scenario are identified.
   These key points help identify the most likely Area of work
   related to the scenario. To consistently provide this
   information, each scenario has the following outline:
   - Overview
   - Key Points
   - Protocol Requirements

   Temporary Note: These scenarios have not been agreed upon by the
   ZeroConf WG, thus they will likely change. For this reason, only
   the limited information is provided for each scenario in the
   current draft.

4.1 Single IP Network Host Configuration

4.1.1  Overview

   Hosts on a single IP network within the ZeroConf network
   communicate to each other. To do this, hosts must configure their
   IP address and net mask. This scenario is of utmost importance.

   This scenario is most applicable to networks shown in Figures 1
   and 2.

4.1.2  Key Points




   Hattig                                                  [Page 14]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


   This scenario deals with the Area of IP host configuration.

   This scenario requires a unique host portion of the IP address
   for each host. The network portion of the IP address must be the
   same for each host.

4.1.3  Protocol Requirements

   - Host numbers of IP addresses MUST be unique within a single IP
     network.
   - Network numbers of IP addresses MUST be equal within a single
     IP network.
   - IP addresses MUST be private and not globally routable such as
     those listed in RFC 1918.
   - IP address MAY be routable within the ZeroConf network, but
     this is not required.

4.2 Multiple IP Network Host Configuration

4.2.1  Overview

   This scenario does not include a DHCP server. Hosts on multiple
   IP networks within a ZeroConf network communicate to each other.
   To do this, hosts must configure their IP address, net mask, and
   default route.

4.2.2  Key Points

   This scenario deals with the Area of IP host configuration.

   This scenario requires a unique host portion of the IP address
   for each host on an IP network. The network number portion of an
   IP address must be the same for each host on a single IP network.
   The network number portion of the IP address must be the unique
   within the ZeroConf network for each IP network. Each host must
   be configured with a default route.

4.2.3  Protocol Requirements

   - Host numbers of IP addresses MUST be unique within a single IP
     network.
   - Network numbers of IP addresses MUST be equal within a single
     IP network.
   - IP addresses MUST be private and not globally routable such as
     those listed in RFC 1918.
   - IP address MUST be routable within the ZeroConf network.
   - IP network numbers MUST be unique within the entire ZeroConf
     network.
   - The host MUST configure a default route.




   Hattig                                                  [Page 15]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


4.3 Bridge Install between already operational IP Hosts

4.3.1  Overview

   This scenario does not include a DHCP server. Within a single IP
   network, a bridge (or hub) is installed after IP hosts have been
   configured to communicate on a single IP network. Two hosts on a
   single IP network may now 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.

4.3.2  Key Points

   This scenario deals with the Area of IP host configuration.

   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.

4.3.3  Protocol Requirements

   - Hosts MUST re-configure IP address and net mask at various
     times after initial configuration.
   - All requirements in section 4.1.3.

4.4 Router Install between already operational IP Hosts

4.4.1  Overview

   This scenario does not include a DHCP server. 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.

4.4.2  Key Points

   This scenario deals with the Area of IP host configuration.

   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.

4.4.3  Protocol Requirements




   Hattig                                                  [Page 16]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


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

4.5 IP Host Configuration with DHCP server

4.5.1  Overview

   This scenario is for single IP network or multiple IP network
   ZeroConf networks. Hosts communicate to each other. To do this,
   hosts must get their IP address, net mask, and default route from
   a DHCP server. There is only one DHCP server.

4.5.2  Key Points

   This scenario deals with the Area of IP host configuration.

   DHCP servers in ZeroConf networks do not require user
   configuration. Servers allocate private addresses that are not
   globally routable.  However, the addresses must be routable
   within the ZeroConf network. DHCP servers ensure a unique host
   portion of the IP address for each host on an IP network. The
   DHCP server ensures the network number portion of an IP address
   is the same for each host on a single IP network.  The DHCP
   server must provide a default route to each host. All hosts must
   implement a DHCP client. This places unique requirements on DHCP
   servers as well as hosts.

   If previously operation hosts achieve connectivity to the DHCP
   server through the installation of a bridge or router, hosts must
   somehow determine or learn about the presents of the DHCP server
   and request the appropriate information from the DHCP server.

4.5.3  Protocol Requirements

   - A DHCP server MUST be accessible by all hosts on the network.
   - The DHCP server MUST require zero-configuration by a user.
   - The DHCP server MUST only allocate private addresses that are
     not globally routable such as those listed in RFC 1918.
   - The DHCP server MUST ensure host numbers of IP addresses are
     unique within a single IP network.
   - The DHCP server MUST ensure network numbers of IP addresses are
     equal within a single IP network.
   - The DHCP server MAY ensure IP addresses are routable within the
     ZeroConf network, but this is not required.
   - All hosts MUST implement a DHCP client to retrieve their IP
     address, net mask, and default route.
   - Routers MUST implement DHCP rely agents.





   Hattig                                                  [Page 17]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


4.6 Domain Name Resolution within an IP network

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

4.6.2  Key Points

   This scenario deals with the Area of domain name to IP address
   resolution.

   Name resolution must span the entire ZeroConf network, but be
   limited by the gateway from leaving or entering the ZeroConf
   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.

4.6.3  Protocol Requirements

   - A host that wishes to be addressable by DNS 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 a 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.

4.7 IP Multicast Address Allocation

4.7.1  Overview

   Numerous protocols have a need for dynamically allocated IP
   multicast addresses. Traditionally these have been audio or video
   streaming protocols; however, of late, data applications such as
   stock quotes or hourly news are increasing sent encapsulated in
   packets destined to IP multicast addresses.




   Hattig                                                  [Page 18]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


4.7.2  Key Points

   This scenario deals with the Area of domain name to IP address
   resolution.

   IP multicast address allocation protocol must be routed through
   the entire ZeroConf network; however, the gateway limits this
   protocol from leaving or entering the ZeroConf network. In
   addition to limiting the multicast allocation protocol, the
   gateway limits the packets that utilize the allocated IP
   multicast addresses.

4.7.3  Protocol Requirements

   - All hosts MUST allocate IP multicast address from the same
     pool.
   - The pool of IP multicast addresses MUST NOT be globally
     accessible (e.g. Administratively scoped IP multicast addresses
     in [RFC 2365])
   - Routers MUST route packets destined to this pool of IP
     multicast addresses.
   - Gateways MUST limit packets destined to this pool of IP
     multicast addresses from leaving or entering the ZeroConf
     network.
   - One and only one host MUST be identified as the owner of each
     allocated IP multicast address.
   - The owner MUST deallocate the IP multicast address whenever
     possible.
   - Allocated IP multicast addresses MUST automatically become
     deallocated if owner stops operating.
   - Ownership MUST be able to pass from one host to another, in the
     case the original owner wishes to stop participation in the use
     of the IP multicast address and another host wishes to continue
     participation in the use of the IP multicast address.

4.8 Service Discovery

4.8.1  Overview

   A key component to the ZeroConf network is service discovery
   without user-configured servers. This requires a common
   definition a service and common methods for clients (hosts
   wanting a service) to find service-specific servers (hosts
   providing a service). When multiple servers provide the same
   service, hosts and/or people must be able to pick a preferred
   server based on service specific attributes, connectivity,
   physical location of the server, or other metrics.

   For example, a small business may have a high quality color
   printer, a printer that prints a high number of pages per second,



   Hattig                                                  [Page 19]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


   or a printer in a particular office. A person may want to print
   to the color printer, print to the fast printer, or the closest
   printer. Of course, many other metrics may exist.

4.8.2  Key Points

   This scenario deals with the Area of service discovery.

   A service must be identifiable and instrumentable.
   Instrumentation allows attributes to be identified and utilized
   by people or programs. Clients should be able to discover
   services through passive advertisements by the servers and
   through active queries by the client.

4.8.3  Protocol Requirements

   - A service MUST be identifiable.
   - A service MAY be instrumentable.
   - Servers MAY have the ability to advertise service.
   - Servers MAY have the ability to respond to client queries.
   - Clients MAY have the ability to use service advertisements.
   - Clients MAY have the ability to query for services.
   - Clients and servers MAY have the ability present the
     instrumentation of a service to people.
   - Clients and servers MAY have the ability to programmatically
     use instrumentation of a service.

4.9 Additional Potential Scenarios

   - A ZeroConf host accessing the global Internet through the
     gateway.
   - Multiple ZeroConf hosts simultaneously accessing the Internet
     through the gateway.
   - ZeroConf host accessing a corporate LAN through the gateway and
     a corporate firewall.
   - Allow access from the Internet to a ZeroConf server (e.g.
     household WEB server).
   - Allow access from the Internet to multiple ZeroConf servers
     (e.g. family WEB server and individual family-member WEB
     server).
   - Host connecting to another ZeroConf network through a non-
     ZeroConf network and a gateway at the border of each ZeroConf
     network.
   - Browsing and human friendly identifiers (service type name,
     internationalization, attributes)
   - Device Identification & Discovery
   - ZeroConf host interoperates with Ad Hoc host via MANET.
   - Behavior upon receiving router advertisements





   Hattig                                                  [Page 20]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


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

   [TO DO:  Add security requirements after potential threats have
   been identified and selected as requiring attention by the
   ZEROCONF Working Group.]

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

5.2 Domain name to IP address resolution

   Potential threats include:
   - A host could masquerade, responding to names requests
     illigitimately.
   - 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.

5.3 Multicast Address allocation

   Potential threats include:




   Hattig                                                  [Page 21]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


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

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

6  Additional Considerations

6.1 IANA Considerations

   There are no known IANA considerations arising from this
   document.

6.2 Internationalization Considerations

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

6.3 Is service discovery conclusive?

   When service discovery is successful, should the client be able
   to use the service, or do we assume that it may not be able to.
   In the former case service discovery finds only those services
   that match the client's capabilities and requirements. In the
   latter case the client may have to perform feature negotiation
   with the service - the result of which may be that the client is
   not able to use the service.

6.4 Security Considerations

   ZeroConf security considerations are in Section 5 of this
   document.

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



   Hattig                                                  [Page 22]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


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

8  Editor

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

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




   Hattig                                                  [Page 23]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


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

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

   [DisAuto]    R. Troll, DHCP Option to Disable Stateless Auto-
                Configuration in IPv4 Clients  draft-ietf-
                autoconfig-04.txt  February, 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.

   [MADCAP]     iS. Hanna, B. Patel, M. Shah  Multicast Address
                Dynamic Client Allocation Protocol (MADCAP)  draft-



   Hattig                                                  [Page 24]


   Internet Draft      draft-ietf-zeroconf-reqts-00.txt     Oct 1999


                ietf-malloc-madcap-05.txt May 1999. A work in
                progress.

   [SSDP]       Y. Goand 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.

   [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 25]