ZeroConf WG M. Hattig
Internet Engineering Task Force Editor
INTERNET DRAFT Intel Corp.
Expires April 2000 October 21, 1999
ZeroConf Requirements
draft-ietf-zeroconf-reqts-00.txt
Status of This Memo
This document is a submission by the ZeroConf Working Group of
the Internet Engineering Task Force (IETF). Comments should be
submitted to the zeroconf@merit.edu mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of [RFC 2026]. Internet-Drafts
are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
Zero Configuration (ZeroConf) Networks are a particular class of
TCP/IP networks that may be established in the home, in small
offices or even on an impromptu basis. ZeroConf Networks do not
have and should not be expected to have user configurable network
infrastructure such as DHCP servers, DNS and other administered
services. This is because typical ZeroConf network users neither
have the skill nor desire to configure, administer, or manage a
network.
This document presents ZeroConf protocol requirements for four
areas: IP host configuration, domain name to IP address
resolution, IP multicast address allocation, and service
discovery. Security issues overlay each area. ZeroConf protocols
in each these areas must transition easily to and from
administered protocols.
Hattig [Page 1]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
Table of Contents
1 Overview....................................................2
2 Introduction................................................3
2.1 Areas of work.............................................3
2.2 Reading This Document.....................................4
2.3 General Considerations....................................5
3 ZeroConf Network Architecture...............................6
3.1 Topologies................................................6
3.2 ZeroConf and non-ZeroConf Protocols......................12
3.3 Assumptions and Restrictions.............................13
4 Scenarios..................................................14
4.1 Single IP Network Host Configuration.....................14
4.2 Multiple IP Network Host Configuration...................15
4.3 Bridge Install between already operational IP Hosts......16
4.4 Router Install between already operational IP Hosts......16
4.5 IP Host Configuration with DHCP server...................17
4.6 Domain Name Resolution within an IP network..............18
4.7 IP Multicast Address Allocation..........................18
4.8 Service Discovery........................................19
4.9 Additional Potential Scenarios...........................20
5 Security Requirements......................................21
5.1 IP Host Configuration....................................21
5.2 Domain name to IP address resolution.....................21
5.3 Multicast Address allocation.............................21
5.4 Service Discovery........................................22
6 Additional Considerations..................................22
6.1 IANA Considerations......................................22
6.2 Internationalization Considerations......................22
6.3 Is service discovery conclusive?.........................22
6.4 Security Considerations..................................22
7 Full Copyright Statement...................................22
8 Editor.....................................................23
9 References.................................................23
1 Overview
Zero Configuration (ZeroConf) Networks are a particular class of
TCP/IP networks. These networks may be established in a home, in
a small office or even on an impromptu basis. ZeroConf networks
typically do not have and should not be expected to have user
configurable network infrastructure such as DHCP servers, DNS and
other administered services. This is because typical ZeroConf
network users neither have the skill nor desire to configure,
administer, or manage a network.
This document presents ZeroConf protocol requirements for four
areas: IP host configuration, domain name to IP address
resolution, IP multicast address allocation, and service
Hattig [Page 2]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
discovery. Security issues overlay each area. ZeroConf protocols
in each these areas must transition easily to and from
administered protocols.
This ZeroConf requirements document is a companion to a ZeroConf
profile document. This requirements document lists requirements
for protocols. The profile document relates the protocol
requirements to actual protocols. In some cases, a protocol may
meet all requirements to become the required protocol for
ZeroConf networks. When protocols are insufficient or multiple
protocols are competing, the profile document states the
requirements of the protocol and the relationship of the
requirements to the existing protocols.
In addition, the profile document shows how ZeroConf protocols
transition between operating in a ZeroConf network and operating
in a Non-ZeroConf network. Such transitions may be heavily
influenced by connectivity of the ZeroConf network to a non-
ZeroConf network such as the global Internet.
The major sections to this requirements document are the
Introduction, ZeroConf Network Architecture, Scenarios, and
Security sections. Since this document deals with so many aspects
of TCP/IP networking (i.e. service discovery to IP host
configuration), the introduction lists the necessary background
information and provides ideas for readers who wish to focus on
specific topics. The ZeroConf Network Architecture defines the
network assumed throughout this document. The scenarios clarify
the scope covered by the document and motivate particular
requirements of ZeroConf protocols.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in [RFC 2119].
2 Introduction
This introduction specifically defines the term "Area", presents
how to best read this document (including references), and
presents general considerations for implementers of ZeroConf
protocols.
2.1 Areas of work
Throughout this document, when the word Area is capitalized, the
word is referring the four Areas of protocol work in which this
document focuses. These protocol Areas are:
- IP host configuration
- Domain name to IP address resolution
Hattig [Page 3]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
- IP multicast address
- Service discovery
2.2 Reading This Document
This document deals with a wide range of networking topics. All
readers may not be interested in all Areas. To help the reader
focus on particular interests, this section describes the
organization of the document, the background information for each
Area, and explains different types of requirements.
2.2.1 Organization
The first major section of this document defines the ZeroConf
Network Architecture assumed throughout this document and assumed
throughout the profile document.
The Scenarios Section scopes the overall ZeroConf problem space
to provide the framework for requirements of protocols. This
section identifies some but not all requirements of protocols.
This section mentions very little about specific protocols. There
is a common outline for each scenario.
The Security section lists security issues and requirements to
prevent security problems.
2.2.2 Background information
This section lists the background reference information for
general knowledge, IP host configuration, domain name to IP
address resolution, IP multicast address allocation, service
discovery, and security. All readers should be familiar with at
least the general knowledge references before reading this
document.
All readers should be familiar with the following documents:
- [STD3] RFC 1122 Requirements for Internet Hosts - Comm Layers
- [STD4] RFC 1123 Requirements for Internet Hosts - App Layers
- [RFC 1458] RFC 1458 Requirements for Multicast Protocols
- [RFC 1812] RFC 1812 Requirements for Internet Gateways
IP host configuration:
- [IPv4Auto] Ipv4 Auto-Configuration ID
- [RFC 1918] RFC 1918 Private Addresses
- [RFC 2131] RFC 2131 DHCP
- [RFC 2132] RFC 2132 DHCP Options
- [RFC 2462] IPv6 Auto-Configuration
- [RFC 2461] IPv6 Neighbor Discovery
- [IPv6 WG] Next Generation (Ipv6) WG
- [DHC WG] Dynamic Host Configuration WG
Hattig [Page 4]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
Domain name to IP address resolution:
- [Mcast DNS] Multicast DNS
- [RFC 1034] RFC 1034 DNS
- [DNS WG] DNS Update WG
Multicast address allocation:
- [MADCAP] Multicast Address Dynamic Client Alloc Protocol ID
- [RFC 2365] RFC 2365, Administratively Scoped Multicast Address
- [MALLOC WG] Multicast Address Allocation WG
Service discovery:
- [SSDP] Simple Service Discovery Protocol ID
- [RFC 2608] RFC 2608 Service Location Protcol v2
- [RFC 2609] RFC 2609 SLP Schemes
Security background information is:
- [RFC 2316] RFC 2316, IAB Security Architecture Workshop
- [RFC 2401] RFC 2401, Security Architecture for IP
- [RFC 2411] RFC 2411, IP Security Document Roadmap
- [RFC 2504] RFC 2504, User's Security Handbook
2.2.3 Requirements
This document identifies scenarios that drive the requirements
for protocols. The requirements for protocols then help identify
specific protocols. The ZeroConf profile document discusses
specific protocols; this ZeroConf requirements document only
discusses the requirements for those specific protocols.
Requirements for protocols may have device specific aspects. For
example, a router may automatically forward IP packets with a
particular UDP port number between IP networks to make sure
client requests reach a server on another IP network. To provide
the proper device context, device descriptions are given along
with particular device requirements when appropriate.
2.3 General Considerations
These considerations are for vendors of ZeroConf networking
software.
2.3.1 Continuing ZeroConfig Network Evolution
ZeroConf networks are in their infancy. Many people speculate
about which link layer technologies will be the most important,
which devices will be most widely deployed, which applications
will be the "killer", etc. etc. Because of this broad speculation
and unpredictability the ZeroConf WG has limited the complexity
Hattig [Page 5]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
of the networks it will consider. For example, at most a single
router is considered in a ZeroConf network.
These limitations are a practical matter to allow the WG to make
progress. Without such limitations, the load of speculation would
prevent the working group from addressing even simple matters.
Vendors should be aware of these limitations and implement in a
flexible way to allow their implementations to someday go beyond
the restrictions imposed by the ZeroConf WG.
2.3.2 Configuration, Administration, and Management
Ideally, user configuration, administration, and management do
not occur in a ZeroConf network; this is the primary goal of the
ZeroConf WG. In other words, ZeroConf networks should be self-
healing and self-correcting. Despite this, there may be cases
where minimal user intervention is necessary; the key word in
this sentence is "minimal".
2.3.3 Error Log Messages
A goal of the ZeroConf requirements is to automate basic
functions to the extent that they will be transparent to the
user. This will minimize the requirement for the user to either
enter information or be presented with and interpret error
conditions. It is quite likely, however, that error logging, and
network management may be implemented on hosts supporting
ZeroConf protocols. Further discussion of network management and
operational issues is beyond the scope of this requirements
document.
3 ZeroConf Network Architecture
This section describes network topologies considered by this
document and states assumptions about the operation of protocols
in the ZeroConf Network.
3.1 Topologies
ZeroConf networks follow the Internet Model as described in STD4.
Specifically, ZeroConf networks consist of bridges, routers
(gateways), hosts, link layer networks, and IP networks to form
internets.
Here is a summary of the terms in [RFC 1812] that apply to the
ZeroConf Network Architecture:
- Bridges route link layer packets (e.g. Ethernet packets)
between link layer networks (e.g. Ethernet) based on the
Hattig [Page 6]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
destination link layer addresses (e.g. 48-bit Ethernet address)
of a packet.
- Routers (a.k.a. gateways) route IP packets between IP networks
based on the destination IP address of a packet.
- An IP network consists of hosts with interfaces that share the
same network portion of the IP address. A single IP network may
physically consist of several link layer networks connected by
a bridge, but it is one logical IP network; the hosts remain
unaware of the bridge or multiple link layer networks.
- An internet consists of multiple IP networks connected by
routers.
- Autonomous Systems (AS) are internets with a single operational
and management organization (a.k.a. administrator), and a
common set of routing protocols among the routers.
A ZeroConf network is a single Autonomous System (AS). This
simple statement implies many things. For example, service
discovery queries, IP multicast packets, and other IP packets
must stay within a single autonomous system. Also, such packets
must not enter autonomous system; this avoids security problems.
For the rest of this document, the term ZeroConf Network equates
to a network within a single autonomous system and all that that
implies.
RFC 1812 defines different types of routers (e.g. transparent,
embedded). The ZeroConf Network Architecture has two different
types of routers. Both types of routers pass packets between IP
networks based on destination IP address (as one would expect).
The primary difference is that one of these routers resides at
the border between the ZeroConf and the Non-ZeroConf network;
thus this router must impose the restrictions necessary for the
ZeroConf network to remain a single autonomous system. This
router is called a "gateway" throughout the rest of this
document.
The second type of router routes between IP networks within the
ZeroConf Network. Thus, this router has no responsibilities
related to restricting the communication between ZeroConf and
Non-ZeroConf Networks. This device is simply called a "router"
throughout the rest of this document.
The ZeroConf Network Architecture is limited to at most one
router and/or at most one gateway. Zero routers and/or zero
gateways are also part of the ZeroConf Network Architecture.
Hattig [Page 7]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
Figures 1 and 2 show the simplest of ZeroConf networks considered
by this document. Enabling these types of simple TCP/IP networks
is among the primary motivations for this document.
*****************************************************
* ZeroConf Network *
* *
* -------crossover-cable-------- *
* | | *
* | | *
* +------+ +------+ *
* | Host | | Host | *
* +------+ +------+ *
* *
*****************************************************
Figure 1. Two hosts connected with a crossover cable.
This ZeroConf network has two hosts connected through a crossover
cable. A crossover cable between two hosts is the most common
impromptu ZeroConf network.
*****************************************************
* ZeroConf Network *
* *
* -------[ HUB ]------- *
* | | | *
* | | | *
* +------+ +------+ +------+ *
* | Host | | Host | | Host | *
* +------+ +------+ +------+ *
* *
*****************************************************
Figure 2. Three hosts connected with a network with hub
This ZeroConf network has a small number of hosts connected
through a hub. A hub between hosts is the most common fixed-
location ZeroConf network. This is the canonical ZeroConf
network.
Hattig [Page 8]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
Figure 3, Figure 4, and Figure 5 are examples of ZeroConf
Networks that highlight the difference between a router and a
gateway. Figure 5 is an example of a network not considered by
this document. All these figures include connectivity to non-
ZeroConf Network. Examples of a non-ZeroConf network are the
global Internet and a corporate LAN.
***************************
* *
* Non-ZeroConf Network *
* *
***************************
|
|
|
+----------------+
**********************| Gateway |*************************
* ZeroConf Network +----------------+ *
* | *
* | *
* | +--------+ *
* --------------------------------| Bridge |--------------- *
* | | | +--------+ | | *
* | | | | | *
* | | | | | *
* +------+ +------+ +------+ +------+ +------+ *
* | Host | | Host | | Host | | Host | | Host | *
* +------+ +------+ +------+ +------+ +------+ *
* *
*****************************************************************
Figure 3. Single Gateway and Single IP Network.
Figure 3 shows a single gateway and single IP network in the
ZeroConf Network. The gateway routes packets between the ZeroConf
Network and the Non-ZeroConf Network. The single IP network
consists of multiple link layer networks connected by a bridge.
Hattig [Page 9]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
***************************
* *
* Non-ZeroConf Network *
* *
***************************
|
|
|
+----------------+
**********************| Gateway/Bridge |*************************
* ZeroConf Network +----------------+ *
* | | *
* | | *
* +--------+ | | *
* -----------| Router |---| |-------------------- *
* | | +--------+ | | | *
* | | | | | *
* | | | | | *
* +------+ +------+ +------+ +------+ +------+ *
* | Host | | Host | | Host | | Host | | Host | *
* +------+ +------+ +------+ +------+ +------+ *
* *
*****************************************************************
Figure 4. Single Gateway, Single Router, and Two IP Networks.
Figure 4 shows a ZeroConf Network with a single gateway, a single
router, and two IP networks. The gateway/bridge device is a
gateway and a bridge. The bridge portion routes layer 2 packets
between the two link layer networks attached to the gateway
(within the ZeroConf network); these two link layers represent a
single IP network. The router routes IP packets between the two
IP networks within the ZeroConf Network.
Hattig [Page 10]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
***************************
* *
* Non-ZeroConf Network *
* *
***************************
|
|
|
+----------------+
**********************| Gateway/Router |*************************
* ZeroConf Network +----------------+ *
* | | | *
* | | | *
* | | | *
* ------------------| | |---------------------- *
* | | | | | *
* | | | | | *
* | | | | | *
* +------+ +------+ +------+ +------+ +------+ *
* | Host | | Host | | Host | | Host | | Host | *
* +------+ +------+ +------+ +------+ +------+ *
* *
*****************************************************************
Figure 5. Single Gateway, Single Router, and Three IP Networks.
Figure 5 shows a ZeroConf Network with a single gateway, a single
router, and three IP networks. The gateway/router device is a
gateway and a router. The router portion routes IP packets
between the three IP networks within the ZeroConf Network. The
gateway portion routes IP packets between the ZeroConf Network
and the non-ZeroConf Network. In ZeroConf Networks, routers route
within the ZeroConf; gateways route between a ZeroConf and a non-
ZeroConf (which are different autonomous systems); this is the
distinction between a router and a gateway.
Hattig [Page 11]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
***************************
* *
* Non-ZeroConf Network *
* *
***************************
|
|
|
+----------------+
**********************| Gateway/Router |*************************
* ZeroConf Network +----------------+ *
* | | *
* | | *
* +---------+ | | *
* -----------| Router |---| |------------------- *
* | | +---------+ | | | *
* | | | | | *
* | | | | | *
* +------+ +------+ +------+ ------+ +------+ *
* | Host | | Host | | Host | | Host | | Host | *
* +------+ +------+ +------+ +------+ +------+ *
* *
*****************************************************************
Figure 6. Single Gateway, Two Routers, and Three IP Networks.
Figure 6. shows a network that is NOT considered by this document
because two routers are present. The gateway/router device
includes a gateway and a router as in Figure 5. In addition,
there is a second router in the network. Multiple routers within
a single autonomous system create requirements beyond the scope
of the document. Such requirements are coordination between
routers and auto-configuration of routers.
There are no additional topological restrictions on the ZeroConf
Network Architecture. That is, there are no restrictions on the
number of hosts, number of host names, or the number of services.
3.2 ZeroConf and non-ZeroConf Protocols
In this document the term ZeroConf is overloaded. In addition to
ZeroConf (and non-ZeroConf) Networks, this document uses the
terms ZeroConf protocols and non-ZeroConf protocols. ZeroConf
Network is a concept, not really a physical entity. The concept
is that at some point in time one or more protocols within a
network are ZeroConf protocols. In addition, non-ZeroConf
protocols may coexist in this network with ZeroConf protocols.
That is, not ALL protocols in a ZeroConf Network are ZeroConf
protocols.
Hattig [Page 12]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
To illustrate this point, suppose there are standard protocols to
support ZeroConf requirements for IP host configuration and
domain name to IP address resolution.
For IP host configuration, the ZeroConf protocol is
'protocol-h.' The non-ZeroConf protocol is DHCP, supported by a
fully conformant DHCP server.
For domain name to IP address resolution, the protocol is
'protocol-d.' The non-Zeroconf protocol is DNS supported by a
fully conformant DNS server.
In a ZeroConf Network, both ZeroConf and non-ZeroConf protocols
may exist in separate Areas. For example, protocol-h may exist
with DNS (and a DNS server).
However, within a single Area only a ZeroConf or non-ZeroConf
protocol is used at a given point in time. Preference is always
given to the non-ZeroConf protocol if it is present. For example,
a DNS server implemented on a PC in the den is only available
when the PC is powered-up; hosts must detect when the DNS server
is present then use it; otherwise, they must use protocol-d.
The strict definition of a ZeroConf Network is a network that at
some point in time has one or more ZeroConf protocols.
3.3 Assumptions and Restrictions
The architectural assumptions and restrictions for the ZeroConf
Network Architecture are bounded by ZeroConf topologies and by
the protocols (ZeroConf and non-ZeroConf) that operate within the
ZeroConf Network.
Topological assumptions and restrictions are:
- No more than a single router exists in the ZeroConf network;
zero routers are acceptable but two routers are not.
- No more than a single gateway exists in the ZeroConf network;
zero gateways are acceptable but two gateways are not.
- No restrictions on the number of hosts or the number services
exist.
- A gateway prevents ZeroConf protocols from leaving the ZeroConf
network.
- A gateway prevents ZeroConf protocols from entering the
ZeroConf Network from a non-ZeroConf Network.
- A router must route ZeroConf protocols if the protocol is
required to span the entire ZeroConf network.
- A bridge connects similar link layer networks (e.g. HomePNA,
IEEE 802.11, HomeRF are similar because they are Ethernet-like)
- A router connects dissimilar link layer networks. (e.g. IEEE
1394-1995 is dissimilar from Ethernet)
Hattig [Page 13]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
- A gateway device includes a router or a bridge when necessary
and feasible. However, this may not be feasible for some
networking link layers that cannot span the entire distance
between the gateway and link layer specific hosts (e.g. ADSL
gateway in a den and IEEE 1394-1995 MP3 Player in a family
room).
Protocol assumptions within each Area of work are:
- A ZeroConf protocol exists.
- A non-ZeroConf protocol exists.
- A ZeroConf protocol transitions to non-ZeroConf protocol on a
well-defined trigger.
- A Non-ZeroConf protocol transitions to ZeroConf protocol on a
well-defined trigger.
- ZeroConf protocols re-initialize themselves on a well-defined
trigger.
4 Scenarios
This section lists ZeroConf scenarios. This section does not
discuss specific protocols. Instead this section lists scenarios
that provide a framework to produce requirements for protocols.
Each scenario begins with an explanation or overview of the
scenario. Then, the key points of the scenario are identified.
These key points help identify the most likely Area of work
related to the scenario. To consistently provide this
information, each scenario has the following outline:
- Overview
- Key Points
- Protocol Requirements
Temporary Note: These scenarios have not been agreed upon by the
ZeroConf WG, thus they will likely change. For this reason, only
the limited information is provided for each scenario in the
current draft.
4.1 Single IP Network Host Configuration
4.1.1 Overview
Hosts on a single IP network within the ZeroConf network
communicate to each other. To do this, hosts must configure their
IP address and net mask. This scenario is of utmost importance.
This scenario is most applicable to networks shown in Figures 1
and 2.
4.1.2 Key Points
Hattig [Page 14]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
This scenario deals with the Area of IP host configuration.
This scenario requires a unique host portion of the IP address
for each host. The network portion of the IP address must be the
same for each host.
4.1.3 Protocol Requirements
- Host numbers of IP addresses MUST be unique within a single IP
network.
- Network numbers of IP addresses MUST be equal within a single
IP network.
- IP addresses MUST be private and not globally routable such as
those listed in RFC 1918.
- IP address MAY be routable within the ZeroConf network, but
this is not required.
4.2 Multiple IP Network Host Configuration
4.2.1 Overview
This scenario does not include a DHCP server. Hosts on multiple
IP networks within a ZeroConf network communicate to each other.
To do this, hosts must configure their IP address, net mask, and
default route.
4.2.2 Key Points
This scenario deals with the Area of IP host configuration.
This scenario requires a unique host portion of the IP address
for each host on an IP network. The network number portion of an
IP address must be the same for each host on a single IP network.
The network number portion of the IP address must be the unique
within the ZeroConf network for each IP network. Each host must
be configured with a default route.
4.2.3 Protocol Requirements
- Host numbers of IP addresses MUST be unique within a single IP
network.
- Network numbers of IP addresses MUST be equal within a single
IP network.
- IP addresses MUST be private and not globally routable such as
those listed in RFC 1918.
- IP address MUST be routable within the ZeroConf network.
- IP network numbers MUST be unique within the entire ZeroConf
network.
- The host MUST configure a default route.
Hattig [Page 15]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
4.3 Bridge Install between already operational IP Hosts
4.3.1 Overview
This scenario does not include a DHCP server. Within a single IP
network, a bridge (or hub) is installed after IP hosts have been
configured to communicate on a single IP network. Two hosts on a
single IP network may now share the same IP address. In addition,
hosts on different link layer networks may not have been using
the same network number and now they must share the same network
number.
4.3.2 Key Points
This scenario deals with the Area of IP host configuration.
This is a special case of a previous scenario when IP hosts first
communicate on the same IP network. All the key points and
requirements to the previous scenario apply. In addition, host
must have the ability to re-configure their IP address and net
mask.
4.3.3 Protocol Requirements
- Hosts MUST re-configure IP address and net mask at various
times after initial configuration.
- All requirements in section 4.1.3.
4.4 Router Install between already operational IP Hosts
4.4.1 Overview
This scenario does not include a DHCP server. Within a ZeroConf
network, a router is installed after IP hosts have been
configured to communicate throughout the ZeroConf network.
Multiple IP networks within the ZeroConf network may now share
the same IP network number.
4.4.2 Key Points
This scenario deals with the Area of IP host configuration.
This is a special case of a previous scenario when hosts on a
multiple IP networks within a ZeroConf network communicate. All
the key points and requirements to the previous scenario apply.
In addition, host must have the ability to re-configure their IP
address, net mask, and default route.
4.4.3 Protocol Requirements
Hattig [Page 16]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
- Hosts MUST re-configure IP address, net mask, and default route
at various times after the initial configuration.
- All requirements in section 4.2.3.
4.5 IP Host Configuration with DHCP server
4.5.1 Overview
This scenario is for single IP network or multiple IP network
ZeroConf networks. Hosts communicate to each other. To do this,
hosts must get their IP address, net mask, and default route from
a DHCP server. There is only one DHCP server.
4.5.2 Key Points
This scenario deals with the Area of IP host configuration.
DHCP servers in ZeroConf networks do not require user
configuration. Servers allocate private addresses that are not
globally routable. However, the addresses must be routable
within the ZeroConf network. DHCP servers ensure a unique host
portion of the IP address for each host on an IP network. The
DHCP server ensures the network number portion of an IP address
is the same for each host on a single IP network. The DHCP
server must provide a default route to each host. All hosts must
implement a DHCP client. This places unique requirements on DHCP
servers as well as hosts.
If previously operation hosts achieve connectivity to the DHCP
server through the installation of a bridge or router, hosts must
somehow determine or learn about the presents of the DHCP server
and request the appropriate information from the DHCP server.
4.5.3 Protocol Requirements
- A DHCP server MUST be accessible by all hosts on the network.
- The DHCP server MUST require zero-configuration by a user.
- The DHCP server MUST only allocate private addresses that are
not globally routable such as those listed in RFC 1918.
- The DHCP server MUST ensure host numbers of IP addresses are
unique within a single IP network.
- The DHCP server MUST ensure network numbers of IP addresses are
equal within a single IP network.
- The DHCP server MAY ensure IP addresses are routable within the
ZeroConf network, but this is not required.
- All hosts MUST implement a DHCP client to retrieve their IP
address, net mask, and default route.
- Routers MUST implement DHCP rely agents.
Hattig [Page 17]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
4.6 Domain Name Resolution within an IP network
4.6.1 Overview
Domain names within the ZeroConf network must be resolved to IP
addresses. This enables one of the most basic of TCP/IP
networking paradigms of applications only being aware of host
names and not IP addresses.
4.6.2 Key Points
This scenario deals with the Area of domain name to IP address
resolution.
Name resolution must span the entire ZeroConf network, but be
limited by the gateway from leaving or entering the ZeroConf
network. This protocol should include the ability for a host to
choose a name, determine if the name is in use, and then choose a
different name if it is re-used.
The name resolution protocol must become active at various times
such as when previously disconnected yet operational networks now
become connected by the installation of a router or a bridge.
4.6.3 Protocol Requirements
- A host that wishes to be addressable by DNS name MUST select a
domain name.
- A host MUST determine if the domain name is in use by another
host.
- A host MUST participate to defend a name it uses.
- A host MUST be able to reconfigure its name in the case it was
unable to successfully defend the name it previously used.
- At various times a host MUST actively determine if another host
is using its name.
- Gateways MUST restrict this protocol from leaving or entering
the ZeroConf network.
- Routers MUST route this protocol to ensure it spans the entire
ZeroConf network.
4.7 IP Multicast Address Allocation
4.7.1 Overview
Numerous protocols have a need for dynamically allocated IP
multicast addresses. Traditionally these have been audio or video
streaming protocols; however, of late, data applications such as
stock quotes or hourly news are increasing sent encapsulated in
packets destined to IP multicast addresses.
Hattig [Page 18]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
4.7.2 Key Points
This scenario deals with the Area of domain name to IP address
resolution.
IP multicast address allocation protocol must be routed through
the entire ZeroConf network; however, the gateway limits this
protocol from leaving or entering the ZeroConf network. In
addition to limiting the multicast allocation protocol, the
gateway limits the packets that utilize the allocated IP
multicast addresses.
4.7.3 Protocol Requirements
- All hosts MUST allocate IP multicast address from the same
pool.
- The pool of IP multicast addresses MUST NOT be globally
accessible (e.g. Administratively scoped IP multicast addresses
in [RFC 2365])
- Routers MUST route packets destined to this pool of IP
multicast addresses.
- Gateways MUST limit packets destined to this pool of IP
multicast addresses from leaving or entering the ZeroConf
network.
- One and only one host MUST be identified as the owner of each
allocated IP multicast address.
- The owner MUST deallocate the IP multicast address whenever
possible.
- Allocated IP multicast addresses MUST automatically become
deallocated if owner stops operating.
- Ownership MUST be able to pass from one host to another, in the
case the original owner wishes to stop participation in the use
of the IP multicast address and another host wishes to continue
participation in the use of the IP multicast address.
4.8 Service Discovery
4.8.1 Overview
A key component to the ZeroConf network is service discovery
without user-configured servers. This requires a common
definition a service and common methods for clients (hosts
wanting a service) to find service-specific servers (hosts
providing a service). When multiple servers provide the same
service, hosts and/or people must be able to pick a preferred
server based on service specific attributes, connectivity,
physical location of the server, or other metrics.
For example, a small business may have a high quality color
printer, a printer that prints a high number of pages per second,
Hattig [Page 19]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
or a printer in a particular office. A person may want to print
to the color printer, print to the fast printer, or the closest
printer. Of course, many other metrics may exist.
4.8.2 Key Points
This scenario deals with the Area of service discovery.
A service must be identifiable and instrumentable.
Instrumentation allows attributes to be identified and utilized
by people or programs. Clients should be able to discover
services through passive advertisements by the servers and
through active queries by the client.
4.8.3 Protocol Requirements
- A service MUST be identifiable.
- A service MAY be instrumentable.
- Servers MAY have the ability to advertise service.
- Servers MAY have the ability to respond to client queries.
- Clients MAY have the ability to use service advertisements.
- Clients MAY have the ability to query for services.
- Clients and servers MAY have the ability present the
instrumentation of a service to people.
- Clients and servers MAY have the ability to programmatically
use instrumentation of a service.
4.9 Additional Potential Scenarios
- A ZeroConf host accessing the global Internet through the
gateway.
- Multiple ZeroConf hosts simultaneously accessing the Internet
through the gateway.
- ZeroConf host accessing a corporate LAN through the gateway and
a corporate firewall.
- Allow access from the Internet to a ZeroConf server (e.g.
household WEB server).
- Allow access from the Internet to multiple ZeroConf servers
(e.g. family WEB server and individual family-member WEB
server).
- Host connecting to another ZeroConf network through a non-
ZeroConf network and a gateway at the border of each ZeroConf
network.
- Browsing and human friendly identifiers (service type name,
internationalization, attributes)
- Device Identification & Discovery
- ZeroConf host interoperates with Ad Hoc host via MANET.
- Behavior upon receiving router advertisements
Hattig [Page 20]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
5 Security Requirements
The principal goal of security requirements for ZeroConf
networking is to not make IP networking less secure than it is
without the use of ZeroConf protocols. This is challenging since
ZeroConf provides the ability for any host to obtain host
configuration, to discover and to use network resources. In the
case where ZeroConf access media is physically accessible (e.g.
wireless, powerline) or routed to additional network segments,
there is no longer any physical security.
The following sections are security considerations for the four
Areas which this document addresses. The threats fall into three
broad categories:
Hoarding: Hosts claim all available resources, whether they plan
to use them or not. This is a form of denial of service attack.
Masquerading: Hosts can respond to requests that they should not
so they can masquerade as another host.
Antagonistic Server: A server could offer support for a critical
service but intentionally misconfigure hosts on the network.
[TO DO: Add security requirements after potential threats have
been identified and selected as requiring attention by the
ZEROCONF Working Group.]
5.1 IP Host Configuration
Potential threats include:
- A host could hoard IP addresses, denying others access to the
network.
- A host could pose as an antagonistic DHCP server and
misconfigure other hosts on the network.
5.2 Domain name to IP address resolution
Potential threats include:
- A host could masquerade, responding to names requests
illigitimately.
- A host could hoard names, responding to all 'claim' requests.
- A host could pose as an antagonistic DNS server and fail to
resolve names correctly, or intentionally resolve them
incorrectly.
5.3 Multicast Address allocation
Potential threats include:
Hattig [Page 21]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
- A host could hoard multicast addresses, denying others the
ability to obtain them.
5.4 Service Discovery
Potential threats include:
- Servers could masquerade by responding to service discovery
requests which they shouldn't respond to.
- A host could pose as an antagonistic service discovery
'infrastructure element.' Some service discovery protocols
offer a 'registry', 'directory', 'proxy' or other
infrastructure element for scalability.
6 Additional Considerations
6.1 IANA Considerations
There are no known IANA considerations arising from this
document.
6.2 Internationalization Considerations
ZeroConf protocols may exchange human readable strings. Human
readable strings may need to be internationalized.
6.3 Is service discovery conclusive?
When service discovery is successful, should the client be able
to use the service, or do we assume that it may not be able to.
In the former case service discovery finds only those services
that match the client's capabilities and requirements. In the
latter case the client may have to perform feature negotiation
with the service - the result of which may be that the client is
not able to use the service.
6.4 Security Considerations
ZeroConf security considerations are in Section 5 of this
document.
7 Full Copyright Statement
Copyright (C) The Internet Society (1997). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
Hattig [Page 22]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to
the Internet Society or other Internet organizations, except as
needed for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate
it into languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE."
8 Editor
Myron Hattig
Intel Corporation
2111 NE 25th Ave.
Hillsboro, OR 97124
myron.hattig@intel.com
9 References
[STD 3] R. Braden Requirements for Internet Hosts --
Communication Layers RFC 1122, STD 3, October 1989
[STD 4] R. Braden, Requirements for Internet Hosts --
Application and Support RFC 1123, STD 4 October 1989
[RFC 1034] P. Mockapetris, Domain Names - Concepts and
Facilities, RFC 1034, November 1987
[RFC 1458] R. Braudes, Requirements for Multicast Protocols,
RFC 1458, May 1993
[RFC 1918] D. Karrenberg, et al, Address Allocation for Private
Internets, RFC 1918, Feb 1996
[RFC 2026] S. Bradner, The Internet Standards Process --
Revision 3, RFC 2026 Oct 1996
[RFC 2119] S. Bradner. Key words for use in RFCs to Indicate
Requirement Levels. RFC 2119, March 1997.
Hattig [Page 23]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
[RFC 2131] R. Droms. Dynamic Host Configuration Protocol. RFC
2131, March 1997.
[RFC 2132] S. Alexander, R. Droms DHCP Options and BOOTP
Vendor Extension RFC 2132, March 1997.
[RFC 2316] S. Bellovin, Report of the IAB Security Architecture
Workshop, RFC 2316, April 1998
[RFC 2365] D. Meyer Administratively Scoped Multicast Address
RFC 2365,July 1998.
[RFC 2401] S. Kent, Security Architecture for the Internet
Protocol, RFC 2401, Nov 1998
[RFC 2411] R. Thayer, IP Security Document Roadmap, RFC 2411,
Nov 1998
[RFC 2461] T. Narten, E. Nordmark, W. Simpson Neighbor
Discovery for IP Version 6 (IPv6) RFC 2461,
December 1998.
[RFC 2462] S. Thomson, T. Narten IPv6 Address
Autoconfiguration RFC 2462, December 1998.
[RFC 2504] E. Guttman, Users' Security Handbook, RFC 2504, Feb.
1999
[RFC 2608] E. Guttman, C. Perkins, J. Veizades, and M. Day.
Service Location Protocol version 2. RFC 2608, June
1999.
[RFC 2609] E. Guttman, C. Perkins, J. Kempf Service Templates
and service: Schemes, RFC 2609, June 1999.
[IPv4Auto] R. Troll Automatically Choosing an IP Address in an
Ad-Hoc IPv4 Network draft-ietf-dhc-ipv4-autoconfig-
04.txt April, 1999. A work in progress.
[DisAuto] R. Troll, DHCP Option to Disable Stateless Auto-
Configuration in IPv4 Clients draft-ietf-
autoconfig-04.txt February, 1999. A work in
progress.
[MCAST DNS] B. Woodcock, B. Manning Multicast Discovery of DNS
Services draft-manning-multicast-dns-01.txt
December, 1998. A work in progress.
[MADCAP] iS. Hanna, B. Patel, M. Shah Multicast Address
Dynamic Client Allocation Protocol (MADCAP) draft-
Hattig [Page 24]
Internet Draft draft-ietf-zeroconf-reqts-00.txt Oct 1999
ietf-malloc-madcap-05.txt May 1999. A work in
progress.
[SSDP] Y. Goand et al, Simple Service Discovery Protocol,
draft-cai-ssdp-v1-02.txt, June 1999, A work in
progress.
[IPv6 WG] IP Next Generation WG,
www.ietf.org/html.charters/ipngwg-charter.html.
[DHC WG] Dynamic Host Configuration WG,
www.ietf.org/html.charters/dhc-charter.html.
[NAT WG] Network Address Translation WG,
www.ietf.org/html.charters/nat-charter.html.
[DNS WG] DNS Update WG, www.ietf.org/html.charters/dnsind-
charter.html
[MALLOC WG] Multicast Allocation WG Charter,
www.ietf.org/html.charters/malloc-charter.html.
Hattig [Page 25]
