Zeroconf WG M. Hattig
Internet Engineering Task Force Editor
INTERNET DRAFT Intel Corp.
Expires March 2001 September 18, 2000
Zeroconf Requirements
draft-ietf-zeroconf-reqts-05.txt
Status of This Memo
This document is a submission by the Zeroconf Working Group of the
Internet Engineering Task Force (IETF). Comments should be
submitted to the zeroconf@merit.edu mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC 2026]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
Many common TCP/IP protocols such as DHCP [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)
protocols.
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
present.
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
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC
2119].
1.2 Reading This Document
Introduction, Scenarios & Requirements, and Security
Considerations are the major sections of this document.
The Scenarios & Requirements section walks through protocol
scenarios and then lists the requirements of the protocol needed
to accomplish the scenario.
The Security Consideration section lists security issues with
zeroconf protocols.
Requirements dispersed throughout this document begin with the
text "Requirements:" or "Requirement:" on a single line, which is
followed by a bulleted list of requirements.
1.3 Zeroconf Coexistence
It is not necessary to 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
protocol.
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.
Requirement:
- 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.
Requirement:
- 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
section.
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.
Terms:
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.
Requirements:
- 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.
Requirement:
- 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.
Terms:
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.
Assumptions:
- Support for multiple hosts with the same name is not a
requirement.
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.
Requirement:
- 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
names.
Requirement:
- 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
bandwidth.
IP multicast addresses range from 224.0.0.0 to 239.255.255.255.
[RFC 2365] defined scopes are:
node-local (unspecified)
link-local (224.0.0.0/24)
local (239.255.0.0/16)
site-local (unspecified)_
organizational-local (239.192.0.0/14)
global (224.0.1.0-238.255.255.255)
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, 239.255.255.0/24 is reserved for relative
allocations.
Source-Specific Multicast [SSM] addresses are 232.0.0.0 to
232.255.255.255.
Assumptions:
- 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
sources.
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.
Requirements:
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
addresses.
Requirements:
- MUST select a multicast address with a given scope and lease
time.
- 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.
Requirements:
- The first host to use the IP multicast address MUST allocate the
address.
- 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.
Terms:
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
delivery.
service advertisement packet - An unsolicited packet issued by a
server or registry. The advertisement provides the service
identifier and possibly service characteristics.
service characteristics - Characteristics provide a finer
granularity of description to differentiate services beyond just
the service type. For example if the service type is printer,
the characteristics may be color, pages printed per second,
location, etc.
service discovery protocol - A service discovery protocol
enables a client (or clients) to discover a server (or servers)
of a particular service. A service discovery protocol is an
application layer protocol that relies on network and transport
protocol layers.
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
services.
2.4.1 Printer Service
Networked enabled printers allow various networked clients to
submit print jobs. A service discovery protocol MUST allow a
printing 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
ipp.
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)
manner.
Requirements:
- 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
characteristics.
- 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.
Requirements:
- 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
document.
Existing protocols have on-going work related to security; this
document does not duplicate or attempt to extend this on-going
work.
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
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE."
6 Acknowledgements
Thanks to Peter Ford and Stuart Cheshire for hosting the 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
document.
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.
Editor:
Myron Hattig
Intel Corporation
3585 SW 198th Avenue
Aloha, OR 97007
myron.hattig@intel.com
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]
