idnits 2.17.1 draft-ietf-zeroconf-reqts-05.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC1487], RFC, [RFC1034,, 1035], [RFC2131], [RFC2730]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 108 has weird spacing: '...in this docum...' -- 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 (September 18, 2000) is 8621 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) -- Duplicate reference: RFC1034, mentioned in 'RFC 1035', was also mentioned in 'RFC 1034'. ** Obsolete normative reference: RFC 1487 (Obsoleted by RFC 1777, RFC 3494) == Outdated reference: A later version (-04) exists of draft-holbrook-ssm-00 -- Possible downref: Normative reference to a draft: ref. 'SSM' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Zeroconf WG M. Hattig 3 Internet Engineering Task Force Editor 4 INTERNET DRAFT Intel Corp. 5 Expires March 2001 September 18, 2000 7 Zeroconf Requirements 8 draft-ietf-zeroconf-reqts-05.txt 10 Status of This Memo 12 This document is a submission by the Zeroconf Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be 14 submitted to the zeroconf@merit.edu mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are 20 working documents of the Internet Engineering Task Force (IETF), 21 its areas, and its working groups. Note that other groups may 22 also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Abstract 38 Many common TCP/IP protocols such as DHCP [RFC 2131], DNS [RFC 39 1034, RFC 1035], MADCAP [RFC 2730], and LDAP [RFC 1487] must be 40 configured and maintained by an administrative staff. This is 41 unacceptable for emerging networks such as home networks, 42 automobile networks, airplane networks, or adhoc networks at 43 conferences, emergency relief stations, and many others. Such 44 networks may be nothing more than two isolated laptop PCs 45 connected via a wireless LAN. For all these networks, an 46 administrative staff will not exist and the users of these 47 networks neither have the time nor inclination to learn network 48 administration skills. Instead, these networks need protocols that 49 require zero user configuration and administration. This document 50 is part of an effort to define such zero configuration (zeroconf) 51 protocols. 53 Before embarking on defining zeroconf protocols, protocol 54 requirements are needed. This document states the zeroconf 55 protocol requirements for four protocol areas; this document does 56 not define specific protocols. The four areas are: IP host 57 configuration, host name to IP address resolution, IP multicast 58 address allocation, and service discovery. The requirements for 59 these four areas result from examining everyday use or scenarios 60 of these protocols. 62 Table of Contents 64 1 Introduction................................................2 65 1.1 Key words.................................................3 66 1.2 Reading This Document.....................................3 67 1.3 Zeroconf Coexistence......................................3 68 1.4 Scalability...............................................3 69 1.5 Routable Protocol Requirement.............................3 70 1.6 Conflicts and State Changes Requirement...................4 71 2 Scenarios & Requirements....................................4 72 2.1 IP Host Configuration.....................................4 73 2.2 Host name to IP Address Resolution Scenarios..............5 74 2.3 IP Multicast Address Allocation Scenarios.................7 75 2.4 Service Discovery Scenarios...............................9 76 3 Security Considerations....................................11 77 3.1 IPv6 Considerations......................................12 78 4 IANA Considerations........................................13 79 5 Full Copyright Statement...................................13 80 6 Acknowledgements...........................................13 81 7 References.................................................14 83 1 Introduction 85 A zeroconf protocol is able to operate correctly in the absence of 86 either user configuration or external configuration from 87 infrastructure services such as conventional DHCP [RFC 2131] or 88 DNS [RFC 1034, RFC 1035] servers. Zeroconf protocols may use 89 configuration, when it is available, but do not rely on it being 90 present. 92 The benefits of zeroconf protocols over existing configured 93 protocols are an increase in the ease-of-use for end-users and a 94 reduction of the infrastructure necessary to operate. 96 This document discusses requirements for zeroconf protocols in 97 four areas: 98 - IP host configuration 99 - Host name to IP address resolution 100 - IP multicast address allocation 101 - Service discovery 102 Security considerations are also discussed. 104 1.1 Key words 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 107 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 108 in this document are to be interpreted as described in [RFC 109 2119]. 111 1.2 Reading This Document 113 Introduction, Scenarios & Requirements, and Security 114 Considerations are the major sections of this document. 116 The Scenarios & Requirements section walks through protocol 117 scenarios and then lists the requirements of the protocol needed 118 to accomplish the scenario. 120 The Security Consideration section lists security issues with 121 zeroconf protocols. 123 Requirements dispersed throughout this document begin with the 124 text "Requirements:" or "Requirement:" on a single line, which is 125 followed by a bulleted list of requirements. 127 1.3 Zeroconf Coexistence 129 It is not necessary to always use zeroconf protocols in all four 130 areas. For example, it might make sense on some networks to 131 provide a DHCP server for configured address allocation, but 132 perform host name to IP address resolution using a zeroconf 133 protocol. 135 1.4 Scalability 137 Zeroconf protocols are not intended to replace or compete with 138 non-zeroconf protocols deployed in today's large-scale networks. 139 Instead, zeroconf protocols are expected to operate in small 140 networks. As a network grows, the administrators of that network 141 should consider migrating away from zeroconf protocols before 142 scalability becomes an issue. That being said, a zeroconf protocol 143 SHOULD be scalable. 145 1.5 Routable Protocol Requirement 147 Zeroconf protocols have no specific topological restrictions or 148 requirements; networks may consist of multiple IP subnets or a 149 single IP subnet; networks may be isolated or connected to larger 150 networks (e.g. Internet). However, there is a conditional 151 requirement. The condition exists if a protocol is targeted to 152 operate in multiple IP subnet topologies. The requirement is the 153 protocol MUST be routable. For example, a protocol MUST use IP 154 multicast and not use IP broadcast. 156 Requirement: 157 - If a protocol is to operate in multiple IP subnet topologies, 158 the protocol MUST be routable. 160 1.6 Conflicts and State Changes Requirement 162 Spurious topology changes or other events such adding and removing 163 hosts may cause conflicts and state changes within a protocol. 164 Zeroconf protocols must be able to resolve conflicts and state 165 changes caused by topology changes or other events. The scenario 166 in the 2.1.2 Bridge Installed section is the only scenario that 167 illustrates the need for this requirement, thus the below require 168 is duplicated in section 2.1.2. However, this requirement applies 169 to all protocol areas. 171 Requirement: 172 - MUST resolve conflicts and state changes in a timely manner. 174 2 Scenarios & Requirements 176 This section lists scenarios that lead to zeroconf protocol 177 requirements. A subsection exists for each of the four protocol 178 areas. Within each protocol area, terms and assumptions are 179 followed by specific scenarios. The scenarios lead to a list of 180 zeroconf protocol requirements. Each scenario is representative of 181 many potential scenarios of which all yield an identical set of 182 requirements. Each subsection ends with an IPv6 considerations 183 section. 185 2.1 IP Host Configuration 187 In this document, configuration of an IP interface on a host is IP 188 host configuration. IP host configuration always includes the 189 configuration of an IP address and netmask; it may include a 190 default route. IP host configuration is needed before almost any 191 IP communication can take place. 193 Terms: 194 IP subnet - A single logical IP network that may span multiple 195 link layer networks. 197 internet - Multiple IP subnets connected by routers. 199 network - context sensitive term that may apply to one or more 200 the terms link layer network, IP subnet, or internet. 202 IP host configuration scenarios are ICMP echo request/reply 203 scenarios and a bridge install scenario. 205 2.1.1 ICMP Echo Request/Reply 207 There are two brief ICMP echo request/reply scenarios. In the 208 first, both the sender of the ICMP echo request and sender of the 209 ICMP echo reply are on the IP subnet. In the second, the two 210 senders are on different IP subnets within an internet. 212 Requirements: 213 - MUST determine the netmask for an IP subnet. 214 - MUST have unique IP addresses within an IP subnet. 215 - MUST have a default route (only for the internet scenario). 216 - MUST have unique IP subnets within an internet (only for the 217 internet scenario). 219 2.1.2 Bridge Installed 221 This scenario starts with two completely operational standalone 222 networks in which IP host configuration was completed with a 223 zeroconf protocol on each network. These two networks become one 224 after a newly installed bridge connects them. Individual hosts 225 have no indication that the topology has changed. 227 Topology changes may create any of the following problems: 228 conflict among netmasks, conflict among default routes, duplicate 229 IP addresses within an IP subnet, or duplicate IP subnets within 230 an internet. Note that default routes and duplicate IP subnets are 231 not issues for single IP subnet networks. 233 Requirement: 234 - MUST resolve conflicts and state changes in a timely manner. 236 2.1.3 IPv6 Considerations 238 IPv6 allows a host to select an appropriate IP address, netmask, 239 and find a default route, thus if a network is using IPv6, a 240 zeroconf IP host configuration solution already exists. 242 2.2 Host name to IP Address Resolution Scenarios 244 Host names allow users to refer to hosts by name instead of IP 245 addresses. This is among the most fundamental, thus most 246 important, usage paradigms in TCP/IP networking. 248 Terms: 250 host name - One or more strings separated by dots that identify 251 a host. 253 domain name - One or more strings separated by dots that 254 identify a DNS domain. 256 resolver - The host needing a name resolved to an IP address. 258 Assumptions: 259 - Support for multiple hosts with the same name is not a 260 requirement. 262 The scenarios for host name to IP address resolution are Web 263 browsing and host name selection. 265 2.2.1 Web Browsing 267 Users browsing the Web typically enter the name of a Web server. 268 This name must be resolved to an IP address before any actual Web 269 browsing occurs. The Web server may be within the same domain 270 along with the resolver or may be part of some other domain. 272 Requirement: 273 - MUST resolve a host name to an IP address whether the name of 274 the resolver and host name are in the same DNS domain or in 275 different DNS domains. 277 2.2.2 Host Name Selection 279 How the host gets its name (or Domain Name [RFC 1034]) is part of 280 some other configuration protocol or user configuration, but is 281 not part of this zeroconf scenario. This scenario only deals with 282 learning of other host names on the network. The goal is to allow 283 hosts to notify the user or configuration protocol that a 284 duplicate name exists. Thus allowing the user or configuration 285 protocol to attempt to use a different and hopefully unique name 286 so that once operational, all devices within a domain have unique 287 names. 289 Requirement: 290 - MUST allow a host to determine if it has a unique name. 291 - MUST be able to determine if subsequently chosen names are 292 unique, if the first name is not. 293 - If a domain name and host name exist as separate configuration 294 parameters, additional checks for uniqueness SHOULD be 295 performed on the combined host name and domain name. 297 2.2.3 IPv6 Considerations 299 Host name to IP address resolution protocols have no zeroconf 300 related differences for IPv4 and IPv6. 302 2.3 IP Multicast Address Allocation Scenarios 304 IP Multicast is used for multi-receiver bulk-delivery 305 applications, such as audio, video, or news to conserver 306 bandwidth. 308 IP multicast addresses range from 224.0.0.0 to 239.255.255.255. 310 [RFC 2365] defined scopes are: 311 node-local (unspecified) 312 link-local (224.0.0.0/24) 313 local (239.255.0.0/16) 314 site-local (unspecified)_ 315 organizational-local (239.192.0.0/14) 316 global (224.0.1.0-238.255.255.255) 318 A relative assignment is an integer offset from the highest 319 address in the scope and represents a 32-bit address. For example, 320 within the local scope, 239.255.255.0/24 is reserved for relative 321 allocations. 323 Source-Specific Multicast [SSM] addresses are 232.0.0.0 to 324 232.255.255.255. 326 Assumptions: 327 - The node-scoped and SSM addresses require no protocol or 328 interaction between multiple hosts, thus are not mentioned 329 further in this document. 330 - Global and organizational scoped addresses are meant for 331 networks of a greater scale than zeroconf protocols, thus are 332 not mentioned further in this document. 333 - Only local, link-local and site-local scopes are considered 334 further in this document. 335 - A boundary router, as described in [RFC 2365], is present to 336 appropriately control multicast packets from entering and 337 leaving multicast scope boundaries when necessary. 339 Scenarios are scope enumeration, address allocation, and multiple 340 sources. 342 2.3.1 Scope Enumeration 344 Applications that leave the choice of scope up to the user require 345 the ability to enumerate what scopes the host is operating within. 346 In addition, services that are assigned relative addresses require 347 the ability to enumerate what scopes the host is within, only then 348 will a host be able to apply the relative address to a scope. 350 Requirements: 352 - MUST list which of the scopes (only local, link-local, or site- 353 local) are available for hosts. 354 - MUST list per-scope address ranges that may be allocated. 356 2.3.2 Address Allocation 358 IP multicast address allocation (only local, link-local and site- 359 local scopes only) requires coordination among hosts to avoid 360 address collisions. To allocate an address, the host specifies a 361 given scope, the number of addresses it desires, and the lifetime 362 for which it desires. Address collision detection must span the 363 entire scope respective to a particular address. The protocol 364 should include the ability for a host to choose addresses, 365 determine if they are in use, and if used, choose different 366 addresses. 368 Requirements: 369 - MUST select a multicast address with a given scope and lease 370 time. 371 - MUST determine if the address has been allocated within a scope. 372 - MUST defend an allocated address within a scope. 374 2.3.3 Multiple Source 376 An intercom system inside a home is an example of a multiple 377 source IP multicast application. In this type of application, 378 several sources may be sending packets destined to the same IP 379 multicast address. 381 The first host that needs the IP multicast address allocates the 382 address, but some other host may deallocate the address. This is 383 because the first host may leave the multicast group before all 384 the other host leave the group. This requires the last host using 385 the IP multicast address to deallocate the IP multicast address. 387 Requirements: 388 - The first host to use the IP multicast address MUST allocate the 389 address. 390 - The last host to use the IP multicast address MUST deallocate 391 the address. 393 2.3.4 IPv6 Considerations 395 To date, no range has been reserved for dynamic allocation of 396 source-specific addresses in IPv6. Hence, until such a range is 397 reserved, dynamic allocation of Single-source addresses applies 398 only to IPv4. 400 To date, no range has been reserved for dynamic allocation of 401 Link-scoped addresses in IPv4. Hence, unless such a range is 402 reserved, dynamic allocation of Link-scoped addresses applies only 403 to IPv6. 405 2.4 Service Discovery Scenarios 407 Service discovery protocols allow users to select services and/or 408 hosts by a name that is discovered dynamically, rather than the 409 user having to know the name in advance and type it in correctly. 411 Terms: 412 process - A process is an implementation of an algorithm in 413 software, hardware, or a combination of software and hardware. 415 registry - A process that acts as an intermediary between 416 discoverers and advertisers. Servers 'register' service 417 advertisements and other pertinent (e.g. authentication info, 418 announcement criteria) with registries, then the service may be 419 discovered from the registry instead of from a server. 421 registry update - A message that contains updated registry 422 information. It may cause one or more registry entries to be 423 deleted, added, or modified. 425 server - A process that offers services to clients. A server 426 can make its service(s) known to clients by means of a service 427 discovery protocol. 429 service - A service is a set of processes that utilize a 430 particular protocol. Services range from printing to 431 transferring a file to providing on-line pizza order and 432 delivery. 434 service advertisement packet - An unsolicited packet issued by a 435 server or registry. The advertisement provides the service 436 identifier and possibly service characteristics. 438 service characteristics - Characteristics provide a finer 439 granularity of description to differentiate services beyond just 440 the service type. For example if the service type is printer, 441 the characteristics may be color, pages printed per second, 442 location, etc. 444 service discovery protocol - A service discovery protocol 445 enables a client (or clients) to discover a server (or servers) 446 of a particular service. A service discovery protocol is an 447 application layer protocol that relies on network and transport 448 protocol layers. 450 service identifier - A service identifier allows clients, 451 servers, advertisers, discoverers, and registries to uniquely 452 identify an instance of a service. 454 service protocol - A service protocol is used between the client 455 and the server after service discovery is complete. 457 service solicitation - A request packet made by a client to 458 obtain a response packet that indicates a service is present. 459 The response may come from a service or a registry. 461 service type - A service type allows clients, servers, 462 advertisers, discoverers, and registries to uniquely identify a 463 type of service such as a printer service. 465 The scenarios are the discovery of a simple printer service and 466 the discovery of a printer manager that consolidates many printer 467 services. 469 2.4.1 Printer Service 471 Networked enabled printers allow various networked clients to 472 submit print jobs. A service discovery protocol MUST allow a 473 printing clients to discover the printer service. This requires a 474 service type as well as a service identifier to distinguish 475 instances of a single service type. 477 Printers vary in their characteristics such as location, status, 478 dots per inch, drivers, etc. Discovering these characteristics 479 SHOULD be part of the service discovery protocol. Alternatively, 480 the client and server MAY negotiate the use of these 481 characteristics after the service is found. 483 Discovery SHOULD be possible by either the client actively 484 soliciting the service or by the service advertising then the 485 client passively listening for the advertisements. At least one 486 method MUST be available. Once a client finds the printer, it can 487 utilize different printing protocols such as raw tcp, lpd, and 488 ipp. 490 In the case of a printer service, a printer may be temporarily 491 taken off-line for repair or everyday maintenance. This requires 492 clients to be able to rediscover a service. 494 Service discovery MUST complete in a timely (10s of seconds) 495 manner. 497 Requirements: 498 - MUST discover via service identifier and/or service type. 500 - SHOULD discover via characteristics or negotiate 501 characteristics. 502 - MUST allow discovery by client actively soliciting the service 503 or by the client passively listening for advertisements. Both 504 methods SHOULD be available. 505 - MUST allow clients to rediscover a service. 506 - MUST be independent from any particular service. 507 - MUST complete in a timely (10s of seconds) manner. 509 2.4.2 Printer Manager 511 A printer manager acts as a proxy to various printers. A printer 512 manager improves scalability by providing a single location from 513 which clients can find all printers. 515 In addition, a printer manager provides an evolutionary path for 516 service discovery deployment. For example, if an existing printer 517 does not support the zeroconf service discovery protocol, the 518 printer manager can use a legacy printer specific protocol to 519 learn the existence and characteristics of a printer then expose 520 that printer and its characteristics through the zeroconf service 521 discovery protocol. This allows new printer clients that support 522 the service discovery protocol to discover legacy printers that do 523 not support the zeroconf service discovery protocol. 525 If a print manager uses a registry to cache information about 526 services and characteristics of services, clients MUST be able to 527 extract data from the registry without knowledge that they are 528 talking to a registry. In other words, the client and server sides 529 of the service discovery protocol MUST NOT be any different 530 whether a registry is involved or not. Registry updates that 531 maintain the registry are required of the service discovery 532 protocol but are optionally implemented for a particular service; 533 this allows legacy protocols or the zeroconf service discovery 534 protocol to update and maintain the registry. 536 Requirements: 537 - SHOULD allow for a registry to cache information about services 538 and characteristics of services. 539 - SHOULD allow for clients to extract data from the registry 540 without knowledge that they are talking to a registry. 541 - A registry MUST NOT be required. 543 2.4.3 IPv6 Considerations 545 Service discovery protocols have no zeroconf related differences 546 for IPv4 and IPv6. 548 3 Security Considerations 549 This document is only concerned with security as it relates to the 550 four protocol areas. 552 While link layer encryption, firewalls, password/login protected 553 applications, and user-privilege-access to resources are important 554 security topics, these topics do not relate directly to the four 555 protocol areas; thus, these topics are not considered by this 556 document. 558 Existing protocols have on-going work related to security; this 559 document does not duplicate or attempt to extend this on-going 560 work. 562 The security threats considered are sniffing (data hijacking) and 563 denial of service attacks. These attacks MUST be considered for 564 each protocol area. 566 Sniffing can be deterred with encryption of the data. This may 567 require user to enter some type of key or may only require a 568 simple answer to a question of whether a protocol should encrypt 569 its data or not. Experience may show that encryption is not 570 necessary as long as other security measures such as link layer 571 encryption and firewalls are used. 573 Denial of service attacks are the biggest threat to zeroconf 574 protocols. These attacks include: 576 - Hoarding: A host claims all available resources, whether it 577 plans to use them or not. 579 - Masquerading: A host responds to requests that it should not 580 by masquerading as another host. 582 - Antagonistic Server: A server could offer support for a critical 583 service but intentionally misconfigure hosts on the network. 585 Without having zeroconf protocols defined, it is difficult to 586 analyze how these security threats may affect zeroconf protocols. 587 It is known that most, and possibly all, the security methods 588 require some user configuration. This presents a direct conflict 589 with the basic principle of zeroconf protocols -- no 590 configuration. This is an exception that zeroconf protocols must 591 deal with. Hopefully, best known methods develop along with 592 deployment experience. 594 3.1 IPv6 Considerations 596 IPv6 has built in security, thus if a network is using IPv6, a 597 security solution already exists. 599 4 IANA Considerations 601 No known IANA considerations arise from this document. 603 5 Full Copyright Statement 605 Copyright (C) The Internet Society (2000). All Rights Reserved. 607 This document and translations of it may be copied and furnished 608 to others, and derivative works that comment on or otherwise 609 explain it or assist in its implementation may be prepared, 610 copied, published and distributed, in whole or in part, without 611 restriction of any kind, provided that the above copyright notice 612 and this paragraph are included on all such copies and derivative 613 works. However, this document itself may not be modified in any 614 way, such as by removing the copyright notice or references to the 615 Internet Society or other Internet organizations, except as needed 616 for the purpose of developing Internet standards in which case the 617 procedures for copyrights defined in the Internet Standards 618 process must be followed, or as required to translate it into 619 languages other than English. 621 The limited permissions granted above are perpetual and will not 622 be revoked by the Internet Society or its successors or assigns. 624 This document and the information contained herein is provided on 625 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 626 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 627 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 628 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 629 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 630 PURPOSE." 632 6 Acknowledgements 634 Thanks to Peter Ford and Stuart Cheshire for hosting the NITS 635 (Networking In The Small) BOF that was the catalyst to forming the 636 Zeroconf Working Group. 638 Thanks to Erik Guttman and Stuart Cheshire for forming and 639 chairing the Zeroconf Working Group, which is responsible for this 640 document. 642 Thanks to Erik Guttman for providing key input to the service 643 discovery and the security sections. 645 Thanks to Dave Thaler for providing key input to the IP multicast 646 address allocation sections. 648 Thanks to Stuart Cheshire for providing key input to the 649 introduction and IP host configuration sections. 651 Additional recognition goes the following people for their 652 influential contributions to this document and its predecessors: 653 Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob 654 Quinn, John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl 655 Auerbach, Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland, 656 and Bernard Aboba. 658 Editor: 660 Myron Hattig 661 Intel Corporation 662 3585 SW 198th Avenue 663 Aloha, OR 97007 664 myron.hattig@intel.com 666 7 References 668 [RFC 1034] P. Mockapetris, Host names - Concepts and Facilities, 669 RFC 1034, November 1987 671 [RFC 1035] P. Mockapetris, Host names - Implementations and 672 Specifications, RFC 1034, November 1987 674 [RFC 1487] Yeong, W., Howes, T., and S. Kille, Lightweight 675 Directory Access Protocol, RFC 1487, July 1993. 677 [RFC 2026] S. Bradner, The Internet Standards Process -- Revision 678 3, RFC 2026 Oct 1996 680 [RFC 2119] S. Bradner. Key words for use in RFCs to Indicate 681 Requirement Levels. RFC 2119, March 1997. 683 [RFC 2131] R. Droms. Dynamic Host Configuration Protocol. RFC 684 2131, March 1997. 686 [RFC 2365] D. Meyer Administratively Scoped Multicast Address 687 RFC 2365,July 1998. 689 [RFC 2730] S. Hanna, B. Patel, M. Shah, Multicast Address 690 Dynamic Client Allocation Protocol (MADCAP), RFC 691 2730, Dec 1999. 693 [SSM] H. Holbrook, Source-Specific Multicast for IP, draft- 694 holbrook-ssm-00.txt, March 2000. A work in progress.