idnits 2.17.1 draft-ietf-zeroconf-reqts-12.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC1034], [RFC1035], [RFC2131], [RFC2730], [RFC2251]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 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 -- 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 19, 2002) is 7890 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) == Unused Reference: 'RFC0826' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 869, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 876, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 897, but no explicit reference was found in the text == Unused Reference: 'RFC2461' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'RFC2535' is defined on line 912, but no explicit reference was found in the text == Unused Reference: 'RFC2541' is defined on line 915, but no explicit reference was found in the text == Unused Reference: 'RFC2608' is defined on line 918, but no explicit reference was found in the text == Unused Reference: 'RFC2931' is defined on line 926, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-00 -- Obsolete informational reference (is this intentional?): RFC 1827 (Obsoleted by RFC 2406) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2541 (Obsoleted by RFC 4641) Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Zero Configuration Networking A. Williams 3 Internet-Draft Motorola 4 Expires: March 20, 2003 September 19, 2002 6 Requirements for Automatic Configuration of IP Hosts 7 draft-ietf-zeroconf-reqts-12.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on March 20, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 Many common TCP/IP protocols such as DHCP [RFC2131], DNS 39 [RFC1034][RFC1035], MADCAP [RFC2730], and LDAP [RFC2251] must be 40 configured and maintained by an administrative staff. This is 41 unacceptable for emerging networks such as home networks, automobile 42 networks, airplane networks, or ad hoc networks at conferences, 43 emergency relief stations, and many others. Such networks may be 44 nothing more than two isolated laptop PCs connected via a wireless 45 LAN. For all these networks, an administrative staff will not exist 46 and the users of these networks neither have the time nor inclination 47 to learn network administration skills. Instead, these networks need 48 protocols that require zero user configuration and administration. 49 This document is part of an effort to define such zero configuration 50 (zeroconf) protocols. 52 Before embarking on defining zeroconf protocols, protocol 53 requirements are needed. This document states the zeroconf protocol 54 requirements for four protocol areas; they are: IP interface 55 configuration, translation between host name and IP address, IP 56 multicast address allocation, and service discovery. This document 57 does not define specific protocols, just requirements. The 58 requirements for these four areas result from examining everyday use 59 or scenarios of these protocols. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1 Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2 Reading This Document . . . . . . . . . . . . . . . . . . 4 66 1.3 Zeroconf Coexistence . . . . . . . . . . . . . . . . . . . 5 67 1.4 Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.5 Routable Protocol Requirement . . . . . . . . . . . . . . 5 69 1.6 Maintaining Consistent Network State . . . . . . . . . . . 6 70 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.1 Addition and Removal of Devices . . . . . . . . . . . . . 6 72 2.2 Network Coalescing and Partitioning . . . . . . . . . . . 7 73 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.1 IP Interface Configuration . . . . . . . . . . . . . . . . 8 75 3.1.1 IPv6 Considerations . . . . . . . . . . . . . . . . . . . 10 76 3.2 Translation between Host name and IP Address . . . . . . . 10 77 3.2.1 IPv6 Considerations . . . . . . . . . . . . . . . . . . . 11 78 3.2.2 Relationship to the DNS . . . . . . . . . . . . . . . . . 11 79 3.2.2.1 Close coupling . . . . . . . . . . . . . . . . . . . . . . 12 80 3.2.2.2 Completely orthogonal . . . . . . . . . . . . . . . . . . 12 81 3.2.2.3 API compatible . . . . . . . . . . . . . . . . . . . . . . 12 82 3.3 IP Multicast Address Allocation Scenarios . . . . . . . . 13 83 3.3.1 Scope Enumeration . . . . . . . . . . . . . . . . . . . . 14 84 3.3.2 Address Allocation . . . . . . . . . . . . . . . . . . . . 14 85 3.3.3 Multiple Sources . . . . . . . . . . . . . . . . . . . . . 15 86 3.3.4 IPv6 Considerations . . . . . . . . . . . . . . . . . . . 15 87 3.4 Service Discovery Scenarios . . . . . . . . . . . . . . . 15 88 3.4.1 Printer Service . . . . . . . . . . . . . . . . . . . . . 16 89 3.4.2 IPv6 Considerations . . . . . . . . . . . . . . . . . . . 16 90 4. Security Considerations . . . . . . . . . . . . . . . . . 16 91 4.1 The Basic in/out Security Policy . . . . . . . . . . . . . 17 92 4.2 Security Scenarios . . . . . . . . . . . . . . . . . . . . 18 93 4.2.1 Use on an isolated, secure network link . . . . . . . . . 18 94 4.2.2 Use on a shared (insecure) link . . . . . . . . . . . . . 18 95 4.2.3 Use in conjunction with configured protocols . . . . . . . 18 96 5. IANA Considerations . . . . . . . . . . . . . . . . . . . 19 97 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 19 98 Normative References . . . . . . . . . . . . . . . . . . . 19 99 Informative References . . . . . . . . . . . . . . . . . . 19 100 Author's Address . . . . . . . . . . . . . . . . . . . . . 21 101 Full Copyright Statement . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 A zeroconf protocol is able to operate correctly in the absence of 106 configured information from either a user or infrastructure services 107 such as conventional DHCP [RFC2131] or DNS [RFC1034][RFC1035] 108 servers. Zeroconf protocols may use configured information, when it 109 is available, but do not rely on it being present. For example, the 110 use of MAC addresses (i.e. layer two addresses) as parameters in 111 zeroconf protocols is generally acceptable because they are globally 112 unique and readily available on most devices of interest. 114 The benefits of zeroconf protocols over existing configured protocols 115 are an increase in the ease-of-use for end-users and a simplification 116 of the infrastructure necessary to operate protocols. 118 This document discusses requirements for zeroconf protocols in four 119 areas: 121 o IP interface configuration 123 o Translation between host name and IP address 125 o IP multicast address allocation 127 o Service discovery 129 Security considerations are also discussed. 131 1.1 Key Words 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 1.2 Reading This Document 139 Introduction, Scenarios, Requirements, and Security Considerations 140 are the major sections of this document. 142 The Scenarios & Requirements sections walk through protocol scenarios 143 and then lists the requirements of the protocol needed to accomplish 144 the scenario. 146 The Security Consideration section lists security issues with 147 zeroconf protocols. 149 Requirements dispersed throughout this document begin with the text 150 "Requirements:" or "Requirement:" on a single line, which is followed 151 by a bulleted list of requirements. 153 1.3 Zeroconf Coexistence 155 It is not necessary to simultaneously use zeroconf protocols in all 156 four areas (i.e. IP interface configuration, translation between 157 host name and IP address, IP multicast address allocation, service 158 discovery). For example, it may make sense on some networks to 159 provide a DHCP server for configured IP interface configuration, but 160 perform translation between host name and IP address using a zeroconf 161 protocol. 163 Given that zeroconf protocols may be deployed on existing configured 164 networks, care must be taken in their design to ensure minimum 165 disruption to existing networks and applications. Particular 166 consideration should be given to the security implications of 167 deploying zeroconf protocols in conjunction with standard configured 168 network protocols. 170 Requirements: 172 o Zeroconf protocols MUST minimise their impact on existing 173 networks. 175 o Zeroconf protocols SHOULD minimise their impact on existing 176 applications. 178 o Zeroconf protocols MUST NOT be any less secure than related 179 current IETF-Standard protocols. 181 1.4 Scalability 183 The primary reasons to deploy Zeroconf protocols are simplicity and 184 ease-of-use. Scalability is important but it is a secondary goal. 185 Thus, scalability should not detract from the primary goals of 186 simplicity and ease-of-use. 188 1.5 Routable Protocol Requirement 190 Zeroconf protocols are not inherently limited to a single IP subnet. 191 If a protocol is intended to span multiple IP subnets it MUST NOT use 192 broadcasts or link-local addressing. 194 Requirement: 196 o Protocols intended to span multiple IP subnets MUST NOT use 197 broadcasts or link-local addressing. 199 1.6 Maintaining Consistent Network State 201 Many networks undergo change during their lifetime. For example, 202 hosts may be added and removed, network segments may be re-arranged, 203 and devices may change names or run different services. In a 204 configured network an administrator ensures that protocol parameters 205 are updated to reflect these changes and is responsible for ensuring 206 network consistency. 208 In contrast, zeroconf protocols must adapt to changing network 209 conditions. Zeroconf protocols must be able to resolve conflicts and 210 return the network to a consistent state after changes in network 211 topology or other events. 213 Requirement: 215 o Zeroconf protocols MUST restore the network to a consistent state 216 in a timely fashion when changes in network topology or other 217 events occur. 219 This is a general requirement applicable to all zeroconf protocols. 220 It should be kept in mind when considering the scenarios in Section 2 221 and will be applied to derive requirements for each zeroconf protocol 222 area considered in Section 3. 224 2. Scenarios 226 The scenarios described in the next few sections highlight the 227 general characteristics of the zeroconf protocol environment. Each 228 zeroconf protocol needs to deal with the following aspects of the 229 zeroconf environment. 231 2.1 Addition and Removal of Devices 233 Zeroconf protocols are expected to be useful in networks where hosts 234 come and go. Hosts using zeroconf protocols must not assume that 235 network resources assigned to them (e.g. address assignments, names, 236 etc) will be appropriate for networks they subsequently join. In 237 addition, network resources allocated to a host should be reclaimed 238 once it leaves the network. 240 Requirements: 242 o Zeroconf protocols MUST support mechanisms to probe whether a 243 network resource is currently in use. 245 o Hosts using zeroconf protocols MUST validate allocated network 246 resources when moving to a new network or powering up. 248 o Zeroconf protocols MUST support timely reclamation of any network 249 resources they allocate. 251 Implication: 253 o The information needed to allocate network resources must arrive 254 in the network along with the host. 256 2.2 Network Coalescing and Partitioning 258 Inevitably, two or more operational networks using zeroconf protocols 259 will be connected together, creating a single merged network. Prior 260 to the merge, each zeroconf network has independently allocated 261 resources (e.g. addresses, names, etc). After merging, two hosts in 262 the merged network may end up using the same network resource, thus 263 potentially creating conflicts. 265 In general a network merge "event" cannot be detected. For example, 266 the installation of a layer-2 bridge between two zeroconf networks 267 does not result in network interfaces going up and down on the hosts, 268 which would be an indication that they should re-validate or 269 reconfigure the network resources they are using. 271 Implication: 273 o It is not sufficient to rely on hosts detecting conflicts during 274 power on or movement from network to network. Rather, detection 275 and resolution of network conflicts is an ongoing part of zeroconf 276 protocol operation. 278 Requirement: 280 o Zeroconf protocols MUST resolve network resource conflicts in a 281 timely manner and on an ongoing basis. 283 Zeroconf protocols that detect and resolve network resource conflicts 284 on an ongoing basis will benefit from increased robustness in the 285 face of poor implementation, and varying network conditions. 287 A zeroconf network may also be split into two or more smaller 288 independent networks. The requirement from Section 2.1 that network 289 resources be reclaimed in a timely fashion also applies in this case. 290 Since network merging increases the potential for network conflicts, 291 it may be prudent to ensure that network resources associated with 292 hosts are not immediately re-claimed for re-use. Any network which 293 periodically joins and partitions with another zeroconf network will 294 benefit from this behaviour. An example is an IP network in a car 295 joining with the home network whilst the car is parked in the garage 296 and partitioning when it is driven away. 298 Requirement: 300 o Zeroconf protocols SHOULD NOT immediately reuse network resources 301 as soon as they become available. 303 o Network resources SHOULD be allocated in a way that minimises the 304 probability that two hosts will be allocated the same resource. 306 o Network resources SHOULD be allocated in a way that increases the 307 chances of a particular host being allocated the same resource 308 should it leave and rejoin the network. 310 3. Requirements 312 This section contains a subsection for each of the four protocol 313 areas. Within each subsection, terms and assumptions are followed by 314 specific zeroconf protocol requirements in that area. Each 315 subsection ends with IPv6 considerations. 317 3.1 IP Interface Configuration 319 In this document, IP interface configuration always includes the 320 configuration of an IP address and netmask; it may include some 321 routing information (such as default route). IP interface 322 configuration is needed before almost any IP communication can take 323 place. 325 Terms: 327 IP subnet: A single logical IP network that may span multiple link 328 layer networks. All IP hosts on the IP subnet communicate without 329 any layer 3 forwarding device (e.g. router). 331 internetwork: Multiple IP subnets connected by routers. 333 network: a context sensitive term that may apply to one or more of 334 the terms: a link layer network, an IP subnet, or an internetwork. 336 bridge: a networking device that connects two link layer networks by 337 using only link-layer protocols (e.g. Ethernet). 339 IP interface configuration must take place before an IP packet can be 340 sent from one host to another. This section requires that sufficient 341 information be provided by a zeroconf interface configuration 342 protocol to allow IP packets to be sent to a unicast destination IP 343 address on the same subnet as the sender, and on a different subnet 344 to the sender. 346 Requirements: A zeroconf IP interface configuration protocol 348 o MUST configure an appropriate netmask. 350 o MUST allocate unique IP addresses within an IP subnet. 352 o MUST allow configuration of zero or more gateways (for the 353 internetwork scenario). 355 o MUST have unique IP subnets within an internetwork (This is only 356 for the case when there is one or more router attached in the 357 network where autoconfigured hosts. How routers obtain their 358 configuration is beyond of the scope of this document.) 360 The following requirements are derived from applying Section 2.1 and 361 Section 2.2 to IP interface configuration. 363 Requirements: A zeroconf IP interface configuration protocol 365 o MUST be capable of discovering whether an IP address is currently 366 in use. 368 o Hosts using a zeroconf interface configuration protocol MUST 369 validate allocated IP addresses when moving to a new network or 370 powering up. 372 o MUST support timely reclamation of allocated IP addresses. 374 o MUST resolve IP address conflicts in a timely manner and on an 375 ongoing basis. 377 o SHOULD NOT immediately reuse IP addresses as soon as they become 378 available. 380 o IP addresses SHOULD be allocated in a way that minimises the 381 probability that two hosts will be allocated the same address. 383 o IP addresses SHOULD be allocated in a way that increases the 384 chances of a particular host being allocated the same address 385 should it leave and rejoin the network. 387 3.1.1 IPv6 Considerations 389 IPv6 provides a mechanism that allows a host to generate a link-local 390 IP address Autoconfiguration[RFC2462]. Thus a zeroconf IP interface 391 configuration solution for generating link-local addresses already 392 exists for hosts using IPv6. 394 3.2 Translation between Host name and IP Address 396 A zeroconf name resolution protocol allows users to refer to their 397 devices by name rather than IP address. Host names are more user 398 friendly than IP addresses and host names have a greater chance of 399 remaining unchanged over time. A zeroconf device connected to 400 different networks is quite likely to use different IP addresses, 401 however a host name may stay the same. For applications like web 402 browsers which store bookmarks and histories, use of names rather 403 than IP addresses is beneficial. 405 In a zeroconf network, the information required to construct a host 406 name must enter the network with the device. It is expected that 407 users will configure names into devices, or that devices will come 408 with a pre-configured name. Devices may also construct a name from a 409 MAC address or serial number. How this is to be achieved is outside 410 the scope of this document. 412 Terms: 414 host name: A textual name that allows a user to refer to a host by 415 name rather than IP address. 417 Requirements: 419 o A zeroconf name resolution protocol MUST allow host names to be 420 mapped into IP addresses. 422 o A zeroconf name resolution protocol SHOULD allow IP addresses to 423 be mapped back to names. 425 o Because hosts can connect and disconnect from a network at any 426 time, the failure to resolve a name at some time MUST NOT be taken 427 as an indication that the name will remain invalid for any length 428 of time. 430 o A zeroconf name resolution protocol SHOULD support resolution of 431 names on multiple IP subnets connected by a router. 433 The following requirements are derived from applying Section 2.1 and 434 Section 2.2 to zeroconf name resolution. 436 Requirements: 438 o A zeroconf name resolution protocol MUST support mechanisms to 439 probe whether a host name is currently in use. 441 o A host moving to a new network or powering up MUST ensure that all 442 names it will respond to do not conflict with names already in 443 use. 445 o Zeroconf name resolution protocols MUST allow timely re-use of 446 hostnames. 448 o Zeroconf name resolution protocols MUST resolve host name 449 conflicts in a timely manner and on an ongoing basis. 451 o Conflict detection procedures (such as probing for the existence 452 of a desired host name) MUST NOT prevent valid hostnames from 453 being resolved. 455 o Zeroconf name resolution protocols SHOULD NOT immediately reuse 456 host names as soon as they become available. 458 o Host names SHOULD be chosen in a way that minimises the 459 probability that two hosts will use the same name. Note that this 460 is out of scope of the name resolution protocol itself. 462 3.2.1 IPv6 Considerations 464 Protocols to perform translation between host name and IP address 465 have no known zeroconf-related differences for IPv4 and IPv6. 467 3.2.2 Relationship to the DNS 469 Zeroconf name resolution protocols cannot be directly equated with 470 the DNS even though they may have a number of similarities. For 471 example, the DNS protocols as deployed today rely on a server 472 infrastructure that may not be present in a zeroconf environment. 473 Host names used in zeroconf networks are inherently locally scoped 474 whereas DNS names are global and unique by design. 476 At the time of writing, consensus on how zeroconf name resolution 477 protocols should interact with the DNS has not been reached. The 478 next sections will attempt to capture the flavour of the different 479 approaches that have proposed. 481 3.2.2.1 Close coupling 483 In this approach an application may look up a DNS name (e.g. 484 "www.someco.com") using an existing API and receive and answer from a 485 zeroconf name resolution protocol. The zeroconf name resolution 486 protocol makes use of existing on-the-wire DNS formats, resource 487 record definitions, and namespace. Some names may have a DNS suffix 488 that identifies them as being local in scope. 490 Issues yet to be resolved with this approach relate to security and 491 consistency. If the zeroconf name resolution involves multicasting 492 the request on a local network then the risk of spoofed responses to 493 global DNS names like "www.someco.com" is increased. If the 494 namespace is the same, then doing a zeroconf name lookup should 495 return results consistent with DNS lookup for the same name. What is 496 meant by this consistency is not agreed. Should the zeroconf lookup 497 only be used when the DNS lookup has failed? Should that lookup 498 reflect what would have been returned by the DNS? How should the 499 probing for uniqueness of a zeroconf name relate to updating of a DNS 500 record? 502 3.2.2.2 Completely orthogonal 504 Another approach is to ensure that the zeroconf namespace and the DNS 505 namespace are completely orthogonal. There is therefore no 506 possibility of any application using the DNS via existing APIs 507 behaving differently after a zeroconf name resolution protocol is 508 deployed. Applications would need to explicitly use a zeroconf name 509 lookup API in order to resolve names using a zeroconf lookup 510 protocol. Conversely, existing applications will derive no benefit 511 from zeroconf protocols unless they are re-written. Deployment of a 512 zeroconf name resolution protocol would necessitate application 513 upgrade. 515 3.2.2.3 API compatible 517 In this approach the zeroconf namespace is distinct from the DNS 518 namespace however zeroconf names may be resolved using an existing 519 API. A number of operating systems use generalised name service 520 interfaces that transparently allow a variety of name lookup 521 protocols to be used when resolving hostnames for applications. A 522 zeroconf name resolution protocol could be incorporated into such a 523 system in a straightforward manner as just one more namespace and 524 lookup protocol. 526 Again, there is increased risk of spoofed responses if the multicast 527 zeroconf name resolution protocol is used to resolve 528 "www.someco.com". One possible way of minimising the security risk 529 is to ensure that locally scoped names are distinguishable from DNS 530 names, perhaps via a known reserved DNS suffix or by virtue of not 531 containing a dot. A multicast zeroconf resolution protocol could 532 then avoid making requests for names which look like global DNS 533 names. Alternatively, we could require that zeroconf name lookups 534 only be performed when the equivalent DNS lookup has failed. 536 3.3 IP Multicast Address Allocation Scenarios 538 IP Multicast is used to conserve bandwidth for multi-receiver bulk- 539 delivery applications, such as audio, video, or news. 541 IP Multicast is also used to perform a logical addressing function. 542 For example, when a host needs to communicate with local routers, it 543 can send packets to the all-routers multicast address without having 544 to know in advance the IP address(es) of the router(s). 546 IPv4 multicast addresses range from 224.0.0.0 to 239.255.255.255. 548 [RFC2365] defined multicast scopes are: 550 node-local (unspecified for IPv4) 551 link-local (224.0.0.0/24) 552 local (239.255.0.0/16) 553 site-local (unspecified for IPv4) 554 organizational-local (239.192.0.0/14) 555 global (224.0.1.0-238.255.255.255) 557 A relative assignment is an integer offset from the highest address 558 in the scope and represents a 32-bit address. For example, within 559 the local scope, 239.255.255.0/24 is reserved for relative 560 allocations. 562 Source-Specific Multicast addresses are 232.0.0.0 to 232.255.255.255 563 [I-D.ietf-ssm-arch]. 565 Unicast-prefix-based IPv6 multicast addresses are defined, as well as 566 source-specific multicast addresses for IPv6[RFC3306]. 568 Assumptions: 570 o The node-local and SSM addresses require no protocol or 571 interaction between multiple hosts, thus are not mentioned further 572 in this document. 574 o Global and organizational scoped addresses are meant for networks 575 of a greater scale than zeroconf protocols, thus are not mentioned 576 further in this document. 578 o Only local, link-local and site-local scopes are considered 579 further in this document. 581 o If it is desirable to restrict multicast packets from entering and 582 leaving a multicast scope boundary, it is assumed that the router 583 at the boundary is a "boundary router" as described in [RFC2365]. 585 Scenarios are scope enumeration, address allocation, and multiple 586 sources. 588 3.3.1 Scope Enumeration 590 Applications that leave the choice of scope up to the user require 591 the ability to enumerate what scopes the host is operating within. 592 In addition, services that are assigned relative addresses require 593 the ability to enumerate what scopes the host is within; only then 594 will a host be able to apply the relative address to a scope. 596 Requirements: Application support software used to autoconfigure 597 multicast addresses 599 o MUST list which of the scopes (local, link-local, or site-local) 600 are available for hosts. 602 o MUST list per-scope address ranges that may be allocated. 604 3.3.2 Address Allocation 606 IP multicast address allocation (local, link-local and site-local 607 scopes only) requires an application to be able to request the use of 608 a suitable multicast address. Coordination among applications must 609 occur to avoid conflicting allocations of the same address. This 610 coordination must span the entire scope respective to the address. 611 When an allocated address is no longer required, that address MUST 612 become available for use again. 614 Requirements: A zeroconf multicast address allocation protocol 616 o MUST select a multicast address. 618 o MUST prevent conflicting allocations of the same address. 620 o MUST allow the multicast address to become available after the 621 address is no longer in use. 623 3.3.3 Multiple Sources 625 An intercom system inside a home is an example of a multiple source 626 IP multicast application. In this type of application, several 627 sources may be sending packets destined to the same IP multicast 628 address. 630 This multiple source example illustrates the problem that a 631 particular address may continue to be valid, even after the host that 632 initially allocated the address is no longer present; the zeroconf 633 multicast address allocation must correctly support this type of 634 operation. In other words, if a host allocates a multicast address, 635 then leaves the multicast group, some other host must defend the 636 address. 638 Requirements: 640 o A host other than the allocating host MUST be able to defend or 641 otherwise maintain the allocation of a multicast address. 643 3.3.4 IPv6 Considerations 645 To date, no range has been reserved for dynamic allocation of Link- 646 scoped addresses in IPv4. Hence, unless such a range is reserved, 647 dynamic allocation of link-scoped addresses applies only to IPv6. 649 3.4 Service Discovery Scenarios 651 Service discovery protocols allow users or software to discover and 652 select among available services. This removes the requirement that 653 the user or client software know a server's location in advance in 654 order for the client to communicate with the server. 656 Terms: 658 service: a particular logical function that may be invoked via some 659 network protocol, such as printing, storing a file on a remote 660 disk, or even perhaps requesting delivery of a pizza. 662 service characteristics: Characteristics provide a finer granularity 663 of description to differentiate services beyond just the service 664 type. For example if the service type is printer, the 665 characteristics may be color, pages printed per second, location, 666 etc. 668 service discovery protocol: A service discovery protocol enables 669 clients to discover servers (or peers to find other peers) of a 670 particular service. A service discovery protocol is an 671 application layer protocol that relies on network and transport 672 protocol layers. 674 service protocol: A service protocol is used between the client and 675 the server after service discovery is complete. 677 The scenarios are the discovery of a simple printer service. 679 3.4.1 Printer Service 681 Network-enabled printers allow various network clients to submit 682 print jobs. A service discovery protocol MUST allow a printer 683 service to be discovered by devices needing to print. This requires 684 a service type as well as a service identifier to distinguish 685 instances of a single service type. Service discovery MUST be 686 independent from any particular printing protocol such as lpd, raw- 687 tcp, ipp. 689 Printers vary in their characteristics such as location, status, dots 690 per inch, etc. Discovering a service based on these characteristics 691 SHOULD be part of the service discovery protocol. 693 Service discovery MUST complete in a timely (10s of seconds) manner. 695 Requirements: 697 o MUST allow a service to be discovered. 699 o MUST discover via service identifier and/or service type. 701 o MUST discover services without use of a service-specific protocol. 703 o SHOULD discover via service characteristics. 705 o MUST complete in a timely (10s of seconds) manner. 707 3.4.2 IPv6 Considerations 709 Service discovery protocols have no zeroconf related differences for 710 IPv4 and IPv6. 712 4. Security Considerations 714 Zeroconf protocols are intended to operate in a local scope, in 715 networks containing one or more IP subnets, and potentially in 716 parallel with standard configured network protocols. 718 Application protocols running on networks employing zeroconf 719 protocols will be subject to the same sets of security issues 720 identified for standard configured networks. Examples are: denial of 721 service due to the unauthenticated nature of IPv4 ARP and lack of 722 confidentiality unless IPSec-ESP, TLS, or similar is used. However, 723 networks employing zeroconf protocols do have different security 724 characteristics and the subsequent sections attempt to draw out some 725 of the implications. 727 Security schemes usually rely on some sort of configuration. 728 Security mechanisms for zeroconf network protocols should be designed 729 in keeping with the spirit of zeroconf, thus making it easy for the 730 user to exchange keys, set policy, etc. It is preferable that a 731 single security mechanism be employed that will allow simple 732 configuration of all the various security parameters that may be 733 required. 735 Generally speaking, security mechanisms in IETF protocols are 736 mandatory to implement. A particular implementation might permit a 737 network administrator to turn off a particular security mechanism 738 operationally. However, implementations should be "secure out of the 739 box" and have a safe default configuration. 741 Zeroconf protocols MUST NOT be any less secure than related current 742 IETF-Standard protocols. This consideration overrides the goal of 743 allowing systems to obtain configuration automatically. Security 744 threats to be considered include both active attacks (e.g. denial of 745 service) and passive attacks (e.g. eavesdropping). Protocols that 746 require confidentiality and/or integrity should include integrated 747 confidentiality and/or integrity mechanisms or should specify the use 748 of existing standards-track security mechanisms (e.g. TLS [RFC2246], 749 ESP [RFC1827], AH [RFC2402]) appropriate to the threat. 751 4.1 The Basic in/out Security Policy 753 The claim/collide approach to resource allocation is attractive in 754 the zeroconf environment. To operate securely, hosts allocating 755 resources need to ensure that messages indicating that a network 756 resource is in use are authenticated. Hosts soliciting for a name or 757 service must also be able to authenticate the responses they receive. 758 A message is considered "authenticated" if it can be proved to have 759 been sent by a member of a group of devices running zeroconf 760 protocols. Note that in general, devices running zeroconf protocols 761 must trust the other devices in the group because any device may 762 claim to be using an address or name, or advertising a service. 763 Zeroconf security mechanisms must at a minimum be able to distinguish 764 between messages originating from a device "inside" the group or a 765 device "outside" the group. 767 Requirement: 769 o Security schemes for zeroconf protocols MUST be able to implement 770 a basic "inside/outside" security policy. 772 Access control mechanisms within a zeroconf network are beyond the 773 scope of this document. 775 4.2 Security Scenarios 777 In the next few sections, several scenarios are examined to highlight 778 the security implications of employing zeroconf protocols in various 779 environments. 781 4.2.1 Use on an isolated, secure network link 783 In this scenario all the devices in the network are connected to a 784 secure link (e.g. a control network in a car, or a private network 785 between two devices used for configuration). The link might be a 786 separate physical wire or shared media with layer-2 security enabled 787 (e.g. wireless or power-line networks). Any host that has access to 788 the link is trusted and any packet received from the secure link is 789 considered to be authenticated. In this case, the inside/outside 790 policy is implemented by controlling access to the link itself. 792 4.2.2 Use on a shared (insecure) link 794 In this scenario, a group of devices use zeroconf protocols on 795 link(s) they share with other devices who are NOT part of the group. 796 Various pieces of network configuration MUST be consistent across all 797 hosts sharing the link (e.g. addresses, netmask, routing 798 information) in order for communication to occur at all. 799 Consequently, hosts inside the group are potentially at risk from 800 hosts outside their group when they try to configure such information 801 (e.g. via ARP insecurity). Host names and service identifiers MUST 802 be unique within a group, but with authentication may not need to be 803 unique across the link. Assuming that requests and responses can be 804 associated with a group and authenticated, solicitations and 805 responses for host names and services that are not located inside the 806 group can be ignored. 808 4.2.3 Use in conjunction with configured protocols 810 Zeroconf protocols are likely to be used in conjunction with 811 configured network protocols. In general, zeroconf protocols must 812 not allocate resources from the same address or name spaces used by 813 configured network protocols. Locally allocated zeroconf network 814 resources must not mask global assigned resources. 816 5. IANA Considerations 818 No known IANA considerations arise from this document. 820 6. Acknowledgments 822 Thanks to Peter Ford and Stuart Cheshire for hosting the NITS 823 (Networking In The Small) BOF that was the catalyst to forming the 824 Zeroconf Working Group. 826 Thanks to Erik Guttman and Stuart Cheshire for forming and chairing 827 the Zeroconf Working Group, which is responsible for this document. 829 Thanks to Erik Guttman for providing key input to the service 830 discovery and the security sections. 832 Thanks to Dave Thaler for providing key input to the IP multicast 833 address allocation sections. 835 Thanks to Stuart Cheshire for providing key input to the introduction 836 and IP interface configuration sections. 838 Thanks to Myron Hattig for acting as editor for previous versions of 839 this document. 841 Additional recognition goes the following people for their 842 influential contributions to this document and its predecessors: 843 Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob Quinn, 844 John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl Auerbach, 845 Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland, and Bernard 846 Aboba, Ran Atkinson. 848 Normative References 850 Informative References 852 [I-D.ietf-ssm-arch] Cain, B. and H. Holbrook, "Source-Specific 853 Multicast for IP", draft-ietf-ssm-arch-00 (work 854 in progress), February 2002. 856 [RFC0826] Plummer, D., "Ethernet Address Resolution 857 Protocol: Or converting network protocol 858 addresses to 48.bit Ethernet address for 859 transmission on Ethernet hardware", STD 37, RFC 860 826, November 1982. 862 [RFC1034] Mockapetris, P., "Domain names - concepts and 863 facilities", STD 13, RFC 1034, November 1987. 865 [RFC1035] Mockapetris, P., "Domain names - implementation 866 and specification", STD 13, RFC 1035, November 867 1987. 869 [RFC1123] Braden, R., "Requirements for Internet Hosts - 870 Application and Support", STD 3, RFC 1123, 871 October 1989. 873 [RFC1827] Atkinson, R., "IP Encapsulating Security Payload 874 (ESP)", RFC 1827, August 1995. 876 [RFC2026] Bradner, S., "The Internet Standards Process -- 877 Revision 3", BCP 9, RFC 2026, October 1996. 879 [RFC2119] Bradner, S., "Key words for use in RFCs to 880 Indicate Requirement Levels", BCP 14, RFC 2119, 881 March 1997. 883 [RFC2131] Droms, R., "Dynamic Host Configuration 884 Protocol", RFC 2131, March 1997. 886 [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., 887 Freier, A. and P. Kocher, "The TLS Protocol 888 Version 1.0", RFC 2246, January 1999. 890 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight 891 Directory Access Protocol (v3)", RFC 2251, 892 December 1997. 894 [RFC2365] Meyer, D., "Administratively Scoped IP 895 Multicast", BCP 23, RFC 2365, July 1998. 897 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture 898 for the Internet Protocol", RFC 2401, November 899 1998. 901 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication 902 Header", RFC 2402, November 1998. 904 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, 905 "Neighbor Discovery for IP Version 6 (IPv6)", 906 RFC 2461, December 1998. 908 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless 909 Address Autoconfiguration", RFC 2462, December 910 1998. 912 [RFC2535] Eastlake, D., "Domain Name System Security 913 Extensions", RFC 2535, March 1999. 915 [RFC2541] Eastlake, D., "DNS Security Operational 916 Considerations", RFC 2541, March 1999. 918 [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. 919 Day, "Service Location Protocol, Version 2", RFC 920 2608, June 1999. 922 [RFC2730] Hanna, S., Patel, B. and M. Shah, "Multicast 923 Address Dynamic Client Allocation Protocol 924 (MADCAP)", RFC 2730, December 1999. 926 [RFC2931] Eastlake, D., "DNS Request and Transaction 927 Signatures ( SIG(0)s)", RFC 2931, September 928 2000. 930 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix- 931 based IPv6 Multicast Addresses", RFC 3306, 932 August 2002. 934 Author's Address 936 Aidan Williams 937 Motorola Australian Research Centre 938 Locked Bag 5028 939 Botany, NSW 1455 940 Australia 942 Phone: +61 2 9666 0500 943 EMail: Aidan.Williams@motorola.com 944 URI: http://www.motorola.com.au/marc/ 946 Full Copyright Statement 948 Copyright (C) The Internet Society (2002). All Rights Reserved. 950 This document and translations of it may be copied and furnished to 951 others, and derivative works that comment on or otherwise explain it 952 or assist in its implementation may be prepared, copied, published 953 and distributed, in whole or in part, without restriction of any 954 kind, provided that the above copyright notice and this paragraph are 955 included on all such copies and derivative works. However, this 956 document itself may not be modified in any way, such as by removing 957 the copyright notice or references to the Internet Society or other 958 Internet organizations, except as needed for the purpose of 959 developing Internet standards in which case the procedures for 960 copyrights defined in the Internet Standards process must be 961 followed, or as required to translate it into languages other than 962 English. 964 The limited permissions granted above are perpetual and will not be 965 revoked by the Internet Society or its successors or assigns. 967 This document and the information contained herein is provided on an 968 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 969 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 970 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 971 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 972 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 974 Acknowledgement 976 Funding for the RFC Editor function is currently provided by the 977 Internet Society.