NETWORK Working Group Erik Guttman
INTERNET-DRAFT Sun Microsystems
Intended Category: Best Current Practice
11 July 2001
Expires in six months
Zeroconf Host Profile
<draft-ietf-zeroconf-host-prof-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Comments on this document should be sent to the author and to the
Zeroconf Working Group mailing list: zeroconf@merit.edu.
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.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
Requirements for Internet routers [RFC 1812] and hosts [RFC 1122]
[RFC 1123] provide guidance to vendors and users of Internet
communication software. They represent consensus arising from
experience. This document similarly associates a set of protocols
together for a particular purpose. In contrast to router and host
requirements standards, the Zeroconf Host Profile does not arise out
of experience, (though relevant experience is cited.) Instead, this
comprises a set of protocols which complement each other when
implemented together.
Guttman, E. Expires: 11 January 2002 [Page 1]
Internet Draft Zeroconf Host Profile July 2001
1. Introduction
The goal of the Zero Configuration Networking (ZEROCONF) Working
Group is to enable networking in the absence of configuration and
administration. Zero configuration networking is required for
environments where administration is impractical or impossible, such
as in the home or small office, embedded systems' plugged together'
as in an automobile, or to allow impromptu networks as between the
devices of strangers on a train.
As noted in STD 3 [RFC 1122], the current internet suite of protocols
fall short of this goal.
It would be ideal if a host implementation of the Internet
protocol suite could be entirely self-configuring. This would
allow the whole suite to be implemented in ROM or cast into
silicon, it would simplify diskless workstations, and it would be
an immense boon to harried LAN administrators as well as system
vendors. We have not reached this ideal; in fact, we are not even
close.
This document describes a host profile which provides zero
configuration operation. Like STD 3, this document describes a set
of protocols and makes recommendations with respect to their
implementation. Unlike the the mechanisms described in STD 3, we
have limited experience with many Zeroconf protocols; some are only
now emerging as IETF standards track specifications. Still, we have
extensive experience with related protocols, which provided the
inspiration for the Zeroconf working group and Zeroconf protocols,
specifically the AppleTalk protocol suite [4].
This document defines a profile - a set of related protocols which
complement each other so as to provide a minimum interoperable set of
functions to enable communication in the absence of administration
and network services. The requirements and scenarios for use of
these protocols is described in the Zeroconf Requirements [5]. Just
as Router Requirements have no bearing on devices which support IP
without forwarding packets, the Zeroconf profile specifies only the
behavior of devices which perform automatic configuration.
2. Terminology
Terminology specific to discussion of particular zeroconf protocols
is introduced in the appropriate section.
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [RFC 2119].
Guttman, E. Expires: 11 January 2002 [Page 2]
Internet Draft Zeroconf Host Profile July 2001
3. Zeroconf Host Profile Requirements and Recommendations
IP Interface Configuration and name resolution services are host
requirements (see section 3.3.1.6 [RFC 1122], 6.1.1 [RFC 1123]). A
zeroconf host MUST implement these features.
Service discovery constitutes one of the most useful features of the
AppleTalk protocol suite [4]. The ease of user configuration from
standard service discovery facilities has proved so important that
this feature alone has been decisive in continuing support for
AppleTalk in many networks. For this reason, a zeroconf host SHOULD
implement service discovery functions.
Some multicast applications require the allocation of multicast
addresses which do not conflict with other address allocations.
Zeroconf hosts MAY implement multicast address allocation functions
to support these applications.
The protocols included in the Zeroconf Host Profile provide
equivalent functions when run over IPv4 and IPv6. Where there are
differences, these are noted.
3.1. IP Interface Configuration
3.1.1. Zeroconf Requirements
Hosts which support IPv4 and the Zeroconf Host Profile MUST implement
IPv4 Link-local IP Interace Configuration. [7]
Hosts which support IPv6 and the Zeroconf Host Profile MUST implement
IPv6 Stateless Address Autoconfiguration. [RFC 2461] [RFC 2462]
3.1.2. Discussion
IPv4 link-local address autoconfiguration provides an interface with
the ability to communicate with hosts on the immediately attached
link only. To obtain a routable IPv4 address, some additional
mechanism is required.
Implementation issues likely to arise in implementing IPv4 link-local
address autoconfiguration include potential mandatory address changes
due to conflicts, support for more than one configuration per
interface and complications arising from multihomed devices applying
link-local autoconfiguration on more than one link. [7]
IPv6 stateless address autoconfiguration provides an interface with a
link-local address. This address together with a routing prefix
obtained via a router advertisement message enables the configured
Guttman, E. Expires: 11 January 2002 [Page 3]
Internet Draft Zeroconf Host Profile July 2001
interface to communicate globally.
There is substantial experience deploying both of these protocols.
[Editor: Issues and observations arising from that experience to go
here.]
3.1.3. Comparison against Zeroconf Requirements
The protocols recommended in section 3.1.1 fulfill all Zeroconf
requirments (see Section 2.1 of [5]).
[Editor: Is further detailed analysis required?]
3.2. Translation between Host name and IP Address
3.2.1. Zeroconf Requirements
Hosts which support the Zeroconf Host Profile MUST support Multicast
DNS. [10] This protocol is defined to work over IPv4 and IPv6.
3.2.2. Discussion
There has been no deployment experience with Multicast DNS to date.
There has been extensive experience with the AppleTalk Name Binding
Protocol (NBP) [4] and NetBIOS [RFC 1001]. [Editor: Issues and
observations arising from experience go here.]
3.2.3. Comparison against Zeroconf Requirements
The protocols recommended in section 3.2.1 fulfill all Zeroconf
requirments (see Section 2.2 of [5]).
[Editor: Is further detailed analysis required?]
3.3. IP Multicast Address Allocation
3.3.1 Zeroconf Host Profile Requirements
Hosts which will support applications which require unique multicast
address allocation MAY support the Zeroconf Multicast Address
Allocation Protocol (ZMAAP) [12].
Guttman, E. Expires: 11 January 2002 [Page 4]
Internet Draft Zeroconf Host Profile July 2001
3.3.2. Discussion
There has been no experience with ZMAAP to date.
3.3.3. Comparison against Zeroconf Requirements
The protocols recommended in section 3.3.1 fulfill all Zeroconf
requirments (see Section 2.3 of [5]).
[Editor: Is further detailed analysis required?]
3.4. Service Discovery
SLPv2 [RFC 2608] and DNS SRV RRs [RFC 2782] conveyed over mDNS
constitute two distinct options for service discovery for hosts
conforming to the Zeroconf Host Profile. The options are discussed
below.
This section employs the following terminology:
service
A particular logical function that may be invoked via some network
protocol, such as printing or storing a file on a remote disk.
service characteristics
Characteristics provide a finer granularity of description to
differentiate services beyond just the service type. For example
if the service type is printer, the characteristics may be color,
pages printed per second, location, etc.
service discovery protocol
A service discovery protocol enables clients to discover servers
(or peers to find other peers) of a particular service. A service
discovery protocol is an application layer protocol that relies on
network and transport protocol layers.
service protocol
A service protocol is used between the client and the server after
service discovery is complete.
distinct service
A service is distinct if services of the same type cannot be used
interchangeably by clients. Distinct services include those whose
physical location, capabilities, state, permissions, performance
characteristics or policy differs. A client will discern the
difference between service instances. For example, a client
seeking to print can only usefully send a job to a printer the
user has physical access to. A client attempting to access data
in a database can only do so if the correct database server
Guttman, E. Expires: 11 January 2002 [Page 5]
Internet Draft Zeroconf Host Profile July 2001
(containing the data the client wishes to access) can be located.
indistinct service
A service is indistinct if services of the same type can be used
interchangeably by clients. For example, any SMTP relay, DNS
server or IP gateway will generally provide the same function for
a client.
3.4.1. Zeroconf Host Profile Requirements
Hosts implementing the Zeroconf Host Profile SHOULD implement the
Service Location Protocol, Version 2 (SLPv2) [RFC 2608] to enable
discovery of distinct services. SLPv2 also enables discovery of
indistinct services. SLPv2 entails some modifications when
implemented over IPv6. [RFC 3111]
Hosts implementing the Zeroconf Host Profile SHOULD implement
Multicast DNS [10] and support the use of DNS SRV RRs. [RFC 2782]
3.4.2. Discussion
SLPv2 allows the use of service characteristics to distinguish
different instances of services. This allows a client to request
services on the basis of attributes, and locate the service which
fulfills the client's needs.
DNS SRV RRs allow services to be located by name. A client is not
able to distinguish between different services of the same named type
except by using a service protocol distinct from the service
discovery protocol.
In some cases, DNS SRV RR functionality suffices - and since support
for mDNS is already included in the Zeroconf Host Profile (as a
REQUIRED feature), the lightest-weight implementation may exclude
SLPv2 support.
The reason why one uses mDNS to issue requests for DNS SRV RRs is
that network services may not be present. If a host is configured to
use a DNS server, DNS [RFC 1034] is used instead of mDNS, as
described in [10].
SLPv1 and SLPv2 have been deployed in networks for some time.
[Editor: Include SLP deployment discussion here.]
DNS SRV RRs have been used by some applications to obtain service
locations. These resource records have not been used in conjunction
with mDNS so no guidance can be obtained from direct experience.
AppleTalk Name Bind Protocol [4], however, provides a very similar
function. [Editor: Include NBP observations here.]
Guttman, E. Expires: 11 January 2002 [Page 6]
Internet Draft Zeroconf Host Profile July 2001
Service discovery functionality can be considered as two
complementary functions - client discovery and server advertising. A
host which functions entirely as a service or as a client would need
to implement only those aspects of a service discovery protocol which
it needs to conform with the Zeroconf Host Profile. To be specific,
a host offered network services but never needed to discover them
could implement only SLPv2 Service Agent [RFC 2608] or mDNS server
[10] functions. A host which functioned as a client but never
offered services would only implement SLPv2 User Agent or mDNS
enhanced resolver functions.
3.4.3. Comparison against Zeroconf Requirements
The protocols recommended in section 3.4.1 fulfill all Zeroconf
requirments (see Section 2.4 of [5]).
[Editor: Is further detailed analysis required?]
4. Summary
FEATURE |SECTION| MUST | SHOULD | MAY |
--------------------------------|-------|------|--------|-----|
IP Interface Configuration |3.1 | | | |
IPv4 [7] | | X | | |
IPv4 [RFC 2461] [RFC 2462] | | X | | |
Translation between Host Name |3.2 | | | |
and IP Address [10] | | X | | |
IP Multicast Address Allocation |3.3 | | | |
[12] | | | | X |
Service Discovery |3.4 | | | |
Distinct - [RFC 2608] | | | X | |
Indistinct - [10] [RFC 2782] | | | X | |
--------------------------------|-------|------|--------|-----|
4. Security Considerations
Security considerations of Zeroconf protocols is discussed in [5].
Hosts conforming to the Zeroconf Host Profile MUST support the
security features present in the protocols included in this profile
which they implement.
References
[RFC 1812] Baker, F. (Editor), "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
Guttman, E. Expires: 11 January 2002 [Page 7]
Internet Draft Zeroconf Host Profile July 2001
[RFC 1122] Braden, R. (Editor), "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC 1123] Braden, R. (Editor), "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[4] Sidhu, G., et. al., "Inside AppleTalk", Second Edition, Apple
Computer, Inc, Addison-Wesley, ISBN 0-201-55021-0, 1990.
[5] Hattig, M., "Zeroconf Requirements", draft-ietf-zeroconf-reqts-
08.txt, May 2001. Work in progress.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Cheshire, S., "Dynamic Configuration of IPv4 link-local
addresses", draft-ietf-zeroconf-ipv4-linklocal-03.txt, June
2001. Work in progress.
[RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC 2462] Thomson, S., Narten, T., "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[10] Ebisov, L., Aboba, B., Thaler, D., "Multicast DNS", draft-ietf-
dnsext-mdns-01.txt, July, 2001. Work in progress.
[RFC 1001] Auerbach, K., Aggarwal, A., (editors), "PROTOCOL STANDARD
FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND
METHODS", RFC 1001, March 1987.
[12] Catrina, O. (Editor), Thaler, D., Aboba, B., Guttman, E.,
"Zeroconf Multicast Address Allocation Protocol (ZMAAP)",
draft-ietf-zeroconf-zmaap-01.txt. Work in Progress.
[RFC 2608] Guttman, E., Perkins, C., Veizades, J., Day, M., "Service
Location Protocol, Version 2", RFC 2608, July 1999.
[RFC 3111] Guttman, E., "Service Location Protocol Modifications for
IPv6", RFC 3111, May 2001.
[RFC 2782] Gulbrandsen, A., Vixie, P., Ebisov, L., "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC 1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
Guttman, E. Expires: 11 January 2002 [Page 8]
Internet Draft Zeroconf Host Profile July 2001
Authors' Addresses
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt
Germany
Phone: +49 172 865 5497 Email: erik.guttman@sun.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Guttman, E. Expires: 11 January 2002 [Page 9]
