One document matched: draft-ietf-zeroconf-reqts-04.txt
Differences from draft-ietf-zeroconf-reqts-03.txt
Zeroconf WG M. Hattig
Internet Engineering Task Force Editor
INTERNET DRAFT Intel Corp.
Expires January 2001 July 14, 2000
Zeroconf Requirements
draft-ietf-zeroconf-reqts-04.txt
Status of This Memo
This document is a submission by the Zeroconf Working Group of the
Internet Engineering Task Force (IETF). Comments should be
submitted to the zeroconf@merit.edu mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC 2026]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
Many common TCP/IP protocols such as DHCP, DNS, MADCAP, and LDAP
must be configured and maintained by an administrative staff. This
is unacceptable for emerging networks such as home networks, small
office networks, automobile networks, airplane networks, or adhoc
networks at conferences, emergency relief stations, and many
others. For these networks, an administrative staff will not exist
and the users of these networks neither have the time nor
inclination to learn network administration skills. Instead, these
networks need protocols that require zero user configuration and
administration. This document is part of an effort to define such
zero configuration (zeroconf) protocols.
Before embarking on defining zeroconf protocols, protocol
requirements are needed. This document states zeroconf protocol
requirements for four protocol areas; this document does not
Hattig [Page 1]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
define specific protocols. The four areas are: IP host
configuration, domain name to IP address resolution, IP multicast
address allocation, and service discovery. The requirements for
these four areas result from examining everyday use or scenarios
of these protocols.
Table of Contents
1 Introduction................................................2
1.1 Reading This Document.....................................3
1.2 Zeroconf Protocols........................................3
2 Scenarios & Requirements....................................7
2.1 IP Host Configuration.....................................8
2.2 Domain Name to IP Address Resolution Scenarios...........10
2.3 IP Multicast Address Allocation Scenarios................13
2.4 Service Discovery Scenarios..............................16
3 Security Considerations & Requirements.....................19
3.1 IP Host Configuration....................................19
3.2 Domain Name to IP Address Resolution.....................20
3.3 IP Multicast Address Allocation..........................20
3.4 Service Discovery........................................20
3.5 IPv6 Considerations......................................21
4 IANA Considerations........................................21
5 Full Copyright Statement...................................21
6 Acknowledgements...........................................21
7 References.................................................22
1 Introduction
This document presents requirements for zeroconf protocols in four
areas: IP host configuration, domain name to IP address
resolution, IP multicast address allocation, and service
discovery. Security issues and the transitions between a zeroconf
protocol and a non-zeroconf protocol are also discussed within
each protocol area.
The major sections in this document are the Introduction,
Scenarios & Requirements, and Security Considerations &
Requirements. The introduction provides the background
information, references, terms, and assumptions to ensure a clear
understanding of the subsequent sections. The Scenarios &
Requirements section walks through protocol scenarios and then
lists the requirements of the protocol needed to accomplish the
scenario. The Security section lists threats and security
requirements.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC
2119].
Hattig [Page 2]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
1.1 Reading This Document
Most of the document can be read selectively based on the reader's
protocol area of interest. To encourage this, much of the document
is organized around the four protocol areas:
- IP host configuration
- Domain name to IP address resolution
- IP multicast address allocation
- Service discovery
1.2 Zeroconf Protocols
Below are strict definitions of a zeroconf protocol and a non-
zeroconf protocol. Also discussed are the transitions between a
zeroconf protocol and non-Zeroconf. Finally, a section discusses
how protocols with a centralized server may be zeroconf protocols.
1.2.1 Definitions
A zeroconf protocol requires no user configuration.
A non-zeroconf protocol requires user configuration.
[Editor's Note: The definition of a ZC protocol is a key output of
this document. Be aware that the definition has changed from the
previous version of this document. This change prompted section
1.3.5 Centralized Servers. This editor's note will be removed in
the next version of this draft.]
1.2.2 Transitions
Transition is the act of determining when to change from using the
zeroconf protocol to the non-zeroconf protocol, or vice-versa.
Transition support is not required of a zeroconf protocol nor does
a device require transition support if the device supports the
zeroconf protocol. Below is a discussion of three possible
transitions that a host SHOULD consider when using a zeroconf
protocol.
The first transition is a zeroconf to non-zeroconf transition.
This type of transition may occur either if a host moves to a new
network that does not use a zeroconf protocol when the old network
used a zeroconf protocol. Or if the host stays on the same network
but a new server comes online within that network. For example, if
a DHCP server comes online after hosts are configured with a
zeroconf IP host configuration protocol then hosts MUST re-
configure with DHCP.
Hattig [Page 3]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
The second transition is the opposite of the first; it is a non-
zeroconf to zeroconf transition. This may occur if a host moves
between networks or when a server goes offline within a network.
The third transition occurs if a device moves from one network to
another network when both networks use a zeroconf protocol. For
example, if a person is using a laptop in her home network with a
zeroconf protocol, then she takes that laptop to her neighbor's
home network that uses the same zeroconf protocol: the laptop must
automatically adapt to the new network.
Another subtle example of this third of transition is if the
network topology changes significantly as when a bridge gets
installed between two existing networks. In this case, if the
networks are utilizing a zeroconf IP host configuration protocol,
the protocol SHOULD allow the hosts to detect addressing conflicts
and possibly reconfigure.
1.2.3 Coexistence
A zeroconf protocol in one area MUST be able to coexist with a
non-zeroconf protocol in another area.
To illustrate this point, suppose there are standard zeroconf and
non-zeroconf protocols for IP host configuration and domain name
to IP address resolution.
For IP host configuration, the zeroconf protocol is "protocol-A."
The non-zeroconf protocol is "protocol-B", supported by a fully
conformant "protocol-B" server.
For domain name to IP address resolution, the zeroconf protocol is
"protocol-C". The non-zeroconf protocol is "protocol-D" supported
by a fully conformant "protocol-D" server.
Within a single network, the IP host configuration zeroconf
protocol-A MUST be able to coexist with the domain name to IP
address resolution non-zeroconf protocol-D.
In contrast, zeroconf and non-zeroconf protocols from a single
area MUST NOT be able to coexist during normal operation. They MAY
coexist during a transition, but the coexistence period MUST be
minimal.
1.2.4 Scalability
Scalability is not of great concern because it is expected that
zeroconf protocols will operate in networks of limited size. In
addition, it is likely that as a network grows, the owners of that
network will migrate to using non-zeroconf protocols before
Hattig [Page 4]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
scalability becomes an issue. For this reason, this document
mentions little of scalability requirements.
1.2.5 Centralized Servers
This subsection illustrates how a protocol that takes advantage of
a centralized server may be a zeroconf protocol. This is
illustrated using DHCP in a home network.
Centralized servers such as DHCP servers are being deployed in
home networks to relieve user configuration. However, networks
accidentally operating with multiple DHCP servers present new
configuration challenges. Today's solution is for a person to
configure one of the DHCP servers to stop operating; since a user
must do something (turn off a DHCP server) this is a non-zeroconf
solution.
In order for a centralized server protocol to be zeroconf while
operating with multiple servers, there must be mechanisms to
ensure all clients use the appropriate server. Of course, these
mechanisms must operate without any user configuration.
1.2.6 IP Host Configuration
IP host configuration is the configuration of an interface on an
IP host, which always includes an IP address and sometimes an
netmask and default route. IP host configuration is required
before almost any IP communication can take place.
DHCP is the common IP host configuration solution deployed today.
Zeroconf IP host configuration schemes MUST peacefully coexistence
with DHCP.
The definitions needed for the IP host configuration scenarios
are:
IP subnet - a single logic IP network that may span multiple link
layer networks.
internet - multiple IP subnets connected by routers.
Network - general term that may apply to link layer, IP subnet, or
internet.
1.2.7 Domain name to IP address resolution
DNS is the common way to resolve names to IP addresses. Zeroconf
domain name to IP address resolution protocols MUST peacefully
coexistence with DNS.
Hattig [Page 5]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
It is assumed that sub-domain delegation is not done within the
zone that a zeroconf domain name to IP address resolution protocol
is performed. In other words, a zeroconf zone contains all of the
names in its domain.
In addition, it is assumed a zeroconf domain name to IP address
resolution protocol will only be used if a DNS server is not
present or a host is not configured with the IP address of a DNS
server. It is also assumed that TCP/IP networking connectivity to
other zones MAY exist and those other zones have DNS servers.
Furthermore, it is assumed that a special device or application
exists at the edge of these two zones and is able to convert
between the zeroconf and non-zeroconf domain name to IP address
resolution protocols.
1.2.8 IP Multicast Address Allocation
IP multicast is used to conserve bandwidth and reduce complexity
in the multicast source. MADCAP is the default IP multicast
address allocation protocol. Zeroconf IP multicast address
allocation protocols MUST peacefully coexist with MADCAP.
Zeroconf solutions are only concerned with IP multicast addresses
scoped as Local (i.e. 239.255.0.0/16), link-local, node-local, and
Single-source IP multicast addresses of any scope. It is assumed
that a boundary router (as described in RFC 2365) is present to
appropriately control multicast packets from entering and leaving
the scope boundaries.
1.2.9 Service Discovery
Service discovery protocols have proven to be critical to the
usability of networks. AppleTalk/NBP, NetBIOS/SMB and IPX/SAP have
improved the utility services from printing to gaming are easily
found on these networks. Service Location Protocol version 2
(SLPv2) is defined in Standards Track RFC 2608, and an Internet-
Draft defines Simple Service Discovery Protocols (SSDP).
Service discovery definitions are:
Process - A process is an implementation of an algorithm in
software, hardware, or a combination of software and hardware.
Registry - A process that acts as an intermediary between
discoverers and advertisers. Servers 'register' service
advertisements and other pertinent (e.g. authentication info,
announcement criteria) with registries, then the service may be
discovered from the registry instead of from a server.
Hattig [Page 6]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
Registry update - A message that contains updated registry
information. It may cause one or more registry entries to be
deleted, added, or modified.
Server - A process that offers services to clients. A server can
make its service(s) known to clients by means of a service
discovery protocol.
Service - A service is a set of processes that utilize a
particular protocol. Services range from printing to transferring
a file to providing on-line pizza order and delivery.
Service Advertisement Packet - An unsolicited packet issued by a
server or registry. The advertisement provides the service
identifier and possibly service characteristics.
Service Characteristics - Characteristics provide a finer
granularity of description to differentiate services beyond just
the service type. For example if the service type is printer, the
characteristics may be color, pages printed per second, location,
etc.
Service Discovery Protocol - A service discovery protocol enables
a client (or clients) to discover a server (or servers) of a
particular service. A service discovery protocol is an application
layer protocol that relies on network and transport protocol
layers.
Service Identifier - A service identifier allows clients, servers,
advertisers, discoverers, and registries to uniquely identify an
instance of a service.
Service Protocol - A service protocol is used between the client
and the server after service discovery is complete.
Service Solicitation - A request packet made by a client to obtain
a response packet that indicates a service is present. The
response may come from a service or a registry.
Service Type - A service type allows clients, servers,
advertisers, discoverers, and registries to uniquely identify a
type of service such as a printer service.
2 Scenarios & Requirements
This section lists zeroconf scenarios that lead to requirements
for protocols. There is a subsection for each of the four protocol
areas. Within each protocol area representative scenarios are
discussed and requirements are identified. It is possible to state
an endless number of scenarios but unless those scenarios yield
Hattig [Page 7]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
additional requirements, there is no point of discussing such
scenarios. Also, within each area is a summary of the requirements
and an IPv6 considerations section.
2.1 IP Host Configuration
DHCP is the non-zeroconf IP Host configuration protocol. The
problems preventing DHCP from being a zeroconf protocol are: the
DHCP server may not be present and if multiple DHCP servers are
present they may provide conflicting configuration.
The scenarios in this section are ping and bridge install. Since
DHCP is the non-zeroconf IP host configuration protocol, the
Zeroconf and non-Zeroconf Transitions section discusses
transitioning between zeroconf IP host configuration and DHCP.
2.1.1 Ping
Ping consists of one host sending an ICMP echo request to another
host, then the other host replying with an ICMP echo reply. Ping
has two sub-scenarios: ping to a host on local IP subnet and ping
to a host off the local IP subnet.
When sending a ping (or any other IP packet for that matter), a
host performs the AND operation on the netmask and the destination
IP address then compares that result with the result of an AND
operation on the host's IP address and netmask.
((HostIPAddr & netmask) == (DestIPAddr & netmask))
If the result of this compare is FALSE, then the host forwards the
packet to the default router because the destination address is
off the local IP subnet. If the result is TRUE, then the host
sends an ARP request to resolve the destination IP address to a
hardware address within the local IP subnet.
These steps are important to show the expected utilization and
values of a netmask and the default route. Specifically, the
values for the IP address, netmask, and default route within a
host must be chosen such that the following statements are true:
- All hosts on an IP subnet have a common netmask.
- When a host computes (HostIPAddr & netmask) the result is
identical for all hosts on a single IP subnet.
- When a host computes (HostIPAddr & ~netmask) (inverse netmask)
the result is unique for all hosts on an IP subnet.
- All hosts get a default route that is used for communication
with other IP hosts off the local subnet.
In addition IP subnets must somehow be unique on different IP
subnets within an internet over which the zeroconf IP host
Hattig [Page 8]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
configuration protocol is operating; this insures unique IP
addresses (regardless of the value of the host portion of the IP
address) across the entire internet.
The zeroconf IP host configuration protocol only defines packets
sent over a wire and the associated semantics. Here are zeroconf
IP host configuration protocol requirements to satisfy ping:
- The ability to determine the netmask for an IP subnet.
- The ability to determine the default route for an IP subnet.
- The ability to have unique IP addresses within an IP subnet.
- The ability to have unique IP subnets within an internet.
2.1.2 Bridge Installed
This scenario starts with two completely operational standalone
networks in which IP host configuration was completed with
zeroconf IP host configuration protocols. These two networks
become one after a bridge is installed between them.
This creates two problems. First, hosts may have duplicate IP
addresses. Second, there may be competing netmask and default
route values that disrupt communication.
The bridge scenario results in the following protocol
requirements:
- The ability to avoid or resolve contention among netmasks.
- The ability to avoid or resolve contention among default routes.
- The ability to avoid or resolve duplicate IP addresses within a
subnet.
- The ability to avoid or resolve duplicate IP subnets within an
internet.
2.1.3 Zeroconf and non-Zeroconf Transitions
DHCP is the non-zeroconf IP Host configuration protocol. Here are
examples of intermittent connectivity between zeroconf hosts and
DHCP servers that show the need for IP host configuration
transitions:
- DHCP servers in a PC that gets regularly power-cycled.
- A zeroconf capable device introduced into a network that has a
DHCP server.
- A zeroconf capable device removed from a network that has a DHCP
server.
These scenarios require the periodic actions as well as specific
actions at startup. The action is the same whether it be periodic
or at startup. The action is an attempt to discover a DHCP server.
If the DHCP server is discovered the host uses DHCP, otherwise the
host uses the zeroconf IP host configuration protocol.
Hattig [Page 9]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
IP host configuration zeroconf and non-zeroconf transitions
necessitate the following protocol requirements:
- The ability to detect the presence or absence of a DHCP server
at startup of a device and periodically after a devices starts.
2.1.4 Requirements Summary
Zeroconf IP host configuration protocol requirements are:
- The ability to determine the netmask for an IP subnet.
- The ability to determine the default route for an IP subnet.
- The ability to have unique IP addresses within an IP subnet.
- The ability to have unique IP subnets within an internet.
- The ability to avoid or resolve contention among netmasks.
- The ability to avoid or resolve contention among default routes.
- The ability to avoid or resolve duplicate IP addresses within a
subnet.
- The ability to avoid or resolve duplicate IP subnets within an
internet.
- The ability to detect the presence or absence of a DHCP server
at startup of a device and periodically after a devices starts.
2.1.5 IPv6 Considerations
IPv6 allows a host to select an appropriate IP address, netmask,
and find a default route, thus if a network is using IPv6, there
already exists a zeroconf IP host configuration solution.
2.2 Domain Name to IP Address Resolution Scenarios
DNS is the non-zeroconf domain name to IP address resolution
protocol. The problems with DNS preventing DNS from being a
zeroconf protocol are: user configuration of the IP address of a
DNS server in a client machine, user entering DNS resource records
in the DNS server, devices having unique names, and a DNS server
may not be accessible.
The scenarios in this section are web browsing, domain name
selection, and bridge install. Additional, transition scenarios
list requirements for transitioning between using DNS and using
the zeroconf domain name to IP address resolution protocol.
2.2.1 Web Browsing
Users browsing the WEB typically enter the name of a web server.
This name MUST be resolved to an IP address before any actual web
browsing occurs. The web server may be within the same domain as
the web browser or within a different domain.
The zeroconf domain name to IP address resolution protocol MUST
resolve a name to an IP address without a host being configured
Hattig [Page 10]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
with the IP address of a DNS server. This includes names within
the same domain as the host that is using the zeroconf protocol as
well as names within other domains.
The domain name to IP address resolution protocol requirements for
web browsing are:
- The ability to resolve a name to an IP address without the user
configuring the IP address of a DNS server.
- The user must not be required to enter a mapping of a domain
name to IP address into the DNS database.
2.2.2 Domain Name Selection
A domain name consists of a host name and the name of the domain
itself. A host has control over its host name, but some other
entity configures or determines the name of the domain. In fact
the name of the domain may not be available. A protocol is needed
to maintain unique host portions of a domain name and to possibly
learn the name of the domain.
Note that it may be desirable to have duplicate host names. Such
cases include server farms with load-balanced servers meant to
provide consistent response times during periods of high volume.
Here are the requirements for a name selection protocol:
- The ability to ensure a unique host name (assuming unique names
are desired) is selected.
- The ability to learn the name of the domain (assuming the name
of the domain is known).
2.2.3 Bridge Install
This scenario starts with two completely operational standalone
networks. After name selection is complete, these two networks
become one when a bridge is installed between the networks.
The bridge scenario results in the following protocol
requirements:
- The ability to periodically ensure the uniqueness of a selected
host name.
2.2.4 Zeroconf and non-Zeroconf Transitions
DNS is the non-zeroconf domain name to IP address resolution
protocol. There are four transitional cases to consider. Note that
unless a host is configured with the IP address of the DNS server,
none of these transitions can occur.
The first is a zeroconf to non-zeroconf transition that occurs
when the host is first configured with the IP address of the DNS
Hattig [Page 11]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
server and the host can actually reach the DNS server (i.e. the
DNS server responds to requests).
The second is a non-zeroconf to zeroconf transition that occurs
when for some reason the DNS server can no longer be reached. One
such reason may be that the host is moved to a network without
connectivity to the DNS server. In this case the zeroconf domain
name to IP address resolution protocol MUST be invoked.
The third transition is from zeroconf back to non-zeroconf. This
occurs when the DNS server becomes reachable again. Following the
above example, the host is moved back to the original network with
connectivity to the DNS server.
The final transition is a non-zeroconf to zeroconf transition that
occurs when the IP address of the DNS server is removed from the
host.
These transitions generate the following requirements:
- The ability to detect the presences or absence of DNS server
(applies only if the host is configured with the IP address of
the DNS server). The host must use DNS when the DNS server is
present and zeroconf domain name to IP address resolution when
the DNS server is not present.
2.2.5 Requirements Summary
The domain name to IP address resolution protocol requirements
are:
- The ability to resolve a name to an IP address without the user
configuring the IP address of a DNS server. This includes names
within the same domain as the requesting host as well as names
outside the domain as the requesting host.
- The user must not be required to enter a mapping of a domain
name to IP address.
- The ability to ensure a unique host name (assuming unique names
are desired) is selected.
- The ability to learn the name of the domain (assuming the name
of the domain is known).
- The ability to periodically ensure the uniqueness of a selected
host name.
- The ability to detect the presences or absence of DNS server
(applies only if the host is configured with the IP address of
the DNS server). The host must use DNS when the DNS server is
present and zeroconf domain name to IP address resolution when
the DNS server is not present.
2.2.6 IPv6 Considerations
Hattig [Page 12]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
Domain name to IP address resolution protocols has no zeroconf
related differences for IPv4 and IPv6.
2.3 IP Multicast Address Allocation Scenarios
MADCAP is the non-zeroconf IP Multicast Address Allocation
protocol. The problems preventing MADCAP from being a zeroconf
protocol are: the MADCAP server may not be present and if multiple
MADCAP servers are present they may provide conflicting
configuration.
All IP multicast addresses allocated are from the scopes of Local
(i.e. 239.255.0.0/16), link-local, node-local, and Single-source
IP multicast addresses of any scope. Descriptions of "Scope
Enumeration" and "Allocate Node-scoped or Single-Source Global IP
multicast address" do not result in requirements but do provide
important information about IP multicast operations. The scenarios
of "Allocate Link-scoped or Local-Scope IP multicast", "Allocate
IP Multicast Address Used by Multiple Sources", then the
transitions between zeroconf and MADCAP generate protocol
requirements.
2.3.1 Scope Enumeration
Applications that leave the choice of scope up to the user require
the ability to enumerate what scopes the host is within [RFC
2771].
In addition, services that are assigned relative addresses [RFC
2365] require the ability to enumerate what scopes the host is
within, then a host is able to apply the relative address to a
scope.
When enumerating scopes, the following scopes may be assumed to
exist in all cases (assuming well-known ranges have been reserved
by IANA).
- Node-Local
- Link-Local
- Local (i.e., the Zeroconf area)
- Single-source global
The zeroconf IP multicast address allocation protocol requirements
are:
- The ability for a host to obtain the set of scope names, for all
scopes it is within.
- The ability for a host able to obtain the set of address ranges
for all scopes it is within.
Hattig [Page 13]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
2.3.2 Allocate Node-scoped or Single-Source Global IP multicast
address
Each host is always responsible for allocating its own Node-scoped
and Single-source Global multicast addresses, regardless of
whether it is use of zeroconf protocols since there is no
coordination between devices for such allocation, no protocol is
involved, and there are no protocol requirements.
Allocating (global) single-source addresses is only possible if
the host has already acquired a global unicast IP address.
To date, no range has been reserved for dynamic allocation of
Single-source addresses in IPv6. Hence, until such a range is
reserved, dynamic allocation of Single-source addresses applies
only to IPv4.
2.3.3 Allocate Link-scoped or Local-Scope IP multicast address
Address allocation at the Link and larger scopes requires
coordination to avoid address collisions. To allocate an address,
the host specifies a given scope, the number of addresses it
desires, and the lifetime for which it desires.
To date, no range has been reserved for dynamic allocation of
Link-scoped addresses in IPv4. Hence, unless such a range is
reserved, dynamic allocation of Link-scoped addresses applies only
to IPv6.
Collision detection must span the entire Link for Link-scope
allocations, and must span the entire locally scoped internet for
Local-scope allocations. The protocol should include the ability
for a host to choose addresses, determine if they are in use, and
choose different addresses if so.
The collision detection protocol must become active at various
times such as when previously disconnected yet operational
networks now become connected by the installation of a router or
bridge.
The zeroconf IP multicast address allocation protocol requirements
are:
- The ability for a host to select a multicast address with a
given scope and lifetime.
- The ability for a host to determine if the address has been
allocated by another host.
- The ability for a host to defend the addresses it allocates.
- The ability for a host to determine if another host has
allocated an address that has been allocated by itself; this
SHOULD be done periodically.
Hattig [Page 14]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
- The protocol MUST be routable to ensure it spans the entire
local scope.
2.3.4 Multiple Source
An intercom system inside a home is an example of a multiple
source IP multicast application. In this type of application,
several sources may be sending packets destined to the same IP
multicast address.
Here, the first source that needs the IP address MUST allocate the
address, yet it may not be the host that deallocates the multicast
address. This is because the first source may leave the multicast
group before all the other sources stop sending packets to that IP
multicast address. This requires, the last source using the IP
multicast address to deallocate the IP multicast address after it
is done sending.
The zeroconf IP multicast address allocation protocol requirements
are:
- The ability for the last host acting as a source to deallocate
the IP multicast address.
2.3.5 Zeroconf and non-Zeroconf Transitions
MADCAP is the non-zeroconf IP multicast address allocation
protocol. Hosts MUST be able to transition between MADCAP and the
zeroconf IP multicast address allocation protocol by detecting (or
not detecting) the presences of a MADCAP server.
If MADCAP is detected while using zeroconf IP multicast address
allocation, the host must start utilizing MADCAP. If MADCAP is no
longer detected while using MADCAP, the host must start utilizing
the zeroconf IP multicast address allocation protocol.
The transition requirements are:
- The ability to detect the presence or absence of a MADCAP server
at startup of a device and periodically after a device starts.
2.3.6 Requirements Summary
Zeroconf IP multicast address allocation protocol requirements
are:
- The ability for a host to obtain the set of scope names, for all
scopes it is within.
- The ability for a host able to obtain the set of address ranges
for all scopes it is within.
- The ability for a host to select a multicast address with a
given scope and lifetime.
Hattig [Page 15]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
- The ability for a host to determine if the address has been
allocated by another host.
- The ability for a host to defend the addresses it allocates.
- The ability for a host to determine if another host has
allocated an address that has been allocated by itself; this
SHOULD be done periodically.
- The protocol MUST be routable to ensure it spans the entire
local scope.
- The ability for the last host acting as a source to deallocate
the IP multicast address.
- The ability to detect the presence or absence of a MADCAP server
at startup of a device and periodically after a device starts.
2.3.7 IPv6 Considerations
To date, no range has been reserved for dynamic allocation of
Single-source addresses in IPv6. Hence, until such a range is
reserved, dynamic allocation of Single-source addresses applies
only to IPv4.
To date, no range has been reserved for dynamic allocation of
Link-scoped addresses in IPv4. Hence, unless such a range is
reserved, dynamic allocation of Link-scoped addresses applies only
to IPv6.
2.4 Service Discovery Scenarios
As stated earlier, there is no non-zeroconf service discovery
protocol, thus there are no particular zeroconf problems with an
zeroconf protocol. In addition, there are no zeroconf to non-
zeroconf transition scenarios.
The scenarios are the discovery of a simple printer service and
the discovery of a printer manager that consolidates many printer
services.
2.4.1 Printer Service
Networked enabled printers allow various networked clients to
submit print jobs. A service discovery protocol MUST allow a
printing client to discover the printer service. This requires a
service type as well as a service identifier to distinguish
instances of a single service type.
Printers vary in their characteristics such as location, status,
dots per inch, drivers, etc. Discovering these characteristics
SHOULD be part of the service discovery protocol. Some service
specific protocols allow the client and server to negotiate the
use of these characteristics after the service is found; thus,
alleviating the need for the service discovery protocol to
Hattig [Page 16]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
discover by characteristic. However, characteristic discovery
SHOULD be part of the service discovery protocol for those
services without capability negotiation.
Discovery MUST be possible by either the client actively
soliciting the service or by the service advertising then the
client passively listening for the advertisements. Once a client
finds the printer, it can utilize different printing protocols
such as raw tcp, lpd, and ipp.
Within a short number of seconds after activating a print server,
a user who is actively browsing for a printer MUST be able to see
the device appear in a browser window, or a user application such
as a spreadsheet MUST be able to begin using the print service.
This requires the service discovery to be timely.
In the case of a printer service, a printer may be temporarily
taken off-line for repair or everyday maintenance. This requires
clients to be able to rediscover a service.
The zeroconf service discovery protocol requirements for this
scenario are:
- The protocol MUST allow the client to discover a service via
service identifier and/or service type.
- The protocol SHOULD allow the client to discover a service by
characteristics.
- The protocol MUST allow the client to discovery a service by
actively soliciting the service.
- The protocol MUST allow the client to discover a service by the
client passively listening for advertisements.
- The protocol MUST allow clients to rediscover a service.
- Discovery MUST be timely (within seconds) when a service comes
on line.
- The protocol SHOULD allow services that are no longer active to
notify clients in a time (within seconds) manner.
- A service discovery protocol itself MUST NOT require
configuration.
- The protocol MUST be independent from any particular service.
2.4.2 Printer Manager
A printer manager acts as a proxy to various printers. A printer
manager improves scalability by providing a single location from
which clients can find all printers.
In addition, a printer manager provides an evolutionary path for
service discovery deployment. For example, if an existing printer
does not support the zeroconf service discovery protocol, the
printer manager can use a legacy printer specific protocol to
Hattig [Page 17]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
learn the existence and characteristics of a printer then expose
that printer and its characteristics through the zeroconf service
discovery protocol. This allows new printer clients that support
the service discovery protocol to discover legacy printers that do
not support the zeroconf service discovery protocol.
A print manager requires a registry to cache information about
services and characteristics of services. Clients MUST be able to
extract data from the registry without knowledge that they are
talking to a registry. In other words, the client and server sides
of the service discovery protocol MUST NOT be any different
whether a registry is involved or not. Registry updates that
maintain the registry are required of the service discovery
protocol but are optionally implemented for a particular service;
this allows legacy protocols or the zeroconf service discovery
protocol to update and maintain the registry.
The zeroconf service discovery protocol requirements for printer
manager scenario are:
- The protocol SHOULD allow for registry to cache information
about services and characteristics of services.
- The ability for clients to extract data from the registry
without knowledge that it is talking to a registry.
- A registry MUST not be required for all services.
2.4.3 Requirements Summary
Zeroconf service discovery protocol requirements are:
- The protocol MUST allow the client to discover a service via
service identifier and/or service type.
- The protocol SHOULD allow the client to discover a service by
characteristics.
- The protocol MUST allow the client to discovery a service by
actively soliciting the service.
- The protocol MUST allow the client to discover a service by the
client passively listening for advertisements.
- The protocol MUST allow clients to rediscover a service.
- Discovery MUST be timely (within seconds) when a service comes
on line.
- The protocol SHOULD allow services that are no longer active to
notify clients in a time (within seconds) manner.
- A service discovery protocol itself MUST NOT require
configuration.
- The protocol MUST be independent from any particular service. -
The protocol SHOULD allow for registry to cache information
about services and characteristics of services.
- The ability for clients to extract data from the registry
without knowledge that it is talking to a registry.
- A registry MUST not be required for all services.
Hattig [Page 18]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
2.4.4 IPv6 Considerations
Service discovery protocols have no zeroconf related differences
for IPv4 and IPv6.
3 Security Considerations & Requirements
By definition security requires configuration. Security examples
include a configured key for payload encryption, user entered
passwords for conditional access, and an administrator configures
port mappings to enable a protocol to traverse a firewall. The
configuration required by security is in direct conflict with the
design goals of zeroconf protocols; however, security requirements
take precedence over zeroconf protocol design goals.
Given this reality, this section focuses on the minimal
configuration necessary to make zeroconf protocols secure. In
addition, this section describes types of general threats and how
those general threats apply to each protocol area.
The general threats are:
Hoarding: Hosts claim all available resources, whether they plan
to use them or not. This is a form of denial of service attack.
Masquerading: Hosts can respond to requests that they should not
so they can masquerade as another host.
Antagonistic Server: A server could offer support for a critical
service but intentionally misconfigure hosts on the network.
3.1 IP Host Configuration
Threats include:
- A host could hoard IP addresses.
If secure zeroconf IP host configuration is required, all hosts
MUST be certifiable as valid participants. In addition, a host
MUST be configured with some security information. Furthermore,
some security information must be part of every zeroconf IP host
configuration packet.
Here is an example to illustrate: All hosts are registered as
valid security participants by the manufactures before the product
ships. In addition the product is shipped with a private key.
Before the secure device communicates with another secure device
it gets the other device's registered info, then submits that
registered info to the registration authority to get the devices
public key. Of course this request is encrypted. From that point
on all packets are encrypted using a public key and a private key.
Hattig [Page 19]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
3.2 Domain Name to IP Address Resolution
Potential threats include:
- A host could masquerade by responding to names requests
illegitimately.
- A host could hoard names by responding to all 'claim' requests.
Hosts MUST be able to be configured to use a zeroconf protocol for
domain name to IP address resolution securely. For example, a
'reply' from the resolution protocol could be accompanied by
a 'signature' that could be verified before being accepted.
The security configuration would have to provide the server
portion of the protocol with the data needed to produce a
'signature' that could only be produced if in possession of the
configuration data.
3.3 IP Multicast Address Allocation
Potential threats include:
- A host could hoard multicast addresses by denying others the
ability to obtain them.
- A host could snoop to learn all used IP multicast addresses in
use then reconfigure the border router to allow IP multicast
data to go beyond the desired boundary.
Hosts MUST be able to be configured to use a zeroconf protocol for
multicast address allocation securely. For example, a claim and
defend protocol used for multicast address allocation would have
to include security data with all messages. A host in the
zeroconf network could verify that another host's claim was
legitimate or not.
3.4 Service Discovery
Potential threats include:
- Servers could masquerade by responding to service discovery
requests that they shouldn't respond to.
- A host could pose as an antagonistic service discovery
'infrastructure element.' Some service discovery protocols
offer a 'registry', 'directory', 'proxy' or other
infrastructure element for scalability.
The service discovery protocol MUST provide mechanisms that allow
a client to determine if both the service it discovers and the
service discovery protocol infrastructure it uses to discover
services are 'legitimate.'
The service discovery protocol MUST provide mechanisms that allow
a client to determine if both the service it discovers and the
Hattig [Page 20]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
service discovery protocol infrastructure it uses to discover
services are 'legitimate.'
3.5 IPv6 Considerations
IPv6 has built in security, thus if a network is using IPv6, there
already exists a security solution.
4 IANA Considerations
There are no known IANA considerations arising from this document.
5 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE."
6 Acknowledgements
Thanks to Peter Ford and Stuart Cheshire for hosting the first BOF
that was the catalyst to forming the Zeroconf Working Group, which
is responsible for this document.
Thanks to Erik Guttman and Stuart Cheshire for forming and
chairing the Zeroconf Working Group.
Hattig [Page 21]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
Thanks to Erik Guttman for providing key input to the service
discovery and the security sections.
Thanks to Dave Thaler for providing key input to the IP multicast
address allocation sections.
Additional recognition goes the following people for their
influential contributions to this document and its predecessors:
Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob
Quinn, John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl
Auerbach, Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland,
and Bernard Aboba.
Editor:
Myron Hattig
Intel Corporation
3585 SW 198th Avenue
Hillsboro, OR 97124
myron.hattig@intel.com
7 References
[STD 3] R. Braden Requirements for Internet Hosts --
Communication Layers RFC 1122, STD 3, October 1989
[STD 4] R. Braden, Requirements for Internet Hosts --
Application and Support RFC 1123, STD 4 October 1989
[RFC 1001] PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP
TRANSPORT: CONCEPTS AND METHODS, RFC 1001 March, 1987
[RFC 1002] PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP
TRANSPORT: DETAILED SPECIFICATIONS, RFC 1002, March
1987
[RFC 1034] P. Mockapetris, Domain Names - Concepts and
Facilities, RFC 1034, November 1987
[RFC 1035] P. Mockapetris, Domain Names - Implementations and
Specifications, RFC 1034, November 1987
[RFC 1458] R. Braudes, Requirements for Multicast Protocols, RFC
1458, May 1993
[RFC 1918] D. Karrenberg, et al, Address Allocation for Private
Internets, RFC 1918, Feb 1996
Hattig [Page 22]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
[RFC 2026] S. Bradner, The Internet Standards Process --
Revision 3, RFC 2026 Oct 1996
[RFC 2119] S. Bradner. Key words for use in RFCs to Indicate
Requirement Levels. RFC 2119, March 1997.
[RFC 2131] R. Droms. Dynamic Host Configuration Protocol. RFC
2131, March 1997.
[RFC 2132] S. Alexander, R. Droms DHCP Options and BOOTP Vendor
Extension RFC 2132, March 1997.
[RFC 2316] S. Bellovin, Report of the IAB Security Architecture
Workshop, RFC 2316, April 1998
[RFC 2365] D. Meyer Administratively Scoped Multicast Address
RFC 2365,July 1998.
[RFC 2401] S. Kent, Security Architecture for the Internet
Protocol, RFC 2401, Nov 1998
[RFC 2411] R. Thayer, IP Security Document Roadmap, RFC 2411,
Nov 1998
[RFC 2461] T. Narten, E. Nordmark, W. Simpson Neighbor
Discovery for IP Version 6 (IPv6) RFC 2461, December
1998.
[RFC 2462] S. Thomson, T. Narten IPv6 Address Autoconfiguration
RFC 2462, December 1998.
[RFC 2504] E. Guttman, Users' Security Handbook, RFC 2504, Feb.
1999
[RFC 2608] E. Guttman, C. Perkins, J. Veizades, and M. Day.
Service Location Protocol version 2. RFC 2608, June
1999.
[RFC 2609] E. Guttman, C. Perkins, J. Kempf Service Templates
and service: Schemes, RFC 2609, June 1999.
[RFC 2730] iS. Hanna, B. Patel, M. Shah, Multicast Address
Dynamic Client Allocation Protocol (MADCAP) draft-
ietf-malloc-madcap-05.txt Dec 1999.
[AutoMcast] D. Thaler, B. Adoba, Multicast Address Allocation in
Auto-Configured Networks, draft-thaler-zeroconf-
multicast-00.txt, Oct 1999. A work in progress
Hattig [Page 23]
Internet Draft draft-ietf-zeroconf-reqts-04.txt July 2000
[AutoNet] R. Troll Automatically Choosing an IP Address in an
Ad-Hoc IPv4 Network draft-ietf-dhc-ipv4-autoconfig-
04.txt April, 1999. A work in progress.
[MCAST DNS] B. Woodcock, B. Manning Multicast Discovery of DNS
Services draft-manning-multicast-dns-01.txt
December, 1998. A work in progress.
[MiniDHCP] Bernard Aboba, Auto-Addressing in Multi-segment
Networks, draft-aboba-zeroconf-multi-00.txt, Oct
1999. A work in progress.
[SSDP] www.upnp.org
[IPv6 WG] IP Next Generation WG,
www.ietf.org/html.charters/ipngwg-charter.html.
[DHC WG] Dynamic Host Configuration WG,
www.ietf.org/html.charters/dhc-charter.html.
[NAT WG] Network Address Translation WG,
www.ietf.org/html.charters/nat-charter.html.
[DNSEXT WG] DNS Extension WG,
http://www.ietf.org/html.charters/dnsext-charter.html
[MALLOC WG] Multicast Allocation WG Charter,
www.ietf.org/html.charters/malloc-charter.html.
Hattig [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-23 08:34:21 |