[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 March 2001                                    September 18, 2000

                         Zeroconf Requirements

Status of This Memo

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

   Distribution of this memo is unlimited.

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

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

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

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


   Many common TCP/IP protocols such as DHCP [RFC 2131], DNS [RFC
   1034, RFC 1035], MADCAP [RFC 2730], and LDAP [RFC 1487] must be
   configured and maintained by an administrative staff. This is
   unacceptable for emerging networks such as home networks,
   automobile networks, airplane networks, or adhoc networks at
   conferences, emergency relief stations, and many others. Such
   networks may be nothing more than two isolated laptop PCs
   connected via a wireless LAN. For all these networks, an
   administrative staff will not exist and the users of these
   networks neither have the time nor inclination to learn network
   administration skills. Instead, these networks need protocols that
   require zero user configuration and administration. This document
   is part of an effort to define such zero configuration (zeroconf)

   Hattig                                                  [Page 1]

   Internet Draft      draft-ietf-zeroconf-reqts-05.txt    Sept 2000

   Before embarking on defining zeroconf protocols, protocol
   requirements are needed. This document states the zeroconf
   protocol requirements for four protocol areas; this document does
   not define specific protocols. The four areas are: IP host
   configuration, host name to IP address resolution, IP multicast
   address allocation, and service discovery. The requirements for
   these four areas result from examining everyday use or scenarios
   of these protocols.

                           Table of Contents

   1 Introduction................................................2
   1.1 Key words.................................................3
   1.2 Reading This Document.....................................3
   1.3 Zeroconf Coexistence......................................3
   1.4 Scalability...............................................3
   1.5 Routable Protocol Requirement.............................3
   1.6 Conflicts and State Changes Requirement...................4
   2 Scenarios & Requirements....................................4
   2.1 IP Host Configuration.....................................4
   2.2 Host name to IP Address Resolution Scenarios..............5
   2.3 IP Multicast Address Allocation Scenarios.................7
   2.4 Service Discovery Scenarios...............................9
   3 Security Considerations....................................11
   3.1 IPv6 Considerations......................................12
   4 IANA Considerations........................................13
   5 Full Copyright Statement...................................13
   6 Acknowledgements...........................................13
   7 References.................................................14

1  Introduction

   A zeroconf protocol is able to operate correctly in the absence of
   either user configuration or external configuration from
   infrastructure services such as conventional DHCP [RFC 2131] or
   DNS [RFC 1034, RFC 1035] servers. Zeroconf protocols may use
   configuration, when it is available, but do not rely on it being

   The benefits of zeroconf protocols over existing configured
   protocols are an increase in the ease-of-use for end-users and a
   reduction of the infrastructure necessary to operate.

   This document discusses requirements for zeroconf protocols in
   four areas:
   - IP host configuration
   - Host name to IP address resolution
   - IP multicast address allocation
   - Service discovery

   Hattig                                                  [Page 2]

   Internet Draft      draft-ietf-zeroconf-reqts-05.txt    Sept 2000

   Security considerations are also discussed.

1.1 Key words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   in this  document are to be interpreted as described in [RFC

1.2 Reading This Document

   Introduction, Scenarios & Requirements, and Security
   Considerations are the major sections of this document.

   The Scenarios & Requirements section walks through protocol
   scenarios and then lists the requirements of the protocol needed
   to accomplish the scenario.

   The Security Consideration section lists security issues with
   zeroconf protocols.

   Requirements dispersed throughout this document begin with the
   text "Requirements:" or "Requirement:" on a single line, which is
   followed by a bulleted list of requirements.

1.3 Zeroconf Coexistence

   It is not necessary to always use zeroconf protocols in all four
   areas. For example, it might make sense on some networks to
   provide a DHCP server for configured address allocation, but
   perform host name to IP address resolution using a zeroconf

1.4 Scalability

   Zeroconf protocols are not intended to replace or compete with
   non-zeroconf protocols deployed in today's large-scale networks.
   Instead, zeroconf protocols are expected to operate in small
   networks. As a network grows, the administrators of that network
   should consider migrating away from zeroconf protocols before
   scalability becomes an issue. That being said, a zeroconf protocol
   SHOULD be scalable.

1.5 Routable Protocol Requirement

   Zeroconf protocols have no specific topological restrictions or
   requirements; networks may consist of multiple IP subnets or a
   single IP subnet; networks may be isolated or connected to larger
   networks (e.g. Internet). However, there is a conditional
   requirement. The condition exists if a protocol is targeted to

   Hattig                                                  [Page 3]

   Internet Draft      draft-ietf-zeroconf-reqts-05.txt    Sept 2000

   operate in multiple IP subnet topologies. The requirement is the
   protocol MUST be routable. For example, a protocol MUST use IP
   multicast and not use IP broadcast.

   - If a protocol is to operate in multiple IP subnet topologies,
     the protocol MUST be routable.

1.6 Conflicts and State Changes Requirement

   Spurious topology changes or other events such adding and removing
   hosts may cause conflicts and state changes within a protocol.
   Zeroconf protocols must be able to resolve conflicts and state
   changes caused by topology changes or other events. The scenario
   in the 2.1.2 Bridge Installed section is the only scenario that
   illustrates the need for this requirement, thus the below require
   is duplicated in section 2.1.2. However, this requirement applies
   to all protocol areas.

   - MUST resolve conflicts and state changes in a timely manner.

2  Scenarios & Requirements

   This section lists scenarios that lead to zeroconf protocol
   requirements. A subsection exists for each of the four protocol
   areas. Within each protocol area, terms and assumptions are
   followed by specific scenarios. The scenarios lead to a list of
   zeroconf protocol requirements. Each scenario is representative of
   many potential scenarios of which all yield an identical set of
   requirements. Each subsection ends with an IPv6 considerations

2.1 IP Host Configuration

   In this document, configuration of an IP interface on a host is IP
   host configuration. IP host configuration always includes the
   configuration of an IP address and netmask; it may include a
   default route. IP host configuration is needed before almost any
   IP communication can take place.

     IP subnet - A single logical IP network that may span multiple
     link layer networks.

     internet - Multiple IP subnets connected by routers.

     network - context sensitive term that may apply to one or more
     the terms link layer network, IP subnet, or internet.

   Hattig                                                  [Page 4]

   Internet Draft      draft-ietf-zeroconf-reqts-05.txt    Sept 2000

   IP host configuration scenarios are ICMP echo request/reply
   scenarios and a bridge install scenario.

2.1.1  ICMP Echo Request/Reply

   There are two brief ICMP echo request/reply scenarios. In the
   first, both the sender of the ICMP echo request and sender of the
   ICMP echo reply are on the IP subnet. In the second, the two
   senders are on different IP subnets within an internet.

   - MUST determine the netmask for an IP subnet.
   - MUST have unique IP addresses within an IP subnet.
   - MUST have a default route (only for the internet scenario).
   - MUST have unique IP subnets within an internet (only for the
     internet scenario).

2.1.2  Bridge Installed

   This scenario starts with two completely operational standalone
   networks in which IP host configuration was completed with a
   zeroconf protocol on each network. These two networks become one
   after a newly installed bridge connects them. Individual hosts
   have no indication that the topology has changed.

   Topology changes may create any of the following problems:
   conflict among netmasks, conflict among default routes, duplicate
   IP addresses within an IP subnet, or duplicate IP subnets within
   an internet. Note that default routes and duplicate IP subnets are
   not issues for single IP subnet networks.

   - MUST resolve conflicts and state changes in a timely manner.

2.1.3  IPv6 Considerations

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

2.2 Host name to IP Address Resolution Scenarios

   Host names allow users to refer to hosts by name instead of IP
   addresses. This is among the most fundamental, thus most
   important, usage paradigms in TCP/IP networking.


     host name - One or more strings separated by dots that identify
     a host.

   Hattig                                                  [Page 5]

   Internet Draft      draft-ietf-zeroconf-reqts-05.txt    Sept 2000

     domain name - One or more strings separated by dots that
     identify a DNS domain.

     resolver - The host needing a name resolved to an IP address.

   - Support for multiple hosts with the same name is not a

   The scenarios for host name to IP address resolution are Web
   browsing and host name selection.

2.2.1  Web Browsing

   Users browsing the Web typically enter the name of a Web server.
   This name must be resolved to an IP address before any actual Web
   browsing occurs. The Web server may be within the same domain
   along with the resolver or may be part of some other domain.

   - MUST resolve a host name to an IP address whether the name of
     the resolver and host name are in the same DNS domain or in
     different DNS domains.

2.2.2  Host Name Selection

   How the host gets its name (or Domain Name [RFC 1034]) is part of
   some other configuration protocol or user configuration, but is
   not part of this zeroconf scenario. This scenario only deals with
   learning of other host names on the network. The goal is to allow
   hosts to notify the user or configuration protocol that a
   duplicate name exists. Thus allowing the user or configuration
   protocol to attempt to use a different and hopefully unique name
   so that once operational, all devices within a domain have unique

   - MUST allow a host to determine if it has a unique name.
   - MUST be able to determine if subsequently chosen names are
     unique, if the first name is not.
   - If a domain name and host name exist as separate configuration
     parameters, additional checks for uniqueness SHOULD be
     performed on the combined host name and domain name.

2.2.3  IPv6 Considerations

   Host name to IP address resolution protocols have no zeroconf
   related differences for IPv4 and IPv6.

   Hattig                                                  [Page 6]

   Internet Draft      draft-ietf-zeroconf-reqts-05.txt    Sept 2000

2.3 IP Multicast Address Allocation Scenarios

   IP Multicast is used for multi-receiver bulk-delivery
   applications, such as audio, video, or news to conserver

   IP multicast addresses range from to

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

   A relative assignment is an integer offset from the highest
   address in the scope and represents a 32-bit address. For example,
   within the local scope, is reserved for relative

   Source-Specific Multicast [SSM] addresses are to

   - The node-scoped and SSM addresses require no protocol or
     interaction between multiple hosts, thus are not mentioned
     further in this document.
   - Global and organizational scoped addresses are meant for
     networks of a greater scale than zeroconf protocols, thus are
     not mentioned further in this document.
   - Only local, link-local and site-local scopes are considered
     further in this document.
   - A boundary router, as described in [RFC 2365], is present to
     appropriately control multicast packets from entering and
     leaving multicast scope boundaries when necessary.

   Scenarios are scope enumeration, address allocation, and multiple

2.3.1  Scope Enumeration

   Applications that leave the choice of scope up to the user require
   the ability to enumerate what scopes the host is operating within.
   In addition, services that are assigned relative addresses require
   the ability to enumerate what scopes the host is within, only then
   will a host be able to apply the relative address to a scope.


   Hattig                                                  [Page 7]

   Internet Draft      draft-ietf-zeroconf-reqts-05.txt    Sept 2000

   - MUST list which of the scopes (only local, link-local, or site-
     local) are available for hosts.
   - MUST list per-scope address ranges that may be allocated.

2.3.2  Address Allocation

   IP multicast address allocation (only local, link-local and site-
   local scopes only) requires coordination among hosts to avoid
   address collisions. To allocate an address, the host specifies a
   given scope, the number of addresses it desires, and the lifetime
   for which it desires. Address collision detection must span the
   entire scope respective to a particular address. The protocol
   should include the ability for a host to choose addresses,
   determine if they are in use, and if used, choose different

   - MUST select a multicast address with a given scope and lease
   - MUST determine if the address has been allocated within a scope.
   - MUST defend an allocated address within a scope.

2.3.3  Multiple Source

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

   The first host that needs the IP multicast address allocates the
   address, but some other host may deallocate the address. This is
   because the first host may leave the multicast group before all
   the other host leave the group. This requires the last host using
   the IP multicast address to deallocate the IP multicast address.

   - The first host to use the IP multicast address MUST allocate the
   - The last host to use the IP multicast address MUST deallocate
     the address.

2.3.4  IPv6 Considerations

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

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

   Hattig                                                  [Page 8]

   Internet Draft      draft-ietf-zeroconf-reqts-05.txt    Sept 2000

   reserved, dynamic allocation of Link-scoped addresses applies only
   to IPv6.

2.4 Service Discovery Scenarios

   Service discovery protocols allow users to select services and/or
   hosts by a name that is discovered dynamically, rather than the
   user having to know the name in advance and type it in correctly.

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

     registry - A process that acts as an intermediary between
     discoverers and advertisers.  Servers 'register' service
     advertisements and other pertinent (e.g. authentication info,
     announcement criteria) with registries, then the service may be
     discovered from the registry instead of from a server.

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

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

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

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

     service characteristics - Characteristics provide a finer
     granularity of description to differentiate services beyond just
     the service type. For example if the service type is printer,
     the characteristics may be color, pages printed per second,
     location, etc.

     service discovery protocol - A service discovery protocol
     enables a client (or clients) to discover a server (or servers)
     of a particular service. A service discovery protocol is an
     application layer protocol that relies on network and transport
     protocol layers.

   Hattig                                                  [Page 9]

   Internet Draft      draft-ietf-zeroconf-reqts-05.txt    Sept 2000

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

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

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

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

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

2.4.1  Printer Service

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

   Printers vary in their characteristics such as location, status,
   dots per inch, drivers, etc. Discovering these characteristics
   SHOULD be part of the service discovery protocol. Alternatively,
   the client and server MAY negotiate the use of these
   characteristics after the service is found.

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

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

   Service discovery MUST complete in a timely (10s of seconds)

   - MUST discover via service identifier and/or service type.

   Hattig                                                  [Page 10]

   Internet Draft      draft-ietf-zeroconf-reqts-05.txt    Sept 2000

   - SHOULD discover via characteristics or negotiate
   - MUST allow discovery by client actively soliciting the service
     or by the client passively listening for advertisements. Both
     methods SHOULD be available.
   - MUST allow clients to rediscover a service.
   - MUST be independent from any particular service.
   - MUST complete in a timely (10s of seconds) manner.

2.4.2  Printer Manager

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

   In addition, a printer manager provides an evolutionary path for
   service discovery deployment. For example, if an existing printer
   does not support the zeroconf service discovery protocol, the
   printer manager can use a legacy printer specific protocol to
   learn the existence and characteristics of a printer then expose
   that printer and its characteristics through the zeroconf service
   discovery protocol. This allows new printer clients that support
   the service discovery protocol to discover legacy printers that do
   not support the zeroconf service discovery protocol.

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

   - SHOULD allow for a registry to cache information about services
     and characteristics of services.
   - SHOULD allow for clients to extract data from the registry
     without knowledge that they are talking to a registry.
   - A registry MUST NOT be required.

2.4.3  IPv6 Considerations

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

3  Security Considerations

   Hattig                                                  [Page 11]

   Internet Draft      draft-ietf-zeroconf-reqts-05.txt    Sept 2000

   This document is only concerned with security as it relates to the
   four protocol areas.

   While link layer encryption, firewalls, password/login protected
   applications, and user-privilege-access to resources are important
   security topics, these topics do not relate directly to the four
   protocol areas; thus, these topics are not considered by this

   Existing protocols have on-going work related to security; this
   document does not duplicate or attempt to extend this on-going

   The security threats considered are sniffing (data hijacking) and
   denial of service attacks. These attacks MUST be considered for
   each protocol area.

   Sniffing can be deterred with encryption of the data. This may
   require user to enter some type of key or may only require a
   simple answer to a question of whether a protocol should encrypt
   its data or not. Experience may show that encryption is not
   necessary as long as other security measures such as link layer
   encryption and firewalls are used.

   Denial of service attacks are the biggest threat to zeroconf
   protocols. These attacks include:

   - Hoarding: A host claims all available resources, whether it
     plans to use them or not.

   - Masquerading: A host responds to requests that it should not
     by masquerading as another host.

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

   Without having zeroconf protocols defined, it is difficult to
   analyze how these security threats may affect zeroconf protocols.
   It is known that most, and possibly all, the security methods
   require some user configuration. This presents a direct conflict
   with the basic principle of zeroconf protocols -- no
   configuration. This is an exception that zeroconf protocols must
   deal with. Hopefully, best known methods develop along with
   deployment experience.

3.1 IPv6 Considerations

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

   Hattig                                                  [Page 12]

   Internet Draft      draft-ietf-zeroconf-reqts-05.txt    Sept 2000

4  IANA Considerations

   No known IANA considerations arise from this document.

5  Full Copyright Statement

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

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

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

   This document and the information contained herein is provided on

6  Acknowledgements

   Thanks to Peter Ford and Stuart Cheshire for hosting the NITS
   (Networking In The Small) BOF that was the catalyst to forming the
   Zeroconf Working Group.

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

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

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

   Hattig                                                  [Page 13]

   Internet Draft      draft-ietf-zeroconf-reqts-05.txt    Sept 2000

   Thanks to Stuart Cheshire for providing key input to the
   introduction and IP host configuration sections.

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


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

7  References

   [RFC 1034]  P. Mockapetris, Host names - Concepts and Facilities,
                RFC 1034, November 1987

   [RFC 1035]  P. Mockapetris, Host names - Implementations and
                Specifications, RFC 1034, November 1987

   [RFC 1487]  Yeong, W., Howes, T., and S. Kille, Lightweight
                Directory Access Protocol, RFC 1487, July 1993.

   [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 2365]  D. Meyer  Administratively Scoped Multicast Address
                RFC 2365,July 1998.

   [RFC 2730]  S. Hanna, B. Patel, M. Shah,  Multicast Address
                Dynamic Client Allocation Protocol (MADCAP), RFC
                2730, Dec 1999.

   [SSM]        H. Holbrook, Source-Specific Multicast for IP, draft-
                holbrook-ssm-00.txt, March 2000. A work in progress.

   Hattig                                                  [Page 14]