draft-ietf-zeroconf-host-prof-00.txt   draft-ietf-zeroconf-host-prof-01.txt 
NETWORK Working Group Erik Guttman NETWORK Working Group Erik Guttman
INTERNET-DRAFT Sun Microsystems INTERNET-DRAFT Sun Microsystems
Intended Category: Best Current Practice Category: Standards Track
11 July 2001 20 July 2001
Expires in six months Expires in six months
Zeroconf Host Profile Zeroconf Host Profile Applicability Statement
<draft-ietf-zeroconf-host-prof-00.txt> <draft-ietf-zeroconf-host-prof-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Comments on this document should be sent to the author and to the Comments on this document should be sent to the author and to the
Zeroconf Working Group mailing list: zeroconf@merit.edu. Zeroconf Working Group mailing list: zeroconf@merit.edu.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 42 skipping to change at page 1, line 42
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document specifies a set of Zero Configuration Protocols which
combined support the Zero Configuration domain of applicability.
This host profile supports the same upper layer feature set as
defined in STD 3 [RFC 1123] by hosts lacking any prior configuration,
though in a restricted domain.
1. Introduction
The Internet Standards Process [RFC 2026], Section 3.2, defines how
applicability statements are standardized to associate sets of
protocols for a particular domain of applicabiliy. This
specification defines the Zero Configuration domain of applicability
and a set of protocols which support it.
Requirements for Internet routers [RFC 1812] and hosts [RFC 1122] Requirements for Internet routers [RFC 1812] and hosts [RFC 1122]
[RFC 1123] provide guidance to vendors and users of Internet [RFC 1123] provide guidance to vendors and users of Internet
communication software. They represent consensus arising from communication software. They represent consensus arising from
experience. This document similarly associates a set of protocols experience. This document similarly associates a set of protocols
together for a particular purpose. In contrast to router and host together for a particular purpose. In contrast to router and host
requirements standards, the Zeroconf Host Profile does not arise out requirements standards, the Zeroconf Host Profile does not arise out
of experience, (though relevant experience is cited.) Instead, this of experience, (though relevant experience is cited.) Instead, this
comprises a set of protocols which complement each other when comprises a set of protocols which complement each other when
implemented together. implemented together.
1. Introduction
The goal of the Zero Configuration Networking (ZEROCONF) Working The goal of the Zero Configuration Networking (ZEROCONF) Working
Group is to enable networking in the absence of configuration and Group is to enable networking in the absence of configuration and
administration. Zero configuration networking is required for administration. Zero configuration networking is required for
environments where administration is impractical or impossible, such environments where administration is impractical or impossible, such
as in the home or small office, embedded systems' plugged together' as in the home or small office, embedded systems' plugged together'
as in an automobile, or to allow impromptu networks as between the as in an automobile, or to allow impromptu networks as between the
devices of strangers on a train. devices of strangers on a train.
As noted in STD 3 [RFC 1122], the current internet suite of protocols As noted in STD 3 [RFC 1122], the current internet suite of protocols
fall short of this goal. fall short of this goal.
skipping to change at page 2, line 36 skipping to change at page 2, line 46
This document describes a host profile which provides zero This document describes a host profile which provides zero
configuration operation. Like STD 3, this document describes a set configuration operation. Like STD 3, this document describes a set
of protocols and makes recommendations with respect to their of protocols and makes recommendations with respect to their
implementation. Unlike the the mechanisms described in STD 3, we implementation. Unlike the the mechanisms described in STD 3, we
have limited experience with many Zeroconf protocols; some are only have limited experience with many Zeroconf protocols; some are only
now emerging as IETF standards track specifications. Still, we have now emerging as IETF standards track specifications. Still, we have
extensive experience with related protocols, which provided the extensive experience with related protocols, which provided the
inspiration for the Zeroconf working group and Zeroconf protocols, inspiration for the Zeroconf working group and Zeroconf protocols,
specifically the AppleTalk protocol suite [4]. 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 2. Terminology
Terminology specific to discussion of particular zeroconf protocols Terminology specific to discussion of particular zeroconf protocols
is introduced in the appropriate section. is introduced in the appropriate section.
In this document, the key words "MAY", "MUST, "MUST NOT", In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [RFC 2119]. interpreted as described in [RFC 2119].
3. Zeroconf Host Profile Requirements and Recommendations 3. The Zero Configuration Domain of Applicability
Hosts which lack any specific configuration have zero configuration.
The zero configuration domain of applicability concerns hosts with
zero configuration for specific functions
3.1. Zero configuration is not all or nothing
A host may be configured with regard to some functions and have zero
configuration for others. For example, a host may lack IP interface
configuration (described in Section 4.1) but have naming
configuration (described in Section 4.2) In this case, zero
configuration IP interface autoconfiguration will be used by a host
adhering to the Zeroconf Host Profile.
3.2. Configured vs. Zero Configuration Protocol behavior
Zero configuration behavior in each area is well defined. The
specific behavior of a host when it becomes configured varies. Each
protocol which supports the zero configuration protocol requirements
varies in this respect.
IPv4 Link-local IP Interace Configuration [7] and IPv6 address
autoconfiguration, [RFC 2461] and ZMAAP [12] are used whether an
interface is configued or not.
Link-local Multicast DNS [10] by default is only used when a host has
no configured DNS server, unless specifically configure to enable
link-local Multicast behavior.
SLPv2 [RFC 2608] always operates in a zero configuration mode,
transitions in behavior and reconfiguration occur automatically.
(SLPv2 agents may also be configured manually, but that does this
does not reduce or change their automatic functions.)
3.3. Scalability and network configuration
The zero configuration domain of applicability includes any IP
network which supports multicast (though only broadcast is needed for
IPv4 link-local interface configuration). Some protocols described
in this applicability statement are defined to only operate using
link-local addressing and link-local scope multicast. This is not an
inherant limitation of this domain of applicability - for example,
SLPv2 [RFC 2608] is defined to operate at admin local scope [RFC
2365] for IPv4 and site local scope for IPv6. [RFC 3111] In any
case, the zero configuration domain of applicability is a network
under a single common administration, and in some cases only a single
network link.
4. Zeroconf Host Profile Requirements and Recommendations
IP Interface Configuration and name resolution services are host IP Interface Configuration and name resolution services are host
requirements (see section 3.3.1.6 [RFC 1122], 6.1.1 [RFC 1123]). A requirements (see section 3.3.1.6 [RFC 1122], 6.1.1 [RFC 1123]). A
zeroconf host MUST implement these features. zeroconf host MUST implement these features.
Service discovery constitutes one of the most useful features of the Service discovery constitutes one of the most useful features of the
AppleTalk protocol suite [4]. The ease of user configuration from AppleTalk protocol suite [4]. The ease of user configuration from
standard service discovery facilities has proved so important that standard service discovery facilities has proved so important that
this feature alone has been decisive in continuing support for this feature alone has been decisive in continuing support for
AppleTalk in many networks. For this reason, a zeroconf host SHOULD AppleTalk in many networks. For this reason, a zeroconf host SHOULD
skipping to change at page 3, line 27 skipping to change at page 4, line 27
Some multicast applications require the allocation of multicast Some multicast applications require the allocation of multicast
addresses which do not conflict with other address allocations. addresses which do not conflict with other address allocations.
Zeroconf hosts MAY implement multicast address allocation functions Zeroconf hosts MAY implement multicast address allocation functions
to support these applications. to support these applications.
The protocols included in the Zeroconf Host Profile provide The protocols included in the Zeroconf Host Profile provide
equivalent functions when run over IPv4 and IPv6. Where there are equivalent functions when run over IPv4 and IPv6. Where there are
differences, these are noted. differences, these are noted.
3.1. IP Interface Configuration 4.1. IP Interface Configuration
3.1.1. Zeroconf Requirements 4.1.1. Zeroconf Requirements
Hosts which support IPv4 and the Zeroconf Host Profile MUST implement Hosts which support IPv4 and the Zeroconf Host Profile MUST implement
IPv4 Link-local IP Interace Configuration. [7] IPv4 Link-local IP Interace Configuration. [7]
Hosts which support IPv6 and the Zeroconf Host Profile MUST implement Hosts which support IPv6 and the Zeroconf Host Profile MUST implement
IPv6 Stateless Address Autoconfiguration. [RFC 2461] [RFC 2462] IPv6 Stateless Address Autoconfiguration. [RFC 2461] [RFC 2462]
3.1.2. Discussion 4.1.2. Discussion
IPv4 link-local address autoconfiguration provides an interface with IPv4 link-local address autoconfiguration provides an interface with
the ability to communicate with hosts on the immediately attached the ability to communicate with hosts on the immediately attached
link only. To obtain a routable IPv4 address, some additional link only. To obtain a routable IPv4 address, some additional
mechanism is required. mechanism is required.
Implementation issues likely to arise in implementing IPv4 link-local Implementation issues likely to arise in implementing IPv4 link-local
address autoconfiguration include potential mandatory address changes address autoconfiguration include potential mandatory address changes
due to conflicts, support for more than one configuration per due to conflicts, support for more than one configuration per
interface and complications arising from multihomed devices applying interface and complications arising from multihomed devices applying
skipping to change at page 4, line 7 skipping to change at page 5, line 4
due to conflicts, support for more than one configuration per due to conflicts, support for more than one configuration per
interface and complications arising from multihomed devices applying interface and complications arising from multihomed devices applying
link-local autoconfiguration on more than one link. [7] link-local autoconfiguration on more than one link. [7]
IPv6 stateless address autoconfiguration provides an interface with a IPv6 stateless address autoconfiguration provides an interface with a
link-local address. This address together with a routing prefix link-local address. This address together with a routing prefix
obtained via a router advertisement message enables the configured obtained via a router advertisement message enables the configured
interface to communicate globally. interface to communicate globally.
There is substantial experience deploying both of these protocols. There is substantial experience deploying both of these protocols.
[Editor: Issues and observations arising from that experience to go [Editor: Issues and observations arising from that experience to go
here.] here.]
3.1.3. Comparison against Zeroconf Requirements 4.1.3. Comparison against Zeroconf Requirements
The protocols recommended in section 3.1.1 fulfill all Zeroconf The protocols recommended in section 3.1.1 fulfill all Zeroconf
requirments (see Section 2.1 of [5]). requirments (see Section 2.1 of [5]).
[Editor: Is further detailed analysis required?] [Editor: Is further detailed analysis required?]
3.2. Translation between Host name and IP Address 4.2. Translation between Host name and IP Address
3.2.1. Zeroconf Requirements 4.2.1. Zeroconf Requirements
Hosts which support the Zeroconf Host Profile MUST support Multicast Hosts which support the Zeroconf Host Profile MUST support Multicast
DNS. [10] This protocol is defined to work over IPv4 and IPv6. DNS. [10] This protocol is defined to work over IPv4 and IPv6.
3.2.2. Discussion 4.2.2. Discussion
There has been no deployment experience with Multicast DNS to date. There has been no deployment experience with Multicast DNS to date.
There has been extensive experience with the AppleTalk Name Binding There has been extensive experience with the AppleTalk Name Bind
Protocol (NBP) [4] and NetBIOS [RFC 1001]. [Editor: Issues and Protocol (NBP) [4] and NetBIOS [RFC 1001]. [Editor: Issues and
observations arising from experience go here.] observations arising from experience go here.]
3.2.3. Comparison against Zeroconf Requirements 4.2.3. Comparison against Zeroconf Requirements
The protocols recommended in section 3.2.1 fulfill all Zeroconf The protocols recommended in section 3.2.1 fulfill all Zeroconf
requirments (see Section 2.2 of [5]). requirments (see Section 2.2 of [5]).
[Editor: Is further detailed analysis required?] [Editor: Is further detailed analysis required?]
3.3. IP Multicast Address Allocation 4.3. IP Multicast Address Allocation
3.3.1 Zeroconf Host Profile Requirements 4.3.1 Zeroconf Host Profile Requirements
Hosts which will support applications which require unique multicast Hosts which will support applications which require unique multicast
address allocation MAY support the Zeroconf Multicast Address address allocation MAY support the Zeroconf Multicast Address
Allocation Protocol (ZMAAP) [12]. Allocation Protocol (ZMAAP) [12].
3.3.2. Discussion 4.3.2. Discussion
There has been no experience with ZMAAP to date. There has been no experience with ZMAAP to date.
3.3.3. Comparison against Zeroconf Requirements 4.3.3. Comparison against Zeroconf Requirements
The protocols recommended in section 3.3.1 fulfill all Zeroconf The protocols recommended in section 3.3.1 fulfill all Zeroconf
requirments (see Section 2.3 of [5]). requirments (see Section 2.3 of [5]).
[Editor: Is further detailed analysis required?] [Editor: Is further detailed analysis required?]
3.4. Service Discovery 4.4. Service Discovery
SLPv2 [RFC 2608] and DNS SRV RRs [RFC 2782] conveyed over mDNS SLPv2 [RFC 2608] and DNS SRV RRs [RFC 2782] conveyed over mDNS
constitute two distinct options for service discovery for hosts constitute two distinct options for service discovery for hosts
conforming to the Zeroconf Host Profile. The options are discussed conforming to the Zeroconf Host Profile. The options are discussed
below. below.
This section employs the following terminology: This section employs the following terminology:
service service
A particular logical function that may be invoked via some network A particular logical function that may be invoked via some network
skipping to change at page 6, line 12 skipping to change at page 6, line 51
user has physical access to. A client attempting to access data user has physical access to. A client attempting to access data
in a database can only do so if the correct database server in a database can only do so if the correct database server
(containing the data the client wishes to access) can be located. (containing the data the client wishes to access) can be located.
indistinct service indistinct service
A service is indistinct if services of the same type can be used A service is indistinct if services of the same type can be used
interchangeably by clients. For example, any SMTP relay, DNS interchangeably by clients. For example, any SMTP relay, DNS
server or IP gateway will generally provide the same function for server or IP gateway will generally provide the same function for
a client. a client.
3.4.1. Zeroconf Host Profile Requirements 4.4.1. Zeroconf Host Profile Requirements
Hosts implementing the Zeroconf Host Profile SHOULD implement the Hosts implementing the Zeroconf Host Profile SHOULD implement the
Service Location Protocol, Version 2 (SLPv2) [RFC 2608] to enable Service Location Protocol, Version 2 (SLPv2) [RFC 2608] to enable
discovery of distinct services. SLPv2 also enables discovery of discovery of distinct services. SLPv2 also enables discovery of
indistinct services. SLPv2 entails some modifications when indistinct services. SLPv2 entails some modifications when
implemented over IPv6. [RFC 3111] implemented over IPv6. [RFC 3111]
Hosts implementing the Zeroconf Host Profile SHOULD implement Hosts implementing the Zeroconf Host Profile SHOULD implement
Multicast DNS [10] and support the use of DNS SRV RRs. [RFC 2782] Multicast DNS [10] and support the use of DNS SRV RRs. [RFC 2782]
3.4.2. Discussion 4.4.2. Discussion
SLPv2 allows the use of service characteristics to distinguish SLPv2 allows the use of service characteristics to distinguish
different instances of services. This allows a client to request different instances of services. This allows a client to request
services on the basis of attributes, and locate the service which services on the basis of attributes, and locate the service which
fulfills the client's needs. fulfills the client's needs.
DNS SRV RRs allow services to be located by name. A client is not 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 able to distinguish between different services of the same named type
except by using a service protocol distinct from the service except by using a service protocol distinct from the service
discovery protocol. discovery protocol.
skipping to change at page 7, line 4 skipping to change at page 7, line 40
described in [10]. described in [10].
SLPv1 and SLPv2 have been deployed in networks for some time. SLPv1 and SLPv2 have been deployed in networks for some time.
[Editor: Include SLP deployment discussion here.] [Editor: Include SLP deployment discussion here.]
DNS SRV RRs have been used by some applications to obtain service DNS SRV RRs have been used by some applications to obtain service
locations. These resource records have not been used in conjunction locations. These resource records have not been used in conjunction
with mDNS so no guidance can be obtained from direct experience. with mDNS so no guidance can be obtained from direct experience.
AppleTalk Name Bind Protocol [4], however, provides a very similar AppleTalk Name Bind Protocol [4], however, provides a very similar
function. [Editor: Include NBP observations here.] function. [Editor: Include NBP observations here.]
Service discovery functionality can be considered as two Service discovery functionality can be considered as two
complementary functions - client discovery and server advertising. A complementary functions - client discovery and server advertising. A
host which functions entirely as a service or as a client would need host which functions entirely as a service or as a client would need
to implement only those aspects of a service discovery protocol which to implement only those aspects of a service discovery protocol which
it needs to conform with the Zeroconf Host Profile. To be specific, it needs to conform with the Zeroconf Host Profile. To be specific,
a host offered network services but never needed to discover them a host offered network services but never needed to discover them
could implement only SLPv2 Service Agent [RFC 2608] or mDNS server could implement only SLPv2 Service Agent [12] or mDNS server [10]
[10] functions. A host which functioned as a client but never functions. A host which functioned as a client but never offered
offered services would only implement SLPv2 User Agent or mDNS services would only implement SLPv2 User Agent or mDNS enhanced
enhanced resolver functions. resolver functions.
3.4.3. Comparison against Zeroconf Requirements 4.4.3. Comparison against Zeroconf Requirements
The protocols recommended in section 3.4.1 fulfill all Zeroconf The protocols recommended in section 3.4.1 fulfill all Zeroconf
requirments (see Section 2.4 of [5]). requirments (see Section 2.4 of [5]).
[Editor: Is further detailed analysis required?] [Editor: Is further detailed analysis required?]
4. Summary 5. Requirement Levels
FEATURE |SECTION| MUST | SHOULD | MAY | As required by [RFC 2026], Section 3.3, each technical specification
IP Interface Configuration |3.1 | | | | which is cited must be associated with a requirement level.
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 FEATURE |SECTION|REQUIRED|RECOMMENDED|ELECTIVE|
--------------------------------|-------|--------|-----------|--------|
IP Interface Configuration |3.1 | X | | |
Translation between Host Name |3.2 | X | | |
and IP Address | | | | |
IP Multicast Address Allocation |3.3 | | | X |
Service Discovery - |3.4 | | X | |
--------------------------------|-------|--------|-----------|--------|
6. Security Considerations
Security considerations of Zeroconf protocols is discussed in [5]. Security considerations of Zeroconf protocols is discussed in [5].
Hosts conforming to the Zeroconf Host Profile MUST support the Hosts conforming to the Zeroconf Host Profile MUST support the
security features present in the protocols included in this profile security features present in the protocols included in this profile
which they implement. which they implement.
References References
[RFC 1812] Baker, F. (Editor), "Requirements for IP Version 4 [RFC 1812] Baker, F. (Editor), "Requirements for IP Version 4
Routers", RFC 1812, June 1995. Routers", RFC 1812, June 1995.
skipping to change at page 8, line 21 skipping to change at page 9, line 6
[4] Sidhu, G., et. al., "Inside AppleTalk", Second Edition, Apple [4] Sidhu, G., et. al., "Inside AppleTalk", Second Edition, Apple
Computer, Inc, Addison-Wesley, ISBN 0-201-55021-0, 1990. Computer, Inc, Addison-Wesley, ISBN 0-201-55021-0, 1990.
[5] Hattig, M., "Zeroconf Requirements", draft-ietf-zeroconf-reqts- [5] Hattig, M., "Zeroconf Requirements", draft-ietf-zeroconf-reqts-
08.txt, May 2001. Work in progress. 08.txt, May 2001. Work in progress.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Cheshire, S., "Dynamic Configuration of IPv4 link-local [7] Cheshire, S., "Dynamic Configuration of IPv4 link-local
addresses", draft-ietf-zeroconf-ipv4-linklocal-03.txt, June addresses", draft-ietf-zeroconf-ipv4-linklocal-04.txt Work in
2001. Work in progress. progress.
[RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery [RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC 2462] Thomson, S., Narten, T., "IPv6 Stateless Address [RFC 2462] Thomson, S., Narten, T., "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[10] Ebisov, L., Aboba, B., Thaler, D., "Multicast DNS", draft-ietf- [10] Ebisov, L., Aboba, B., Thaler, D., "Multicast DNS", draft-ietf-
dnsext-mdns-01.txt, July, 2001. Work in progress. dnsext-mdns-02.txt. Work in progress.
[RFC 1001] Auerbach, K., Aggarwal, A., (editors), "PROTOCOL STANDARD [RFC 1001] Auerbach, K., Aggarwal, A., (editors), "PROTOCOL STANDARD
FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND
METHODS", RFC 1001, March 1987. METHODS", RFC 1001, March 1987.
[12] Catrina, O. (Editor), Thaler, D., Aboba, B., Guttman, E., [12] Catrina, O. (Editor), Thaler, D., Aboba, B., Guttman, E.,
"Zeroconf Multicast Address Allocation Protocol (ZMAAP)", "Zeroconf Multicast Address Allocation Protocol (ZMAAP)",
draft-ietf-zeroconf-zmaap-01.txt. Work in Progress. draft-ietf-zeroconf-zmaap-01.txt. Work in Progress.
[RFC 2608] Guttman, E., Perkins, C., Veizades, J., Day, M., "Service [RFC 2608] Guttman, E., Perkins, C., Veizades, J., Day, M., "Service
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/