idnits 2.17.1 draft-ietf-zeroconf-host-prof-01.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 ([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 (20 July 2001) is 8313 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2026' is mentioned on line 362, but not defined -- 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-04 ** 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-02 ** 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 (~~), 7 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 Category: Standards Track 5 20 July 2001 6 Expires in six months 8 Zeroconf Host Profile Applicability Statement 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 This document specifies a set of Zero Configuration Protocols which 42 combined support the Zero Configuration domain of applicability. 43 This host profile supports the same upper layer feature set as 44 defined in STD 3 [RFC 1123] by hosts lacking any prior configuration, 45 though in a restricted domain. 47 1. Introduction 49 The Internet Standards Process [RFC 2026], Section 3.2, defines how 50 applicability statements are standardized to associate sets of 51 protocols for a particular domain of applicabiliy. This 52 specification defines the Zero Configuration domain of applicability 53 and a set of protocols which support it. 55 Requirements for Internet routers [RFC 1812] and hosts [RFC 1122] 56 [RFC 1123] provide guidance to vendors and users of Internet 57 communication software. They represent consensus arising from 58 experience. This document similarly associates a set of protocols 59 together for a particular purpose. In contrast to router and host 60 requirements standards, the Zeroconf Host Profile does not arise out 61 of experience, (though relevant experience is cited.) Instead, this 62 comprises a set of protocols which complement each other when 63 implemented together. 65 The goal of the Zero Configuration Networking (ZEROCONF) Working 66 Group is to enable networking in the absence of configuration and 67 administration. Zero configuration networking is required for 68 environments where administration is impractical or impossible, such 69 as in the home or small office, embedded systems' plugged together' 70 as in an automobile, or to allow impromptu networks as between the 71 devices of strangers on a train. 73 As noted in STD 3 [RFC 1122], the current internet suite of protocols 74 fall short of this goal. 76 It would be ideal if a host implementation of the Internet 77 protocol suite could be entirely self-configuring. This would 78 allow the whole suite to be implemented in ROM or cast into 79 silicon, it would simplify diskless workstations, and it would be 80 an immense boon to harried LAN administrators as well as system 81 vendors. We have not reached this ideal; in fact, we are not even 82 close. 84 This document describes a host profile which provides zero 85 configuration operation. Like STD 3, this document describes a set 86 of protocols and makes recommendations with respect to their 87 implementation. Unlike the the mechanisms described in STD 3, we 88 have limited experience with many Zeroconf protocols; some are only 89 now emerging as IETF standards track specifications. Still, we have 90 extensive experience with related protocols, which provided the 91 inspiration for the Zeroconf working group and Zeroconf protocols, 92 specifically the AppleTalk protocol suite [4]. 94 2. Terminology 96 Terminology specific to discussion of particular zeroconf protocols 97 is introduced in the appropriate section. 99 In this document, the key words "MAY", "MUST, "MUST NOT", 100 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 101 interpreted as described in [RFC 2119]. 103 3. The Zero Configuration Domain of Applicability 105 Hosts which lack any specific configuration have zero configuration. 106 The zero configuration domain of applicability concerns hosts with 107 zero configuration for specific functions 109 3.1. Zero configuration is not all or nothing 111 A host may be configured with regard to some functions and have zero 112 configuration for others. For example, a host may lack IP interface 113 configuration (described in Section 4.1) but have naming 114 configuration (described in Section 4.2) In this case, zero 115 configuration IP interface autoconfiguration will be used by a host 116 adhering to the Zeroconf Host Profile. 118 3.2. Configured vs. Zero Configuration Protocol behavior 120 Zero configuration behavior in each area is well defined. The 121 specific behavior of a host when it becomes configured varies. Each 122 protocol which supports the zero configuration protocol requirements 123 varies in this respect. 125 IPv4 Link-local IP Interace Configuration [7] and IPv6 address 126 autoconfiguration, [RFC 2461] and ZMAAP [12] are used whether an 127 interface is configued or not. 129 Link-local Multicast DNS [10] by default is only used when a host has 130 no configured DNS server, unless specifically configure to enable 131 link-local Multicast behavior. 133 SLPv2 [RFC 2608] always operates in a zero configuration mode, 134 transitions in behavior and reconfiguration occur automatically. 135 (SLPv2 agents may also be configured manually, but that does this 136 does not reduce or change their automatic functions.) 138 3.3. Scalability and network configuration 140 The zero configuration domain of applicability includes any IP 141 network which supports multicast (though only broadcast is needed for 142 IPv4 link-local interface configuration). Some protocols described 143 in this applicability statement are defined to only operate using 144 link-local addressing and link-local scope multicast. This is not an 145 inherant limitation of this domain of applicability - for example, 146 SLPv2 [RFC 2608] is defined to operate at admin local scope [RFC 147 2365] for IPv4 and site local scope for IPv6. [RFC 3111] In any 148 case, the zero configuration domain of applicability is a network 149 under a single common administration, and in some cases only a single 150 network link. 152 4. Zeroconf Host Profile Requirements and Recommendations 154 IP Interface Configuration and name resolution services are host 155 requirements (see section 3.3.1.6 [RFC 1122], 6.1.1 [RFC 1123]). A 156 zeroconf host MUST implement these features. 158 Service discovery constitutes one of the most useful features of the 159 AppleTalk protocol suite [4]. The ease of user configuration from 160 standard service discovery facilities has proved so important that 161 this feature alone has been decisive in continuing support for 162 AppleTalk in many networks. For this reason, a zeroconf host SHOULD 163 implement service discovery functions. 165 Some multicast applications require the allocation of multicast 166 addresses which do not conflict with other address allocations. 167 Zeroconf hosts MAY implement multicast address allocation functions 168 to support these applications. 170 The protocols included in the Zeroconf Host Profile provide 171 equivalent functions when run over IPv4 and IPv6. Where there are 172 differences, these are noted. 174 4.1. IP Interface Configuration 176 4.1.1. Zeroconf Requirements 178 Hosts which support IPv4 and the Zeroconf Host Profile MUST implement 179 IPv4 Link-local IP Interace Configuration. [7] 181 Hosts which support IPv6 and the Zeroconf Host Profile MUST implement 182 IPv6 Stateless Address Autoconfiguration. [RFC 2461] [RFC 2462] 184 4.1.2. Discussion 186 IPv4 link-local address autoconfiguration provides an interface with 187 the ability to communicate with hosts on the immediately attached 188 link only. To obtain a routable IPv4 address, some additional 189 mechanism is required. 191 Implementation issues likely to arise in implementing IPv4 link-local 192 address autoconfiguration include potential mandatory address changes 193 due to conflicts, support for more than one configuration per 194 interface and complications arising from multihomed devices applying 195 link-local autoconfiguration on more than one link. [7] 197 IPv6 stateless address autoconfiguration provides an interface with a 198 link-local address. This address together with a routing prefix 199 obtained via a router advertisement message enables the configured 200 interface to communicate globally. 202 There is substantial experience deploying both of these protocols. 204 [Editor: Issues and observations arising from that experience to go 205 here.] 207 4.1.3. Comparison against Zeroconf Requirements 209 The protocols recommended in section 3.1.1 fulfill all Zeroconf 210 requirments (see Section 2.1 of [5]). 212 [Editor: Is further detailed analysis required?] 214 4.2. Translation between Host name and IP Address 216 4.2.1. Zeroconf Requirements 218 Hosts which support the Zeroconf Host Profile MUST support Multicast 219 DNS. [10] This protocol is defined to work over IPv4 and IPv6. 221 4.2.2. Discussion 223 There has been no deployment experience with Multicast DNS to date. 224 There has been extensive experience with the AppleTalk Name Bind 225 Protocol (NBP) [4] and NetBIOS [RFC 1001]. [Editor: Issues and 226 observations arising from experience go here.] 228 4.2.3. Comparison against Zeroconf Requirements 230 The protocols recommended in section 3.2.1 fulfill all Zeroconf 231 requirments (see Section 2.2 of [5]). 233 [Editor: Is further detailed analysis required?] 235 4.3. IP Multicast Address Allocation 237 4.3.1 Zeroconf Host Profile Requirements 239 Hosts which will support applications which require unique multicast 240 address allocation MAY support the Zeroconf Multicast Address 241 Allocation Protocol (ZMAAP) [12]. 243 4.3.2. Discussion 245 There has been no experience with ZMAAP to date. 247 4.3.3. Comparison against Zeroconf Requirements 249 The protocols recommended in section 3.3.1 fulfill all Zeroconf 250 requirments (see Section 2.3 of [5]). 252 [Editor: Is further detailed analysis required?] 254 4.4. Service Discovery 256 SLPv2 [RFC 2608] and DNS SRV RRs [RFC 2782] conveyed over mDNS 257 constitute two distinct options for service discovery for hosts 258 conforming to the Zeroconf Host Profile. The options are discussed 259 below. 261 This section employs the following terminology: 263 service 264 A particular logical function that may be invoked via some network 265 protocol, such as printing or storing a file on a remote disk. 267 service characteristics 268 Characteristics provide a finer granularity of description to 269 differentiate services beyond just the service type. For example 270 if the service type is printer, the characteristics may be color, 271 pages printed per second, location, etc. 273 service discovery protocol 274 A service discovery protocol enables clients to discover servers 275 (or peers to find other peers) of a particular service. A service 276 discovery protocol is an application layer protocol that relies on 277 network and transport protocol layers. 279 service protocol 280 A service protocol is used between the client and the server after 281 service discovery is complete. 283 distinct service 284 A service is distinct if services of the same type cannot be used 285 interchangeably by clients. Distinct services include those whose 286 physical location, capabilities, state, permissions, performance 287 characteristics or policy differs. A client will discern the 288 difference between service instances. For example, a client 289 seeking to print can only usefully send a job to a printer the 290 user has physical access to. A client attempting to access data 291 in a database can only do so if the correct database server 292 (containing the data the client wishes to access) can be located. 294 indistinct service 295 A service is indistinct if services of the same type can be used 296 interchangeably by clients. For example, any SMTP relay, DNS 297 server or IP gateway will generally provide the same function for 298 a client. 300 4.4.1. Zeroconf Host Profile Requirements 302 Hosts implementing the Zeroconf Host Profile SHOULD implement the 303 Service Location Protocol, Version 2 (SLPv2) [RFC 2608] to enable 304 discovery of distinct services. SLPv2 also enables discovery of 305 indistinct services. SLPv2 entails some modifications when 306 implemented over IPv6. [RFC 3111] 308 Hosts implementing the Zeroconf Host Profile SHOULD implement 309 Multicast DNS [10] and support the use of DNS SRV RRs. [RFC 2782] 311 4.4.2. Discussion 313 SLPv2 allows the use of service characteristics to distinguish 314 different instances of services. This allows a client to request 315 services on the basis of attributes, and locate the service which 316 fulfills the client's needs. 318 DNS SRV RRs allow services to be located by name. A client is not 319 able to distinguish between different services of the same named type 320 except by using a service protocol distinct from the service 321 discovery protocol. 323 In some cases, DNS SRV RR functionality suffices - and since support 324 for mDNS is already included in the Zeroconf Host Profile (as a 325 REQUIRED feature), the lightest-weight implementation may exclude 326 SLPv2 support. 328 The reason why one uses mDNS to issue requests for DNS SRV RRs is 329 that network services may not be present. If a host is configured to 330 use a DNS server, DNS [RFC 1034] is used instead of mDNS, as 331 described in [10]. 333 SLPv1 and SLPv2 have been deployed in networks for some time. 334 [Editor: Include SLP deployment discussion here.] 336 DNS SRV RRs have been used by some applications to obtain service 337 locations. These resource records have not been used in conjunction 338 with mDNS so no guidance can be obtained from direct experience. 339 AppleTalk Name Bind Protocol [4], however, provides a very similar 340 function. [Editor: Include NBP observations here.] 342 Service discovery functionality can be considered as two 343 complementary functions - client discovery and server advertising. A 344 host which functions entirely as a service or as a client would need 345 to implement only those aspects of a service discovery protocol which 346 it needs to conform with the Zeroconf Host Profile. To be specific, 347 a host offered network services but never needed to discover them 348 could implement only SLPv2 Service Agent [12] or mDNS server [10] 349 functions. A host which functioned as a client but never offered 350 services would only implement SLPv2 User Agent or mDNS enhanced 351 resolver functions. 353 4.4.3. Comparison against Zeroconf Requirements 355 The protocols recommended in section 3.4.1 fulfill all Zeroconf 356 requirments (see Section 2.4 of [5]). 358 [Editor: Is further detailed analysis required?] 360 5. Requirement Levels 362 As required by [RFC 2026], Section 3.3, each technical specification 363 which is cited must be associated with a requirement level. 365 FEATURE |SECTION|REQUIRED|RECOMMENDED|ELECTIVE| 366 --------------------------------|-------|--------|-----------|--------| 367 IP Interface Configuration |3.1 | X | | | 368 Translation between Host Name |3.2 | X | | | 369 and IP Address | | | | | 370 IP Multicast Address Allocation |3.3 | | | X | 371 Service Discovery - |3.4 | | X | | 372 --------------------------------|-------|--------|-----------|--------| 374 6. Security Considerations 376 Security considerations of Zeroconf protocols is discussed in [5]. 377 Hosts conforming to the Zeroconf Host Profile MUST support the 378 security features present in the protocols included in this profile 379 which they implement. 381 References 383 [RFC 1812] Baker, F. (Editor), "Requirements for IP Version 4 384 Routers", RFC 1812, June 1995. 386 [RFC 1122] Braden, R. (Editor), "Requirements for Internet Hosts -- 387 Communication Layers", STD 3, RFC 1122, October 1989. 389 [RFC 1123] Braden, R. (Editor), "Requirements for Internet Hosts -- 390 Application and Support", STD 3, RFC 1123, October 1989. 392 [4] Sidhu, G., et. al., "Inside AppleTalk", Second Edition, Apple 393 Computer, Inc, Addison-Wesley, ISBN 0-201-55021-0, 1990. 395 [5] Hattig, M., "Zeroconf Requirements", draft-ietf-zeroconf-reqts- 396 08.txt, May 2001. Work in progress. 398 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, March 1997. 401 [7] Cheshire, S., "Dynamic Configuration of IPv4 link-local 402 addresses", draft-ietf-zeroconf-ipv4-linklocal-04.txt Work in 403 progress. 405 [RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery 406 for IP Version 6 (IPv6)", RFC 2461, December 1998. 408 [RFC 2462] Thomson, S., Narten, T., "IPv6 Stateless Address 409 Autoconfiguration", RFC 2462, December 1998. 411 [10] Ebisov, L., Aboba, B., Thaler, D., "Multicast DNS", draft-ietf- 412 dnsext-mdns-02.txt. Work in progress. 414 [RFC 1001] Auerbach, K., Aggarwal, A., (editors), "PROTOCOL STANDARD 415 FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND 416 METHODS", RFC 1001, March 1987. 418 [12] Catrina, O. (Editor), Thaler, D., Aboba, B., Guttman, E., 419 "Zeroconf Multicast Address Allocation Protocol (ZMAAP)", 420 draft-ietf-zeroconf-zmaap-01.txt. Work in Progress. 422 [RFC 2608] Guttman, E., Perkins, C., Veizades, J., Day, M., "Service 423 Location Protocol, Version 2", RFC 2608, July 1999. 425 [RFC 3111] Guttman, E., "Service Location Protocol Modifications for 426 IPv6", RFC 3111, May 2001. 428 [RFC 2782] Gulbrandsen, A., Vixie, P., Ebisov, L., "A DNS RR for 429 specifying the location of services (DNS SRV)", RFC 2782, 430 February 2000. 432 [RFC 1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 433 RFC 1034, November 1987. 435 Authors' Addresses 437 Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt 438 Germany 440 Phone: +49 172 865 5497 Email: erik.guttman@sun.com 442 Full Copyright Statement 444 Copyright (C) The Internet Society (2001). All Rights Reserved. 446 This document and translations of it may be copied and furnished to 447 others, and derivative works that comment on or otherwise explain it 448 or assist in its implementation may be prepared, copied, published 449 and distributed, in whole or in part, without restriction of any 450 kind, provided that the above copyright notice and this paragraph are 451 included on all such copies and derivative works. However, this 452 document itself may not be modified in any way, such as by removing 453 the copyright notice or references to the Internet Society or other 454 Internet organizations, except as needed for the purpose of 455 developing Internet standards in which case the procedures for 456 copyrights defined in the Internet Standards process must be 457 followed, or as required to translate it into languages other than 458 English. 460 The limited permissions granted above are perpetual and will not be 461 revoked by the Internet Society or its successors or assigns. 463 This document and the information contained herein is provided on an 464 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 465 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 466 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 467 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 468 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 470 Acknowledgement 472 Funding for the RFC Editor function is currently provided by the 473 Internet Society.