idnits 2.17.1 draft-ietf-zeroconf-host-prof-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC1122], [RFC1812], [RFC1123]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (11 July 2001) is 8318 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-12) exists of draft-ietf-zeroconf-reqts-08 ** Downref: Normative reference to an Informational draft: draft-ietf-zeroconf-reqts (ref. '5') == Outdated reference: A later version (-17) exists of draft-ietf-zeroconf-ipv4-linklocal-03 ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) == Outdated reference: A later version (-47) exists of draft-ietf-dnsext-mdns-01 ** Downref: Normative reference to an Informational draft: draft-ietf-dnsext-mdns (ref. '10') == Outdated reference: A later version (-02) exists of draft-ietf-zeroconf-zmaap-01 -- Possible downref: Normative reference to a draft: ref. '12' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK Working Group Erik Guttman 3 INTERNET-DRAFT Sun Microsystems 4 Intended Category: Best Current Practice 5 11 July 2001 6 Expires in six months 8 Zeroconf Host Profile 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Comments on this document should be sent to the author and to the 17 Zeroconf Working Group mailing list: zeroconf@merit.edu. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). All Rights Reserved. 39 Abstract 41 Requirements for Internet routers [RFC 1812] and hosts [RFC 1122] 42 [RFC 1123] provide guidance to vendors and users of Internet 43 communication software. They represent consensus arising from 44 experience. This document similarly associates a set of protocols 45 together for a particular purpose. In contrast to router and host 46 requirements standards, the Zeroconf Host Profile does not arise out 47 of experience, (though relevant experience is cited.) Instead, this 48 comprises a set of protocols which complement each other when 49 implemented together. 51 1. Introduction 53 The goal of the Zero Configuration Networking (ZEROCONF) Working 54 Group is to enable networking in the absence of configuration and 55 administration. Zero configuration networking is required for 56 environments where administration is impractical or impossible, such 57 as in the home or small office, embedded systems' plugged together' 58 as in an automobile, or to allow impromptu networks as between the 59 devices of strangers on a train. 61 As noted in STD 3 [RFC 1122], the current internet suite of protocols 62 fall short of this goal. 64 It would be ideal if a host implementation of the Internet 65 protocol suite could be entirely self-configuring. This would 66 allow the whole suite to be implemented in ROM or cast into 67 silicon, it would simplify diskless workstations, and it would be 68 an immense boon to harried LAN administrators as well as system 69 vendors. We have not reached this ideal; in fact, we are not even 70 close. 72 This document describes a host profile which provides zero 73 configuration operation. Like STD 3, this document describes a set 74 of protocols and makes recommendations with respect to their 75 implementation. Unlike the the mechanisms described in STD 3, we 76 have limited experience with many Zeroconf protocols; some are only 77 now emerging as IETF standards track specifications. Still, we have 78 extensive experience with related protocols, which provided the 79 inspiration for the Zeroconf working group and Zeroconf protocols, 80 specifically the AppleTalk protocol suite [4]. 82 This document defines a profile - a set of related protocols which 83 complement each other so as to provide a minimum interoperable set of 84 functions to enable communication in the absence of administration 85 and network services. The requirements and scenarios for use of 86 these protocols is described in the Zeroconf Requirements [5]. Just 87 as Router Requirements have no bearing on devices which support IP 88 without forwarding packets, the Zeroconf profile specifies only the 89 behavior of devices which perform automatic configuration. 91 2. Terminology 93 Terminology specific to discussion of particular zeroconf protocols 94 is introduced in the appropriate section. 96 In this document, the key words "MAY", "MUST, "MUST NOT", 97 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 98 interpreted as described in [RFC 2119]. 100 3. Zeroconf Host Profile Requirements and Recommendations 102 IP Interface Configuration and name resolution services are host 103 requirements (see section 3.3.1.6 [RFC 1122], 6.1.1 [RFC 1123]). A 104 zeroconf host MUST implement these features. 106 Service discovery constitutes one of the most useful features of the 107 AppleTalk protocol suite [4]. The ease of user configuration from 108 standard service discovery facilities has proved so important that 109 this feature alone has been decisive in continuing support for 110 AppleTalk in many networks. For this reason, a zeroconf host SHOULD 111 implement service discovery functions. 113 Some multicast applications require the allocation of multicast 114 addresses which do not conflict with other address allocations. 115 Zeroconf hosts MAY implement multicast address allocation functions 116 to support these applications. 118 The protocols included in the Zeroconf Host Profile provide 119 equivalent functions when run over IPv4 and IPv6. Where there are 120 differences, these are noted. 122 3.1. IP Interface Configuration 124 3.1.1. Zeroconf Requirements 126 Hosts which support IPv4 and the Zeroconf Host Profile MUST implement 127 IPv4 Link-local IP Interace Configuration. [7] 129 Hosts which support IPv6 and the Zeroconf Host Profile MUST implement 130 IPv6 Stateless Address Autoconfiguration. [RFC 2461] [RFC 2462] 132 3.1.2. Discussion 134 IPv4 link-local address autoconfiguration provides an interface with 135 the ability to communicate with hosts on the immediately attached 136 link only. To obtain a routable IPv4 address, some additional 137 mechanism is required. 139 Implementation issues likely to arise in implementing IPv4 link-local 140 address autoconfiguration include potential mandatory address changes 141 due to conflicts, support for more than one configuration per 142 interface and complications arising from multihomed devices applying 143 link-local autoconfiguration on more than one link. [7] 145 IPv6 stateless address autoconfiguration provides an interface with a 146 link-local address. This address together with a routing prefix 147 obtained via a router advertisement message enables the configured 148 interface to communicate globally. 150 There is substantial experience deploying both of these protocols. 151 [Editor: Issues and observations arising from that experience to go 152 here.] 154 3.1.3. Comparison against Zeroconf Requirements 156 The protocols recommended in section 3.1.1 fulfill all Zeroconf 157 requirments (see Section 2.1 of [5]). 159 [Editor: Is further detailed analysis required?] 161 3.2. Translation between Host name and IP Address 163 3.2.1. Zeroconf Requirements 165 Hosts which support the Zeroconf Host Profile MUST support Multicast 166 DNS. [10] This protocol is defined to work over IPv4 and IPv6. 168 3.2.2. Discussion 170 There has been no deployment experience with Multicast DNS to date. 171 There has been extensive experience with the AppleTalk Name Binding 172 Protocol (NBP) [4] and NetBIOS [RFC 1001]. [Editor: Issues and 173 observations arising from experience go here.] 175 3.2.3. Comparison against Zeroconf Requirements 177 The protocols recommended in section 3.2.1 fulfill all Zeroconf 178 requirments (see Section 2.2 of [5]). 180 [Editor: Is further detailed analysis required?] 182 3.3. IP Multicast Address Allocation 184 3.3.1 Zeroconf Host Profile Requirements 186 Hosts which will support applications which require unique multicast 187 address allocation MAY support the Zeroconf Multicast Address 188 Allocation Protocol (ZMAAP) [12]. 190 3.3.2. Discussion 192 There has been no experience with ZMAAP to date. 194 3.3.3. Comparison against Zeroconf Requirements 196 The protocols recommended in section 3.3.1 fulfill all Zeroconf 197 requirments (see Section 2.3 of [5]). 199 [Editor: Is further detailed analysis required?] 201 3.4. Service Discovery 203 SLPv2 [RFC 2608] and DNS SRV RRs [RFC 2782] conveyed over mDNS 204 constitute two distinct options for service discovery for hosts 205 conforming to the Zeroconf Host Profile. The options are discussed 206 below. 208 This section employs the following terminology: 210 service 211 A particular logical function that may be invoked via some network 212 protocol, such as printing or storing a file on a remote disk. 214 service characteristics 215 Characteristics provide a finer granularity of description to 216 differentiate services beyond just the service type. For example 217 if the service type is printer, the characteristics may be color, 218 pages printed per second, location, etc. 220 service discovery protocol 221 A service discovery protocol enables clients to discover servers 222 (or peers to find other peers) of a particular service. A service 223 discovery protocol is an application layer protocol that relies on 224 network and transport protocol layers. 226 service protocol 227 A service protocol is used between the client and the server after 228 service discovery is complete. 230 distinct service 231 A service is distinct if services of the same type cannot be used 232 interchangeably by clients. Distinct services include those whose 233 physical location, capabilities, state, permissions, performance 234 characteristics or policy differs. A client will discern the 235 difference between service instances. For example, a client 236 seeking to print can only usefully send a job to a printer the 237 user has physical access to. A client attempting to access data 238 in a database can only do so if the correct database server 239 (containing the data the client wishes to access) can be located. 241 indistinct service 242 A service is indistinct if services of the same type can be used 243 interchangeably by clients. For example, any SMTP relay, DNS 244 server or IP gateway will generally provide the same function for 245 a client. 247 3.4.1. Zeroconf Host Profile Requirements 249 Hosts implementing the Zeroconf Host Profile SHOULD implement the 250 Service Location Protocol, Version 2 (SLPv2) [RFC 2608] to enable 251 discovery of distinct services. SLPv2 also enables discovery of 252 indistinct services. SLPv2 entails some modifications when 253 implemented over IPv6. [RFC 3111] 255 Hosts implementing the Zeroconf Host Profile SHOULD implement 256 Multicast DNS [10] and support the use of DNS SRV RRs. [RFC 2782] 258 3.4.2. Discussion 260 SLPv2 allows the use of service characteristics to distinguish 261 different instances of services. This allows a client to request 262 services on the basis of attributes, and locate the service which 263 fulfills the client's needs. 265 DNS SRV RRs allow services to be located by name. A client is not 266 able to distinguish between different services of the same named type 267 except by using a service protocol distinct from the service 268 discovery protocol. 270 In some cases, DNS SRV RR functionality suffices - and since support 271 for mDNS is already included in the Zeroconf Host Profile (as a 272 REQUIRED feature), the lightest-weight implementation may exclude 273 SLPv2 support. 275 The reason why one uses mDNS to issue requests for DNS SRV RRs is 276 that network services may not be present. If a host is configured to 277 use a DNS server, DNS [RFC 1034] is used instead of mDNS, as 278 described in [10]. 280 SLPv1 and SLPv2 have been deployed in networks for some time. 281 [Editor: Include SLP deployment discussion here.] 283 DNS SRV RRs have been used by some applications to obtain service 284 locations. These resource records have not been used in conjunction 285 with mDNS so no guidance can be obtained from direct experience. 286 AppleTalk Name Bind Protocol [4], however, provides a very similar 287 function. [Editor: Include NBP observations here.] 288 Service discovery functionality can be considered as two 289 complementary functions - client discovery and server advertising. A 290 host which functions entirely as a service or as a client would need 291 to implement only those aspects of a service discovery protocol which 292 it needs to conform with the Zeroconf Host Profile. To be specific, 293 a host offered network services but never needed to discover them 294 could implement only SLPv2 Service Agent [RFC 2608] or mDNS server 295 [10] functions. A host which functioned as a client but never 296 offered services would only implement SLPv2 User Agent or mDNS 297 enhanced resolver functions. 299 3.4.3. Comparison against Zeroconf Requirements 301 The protocols recommended in section 3.4.1 fulfill all Zeroconf 302 requirments (see Section 2.4 of [5]). 304 [Editor: Is further detailed analysis required?] 306 4. Summary 308 FEATURE |SECTION| MUST | SHOULD | MAY | 309 --------------------------------|-------|------|--------|-----| 310 IP Interface Configuration |3.1 | | | | 311 IPv4 [7] | | X | | | 312 IPv4 [RFC 2461] [RFC 2462] | | X | | | 313 Translation between Host Name |3.2 | | | | 314 and IP Address [10] | | X | | | 315 IP Multicast Address Allocation |3.3 | | | | 316 [12] | | | | X | 317 Service Discovery |3.4 | | | | 318 Distinct - [RFC 2608] | | | X | | 319 Indistinct - [10] [RFC 2782] | | | X | | 320 --------------------------------|-------|------|--------|-----| 322 4. Security Considerations 324 Security considerations of Zeroconf protocols is discussed in [5]. 325 Hosts conforming to the Zeroconf Host Profile MUST support the 326 security features present in the protocols included in this profile 327 which they implement. 329 References 331 [RFC 1812] Baker, F. (Editor), "Requirements for IP Version 4 332 Routers", RFC 1812, June 1995. 334 [RFC 1122] Braden, R. (Editor), "Requirements for Internet Hosts -- 335 Communication Layers", STD 3, RFC 1122, October 1989. 337 [RFC 1123] Braden, R. (Editor), "Requirements for Internet Hosts -- 338 Application and Support", STD 3, RFC 1123, October 1989. 340 [4] Sidhu, G., et. al., "Inside AppleTalk", Second Edition, Apple 341 Computer, Inc, Addison-Wesley, ISBN 0-201-55021-0, 1990. 343 [5] Hattig, M., "Zeroconf Requirements", draft-ietf-zeroconf-reqts- 344 08.txt, May 2001. Work in progress. 346 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [7] Cheshire, S., "Dynamic Configuration of IPv4 link-local 350 addresses", draft-ietf-zeroconf-ipv4-linklocal-03.txt, June 351 2001. Work in progress. 353 [RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery 354 for IP Version 6 (IPv6)", RFC 2461, December 1998. 356 [RFC 2462] Thomson, S., Narten, T., "IPv6 Stateless Address 357 Autoconfiguration", RFC 2462, December 1998. 359 [10] Ebisov, L., Aboba, B., Thaler, D., "Multicast DNS", draft-ietf- 360 dnsext-mdns-01.txt, July, 2001. Work in progress. 362 [RFC 1001] Auerbach, K., Aggarwal, A., (editors), "PROTOCOL STANDARD 363 FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND 364 METHODS", RFC 1001, March 1987. 366 [12] Catrina, O. (Editor), Thaler, D., Aboba, B., Guttman, E., 367 "Zeroconf Multicast Address Allocation Protocol (ZMAAP)", 368 draft-ietf-zeroconf-zmaap-01.txt. Work in Progress. 370 [RFC 2608] Guttman, E., Perkins, C., Veizades, J., Day, M., "Service 371 Location Protocol, Version 2", RFC 2608, July 1999. 373 [RFC 3111] Guttman, E., "Service Location Protocol Modifications for 374 IPv6", RFC 3111, May 2001. 376 [RFC 2782] Gulbrandsen, A., Vixie, P., Ebisov, L., "A DNS RR for 377 specifying the location of services (DNS SRV)", RFC 2782, 378 February 2000. 380 [RFC 1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 381 RFC 1034, November 1987. 383 Authors' Addresses 385 Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt 386 Germany 388 Phone: +49 172 865 5497 Email: erik.guttman@sun.com 390 Full Copyright Statement 392 Copyright (C) The Internet Society (2001). All Rights Reserved. 394 This document and translations of it may be copied and furnished to 395 others, and derivative works that comment on or otherwise explain it 396 or assist in its implementation may be prepared, copied, published 397 and distributed, in whole or in part, without restriction of any 398 kind, provided that the above copyright notice and this paragraph are 399 included on all such copies and derivative works. However, this 400 document itself may not be modified in any way, such as by removing 401 the copyright notice or references to the Internet Society or other 402 Internet organizations, except as needed for the purpose of 403 developing Internet standards in which case the procedures for 404 copyrights defined in the Internet Standards process must be 405 followed, or as required to translate it into languages other than 406 English. 408 The limited permissions granted above are perpetual and will not be 409 revoked by the Internet Society or its successors or assigns. 411 This document and the information contained herein is provided on an 412 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 413 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 414 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 415 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 416 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 418 Acknowledgement 420 Funding for the RFC Editor function is currently provided by the 421 Internet Society.