ZeroConf WG M. Hattig
Internet Engineering Task Force Editor
INTERNET DRAFT Intel Corp.
Expires May 2000 November 24, 1999
ZeroConf Requirements
draft-ietf-zeroconf-reqts-01.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 and the transitions between a ZeroConf
protocol and a non-ZeroConf protocol are also discussed within the
context of these protocol requirements.
Hattig [Page 1]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
Table of Contents
1 Overview....................................................2
2 Introduction................................................3
2.1 Reading This Document.....................................3
2.2 ZeroConf Protocols........................................4
2.3 ZeroConf Networks.........................................7
3 Scenarios..................................................13
3.1 IP Host Configuration....................................13
3.2 Domain Name to IP Address Resolution.....................15
3.3 IP Multicast Address Allocation..........................16
3.4 Service Discovery........................................16
3.5 Additional Scenarios.....................................16
4 Security Requirements......................................17
4.1 IP Host Configuration....................................17
4.2 Domain name to IP address resolution.....................17
4.3 Multicast Address allocation.............................17
4.4 Service Discovery........................................18
5 Additional Considerations..................................18
5.1 IANA Considerations......................................18
5.2 Internationalization Considerations......................18
5.3 Security Considerations..................................18
6 Full Copyright Statement...................................18
7 Editor.....................................................19
8 References.................................................19
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
discovery. Security issues and the transitions between a ZeroConf
protocol and a non-ZeroConf protocol are also discussed within the
context of these protocol requirements.
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 one of the required protocols for
ZeroConf networks. When protocols are insufficient or multiple
Hattig [Page 2]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
protocols are competing, the profile document states the
requirements of the protocol and the relationship of the
requirements to the existing protocols.
The major sections to this requirements document are the
Introduction, Scenarios, and Security. The introduction provides
the background information to have a meaningful scenarios
discussion. The scenarios describe a set of actions then the
requirements from protocols to satisfy those actions. The
security section re-examines the scenarios with security
considerations.
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 presents how to best read this document and
provides the restrictions, definitions and assumptions for the
remainder of the document.
2.1 Reading This Document
The major sections of the document are this Introduction,
Scenarios, and Security.
This Introduction provides the necessary information to have a
concise scenario discussions. This includes reference information,
definitions, restriction, and assumptions. All readers should read
the entire introduction.
The Scenarios Section lists specific scenarios. Each scenario
results in protocol requirements. Scenarios are chosen to generate
unique requirements. Each scenario has an overview, key points,
and protocol requirements.
The Security section lists security issues and requirements that
relate to the scenarios.
Because this document deals with a wide range of networking
topics, many sections are divided by topic. The division allows
readers focus on particular interests. The topics are:
- IP host configuration,
- domain name to IP address resolution,
- IP multicast address allocation, and
- service discovery.
Hattig [Page 3]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
The below references follow this division with additions of
security and general knowledge references. Note that some working
groups are listed because they specify protocols that impact
ZeroConf protocols.
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
Domain name to IP address resolution:
- [Mcast DNS] Multicast DNS
- [RFC 1001] NETBIOS: CONCEPTS AND METHODS
- [RFC 1002] NETBIOS: DETAILED SPECIFICATIONS
- [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:
- [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
All readers should be familiar with the general knowledge
references.
2.2 ZeroConf Protocols
Hattig [Page 4]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
This section defines "ZeroConf protocol". Then, the assumptions
and restrictions of protocols are discussed. The assumptions and
restrictions are divided by networking topic.
2.2.1 Definition of ZeroConf Protocol
A ZeroConf protocol requires no user configuration and does not
rely on the existence of a centralized server.
A non-ZeroConf protocol requires user configuration or relies on a
centralized server.
A ZeroConf protocol must easily transition in three ways:
1. from a ZeroConf protocol to a non-ZeroConf protocol,
2. from a non-ZeroConf protocol to a ZeroConf protocol, and
3. from a ZeroConf protocol back to a ZeroConf protocol (possibly
with new values).
The ZeroConf to non-ZeroConf transition occurs when either a
device moves to a different network or when a server becomes
accessible on the network. For example, if a DHCP server gets
added to a network, then [IPv4Auto] is no longer be needed.
The non-ZeroConf to ZeroConf transition occurs when either a
device moves to a different network or when a server is no longer
accessible. For example, if a DHCP server is no longer on the
network so IP host must configure with [IPv4Auto].
The third transition occurs when a device moves from one ZeroConf
network to another ZeroConf network or when the ZeroConf network
topology changes significantly. For example a bridge is installed
between two existing ZeroConf networks. This is more like
"restarting" the ZeroConf protocol than transitioning.
Ideally these transitions occur due to some active trigger. When
there is no active trigger, a periodic timer should passively
allow for the transition to occur.
DHCP and [IPv4Auto] simply provide a clear illustrative example;
these protocols are in no way required by this document.
A ZeroConf protocol in one area may 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 (two of the
four Areas).
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.
Hattig [Page 5]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
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 non-ZeroConf protocol-B (with its
server) may co-exist with the ZeroConf protocol-C.
2.2.2 IP Host Configuration
Of the four areas, IP host configuration is the most
straightforward. IP host configuration is complete when there is a
known IP address, netmask, and default route for an interface on
an IP host. DHCP is the most prevalent non-ZeroConf solution
deployed today.
Network topologies greatly affect IP host configuration. While
hosts on a single IP network do not need a netmask or default
route to communicate, hosts on different IP networks do.
2.2.3 Domain name to IP address resolution
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.
Domain name to IP address resolution is accomplished in many
networks with DNS; therefore, it is highly likely that DNS will
play a key role in this area.
ZeroConf protocols must allow resolution of fully qualified domain
names as well as non-fully qualified domain names.
2.2.4 IP Multicast Address Allocation
[MADCAP] defines a sever-based allocation of IP multicast
addresses. Much like DHCP and DNS servers, [MADCAP] servers will
likely play a key role in the IP multicast address allocation
Area.
[EDITOR'S NOTE: Help wanted. There has not been a lot of
discussion on IP multicast address allocation. ]
2.2.5 Service Discovery
While IP Host configuration is the most straightforward, service
discovery is the least. The leading protocols in this Area are
SLPv2 [RFC 2608] and [SSDP].
Hattig [Page 6]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
[EDITOR'S NOTE: HELP!!!! There has been lots of discussion on the
list, but before I'm able to write something useful we need some
high-level discussion.
a) What are the major components of service discovery?
b) Definition of a service
c) Is service discover conclusive?
d) What kinds of services does ZeroConfig network want to
discover? or What are the service we are talking about?
e) What is the goal of service discovery?
f) What is the position of service discovery protocol in network?
g) Bootstrapping protocol or not?
h) How does a service discovery protocol support both simple and
complex devices in a ZeroConfig network? ]
2.3 ZeroConf Networks
A ZeroConf network is a network that at some point in time has one
or more ZeroConf protocols. By this definition, almost all
networks are ZeroConf networks. This definition is intentionally
broad because this document does not intend to mandate some
networks to be ZeroConf or exclude other networks from using
ZeroConf protocols. The sole intention of using the term "ZeroConf
network" is to focus the discussion within this document.
Generally speaking, the Internet and corporate LANs are non-
ZeroConf networks because they have many non-ZeroConf protocols.
Also, generally speaking, ZeroConf networks are grouped by the
topologies shown below.
This section describes the existing Internet network model, the
ZeroConf topologies, and a summary of the key points.
2.3.1 Existing Internet Model
All networks in this document follow the Internet Model as
described in RFC 1812. Specifically, networks consist of bridges,
routers, hosts, link layer networks, and IP networks to form
internets. [STD 3] and [STD 4] define IP host requirements.
A summary of the terms from [RFC 1812] that apply to this document
are:
- Bridges: a device that routes link layer packets (e.g. Ethernet
packets) between link layer networks (e.g. Ethernet) based on
the destination link layer addresses (e.g. 48-bit Ethernet
address) of a packet.
- Routers: a devices that routes IP packets between IP networks
based on the destination IP address of a packet.
- IP network: a network that consists of hosts with interfaces
that share the same network portion of the IP address. A single
Hattig [Page 7]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
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.
- internet: a network that consists of multiple IP networks
connected by routers.
2.3.2 Isolated Single IP Network
In an isolated single IP network topology, hosts simply connect
directly to each other with no routers. Also, there is no
connectivity to non-ZeroConf networks. Enabling these types of
simple networks is one of the primary motivations behind this
document.
The two primary instances of single IP-network topologies are
shown in Figure 1 and Figure 2.
*****************************************************
* ZeroConf Network *
* *
* ------ crossover cable ------- *
* | | *
* | | *
* +------+ +------+ *
* | Host | | Host | *
* +------+ +------+ *
* *
*****************************************************
Figure 1. Impromptu network
The ZeroConf network in Figure 1 has two hosts connected through a
crossover cable. A crossover cable between two hosts is one of the
most common impromptu ZeroConf networks. Infrared or other point-
to-point wireless technologies are other examples.
*****************************************************
* ZeroConf Network *
* *
* -------[ HUB ]------- *
* | | | *
* | | | *
* +------+ +------+ +------+ *
* | Host | | Host | | Host | *
* +------+ +------+ +------+ *
* *
*****************************************************
Figure 2. Fixed location network
Hattig [Page 8]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
The Figure 2 ZeroConf network has a small number of hosts
connected through a hub. A hub between hosts is the most common
fixed-location ZeroConf network.
Only an IP address and netmask is needed for an IP host to
communicate with other hosts on these networks. If the IP address
is a link-local (169.254/16) address, the netmask is not needed.
2.3.3 Single IP Network with a Gateway
In a topology with a single IP network and a gateway, the gateway
is a specialized router. It resides between the ZeroConf and non-
ZeroConf networks. The single IP network within the ZeroConf
network connects directly to the gateway.
The gateway is specialized because it restricts packets that pass
between the ZeroConf and non-ZeroConf networks to ensure autonomy
of the ZeroConf network and to avoid many security problems. For
the remainder of this document the term gateway has this meaning.
Figure 3 shows the single IP network with a gateway topology.
***************************
* *
* non-ZeroConf *
* Network *
* *
***************************
|
|
|
+----------------+
**********************| Gateway |*************************
* ZeroConf Network +----------------+ *
* | *
* | *
* | IP Network *
* ------------------------|----------------------------- *
* | | | | | *
* | | | | | *
* | | | | | *
* +------+ +------+ +------+ +------+ +------+ *
* | Host | | Host | | Host | | Host | | Host | *
* +------+ +------+ +------+ +------+ +------+ *
* *
*****************************************************************
Figure 3. Single IP Network with gateway Topology
Hattig [Page 9]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
Examples of this topology include a typical small business network
with a single gateway and a single Ethernet segment; a home
network with a single gateway and a single Home Phonewire Network
Alliance (HomePNA) link connecting a few PCs; and an Internet cafe
where people with 802.11 equipped laptops roam into the cafe,
lease some Internet connection time, then start surfing the
Internet while sipping their mocha.
The key points to this topology are that no default route is
needed for communication within the ZeroConf network; the netmask
and default route allow hosts to easily communicate outside the
ZeroConf network through the gateway; and IP broadcast packets can
reach all hosts and can be used to query for servers.
2.3.4 Star Topology
Star topologies center around a gateway. A gateway is a router
that resides between the ZeroConf and non-ZeroConf networks.
Multiple link layer networks that resides in the ZeroConf network
are directly connected to the gateway.
In addition to the above definition of a gateway, the gateway in a
star topology provides connectivity between all IP networks within
the ZeroConf network.
Figure 4 shows the general form of this topology.
***************************
* *
* Non-ZeroConf *
* Network *
* *
***************************
|
|
|
+----------------+
**********************| Gateway |*************************
* ZeroConf Network +----------------+ *
* | | | *
* | | | *
* | | | *
* | | | *
* IP network A | | | IP network B *
* ------------------| | |---------------------- *
* | | | | | *
* | | | IP network C | | *
* | | | | | *
* +------+ +------+ +------+ +------+ +------+ *
* | Host | | Host | | Host | | Host | | Host | *
Hattig [Page 10]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
* +------+ +------+ +------+ +------+ +------+ *
* *
*****************************************************************
Figure 4. Generic Star Topology
The primary example of this topology is a future home network with
many link layers such as HomePNA, HomeRF, IEEE 802.11, and IEEE
1394-1995. Most agree that home networks will be composed of many
different link layers that meet specific needs. These networks
either require no new wires to be installed or provide some
special function such as the ability to roam or to carry high-
quality video streams.
This topology requires all hosts to be configured with IP address,
netmask, and default route to communicate within the ZeroConf
network or outside the ZeroConf network. IP multicast must be used
to reach all hosts in the ZeroConf network (or to query for
servers) and the gateway must limit that IP multicast traffic from
leaving the ZeroConf network.
2.3.5 Ad-hoc Topology
Ad-hoc topologies have multiple gateways and/or multiple routers.
As with other topologies, gateways in an ad-hoc topology reside
between the ZeroConf network and the non-ZeroConf network. The
gateways ensure autonomy of the ZeroConf network by restricting
packets between the ZeroConf and non-ZeroConf networks. Routers
reside somewhere within the ZeroConf network and connect multiple
IP networks.
Figure 5 shows an instance of an ad-hoc network.
***************************
* *
* Internet *
* *
***************************
|
|ADSL
|
+----------------+
**********************| Gateway |*************************
* ZeroConf Network +----------------+ *
* | | *
* | | *
* IEEE 1394-1995 +--------+ | | HomePNA *
* -----------| Router |---| |-------------------- *
* | | +--------+ | | | *
* | | | HomeRF | | *
* | | | | | *
Hattig [Page 11]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
* +------+ +------+ +------+ +------+ +------+ *
* | Host | | Host | | Host | | Host | | Host | *
* +------+ +------+ +------+ +------+ +------+ *
* *
*****************************************************************
Figure 5. Home Network
Figure 5 shows a future home network. Such networks will come
about through users installing follow-on networks in their homes
over time without a long-term plan. Ad-hoc networking is the
expected long-term deployment pattern of many home networks.
This topology requires all hosts to be configured with IP address,
netmask, and default route to communicate within the ZeroConf
network or outside the ZeroConf network. IP multicast must be used
to reach all hosts in the ZeroConf network (or to query for
servers) and the gateway must limit that IP multicast traffic from
leaving the ZeroConf network. In addition, router-to-router
protocols may be required.
This document does not consider router-to-route ZeroConf
protocols; only ZeroConf protocols between hosts. In some limited
cases, ZeroConf protocols may require interaction between hosts
and routers.
[EDITOR'S NOTE: We need to discuss this a little more on the list.
We're getting close.]
2.3.6 Summary
The purpose of showing topologies is to restrict and focus the
discussion in this document. The purpose is not to mandate some
networks as ZeroConf and others as non-ZeroConf.
The gateway is a specialized router. It restricts packets that
pass between the ZeroConf and non-ZeroConf networks to ensure
autonomy of the ZeroConf network and to avoid many security
problems.
All ZeroConf protocols MUST operate in single IP networks and star
topologies. ZeroConf protocols SHOULD operate in ad-hoc networks.
However, router-to-router communication in such networks is
outside the scope of this document.
As topologies increase in complexity, the assumptions increase in
complexity. For example, hosts in an isolated single IP network
topology can use link-local addresses without configuring a
netmask or default route. Alternately, hosts in ad-hoc topologies
must use a netmask and a default route.
Hattig [Page 12]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
3 Scenarios
This section lists ZeroConf scenarios. This section does not
discuss specific protocols. Instead this section lists scenarios
that lead to requirements for protocols.
Each scenario begins with an explanation or overview. Then, the
key points of the scenario are identified along with requirements.
To consistently provide this information, each scenario has the
following outline:
- Overview
- Key Points
- Protocol Requirements
To provide further focus, the scenarios are grouped by networking
topic.
[EDITOR'S 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.]
3.1 IP Host Configuration
3.1.1 Single IP Network Communication
3.1.1.1 Overview
Hosts on a single IP network within the ZeroConf network
communicate to each other.
3.1.1.2 Key Points
This scenario applies to single IP network topologies (isolated or
with a gateway). As stated, if link-local IP address is used, then
only the IP address must be configured. Otherwise, an IP address
and netmask must be configured.
3.1.1.3 Protocol Requirements
- IP hosts MUST configure an IP address.
- IP hosts MUST configure a netmask (if the IP address is not
link-local).
- The host number of an IP address MUST be unique within a single
IP network.
- The network number of an IP address MUST equal the network
number of other IP addresses within a single IP network (if the
IP address is not link-local).
Hattig [Page 13]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
3.1.2 Multiple IP Network Communication
3.1.2.1 Overview
Hosts on multiple IP networks within a ZeroConf network
communicate to each other.
3.1.2.2 Key Points
This scenario is important for star topologies and ad-hoc
topologies.
3.1.2.3 Protocol Requirements
- IP hosts MUST configure an IP address.
- IP hosts MUST configure a netmask.
- IP hosts MUST configure a default route.
- The host number of an IP address MUST be unique within a single
IP network.
- The network number of an IP address MUST equal the network
number of other IP addresses within a single IP network.
- Network numbers of IP addresses MUST be unique within the entire
ZeroConf network.
- IP address MUST be routable within the ZeroConf network.
3.1.3 Bridge Installed
3.1.3.1 Overview
Between two operational IP networks, a bridge (or hub) is
installed. Now, two hosts on the newly formed IP network may 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.
3.1.3.2 Key Points
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.
3.1.3.3 Protocol Requirements
- Hosts MUST be able to re-configure their IP address and netmask
after networks are connected.
- All requirements in section 3.1.1.3.
Hattig [Page 14]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
3.1.4 Router Installed
3.1.4.1 Overview
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.
3.1.4.2 Key Points
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.
3.1.4.3 Protocol Requirements
- Hosts MUST re-configure IP address, net mask, and default route
at various times after the initial configuration.
- All requirements in section 3.1.2.3.
3.2 Domain Name to IP Address Resolution
3.2.1 Resolve Non-Fully Qualified Name
3.2.1.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.
3.2.1.2 Key Points
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.
3.2.1.3 Protocol Requirements
- A host that wishes to be addressable by name MUST select a
domain name.
Hattig [Page 15]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
- A host MUST determine if the domain name is in use by another
host.
- A host MUST participate to defend the 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.
3.2.2 Resolve Fully Qualified Name
[TBD]
3.2.2.1 Overview
3.2.2.2 Key Points
3.2.2.3 Protocol Requirements
3.3 IP Multicast Address Allocation
[TBD]
3.3.1 Allocate XX Scoped IP multicast address
[TBD, one XX for each relevant scope.]
3.4 Service Discovery
3.4.1 Discover Printer
[TBD]
3.4.2 Discover Shared Internet Access Service
[TBD]
3.4.3 Discover Internet Web Server
[TBD]
3.4.4 Discover Multiple Web Servers
3.5 Additional Scenarios
[EDITOR'S NOTE: Please post additional scenarios for discussion to
ZeroConf@merit.edu. Eventually this section will be removed.]
Hattig [Page 16]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
4 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.]
4.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.
4.2 Domain name to IP address resolution
Potential threats include:
- A host could masquerade, responding to names requests
illegitimately.
- 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.
4.3 Multicast Address allocation
Potential threats include:
Hattig [Page 17]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
- A host could hoard multicast addresses, denying others the
ability to obtain them.
4.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.
5 Additional Considerations
5.1 IANA Considerations
There are no known IANA considerations arising from this document.
5.2 Internationalization Considerations
ZeroConf protocols may exchange human readable strings. Human
readable strings may need to be internationalized.
5.3 Security Considerations
ZeroConf security considerations are in Section 5 of this
document.
6 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
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.
Hattig [Page 18]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
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."
7 Editor
Myron Hattig
Intel Corporation
2111 NE 25th Ave. JF3 206
Hillsboro, OR 97124
myron.hattig@intel.com
8 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.
Hattig [Page 19]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
[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-
ietf-malloc-madcap-05.txt May 1999. A work in
progress.
Hattig [Page 20]
Internet Draft draft-ietf-zeroconf-reqts-01.txt Nov 1999
[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 21]
