Zeroconf WG M. Hattig
Internet Engineering Task Force Editor
INTERNET DRAFT Intel Corp.
Expires July 2000 January 10, 2000
Zeroconf Requirements
draft-ietf-zeroconf-reqts-02.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 for an adhoc purpose. Zeroconf networks do not
have and should not be expected to have user configurable network
infrastructure such as DHCP, 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
each protocol area.
Table of Contents
Hattig [Page 1]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
1 Overview....................................................2
2 Introduction................................................3
2.1 Reading This Document.....................................3
2.2 Zeroconf Protocols........................................4
2.3 Zeroconf Networks........................................10
3 Scenarios..................................................16
3.1 IP Host Configuration Scenarios..........................16
3.2 Domain Name to IP Address Resolution Scenarios...........18
3.3 IP Multicast Address Allocation Scenarios................19
3.4 Service Discovery Scenarios..............................19
3.5 Additional Scenarios.....................................25
4 Security Requirements......................................25
4.1 ZeroConf Security Threat Analysis........................25
4.2 Security Requirements....................................26
5 Additional Considerations..................................28
5.1 IANA Considerations......................................28
5.2 Internationalization Considerations......................28
5.3 Security Considerations..................................28
6 Full Copyright Statement...................................28
7 Acknowledgements...........................................29
8 References.................................................30
1 Overview
[Editor's Note: Most of the effort that has gone into version 02
has been devoted to section 2. With the exception of service
discovery I believe section 2 is 95% done and hope that we'll
close on all section 2 issues in the next few weeks. This should
put us well on the way to finish by March 10th, which is the
submission deadline for the next IETF meeting.]
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 for an adhoc purpose. Zeroconf networks
typically do not have and should not be expected to have user
configurable network infrastructure such as DHCP, 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
each protocol area.
This Zeroconf requirements document is a companion to a Zeroconf
profile document. This requirements document lists requirements
Hattig [Page 2]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
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
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 enable concise scenario discussions.
Scenarios must be concise in definition and scope to generate
useful protocol requirements. The security section lists threats
and security requirements all four protocol areas.
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 restrictions, assumptions, and terms.
2.1 Reading This Document
This Introduction provides the necessary information to have a
concise scenario discussion. This includes reference information,
restrictions, assumptions, and terms. All readers should read the
entire introduction.
Of the scenarios listed in the Scenario section, different
scenarios generate unique requirements but are not the only
scenarios that could possibly generate those unique requirements.
Each scenario has an overview, key points, and protocol
requirements.
The Security section lists threats and security requirements for
each protocol area.
Because this document deals four distinct protocol areas, many
sections are divided into those areas. They are:
- IP host configuration
- Domain name to IP address resolution
- IP multicast address allocation
- Service discovery
The below references follow this division with additional
references for security and general knowledge. Note that some
Hattig [Page 3]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
working groups are listed because they specify protocols that
impact Zeroconf protocols.
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
- [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
- [DNS WG] DNS Update 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
All readers should be familiar with the general knowledge
references.
2.2 Zeroconf Protocols
Hattig [Page 4]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
A subsection below defines what "Zeroconf protocol" means. Then,
additional subsections state the assumptions and restrictions of
each protocol area.
2.2.1 Zeroconf Protocol
Below is a definition of a Zeroconf protocol and a non-Zeroconf
protocol. Additional discussions describe a host transitioning
between Zeroconf and non-Zeroconf protocols, then the coexistence
of these protocols.
2.2.1.1 Definitions
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.
2.2.1.2 Transitions
A host using 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 host
moves to a different network or when a server becomes accessible
on the network. For example, if a DHCP server comes on-line after
hosts are configured with [AutoNet], then hosts must re-configure
with DHCP.
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 then IP hosts must re-configure with [AutoNet].
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, if a bridge is
installed between two networks where hosts were already configured
using [AutoNet], then hosts must re-configure with [AutoNet] to
ensure duplicate IP addresses do not exist.
A host can determine a transition is necessary by two methods: the
host periodically checking if a transition is needed or by
receiving a proactive mechanism from some entity that knows a
transition is underway. Solutions SHOULD have both a periodic
Hattig [Page 5]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
checking and a proactive mechanism (assuming the proactive
mechanism uses an unacknowledged packet such as IP broadcast).
Periodic checking ensures a host transitions even when that host
does not receive the packet carrying the proactive mechanism. A
proactive mechanism allows the time between periodic checks to be
greater; thus the checking will not consume excessive bandwidth or
processing resources.
For example if the DHCP server broadcasts an "DHCPAck" with a new
"I'm Here" option or "I'm Leaving" option as the proactive
mechanism, then [AutoNet] must still send a periodic DCHPDiscover
message.
Note, the DHCP and [AutoNet] examples have no bearing on the
stated requirements in this document. These examples were chosen
simply because they are illustrative.
2.2.1.3 Coexistence
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 protocol 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.
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 coexist with the Zeroconf protocol-C.
Alternately, Zeroconf and non-Zeroconf protocols from a single
area SHOULD not coexist during normal operation. They may coexist
during a transition, but the coexistence period SHOULD be minimal.
2.2.2 IP Host Configuration
IP host configuration is required before virtually any IP
communication can take place. In most cases, IP host configuration
is complete when there is a known IP address, netmask, and default
route for an interface on a host.
DHCP is the common host configuration solution deployed today.
DHCP consists of servers and clients. The client discovers the
Hattig [Page 6]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
server, and then the server offers configuration parameters to
clients. It is assumed that all Zeroconf IP host configuration
schemes will co-existence with DHCP. In other words DHCP is the
non-Zeroconf solution for IP host configuration.
2.2.3 Domain name to IP address resolution
Web browsing to an URL utilizes domain name to IP resolution. This
resolution capability allows applications (and sometimes 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 on hosts query the DNS servers
for the information in resource records. DNS is the non-Zeroconf
solution for domain name to IP address resolution.
2.2.4 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 the multicasted packets get transmitted beyond
certain administrative domains (e.g. through a RFC 2365 boundary
router).
MADCAP is the non-Zeroconf IP multicast address allocation
solution. MADCAP is a server-client protocol where clients request
IP multicast addresses from a server. MADCAP operates much like
DHCP.
Zeroconf solutions are only concerned with IP multicast address
scoped as site-local (i.e. 239.255.0.0/16). A boundary router (as
described in [RFC 2365]) must be present to appropriately control
multicast packets from entering and leaving the Zeroconf network.
2.2.5 Service Discovery
Service discovery protocols have proven to be critical to the
usability of networks. AppleTalk/NBP, NetBIOS/SMB and IPX/SAP are
perfect examples in that they greatly improved the utility of
their respective network architectures. 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 purposes.
Hattig [Page 7]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
Also, unlike the other protocol areas, no incumbent service
discovery protocol exists. Service Location Protocol version 2
(SLPv2) is defined in Standards Track RFC 2609. An Internet-Draft
defines Simple Service Discovery Protocols (SSDP), which is
another service discovery protocol.
Considerable service discovery terminology is necessary to have a
service discovery scenario discussion. The terms below are
categorized into basic, processes, packet types, actions, then
alphabetized within those categories. Following the terms is a
list of service discovery protocol assumed requirements.
Basic Terms:
Process - A process is an implementation of an algorithm in
software, hardware, or a combination of software and hardware.
Service - A service is set of processes that do a wide range of
network related things. Services range from printing to
transferring a file to providing on-line pizza order and delivery
service. A service may find some network management information,
perform some action, control some resource, or perform just about
any network-related function.
Service Characteristics - Characteristics differentiate services.
They may differential the same type of service in terms of
capabilities (e.g. color printing vs black and white), state (e.g.
printer ready vs paper jam), physical location (e.g. my office vs
my home), and many other things. Characteristic may include
service-unique information such as access information, version
numbers, contact information, 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, but does not interact with, network
and transport protocol layers.
Service Identifier - A service may be identified by general
service type as well as service characteristics. Clients, servers,
advertisers, discoverers, and registries use service identifiers.
Service Protocol - A service protocol is used between the client
and the server after service discovery is complete.
Processes:
Advertiser - A process that advertises a service using a service
discovery protocol. A server generally activates the advertiser.
Hattig [Page 8]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
Client - A process that uses a service discovery protocol to
discover a service.
Discoverer - A process that discovers a service using a service
discovery protocol. A client generally activates the discoverer.
Registry - A process that acts as an intermediary between
discoverers and advertisers. Servers 'register' service
advertisements and other pertinent (e.g. authentication info,
announcement criteria) with registries, then the service may be
discovered from the registry instead of from a server. The
registry may be centralized for a group of clients to access or
cached within a single client. A registry reduces the number of
queries to enhance the scalability of a service discovery
protocol.
Peer - A process that is both a client and service for a specific
service protocol.
Server - A process that offers a service to clients through a
service discovery protocol.
Packets Types:
Service Advertisement - A solicited response issued by a server or
registry. The advertisement provides the service identifier and
possibly service characteristics.
Service Solicitation - A request made by a client to obtain
service advertisements.
Service Announcement - An unsolicited informative message issued
by a server or registry. The announcement provides the service
identifier and possibly service characteristics.
Registry update - A message that contains updated a registry
information. It may cause one or more registry entries to be
deleted, added, or modified.
Actions:
Client-Server negotiation: The act of a client using the service
protocol to negotiate with a server after the service has been
discovered with the service discovery protocol.
Registry cleanup: An internal process of the registry to remove
unwanted information.
Service discovery: The act of a client discovering a service.
Hattig [Page 9]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
Utilizing a service: The act of a client using a service after the
service has been discovered.
Assumed Service Discovery Protocol Requirements:
A service discovery protocol MUST allow a client to discover then
utilize a service.
A discovery protocol itself MUST require no configuration.
(Clients must know what they need and services must know what they
are, but this is a service installation and configuration issue,
not a service discovery issue.)
A service discovery protocol SHOULD allow a client to use
Solicitation messages with specific characteristics. This enables
a client to avoid complex client-server negotiations that may
occur after service discovery. Characteristics also allow human
users to determine which service to use (browse).
A service discovery protocol SHOULD limit the use of Service
Announcement messages so as to not flood the network unnecessarily
and most importantly not cause 'broadcast storms'.
A service discovery protocol SHOULD automatically sense when it
must stop multicasting requests from Discoverers to Advertisers
and instead employ a Registry of some sort.
A service discovery protocol MUST not cause scalability or
operational problems in larger non-Zeroconf networks if clients
and servers somehow transition to such networks.
A service discovery protocol MUST be rich enough in its semantics
to be able to represent a wide range of services.
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 to avoid mandating a network to be Zeroconf or exclude
another network from using a Zeroconf protocol. The Internet and
corporate LANs are considered non-Zeroconf networks because,
today, these networks have little use for Zeroconf protocols.
This section describes the existing Internet network model, the
Zeroconf topologies, and a summary of the key points.
2.3.1 Existing Internet Model
Hattig [Page 10]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
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. A summary of the terms from [RFC 1812] that apply
to this document are:
- Bridge: 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.
- Router: a devices that routes IP packets between IP networks
based on the destination IP address of an IP packet.
- IP network: a network that consists of hosts with interfaces
that share the same network portion of their IP addresses. 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.
- 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 connect directly
to each other without routers. This implies no connectivity to
non-Zeroconf networks.
Enabling isolated single IP networks is one of the primary
motivations behind this document.
Two instances of single IP-network topologies are shown in Figure
1 and Figure 2.
*****************************************************
* Zeroconf Network *
* *
* ------ crossover cable ------- *
* | | *
* | | *
* +------+ +------+ *
* | Host | | Host | *
* +------+ +------+ *
* *
*****************************************************
Figure 1. Cross-over cable Ethernet network
The Zeroconf network in Figure 1 has two hosts connected through a
crossover Ethernet cable. Infrared or other point-to-point
wireless technologies are similar examples. These networks can be
Hattig [Page 11]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
created and torn down on an adhoc basis for seminars, conferences,
hour-long meetings, or for many other reasons.
*****************************************************
* Zeroconf Network *
* *
* -------[ HUB ]------- *
* | | | *
* | | | *
* +------+ +------+ +------+ *
* | Host | | Host | | Host | *
* +------+ +------+ +------+ *
* *
*****************************************************
Figure 2. Hosts connected by Ethernet Hub
The Figure 2 Zeroconf network has a small number of hosts
connected through an Ethernet hub. This may be a small office
network or a gaming network.
In this topology, IP broadcast packets reach all hosts and no
routing takes place, thus a default route is not a needed
configuration parameter. A host sending an IP packet SHOULD not
AND the netmask with the destination IP address to determine
whether to forward the IP packet to the default router or to send
an ARP packet to resolve the destination IP address to a hardware
address. Instead, hosts SHOULD always opt to use ARP; a default
route existing or not existing in the IP host configuration
determines this.
2.3.3 Single IP Network with a Gateway
A specialized router called a gateway resides between the Zeroconf
and non-Zeroconf networks. The single IP network within the
Zeroconf network connects directly to the gateway.
The gateway is a specialized router in that it restricts the
routing of IP packets between the Zeroconf and non-Zeroconf
networks. This restriction ensures autonomy of the Zeroconf
network and avoids many security problems. In addition, the
gateway acts as a multicast boundary router as defined in RFC
2365.
Enabling single IP networks with a gateway is one of the primary
motivations behind this document.
Figure 3 shows the single IP network with a gateway topology.
***************************
Hattig [Page 12]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
* *
* non-Zeroconf *
* Network *
* *
***************************
|
|
|
+----------------+
**********************| Gateway |*************************
* Zeroconf Network +----------------+ *
* | *
* | *
* | IP Network *
* ------------------------|----------------------------- *
* | | | | | *
* | | | | | *
* | | | | | *
* +------+ +------+ +------+ +------+ +------+ *
* | Host | | Host | | Host | | Host | | Host | *
* +------+ +------+ +------+ +------+ +------+ *
* *
*****************************************************************
Figure 3. Single IP Network with a Gateway
Examples of this topology include a typical small business network
with remote-access router and a single Ethernet segment. Another
common example is a home network with an ADSL-modem and a single
Home Phonewire Network Alliance (HomePNA) link connecting a few
PCs.
In this topology, broadcast packets reach all hosts and routing
only occurs to communicate between Zeroconf and non-Zeroconf
networks. All hosts SHOULD rely on netmask and the default route
as a normal IP host does when determining to ARP or to forward
packets to the default route.
2.3.4 Multiple IP Networks through a Gateway
In this topology, all IP networks within the Zeroconf network
connect directly to the gateway.
Enabling this topology is a goal for this document.
Figure 4 shows the general form of this topology.
***************************
* *
* Non-Zeroconf *
Hattig [Page 13]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
* Network *
* *
***************************
|
|
|
+----------------+
**********************| Gateway |*************************
* Zeroconf Network +----------------+ *
* | | | *
* | | | *
* | | | *
* | | | *
* IP network A | | | IP network B *
* ------------------| | |---------------------- *
* | | | | | *
* | | | IP network C | | *
* | | | | | *
* +------+ +------+ +------+ +------+ +------+ *
* | Host | | Host | | Host | | Host | | Host | *
* +------+ +------+ +------+ +------+ +------+ *
* *
*****************************************************************
Figure 4. Multiple IP Networks through a Gateway
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. These link layers are installed because they either
require no new wires (e.g. phone line, wireless, powerline) or
provide some special function such as the ability to roam (e.g.
wireless) or to carry high-quality video streams (e.g. IEEE 1394-
1995).
Communication between IP networks within the Zeroconf network and
between the Zeroconf and non-Zeroconf networks is achieved by
utilizing the routing capability in the gateway; therefore all
hosts SHOULD be configured with netmask and default route.
Broadcasts do not reach all hosts within the Zeroconf Network;
therefore, multicasting is the best solution to reach all hosts.
In order for multicast packets to reach all hosts, the gateway
must be a multicast router and act as a boundary router (as
defined in RFC 2365) to restrict certain multicast packets from
leaving the Zeroconf network.
2.3.5 Networks with Routers and Gateways
In this topology, routers connect IP Networks within the Zeroconf
network and gateways connect the Zeroconf network to the non-
Zeroconf network.
Hattig [Page 14]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
Supporting this topology is not a goal of this document because it
would require router auto-configuration, router pre-configuration,
or some router-to-router communication to somehow enable router
configuration; this document in no way precludes such work in
other documents.
Zeroconf protocols that communicate between a host and a router to
configure the host MAY be considered.
Figure 5 shows a sample network with routers and gateways.
*************************************
* *
* Internet *
* *
*************************************
| |
| |
| |
+----------------+ +------------+
*******************| Gateway |****| Gateway |***********
* Zeroconf Network +----------------+ +------------+ *
* | | | IP network D *
* | | | *
* IP network A +--------+ | | IP network C +--------+ *
* -----------| Router |---| |--------------| Router | *
* | | +--------+ | | +--------+ *
* | | |IP network B | | *
* | | | | | *
* +------+ +------+ +------+ +------+ +------+ *
* | Host | | Host | | Host | | Host | | Host | *
* +------+ +------+ +------+ +------+ +------+ *
* *
******************************************************************
Figure 5. Routers and Gateways Network
This topology is only applicable in a medium to large business;
generally, these are not Zeroconf networks.
2.3.6 Summary
The purpose of showing topologies is to make this document
concise. 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
Hattig [Page 15]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
problems. The gateway SHOULD act as a boundary router as defined
in RFC 2365.
All Zeroconf protocols MUST operate in single IP networks
(isolated and connected) and SHOULD operate in networks with
multiple IP networks with a single gateway. It is beneficial, but
not required, for Zeroconf protocols to operate in networks with
multiple gateways and multiple routers.
3 Scenarios
This section lists Zeroconf scenarios that lead to requirements
for protocols. Specific protocols are not discussed.
Each scenario begins with an explanation or overview. Then, the
key points of the scenario are identified along with requirements.
Each scenario has the following outline:
- Overview
- Key Points
- Protocol Requirements
The scenarios are grouped by IP host configuration, domain name to
IP address resolution, IP multicast address allocation, and
service discovery.
The scenarios take place within a Zeroconf network unless
otherwise stated.
3.1 IP Host Configuration Scenarios
3.1.1 Isolated Single IP Network Communication
3.1.1.1 Overview
Hosts on a single IP network communicate to each other.
3.1.1.2 Key Points
This scenario applies to single IP network topologies (isolated or
with a gateway). Only the IP address must be configured. The
netmask can be configured to a value or assumed to be
255.255.255.255. No default route is needed.
3.1.1.3 Protocol Requirements
- IP hosts MUST configure an IP address.
- IP hosts MUST configure a netmask or assume 255.255.255.255.
- The host number of an IP address MUST be unique within a single
IP network.
Hattig [Page 16]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
- The network number of an IP address MUST equal the network
number of other IP addresses within a single IP network.
3.1.2 Multiple IP Network Communication
All the networks in this section are isolated from non-Zeroconf
networks.
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.
Hattig [Page 17]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
3.1.3.3 Protocol Requirements
- Hosts MUST be able to re-configure their IP address and netmask
after networks are connected.
There is an addition requirment to your "periodic conflict
detection" requirement. It is an active mechanism to restart
conflict detction. This is needed in case the period is too
large for a hosts needs.
- All requirements in section 3.1.1.3.
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 Scenarios
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
Hattig [Page 18]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
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.
- 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 Scenarios
[TBD]
3.3.1 Allocate XX Scoped IP multicast address
[TBD, one XX for each relevant scope.]
3.4 Service Discovery Scenarios
3.4.1 Discover Printer
3.4.1.1 Overview
Networked enabled printers allow various clients to submit print
jobs. There are different printing protocols possible (raw tcp,
lpd, ipp, etc.) Further, printers vary in a number of ways (their
location, status and capabilities). Printer discovery is
Hattig [Page 19]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
important for both printing clients as well as 'printing managers'
- that is, software which manages all printers of a particular
kind on the network.
3.4.1.2 Key Points
Printer discovery must allow a printing client to discover the
location of a printer and enough information about the print job
submission protocol to be able to submit jobs. Further printer
discovery must discriminate between printers which are useful and
those which are not. A printer which is located in a remote
facility (across a continent) is not useful, nor is a printer
which can't print in color, on transparencies, etc. if that is
what the client needs to do. Printer discovery has to be timely -
so that when a printer comes on line, a print client or a print
manager application can discover the printer in a timely way.
3.4.1.3 Protocol Requirements
Printer discovery implies the following requirements for service
discovery.
- The service discovery mechanism has to allow for discriminating
queries. A client has to be able to discover a printer for
which it has a driver, for instance.
- Service discovery has to be able to discover the characteristics
of an advertised service. A print client or a print manager
has to be able to find out the configuration and possibly even
status of the printer to be able to adequately provide
information to the print client or print manager which is
searching for appropriate print servers. This information may
be used for a user interface or by a program so the format of
the information has to be standardized.
- Service discovery has to be able to be done in a 'timely way.'
That is, within a short number of seconds after activating a
print server, a user who is actively browsing for printer
should be able to see the device appear in a browser window, or
a printer manager should be able to begin managing the print
server.
3.4.2 Discover File Access Server
3.4.2.1 Overview
File sharing is done using different protocols. A file sharing
client is only interested in file sharing services which use the
access protocol it is capable of. File sharing is typically done
by human users - in this case attributes of the file access server
Hattig [Page 20]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
have to be discovered so the human user can select which server to
access. File sharing is done on a 'session basis' so timely
rediscovery of selected file servers is necessary.
3.4.2.2 Key Points
File sharing is a key application of personal computing. There
are a variety of file access protocols available (NFS, Novell file
access protocol (?), AppleShare, NetBIOS/SMB, etc.) A client must
be able to discover those file systems which exist on a network,
which the client can get access to, that support the file access
protocol the client is capable of using.
Further, existing service discovery mechanisms for file access
servers (from Novell, Apple and Microsoft proprietary protocols)
allow the user to discover something about the file system they
would access. This include the name of the file system, a human
readable description of it as well as a 'group' or 'groups' that
the file system was shared to.
Since there may be many 'peers' in a network of personal computing
devices, it is critical that some grouping is possible, so that
users can locate file access servers that are meaningful to them
(located nearby, shared by colleagues close to them in the
organization, shared by those who will allow the user access to
the files, file systems whose content is of a general kind, etc.)
Further, grouping file access servers is important to allow the
service discovery activity to be scalable in a network containing
many systems capable of (or actively) providing file access
service. This scalability consideration is different than the
previous point (where grouping services prevents too much
information to select from). In this case, scalability implies
that requests will only be received and processed by a subset of
the file access servers which advertise their services (or by a
subset of the 'service discovery protocol infrastructure' to be
more general). This will prevent service discovery from being a
burden to the network. This is an extremely important point:
Experience has shown that service discovery for services which are
shared by many personal computers in larger networks can have
disastrous effects.
AppleTalk, Novell networks and Microsoft networks all suffer in
performance for this reason. Finally, file access is typically
done on a 'session' basis. That is, when a user decides to access
a file system, he or she wants access to it over time. If the
file system is not available for a time, the user wants to get
access to it again when the file system is again available. If
the client system is moved or deactivated, the user wants to be
able to discover the same file system again when the client device
Hattig [Page 21]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
is again able to locate the previously discovered and selected
file access server.
3.4.2.3 Protocol Requirements
File access server discovery implies the following requirements:
- Clients can discover the location of file access servers which
support the file access protocol they support.
- Clients can discover only those file access servers which are in
a 'group' they are interested in. This grouping has to be
possible along a variety of different conceptual lines
location, organizational - like which department, or functional
- like a general description of the servers such as "reference
library" or "mailing list archives".) This is possible in
Novell, AppleTalk and Microsoft networks. It should be
possible on IP networks in general.
- The groupings listed above must be able to limit the effects of
the file access protocol on the network. This allows for
scalable service discovery in a larger network.
- Clients can discover some information about file systems that
they could choose to access (the name of the file system, a
description of it and whether the user has access permission,
at the very least).
- Clients should be able to rediscover the file system over time
so that the user can discover the same file access service even
if that service goes down and comes back up, or if the client
device moves or goes down, then is once again on a network
where the file access server is present.
3.4.3 Discover Manageable Device
3.4.3.1 Overview
One important application of service discovery is the discovery of
manageable devices by a 'management' system. Conversely,
manageable devices may need to discover their manager. The
relationship between manager and managed system is different than
is the case in most service discovery applications since the
manageable device is in many respects a service with respect to
the manager, but there is usually only one manager and many
manageable systems.
3.4.3.2 Key Points
Hattig [Page 22]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
The management system (manager) needs to be able to discover
devices which support appropriate management services (management
agents). Currently this discovery is done in many networks by
having the manager scan all addresses in order to determine the
location and existence of all agents. This does not scale well to
larger address spaces.
Managers need to discover agents in a timely way. That is, when
an agent is activated, a manager needs to be able to discover it
within a short number of seconds.
Managers often need to discover a set of agents which have a
certain configuration. For instance, only those agents running on
a certain hardware platform, with a certain software version.
This allows the manager to determine the population of agents
which need an upgrade immediately. This is not to say that the
service discovery mechanism should replace the management protocol
(whereby the manager can interrogate the agent and obtain or set
specific management information). The facility to find only
specific agents allows the manager to discriminate among agents on
the network so that it can interrogate only that subset that are
relevent. This is important for scaling management software to
larger networks where there may be many agents. This is even
important on smaller networks where a specialized manager is only
able to manager a very specific subset of all devices.
3.4.3.3 Protocol Requirements
The service discovery mechanisms for managers to find agents (and
thereby manageable devices) require the following:
- Managers have to be able to find all agents they can manage.
- Managers have to have the ability to discover agents shortly
after they are activated.
- Managers have to be able to discover only the subset of agents
that are relevant. This means that managers have to be able to
discover agents on the basis of their hardware, software or
there device specification or status. To some extent the
service discovery protocol has to return information about the
agent to the manager, but this enhances the manager-agent
relationship. It does not replace the management protocol
which can do specific management operations (including very
specific structured queries of an agent by a manager).
3.4.4 Discover Service Discovery Infrastructure
3.4.4.1 Overview
Hattig [Page 23]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
Service discovery protocols have two modes: The first is used in
a zeroconf environment. The protocol in this case may not scale
very well in a larger environment. The second mode is to be used
in a configured network. In this case, the service discovery
protocol must scale well. Clients discovering services and
servers offering services have to be able to discover 'service
discovery infrastructure' when it is present and transition to its
use. Further, configuration must be able to be supplied to
clients and servers so that they will use the service discovery
infrastructure scalably and appropriately.
3.4.4.2 Key Points
Service discovery infrastructure has to be able to be discovered
quickly, and by all clients and servers which are using a service
discovery protocol. This allows for a transition from an ad hoc
(multicast or broadcast based protocol) to one which is suitable
for larger networks.
This service discovery infrastructure provides a concentration of
service discovery information so that point to point messages can
be exchanged instead of all service discovery messages having to
be either multicasted (either solicitations or advertisements).
Clients and servers using a service discovery protocol in a
zeroconf environment have to be able to obtain configuration.
This configuration will enable the clients and servers to use
specific portions of the service discovery infrastructure, or to
use it in a particular way. This allows, for instance, services to
be advertised according to a particular policy, as belonging to a
particular department, in a particular location or network, etc.
Similarly, clients obtaining configuration will only discover
services which they are directed to, such as services in their
department, hotel room, etc.
3.4.4.3 Protocol Requirements
Requirements arising from discovery of service discovery
infrastructure include:
- Service discovery infrastructure provides a transition from
zeroconf service discovery protocol use to scalable and
configured service discovery protocol use.
- Service discovery infrastructure has to be discoverable by
clients and servers which use a service discovery protocol
automatically, and reasonably quickly. The clients and servers
have to use this infrastructure if it becomes available to
ensure scalable behavior.
Hattig [Page 24]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
- Configuration of clients and servers using a service discovery
protocol has to be able to be done dynamicly. This way clients
and servers will obtain the necessary configuration to operate
effectively in larger networks according to the service
deployment policy employed in the network the system is present
in.
3.5 Additional Scenarios
[EDITOR'S NOTE: Please post additional scenarios for discussion to
Zeroconf@merit.edu. Eventually this section will be removed.]
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.
4.1 ZeroConf Security Threat Analysis
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.
4.1.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.1.2 Domain name to IP address resolution
Hattig [Page 25]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
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.1.3 Multicast Address Allocation
Potential threats include:
- A host could hoard multicast addresses, denying others the
ability to obtain them.
4.1.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.
4.2 Security Requirements
Protocols designed for host configuration, name resolution,
service discovery and multicast address allocation include
security mechanisms. These protocols have been designed for use in
configured networks. The same security mechanisms appropriate in a
configured network is not useful in a ZeroConf network.
ZeroConf requirements will not specify that all security threats
be addressed by ZeroConf protocols since it would be inappropriate
to do so.
Security always requires configuration. For that reason, no
secure operation will be possible on a network which has
absolutely no configuration.
That is not the same as saying that ZeroConf requirements are
silent with respect to security. When configuration is added to a
host using ZeroConf protocols, the host transitions to another
mode of operation. In this case, the host which is appropriately
configured may be able to counter threats posed to systems using
ZeroConf protocols.
The ZeroConf requirements specify the transition from insecure to
secure operation. A host fulfilling ZeroConf requirements will be
capable of secure operation in each protocol area, if it is
Hattig [Page 26]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
supplied with appropriate security configuration (such as
cryptographic keys.)
4.2.1 IP Host Configuration
Hosts MUST be able to be configured to use DHCP authentication.
Option 1:
No provision is made for securing IP Host Configuration using
the ZeroConf protocol for IP Host Configuration.
Option 2:
Hosts MUST be able to be configured to use a ZeroConf protocol for
host configuration securely. For example, a claim and defend
protocol used for host configuration 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.
4.2.2 Domain name to IP address resolution
Hosts MUST be able to be configured to use DNS Security.
Option 1:
No provision is made for securing the ZeroConf Domain Name to IP
address resolution protocol.
Option 2:
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.
4.2.3 Multicast Address Allocation
Hosts MUST be able to be configured to use MADCAP security.
Option 1:
No provision is made for securing the ZeroConf protocol for
multicast address allocation.
Option 2:
Hattig [Page 27]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
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.
4.2.4 Service Discovery
Both clients and servers MUST be able to be configured to use
security mechanisms offered by the Service Discovery Protocol.
These mechanisms 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 so that a
server can use security configuration to advertise service
information in a way that clients can verify.
The service discovery protocol MUST provide mechanisms so that a
client can use security configuration to verify service
information it obtains. The client is essentially verifying that
the server had possession of certain secrets. The client trusts
that only 'legitimate' servers would possess these secrets.
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,
Hattig [Page 28]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
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."
7 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 much of the text relating to
service discovery and the security requirements.
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,
Bernard Aboba, and David Thaler.
Editor:
Myron Hattig
Intel Corporation
2111 NE 25th Ave. JF3 206
Hillsboro, OR 97124
myron.hattig@intel.com
Hattig [Page 29]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
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.
[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
Hattig [Page 30]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
[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.
[NAT WG] Network Address Translation WG,
www.ietf.org/html.charters/nat-charter.html.
Hattig [Page 31]
Internet Draft draft-ietf-zeroconf-reqts-02.txt Jan 2000
[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 32]
