Zeroconf WG M. Hattig
Internet Engineering Task Force Editor
INTERNET DRAFT Intel Corp.
Expires September 2000 March 10, 2000
Zeroconf Requirements
draft-ietf-zeroconf-reqts-03.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 presents requirements for
zeroconf protocols in four areas: IP host configuration, domain
Hattig [Page 1]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
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.
An additional part of the overall zeroconf protocol effort
includes a separate profiles document that is a companion to this
requirements document. The profile document matches existing
protocols with the requirements. If existing protocols do not meet
the requirements then new zeroconf protocols must be created.
Table of Contents
1 Introduction................................................2
1.1 Reading This Document.....................................3
1.2 Background Information....................................3
1.3 Zeroconf Protocols........................................4
2 Scenarios & Requirements....................................9
2.1 IP Host Configuration.....................................9
2.2 Domain Name to IP Address Resolution Scenarios...........12
2.3 IP Multicast Address Allocation Scenarios................15
2.4 Service Discovery Scenarios..............................18
3 Security Considerations & Requirements.....................20
3.1 IP Host Configuration....................................21
3.2 Domain Name to IP Address Resolution.....................21
3.3 IP Multicast Address Allocation..........................22
3.4 Service Discovery........................................22
3.5 IPv6 Considerations......................................22
4 IANA Considerations........................................22
5 Full Copyright Statement...................................22
6 Acknowledgements...........................................23
7 References.................................................24
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 to this requirements document are the
Introduction, Scenarios & Requirements, and Security
Considerations & Requirements. The introduction provides the
background information, terms, and assumptions so the scenarios
can be understood. The Scenarios & Requirements section lists
requirements that result from examining everyday usage scenarios
of protocols. The security section lists threats and security
requirements for all four protocol areas.
Hattig [Page 2]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
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.1 Reading This Document
Because this document deals with four distinct protocol areas,
many sections are divided into these areas. These areas are:
- IP host configuration
- Domain name to IP address resolution
- IP multicast address allocation
- Service discovery
With the exception of the introduction, a reader only interested
in particular areas only needs to read about those areas. However,
all readers should read the introduction to understand the flow of
the document and various global assumptions.
Specifically, the introduction provides the necessary background
information to support the scenarios and requirements sections.
This introduction includes reference information, restrictions,
assumptions, and terms.
The Scenarios & Requirements section is divided into protocol
areas. Within each area is a representative set of everyday usage
scenarios that generate unique requirements. A summary of all
requirements finishes each protocol area subsection.
The Security Considerations & Requirements section lists threats
and security requirements for each protocol area.
1.2 Background Information
The below references are divided by protocol area with additional
references for security and general knowledge. Note that some IETF
working groups are listed because they specify protocols that
impact zeroconf protocols. All readers should be familiar with the
general knowledge references.
IP host configuration:
- [AutoNet] Ipv4 Auto-Configuration I-D
- [MiniDHCP] Auto-Addressing in Multi-segment Networks I-D
- [RFC 1918] RFC 1918 Private Addresses
- [RFC 2131] RFC 2131 DHCP
- [RFC 2132] RFC 2132 DHCP Options
- [RFC 2462] IPv6 Auto-Configuration
- [RFC 2461] IPv6 Neighbor Discovery
- [IPv6 WG] Next Generation (Ipv6) WG
Hattig [Page 3]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
- [DHC WG] Dynamic Host Configuration WG
Domain name to IP address resolution:
- [Mcast DNS] Multicast DNS I-D
- [RFC 1001] NETBIOS: CONCEPTS AND METHODS
- [RFC 1002] NETBIOS: DETAILED SPECIFICATIONS
- [RFC 1034] RFC 1034 DNS
- [DNSEXT WG] DNS Extension WG
Multicast address allocation:
- [AutoMcast] Multicast Address Allocation in Auto-Configured
Networks I-D
- [RFC 2730] RFC 2730 MADCAP
- [RFC 2365] RFC 2365 Administratively Scoped Multicast Address
- [MALLOC WG] Multicast Address Allocation WG
Service discovery:
- [SSDP] Simple Service Discovery Protocol I-D
- [RFC 2608] RFC 2608 Service Location Protocol v2
- [RFC 2609] RFC 2609 SLP Schemes
Security:
- [RFC 2316] RFC 2316, IAB Security Architecture Workshop
- [RFC 2401] RFC 2401, Security Architecture for IP
- [RFC 2411] RFC 2411, IP Security Document Roadmap
- [RFC 2504] RFC 2504, User's Security Handbook
General knowledge:
- [STD3] RFC 1122 Requirements for Internet Hosts - Comm Layers
- [STD4] RFC 1123 Requirements for Internet Hosts - App Layers
- [RFC 1458] RFC 1458 Requirements for Multicast Protocols
- [RFC 1812] RFC 1812 Requirements for Internet Gateways
1.3 Zeroconf Protocols
Below are strict definitions of zeroconf protocol and a non-
zeroconf protocol. Also discussed are how a host transitions
between a zeroconf protocol and non-Zeroconf protocol within a
single area as well as coexistence of protocols in different
areas. Then, additional subsections state the assumptions and
restrictions for each protocol area.
1.3.1 Definitions
A zeroconf protocol requires no user configuration and does not
rely on information received from a centralized server.
A non-zeroconf protocol requires user configuration or relies on
information received from a centralized server.
Hattig [Page 4]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
1.3.2 Transitions
Below is a discussion of three possible transitions that a host
SHOULD consider when using a zeroconf protocol. Basically, the
host must be able to determine when to change from using the
zeroconf protocol to the non-zeroconf protocol, or vice-versa. In
addition, if the host moves from one network to another network
and both networks are using a zeroconf protocol, the host must
know to re-initialize or restart the 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 non-zeroconf 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.
The second transition is the opposite of the first; it is a non-
zeroconf to zeroconf transition. This may occur if a host moves to
a different network or when a non-zeroconf server goes offline
within a network.
The third transition occurs if a host 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, then the laptop
must automatically adapt to the zeroconf protocol operating in 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 MUST allow the hosts to detect addressing conflicts
and possibly reconfigure.
1.3.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.
Hattig [Page 5]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
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.3.4 IP Host Configuration
In this document, IP host configuration really is the
configuration of an interface on an IP host. That is, IP host
configuration is complete when a host is able to use an IP
address, netmask, and default route on an interface. IP host
configuration is required before almost any IP communication can
take place through a single interface on a host.
DHCP is the common IP host configuration solution deployed today.
DHCP consists of servers and clients. The client discovers the
server, and then the server offers configuration parameters to
clients. It is assumed that all zeroconf IP host configuration
schemes will coexistence with DHCP. DHCP is the non-zeroconf
solution for IP host configuration.
The definitions needed for the IP host configuration scenarios
are:
IP subnet û a single logic IP network that may span multiple layer
2 networks. All hosts on a single logical IP network have the
identical result when performing the following operations
(HostIPAddr & netmask). In addition, all hosts on the single
logical subnet have a unique result when performing the following
operation (HostIPAddr & ~netmask) (inverse netmask).
internet - multiple IP subnets connected by routers. This may be
the global Internet or a private internet.
Network - general term that may apply to IP subnet, internet,
Internet, or a layer 2 network. The context in which this term is
used defines its meaning.
Hattig [Page 6]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
1.3.5 Domain name to IP address resolution
Web browsing to an URL utilizes domain name to IP address
resolution. When a user enters a host name to download a file with
FTP, the entered name is resolved to an IP address. Domain name to
IP address resolution allows applications and users to remain
blissfully unaware of IP addresses.
DNS is the common way to resolve names. DNS consists of servers
that maintain resource records; a record maps a domain name to an
IP address. In addition, resolvers (i.e. clients) on hosts query
the DNS servers for the information in resource records. Name
servers have authority for particular zones. A zone covers a
complete set or a subset of a domain. If a server cannot directly
resolve a name, it passes the request onto another DNS server or
returns the IP address of another DNS server back to the resolver
so the resovler can query the DNS server it just learned about.
DNS is the non-zeroconf solution for domain name to IP address
resolution.
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 zone includes 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 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, this
also assumes that a special router 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.
A default domain is the domain considered ôlocalö to a host.
1.3.6 IP Multicast Address Allocation
Examples of emerging multicast applications include audio/video
(e.g. TV), bulk news, and intra-home intercom system. These
applications require an IP multicast address prior to sending IP
multicast packets. In most cases, the IP multicast address is
unique per application source. The scope of the multicast address
determines if a multicast packet gets transmitted beyond certain
administrative domains, which are separated by a boundary router
as defined in RFC 2365.
MADCAP is the non-Zeroconf IP multicast address allocation
solution. MADCAP is a client/server protocol that operates much
like DHCP. In addition, the client may define a range from which
Hattig [Page 7]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
the IP multicast address is allocated by passing a scope along
with the clientÆs allocation request.
Zeroconf solutions are only concerned with IP multicast addresses
scoped as Local (i.e. 239.255.0.0/16), link-local, node-local, and
any scope of single-source IP multicast addresses. It is assumed
that an RFC 2365 defined boundary router appropriately controls
multicast packets from physically entering and leaving scope
boundaries.
1.3.7 Service Discovery
Service discovery protocols have proven to be critical to the
usability of networks. AppleTalk/NBP, NetBIOS/SMB and IPX/SAP are
good real-world examples of this. Services from printing to gaming
are easily found on these networks.
Unlike the other protocol areas in this document, service
discovery will not likely have separate zeroconf and non-zeroconf
protocols; one protocol will serve both.
Also unlike the other protocol areas, no service discovery
protocol has been as widely deployed as DNS or DHCP. Service
Location Protocol version 2 (SLPv2) is defined in Standards Track
RFC 2608. An Internet-Draft defines Simple Service Discovery
Protocols (SSDP), which is another service discovery protocol.
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 a client
and a server. Servers 'register' service advertisements and other
pertinent information (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 set of processes that utilize a particular
protocol. Services range from printing to transferring a file to
providing on-line pizza order and delivery.
Hattig [Page 8]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
Service Advertisement Packet - An unsolicited packet issued by a
server or registry. The advertisement provides the service
identifier, service type, and possibly service characteristics.
Service Characteristics û Characteristics provide a finer
granularity of description by which 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 type.
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 everyday usage scenarios that lead to
requirements for zeroconf protocols. There is a subsection for
each of the four protocol areas. Within each protocol area
representative scenarios are discussed and requirements are
identified. Also, within each area is a summary of the
requirements and an IPv6 considerations section.
2.1 IP Host Configuration
IP Host configuration determines the appropriate values for an IP
interface's IP address, netmask, and default route. Then the host
must operate with those values. The scenarios in this section are
ping, bridge install, and transitions between zeroconf IP host
configuration and DHCP.
2.1.1 Ping
Hattig [Page 9]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
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, 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. Here is representative C code:
((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 that a ping to a host on a local
IP subnet presents different requirements than a ping to a host on
a non-local IP subnet. The zeroconf IP host configuration MUST
allow ping to succeed in either case if it is possible within the
TCP/IP connectivity provided by a given network. The specific
protocol requirements follow:
Netmask requirements:
- All hosts on an IP subnet MUST have a common netmask.
IP address requirements:
- The result of (HostIPAddr & netmask) must be the same value for
all hosts on an IP subnet
- The result of (HostIPAddr & ~netmask) (inverse netmask) must be
unique for all hosts on an IP subnet
Default route requirements:
- A default route is not required for communication within the
local subnet.
- A default route is required for communication off the local
subnet.
Note that by definition, IP subnet numbers must be unique within
an internet, thus no address duplication between hosts on
different subnets can exist. Managing IP subnet numbers is not the
function of an IP host configuration protocol; it is the function
of a router or another entity aware of an entire internet.
Zeroconf IP Host configuration does not include configuration of
routers; however, zeroconf IP host configuration MAY utilize a
configured router to retrieve the default route or the netmask.
Hosts could subsequently determine the IP subnet number with the
netmask.
Hattig [Page 10]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
Note that a ping from a host using a private address (as defined
in RFC 1918) to a globally unique IP address on the Internet does
not add additional requirements to the zeroconf IP host
configuration protocol. Instead, it places additional requirements
on the specialized router that sits between the internet using the
private address space and the global Internet. The requirements of
this specialized router are outside the scope of this document.
2.1.2 Bridge Installed
This scenario starts with two completely operational standalone
networks. After initial IP host configuration with zeroconf
protocols, these two networks become one when a bridge gets
installed between them.
Two problems arise. The first is that hosts now may have duplicate
IP addresses. Note, that this is not considered a major problem
because the occurrence of duplicate addresses can be made
statically improbably if the netmask is the same for all networks
and allows for a large number of hosts (e.g. netmask of
255.255.0.0).
Another problem is that the hosts on the two networks are not
using the same netmask or that all hosts do not have the same
result of (HostIPAddr & netmask) operation as was shown to be a
requirement for ping. Note this assumes that a network with
multiple IP subnets operating over a single layer-2 network is not
desirable.
These problems create unique requirements for the bridge install
scenario. Specifically, the zeroconf IP host configuration
protocol MUST provide hosts with the ability to detect duplicate
IP addresses even after initial configuration. Once detected, one
of the hosts must choose a new IP address and ensure that the new
IP address is unique. In addition, the protocol MUST consolidate
two IP subnets into a single IP subnet.
2.1.3 Zeroconf and non-Zeroconf Transitions
DHCP is the non-zeroconf IP host configuration protocol. Hosts
MUST be able to transition between DHCP and the zeroconf IP host
configuration protocol by detecting the presences or absence of a
DHCP server. Barring any new DHCP option, the most likely
mechanism is a DHCP discovery message.
If DHCP is detected while using zeroconf IP host configuration,
the host must start utilizing DHCP. If DHCP is no longer detected
while using DHCP, the host must start utilizing the zeroconf IP
host configuration protocol.
Hattig [Page 11]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
2.1.4 Requirements Summary
Zeroconf IP host configuration protocol requirements are:
- The protocol MUST allow all hosts on an IP subnet to have a
common netmask.
- The protocol MUST allow all hosts on an IP subnet to choose an
IP address such that the result of the (HostIPAddr & netmask)
operation is the same value for all hosts on an IP subnet.
- The protocol MUST allow all hosts on an IP subnet to choose an
IP address such that the result of the (HostIPAddr & ~netmask)
operation (inverse netmask) is unique among all hosts on an IP
subnet.
- The protocol MUST allow hosts to operate without choosing a
default route to communicate with other hosts on their local
subnet.
- The protocol MUST allow hosts to choose a default route if it is
available.
- The protocol MUST allow the host to defend the address it
chooses.
- The protocol MUST provide hosts the ability to detect duplicate
IP addresses after initial configuration.
- The protocol MUST be able to consolidate two IP subnets into a
single IP subnet.
- The protocol MUST allow a host to detect that DHCP is and is not
in use.
- The protocol MUST allow a host to transition from the zeroconf
protocol to DHCP if DHCP is detected while using zeroconf IP
host configuration.
- The protocol MUST allow a host to transition from DHCP to the
zeroconf protocol if while using DHCP the DHCP server is no
longer detected.
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
Domain name to IP address resolution consists of a host making a
query that contains a host name, and then the response to the
query contains the IP address to complete the resolution.
The zeroconf problem with DNS is that the host must be configured
with the IP address of a DNS server. This allows the host to send
a unicast DNS request to a DNS server, then its simplest form, the
DNS server responds with the IP address.
Hattig [Page 12]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
The zeroconf goal for domain name to IP address resolution is to
remove the need for the host to configure the IP address of a DNS
server.
The first scenarios are to resolve a name of a host that resides
within the zeroconf domain and then to resolve a name that resides
outside the zeroconf domain.
Another scenario below is a host determining its name and default
domain. Once a name is selected, the host must ensure the name is
unique within its default domain. This is an ancillary issue for
domain name to IP address resolution that will most likely result
in a protocol that is independent from protocols that resolve
domain names to IP addresses.
The final scenarios are transitions between using DNS and the
zeroconf domain name to IP address resolution protocol.
2.2.1 Name Resolution
The zeroconf domain name to IP address resolution protocol MUST
resolve a name to an IP address without a host being configured
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.
2.2.2 Name and default domain selection
A name selection protocol is necessary so that all host within a
domain have unique names. Once a host chooses a name, it MUST then
determine if the name is in use. If the host requires a unique
name, the host selects a different name and again determines if
the name is unique. This process continues until the host has a
name that is unique within a domain.
A host MUST determine its default domain and the default domain
MUST be the same for all hosts within the domain.
The zeroconf name resolution protocol must become active
periodically to check the validity of name. One example of when
this is necessary is when previously disconnected yet operational
networks now become connected by the installation of a router or a
bridge.
2.2.3 Zeroconf and non-Zeroconf Transitions
DNS is the non-zeroconf domain name to IP address resolution
protocol. There are four transitional cases to consider.
Hattig [Page 13]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
The first is a zeroconf to non-zeroconf transition that occurs
when the host is first configured with the IP address of the DNS
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 zeroconf protocol MUST operate when a host is not configured
to use a DNS server.
- If configured to use DNS the host MUST be able to detect the
presence and the absence of a DNS server.
- If the DNS server becomes absent after configuration, the host
MUST use the zeroconf protocol.
- If the DNS server becomes present after being absent, the host
MUST use DNS.
2.2.4 Requirements Summary
Zeroconf Domain name to IP address protocol requirements are:
- The protocol MUST resolve a name to an IP address without a host
being configured 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 protocol MUST allow the host to defend the name it chooses.
- The protocol MUST operate when a host is not configured to use a
DNS server.
- If configured to use DNS the host MUST be able to detect the
presence and the absence of a DNS server.
- If the DNS server becomes absent after configuration, the host
MUST use the zeroconf protocol.
- If the DNS server becomes present after being absent, the host
MUST use DNS.
Zeroconf name selection protocol requirements are:
Hattig [Page 14]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
- Processing within a host is responsible for choosing a host
name. This includes selecting the initial name as well as
selecting subsequent names if a name proves to be a duplicate.
- The protocol MUST allow the host to determine if the name is in
use by another host within the default domain. At various times
a host MUST actively determine if another host is using its
name.
- The protocol MUST remain within the domain of the hosts using
the protocol.
- The protocol MUST allow hosts to create or determine the
existence of a default domain.
- The protocol MUST ensure all hosts operating within a domain use
the same default domain.
2.2.5 IPv6 Considerations
Domain name to IP address resolution protocols as well as name and
default domain selection have no zeroconf related differences for
IPv4 and IPv6.
2.3 IP Multicast Address Allocation Scenarios
IP multicast is used to conserve bandwidth and reduce complexity
in the source. Bandwidth is conserved because a sender only sends
a single packet, then a large number of receivers receive that
packet. The unicast alternative requires the source to send
individual packets to each destination; this consumes more
bandwidth. In addition, unicasting increases the complexity of the
source because the source must maintain a list of the individual
destinations.
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 requirement 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] also require the ability to enumerate what scopes the host
Hattig [Page 15]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
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:
- A host MUST be able to obtain the set of scope names, for all
scopes it is within.
- A host MUST be able to obtain the set of address ranges for all
scopes it is within.
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
Hattig [Page 16]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
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:
- A host that wishes to allocate a multicast address with a given
scope and lifetime MUST select an address.
- A host MUST determine if the address has been allocated by
another host.
- A host MUST participate to defend the addresses it allocates.
- At various times a host MUST actively determine if another host
has allocated an address it has allocated.
- Routers MUST route this protocol 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:
- When more than one source uses an IP multicast address, the last
host acting as a source for the IP multicast address MUST
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.
Hattig [Page 17]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
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.
2.3.6 Requirements Summary
Zeroconf IP multicast address allocation protocol requirements
are:
- A host that wishes to allocate a multicast address with a given
scope and lifetime MUST select an address.
- A host MUST determine if the address has been allocated by
another host.
- A host MUST participate to defend the addresses it allocates.
- At various times a host MUST actively determine if another host
has allocated an address it has allocated.
- Routers MUST route this protocol to ensure it spans the entire
locally scoped internet.
- The protocol MUST allow the last source that uses a multicast
address to deallocate the multicast address regardless of which
node allocated the address.
- 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.
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
[MODIFY MODIFY MODIFY ] As stated earlier, there is not really a
non-zeroconf service discovery protocol; instead, the service
discovery protocol must scale to larger networks. For this reason
there are no transitional scenarios related to service discovery.
The scenarios are the discovery of a simple printer service and
the discovery of a printer manager that consolidates many printer
services.
Hattig [Page 18]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
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.
Discovery MUST be possible by either the client actively
soliciting the server or by the server 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.
Printers vary in their characteristics such as location, status,
dots per inch, drivers, etc. Discovering these characteristics
MUST 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
discover by characteristic. However, characteristic discovery MUST
be part of the service discovery protocol for those services
without capability negotiation.
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.
A discovery protocol itself MUST NOT require configuration. Note
that configuration of the service discovery protocol is not to be
confused with the configuration of the client or server protocol
which places no requirements on the service discover protocol.
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
Hattig [Page 19]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
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.
2.4.3 Requirements Summary
Zeroconf service discovery protocol requirements are:
- The protocol MUST allow a client to discover the service by a
service type, service identifier, and service characteristics.
- The protocol MUST support solicitations and advertisements.
- The protocol MUST be independent from any particular service.
- The protocol MUST allow timely discovery of a service.
- The protocol MUST allow clients to rediscover a service.
- The protocol MUST NOT require user configuration.
- The protocol MUST allow for registry.
- The protocol MUST allow the client and server sides of the
protocol to interact identically with and without a registry.
- The protocol MUST include optional mechanisms to update a
registry.
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
Hattig [Page 20]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
addition, this section describes four 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.
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' which could be verified before being accepted.
The security configuration would have to provide the server
portion of the protocol with the data needed to produce a
'signature' which could only be produced if in possession of the
configuration data.
Hattig [Page 21]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
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
service discovery protocol infrastructure it uses to discover
services are 'legitimate.'
3.5 IPv6 Considerations
[TBD]
4 IANA Considerations
There are no known IANA considerations arising from this document.
5 Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
Hattig [Page 22]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
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 for hosting the first BOF that was the
catalyst to forming the Zeroconf Working Group.
Thanks to Erik Guttman and Stuart Cheshire for forming and
chairing the Zeroconf Working Group, which is responsible for this
document.
Thanks to Erik Guttman for providing 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
Hattig [Page 23]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
2111 NE 25th Ave. JF3 206
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 1458] R. Braudes, Requirements for Multicast Protocols, RFC
1458, May 1993
[RFC 1918] D. Karrenberg, et al, Address Allocation for Private
Internets, RFC 1918, Feb 1996
[RFC 2026] S. Bradner, The Internet Standards Process --
Revision 3, RFC 2026 Oct 1996
[RFC 2119] S. Bradner. Key words for use in RFCs to Indicate
Requirement Levels. RFC 2119, March 1997.
[RFC 2131] R. Droms. Dynamic Host Configuration Protocol. RFC
2131, March 1997.
[RFC 2132] S. Alexander, R. Droms DHCP Options and BOOTP Vendor
Extension RFC 2132, March 1997.
[RFC 2316] S. Bellovin, Report of the IAB Security Architecture
Workshop, RFC 2316, April 1998
[RFC 2365] D. Meyer Administratively Scoped Multicast Address
RFC 2365,July 1998.
[RFC 2401] S. Kent, Security Architecture for the Internet
Protocol, RFC 2401, Nov 1998
Hattig [Page 24]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
[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
[AutoNet] R. Troll Automatically Choosing an IP Address in an
Ad-Hoc IPv4 Network draft-ietf-dhc-ipv4-autoconfig-
04.txt April, 1999. A work in progress.
[MCAST DNS] B. Woodcock, B. Manning Multicast Discovery of DNS
Services draft-manning-multicast-dns-01.txt
December, 1998. A work in progress.
[MiniDHCP] Bernard Aboba, Auto-Addressing in Multi-segment
Networks, draft-aboba-zeroconf-multi-00.txt, Oct
1999. A work in progress.
[SSDP] Y. Goland et al, Simple Service Discovery Protocol,
draft-cai-ssdp-v1-02.txt, June 1999, A work in
progress.
[IPv6 WG] IP Next Generation WG,
www.ietf.org/html.charters/ipngwg-charter.html.
[DHC WG] Dynamic Host Configuration WG,
www.ietf.org/html.charters/dhc-charter.html.
Hattig [Page 25]
Internet Draft draft-ietf-zeroconf-reqts-03.txt Mar 2000
[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 26]
