idnits 2.17.1 draft-ietf-zeroconf-reqts-11.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 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 ([RFC1034], [RFC1035], [RFC2131], [RFC2730], [RFC2251]), 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 -- 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 (August 26, 2002) is 7907 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: 'SSM' is mentioned on line 486, but not defined == Missing Reference: 'SS6' is mentioned on line 567, but not defined == Unused Reference: 'I-D.holbrook-ssm-arch' is defined on line 792, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipngwg-uni-based-mcast' is defined on line 797, but no explicit reference was found in the text == Unused Reference: 'RFC0826' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 819, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 828, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 855, but no explicit reference was found in the text == Unused Reference: 'RFC2461' is defined on line 864, but no explicit reference was found in the text == Unused Reference: 'RFC2535' is defined on line 874, but no explicit reference was found in the text == Unused Reference: 'RFC2541' is defined on line 878, but no explicit reference was found in the text == Unused Reference: 'RFC2608' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'RFC2931' is defined on line 892, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.holbrook-ssm-arch' -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-uni-based-mcast is -02, but you're referring to -03. ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2541 (Obsoleted by RFC 4641) Summary: 12 errors (**), 0 flaws (~~), 16 warnings (==), 4 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: February 24, 2003 August 26, 2002 6 Zeroconf IP Host Requirements 7 draft-ietf-zeroconf-reqts-11.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 February 24, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1 Key Words . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2 Reading This Document . . . . . . . . . . . . . . . . . . . 3 66 1.3 Zeroconf Coexistence . . . . . . . . . . . . . . . . . . . . 4 67 1.4 Scalability . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.5 Routable Protocol Requirement . . . . . . . . . . . . . . . 4 69 1.6 Maintaining Consistent Network State . . . . . . . . . . . . 4 70 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.1 Addition and Removal of Devices . . . . . . . . . . . . . . 5 72 2.2 Network Coalescing and Partitioning . . . . . . . . . . . . 5 73 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.1 IP Interface Configuration . . . . . . . . . . . . . . . . . 7 75 3.1.1 IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 8 76 3.2 Translation between Host name and IP Address . . . . . . . . 8 77 3.2.1 IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 10 78 3.2.2 Relationship to the DNS . . . . . . . . . . . . . . . . . . 10 79 3.3 IP Multicast Address Allocation Scenarios . . . . . . . . . 10 80 3.3.1 Scope Enumeration . . . . . . . . . . . . . . . . . . . . . 11 81 3.3.2 Address Allocation . . . . . . . . . . . . . . . . . . . . . 12 82 3.3.3 Multiple Sources . . . . . . . . . . . . . . . . . . . . . . 12 83 3.3.4 IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 13 84 3.4 Service Discovery Scenarios . . . . . . . . . . . . . . . . 13 85 3.4.1 Printer Service . . . . . . . . . . . . . . . . . . . . . . 13 86 3.4.2 IPv6 Considerations . . . . . . . . . . . . . . . . . . . . 14 87 4. Security Considerations . . . . . . . . . . . . . . . . . . 14 88 4.1 The Basic in/out Security Policy . . . . . . . . . . . . . . 15 89 4.2 Security Scenarios . . . . . . . . . . . . . . . . . . . . . 15 90 4.2.1 Use on an isolated, secure network link . . . . . . . . . . 16 91 4.2.2 Use on a shared (insecure) link . . . . . . . . . . . . . . 16 92 4.2.3 Use in conjunction with configured protocols . . . . . . . . 16 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 94 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 95 References . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . 20 97 Full Copyright Statement . . . . . . . . . . . . . . . . . . 21 99 1. Introduction 101 A zeroconf protocol is able to operate correctly in the absence of 102 configured information from either a user or infrastructure services 103 such as conventional DHCP [RFC2131] or DNS [RFC1034][RFC1035] 104 servers. Zeroconf protocols may use configured information, when it 105 is available, but do not rely on it being present. For example, the 106 use of MAC addresses (i.e. layer two addresses) as parameters in 107 zeroconf protocols is generally acceptable because they are globally 108 unique and readily available on most devices of interest. 110 The benefits of zeroconf protocols over existing configured protocols 111 are an increase in the ease-of-use for end-users and a simplification 112 of the infrastructure necessary to operate protocols. 114 This document discusses requirements for zeroconf protocols in four 115 areas: 117 o IP interface configuration 119 o Translation between host name and IP address 121 o IP multicast address allocation 123 o Service discovery 125 Security considerations are also discussed. 127 1.1 Key Words 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 1.2 Reading This Document 135 Introduction, Scenarios, Requirements, and Security Considerations 136 are the major sections of this document. 138 The Scenarios & Requirements sections walk through protocol scenarios 139 and then lists the requirements of the protocol needed to accomplish 140 the scenario. 142 The Security Consideration section lists security issues with 143 zeroconf protocols. 145 Requirements dispersed throughout this document begin with the text 146 "Requirements:" or "Requirement:" on a single line, which is followed 147 by a bulleted list of requirements. 149 1.3 Zeroconf Coexistence 151 It is not necessary to simultaneously use zeroconf protocols in all 152 four areas (i.e. IP interface configuration, translation between 153 host name and IP address, IP multicast address allocation, service 154 discovery). For example, it may make sense on some networks to 155 provide a DHCP server for configured IP interface configuration, but 156 perform translation between host name and IP address using a zeroconf 157 protocol. 159 1.4 Scalability 161 The primary reasons to deploy Zeroconf protocols are simplicity and 162 ease-of-use. Scalability is important but it is a secondary goal. 163 Thus, scalability should not detract from the primary goals of 164 simplicity and ease-of-use. 166 1.5 Routable Protocol Requirement 168 Zeroconf protocols are not inherently limited to a single IP subnet. 169 If a protocol is intended to span multiple IP subnets it MUST NOT use 170 broadcasts or link-local addressing. 172 Requirement: 174 o Protocols intended to span multiple IP subnets MUST NOT use 175 broadcasts or link-local addressing. 177 1.6 Maintaining Consistent Network State 179 Many networks undergo change during their lifetime. For example, 180 hosts may be added and removed, network segments may be re-arranged, 181 and devices may change names or run different services. In a 182 configured network an administrator ensures that protocol parameters 183 are updated to reflect these changes, and is responsible for ensuring 184 network consistency. 186 In contrast, zeroconf protocols must adapt to changing network 187 conditions. Zeroconf protocols must be able to resolve conflicts and 188 return the network to a consistent state after changes in network 189 topology or other events. 191 Requirement: 193 o Zeroconf protocols MUST restore the network to a consistent state 194 in a timely fashion when changes in network topology or other 195 events occur. 197 This is a general requirement applicable to all zeroconf protocols. 198 It should be kept in mind when considering the scenarios in Section 199 2, and will be applied to derive requirements for each zeroconf 200 protocol area considered in Section 3. 202 2. Scenarios 204 The scenarios described in the next few sections highlight the 205 general characteristics of the zeroconf protocol environment. Each 206 zeroconf protocol needs to deal with the following aspects of the 207 zeroconf environment. 209 2.1 Addition and Removal of Devices 211 Zeroconf protocols are expected to be useful in networks where hosts 212 come and go. Hosts using zeroconf protocols must not assume that 213 network resources assigned to them (e.g. address assignments, names, 214 etc) will be appropriate for networks they subsequently join. In 215 addition, network resources allocated to a host should be reclaimed 216 once it leaves the network. 218 Requirements: 220 o Zeroconf protocols MUST support mechanisms to probe whether a 221 network resource is currently in use. 223 o Hosts using zeroconf protocols MUST validate allocated network 224 resources when moving to a new network or powering up. 226 o Zeroconf protocols MUST support timely reclamation of any network 227 resources they allocate. 229 Implication: 231 o The information needed to allocate network resources must arrive 232 in the network along with the host. 234 2.2 Network Coalescing and Partitioning 236 Inevitably, two or more operational networks using zeroconf protocols 237 will be connected together, creating a single merged network. Prior 238 to the merge, each zeroconf network has independently allocated 239 resources (e.g. addresses, names, etc). After merging, two hosts in 240 the merged network may end up using the same network resource, thus 241 potentially creating conflicts. 243 In general a network merge "event" cannot be detected. For example, 244 the installation of a layer-2 bridge between two zeroconf networks 245 does not result in network interfaces going up and down on the hosts, 246 which would be an indication that they should re-validate or 247 reconfigure the network resources they are using. 249 Implication: 251 o It is not sufficient to rely on hosts detecting conflicts during 252 power on or movement from network to network. Rather, detection 253 and resolution of network conflicts is an ongoing part of zeroconf 254 protocol operation. 256 Requirement: 258 o Zeroconf protocols MUST resolve network resource conflicts in a 259 timely manner and on an ongoing basis. 261 Zeroconf protocols that detect and resolve network resource conflicts 262 on an ongoing basis will benefit from increased robustness in the 263 face of poor implementation, and varying network conditions. 265 A zeroconf network may also be split into two or more smaller 266 independent networks. The requirement from Section 2.1 that network 267 resources be reclaimed in a timely fashion also applies in this case. 268 Since network merging increases the potential for network conflicts, 269 it may be prudent to ensure that network resources associated with 270 hosts are not immediately re-claimed for re-use. Any network which 271 periodically joins and partitions with another zeroconf network will 272 benefit from this behaviour. An example is an IP network in a car 273 joining with the home network whilst the car is parked in the garage 274 and partitioning when it is driven away. 276 Requirement: 278 o Zeroconf protocols SHOULD NOT immediately reuse network resources 279 as soon as they become available. 281 o Network resources SHOULD be allocated in a way that minimises the 282 probability that two hosts will be allocated the same resource. 284 o Network resources SHOULD be allocated in a way that increases the 285 chances of a particular host being allocated the same resource 286 should it leave and rejoin the network. 288 3. Requirements 290 This section contains a subsection for each of the four protocol 291 areas. Within each subsection, terms and assumptions are followed by 292 specific zeroconf protocol requirements in that area. Each 293 subsection ends with IPv6 considerations. 295 3.1 IP Interface Configuration 297 In this document, IP interface configuration always includes the 298 configuration of an IP address and netmask; it may include some 299 routing information (such as default route). IP interface 300 configuration is needed before almost any IP communication can take 301 place. 303 Terms: 305 IP subnet: A single logical IP network that may span multiple link 306 layer networks. All IP hosts on the IP subnet communicate without 307 any layer 3 forwarding device (e.g. router). 309 internetwork: Multiple IP subnets connected by routers. 311 network: a context sensitive term that may apply to one or more of 312 the terms: a link layer network, an IP subnet, or an internetwork. 314 bridge: a networking device that connects two link layer networks by 315 using only link-layer protocols (e.g. Ethernet). 317 IP interface configuration must take place before an IP packet can be 318 sent from one host to another. This section requires that sufficient 319 information be provided by a zeroconf interface configuration 320 protocol to allow IP packets to be sent to a unicast destination IP 321 address on the same subnet as the sender, and on a different subnet 322 to the sender. 324 Requirements: A zeroconf IP interface configuration protocol 326 o MUST configure an appropriate netmask. 328 o MUST allocate unique IP addresses within an IP subnet. 330 o MUST allow configuration of zero or more gateways (for the 331 internetwork scenario). 333 o MUST have unique IP subnets within an internetwork (This is only 334 for the case when there is one or more router attached in the 335 network where autoconfigured hosts. How routers obtain their 336 configuration is beyond of the scope of this document.) 338 The following requirements are derived from applying Section 2.1 and 339 Section 2.2 to IP interface configuration. 341 Requirements: A zeroconf IP interface configuration protocol 343 o MUST be capable of discovering whether an IP address is currently 344 in use. 346 o Hosts using a zeroconf interface configuration protocol MUST 347 validate allocated IP addresses when moving to a new network or 348 powering up. 350 o MUST support timely reclamation of allocated IP addresses. 352 o MUST resolve IP address conflicts in a timely manner and on an 353 ongoing basis. 355 o SHOULD NOT immediately reuse IP addresses as soon as they become 356 available. 358 o IP addresses SHOULD be allocated in a way that minimises the 359 probability that two hosts will be allocated the same address. 361 o IP addresses SHOULD be allocated in a way that increases the 362 chances of a particular host being allocated the same address 363 should it leave and rejoin the network. 365 3.1.1 IPv6 Considerations 367 IPv6 allows a host to select an appropriate IP address and netmask 368 using Stateless Autoconfiguration[RFC2462]. Thus a zeroconf IP 369 interface configuration solution already exists for hosts using IPv6. 371 3.2 Translation between Host name and IP Address 373 A zeroconf name resolution protocol allows users to refer to their 374 devices by name rather than IP address. Host names are more user 375 friendly than IP addresses and host names have a greater chance of 376 remaining unchanged over time. A zeroconf device connected to 377 different networks is quite likely to use a different IP addresses, 378 however a host name may stay the same. For applications like web 379 browsers which store bookmarks and histories, use of names rather 380 than IP addresses is beneficial. 382 In a zeroconf network, the information required to construct a host 383 name must enter the network with the device. It is expected that 384 users will configure names into devices, or that devices will come 385 with a pre-configured name. Devices may also construct a name from a 386 MAC address or serial number. How this is to be achieved is outside 387 the scope of this document. 389 Terms: 391 host name: A textual name that allows a user to refer to a host by 392 name rather than IP address. 394 Requirements: 396 o A zeroconf name resolution protocol MUST allow host names to be 397 mapped into IP addresses. 399 o A zeroconf name resolution protocol SHOULD allow IP addresses to 400 be mapped back to names. 402 o A zeroconf name resolution protocol MUST support resolution of 403 names that could not previously be resolved. In particular, 404 probing a desired host name (which does not exist) when joining a 405 network must not prevent the desired hostname from being resolved. 407 o A zeroconf name resolution protocol MUST support resolution of 408 names on multiple IP subnets connected by a router. 410 The following requirements are derived from applying Section 2.1 and 411 Section 2.2 to zeroconf name resolution. 413 Requirements: 415 o A zeroconf name resolution protocol MUST support mechanisms to 416 probe whether a host name is currently in use. 418 o Hosts using zeroconf name resolution protocols MUST ensure that 419 the use of a desired name will not cause a conflict when moving to 420 a new network or powering up. 422 o Zeroconf name resolution protocols MUST allow timely re-use of 423 hostnames. 425 o Zeroconf name resolution protocols MUST resolve host name 426 conflicts in a timely manner and on an ongoing basis. 428 o Zeroconf name resolution protocols SHOULD NOT immediately reuse 429 host names as soon as they become available. 431 o Host names SHOULD be chosen in a way that minimises the 432 probability that two hosts will use the same resource. Note that 433 this is out of scope of the name resolution protocol itself. 435 3.2.1 IPv6 Considerations 437 Protocols to perform translation between host name and IP address 438 have no known zeroconf-related differences for IPv4 and IPv6. 440 3.2.2 Relationship to the DNS 442 Zeroconf protocols cannot be directly equated with the DNS even 443 though they have a number of similarities. For example, the DNS 444 protocols as deployed today rely on a server infrastructure that may 445 not be present in a zeroconf environment. Host names used in 446 zeroconf networks are inherently locally scoped whereas DNS names are 447 global and unique by design. It should be noted that a DNS server 448 supporting dynamic updates can provide automatic configuration of a 449 DNS name space in a network. 451 The zeroconf namespace is orthogonal to the DNS class IN namespace. 452 It is RECOMMENDED that zeroconf host names conform to the character 453 set and formatting of DNS host names. 455 Using a zeroconf name resolution protocol to query a DNS name is NOT 456 equivalent to using the DNS protocols to query the same name. A host 457 using DNS and zeroconf name resolution protocols at the same time 458 MUST NOT allow zeroconf names to mask DNS names. 460 3.3 IP Multicast Address Allocation Scenarios 462 IP Multicast is used to conserve bandwidth for multi-receiver bulk- 463 delivery applications, such as audio, video, or news. 465 IP Multicast is also used to perform a logical addressing function. 466 For example, when a host needs to communicate with local routers, it 467 can send packets to the all-routers multicast address without having 468 to know in advance the IP address(es) of the router(s). 470 IPv4 multicast addresses range from 224.0.0.0 to 239.255.255.255. 472 [RFC2365] defined multicast scopes are: 474 node-local (unspecified for IPv4) 475 link-local (224.0.0.0/24) 476 local (239.255.0.0/16) 477 site-local (unspecified for IPv4) 478 organizational-local (239.192.0.0/14) 479 global (224.0.1.0-238.255.255.255) 481 A relative assignment is an integer offset from the highest address 482 in the scope and represents a 32-bit address. For example, within 483 the local scope, 239.255.255.0/24 is reserved for relative 484 allocations. 486 Source-Specific Multicast [SSM] addresses are 232.0.0.0 to 487 232.255.255.255. 489 Unicast-prefix-based IPv6 multicast addresses are defined, as well as 490 source-specific multicast addresses for IPv6, in [SS6]. 492 Assumptions: 494 o The node-local and SSM addresses require no protocol or 495 interaction between multiple hosts, thus are not mentioned further 496 in this document. 498 o Global and organizational scoped addresses are meant for networks 499 of a greater scale than zeroconf protocols, thus are not mentioned 500 further in this document. 502 o Only local, link-local and site-local scopes are considered 503 further in this document. 505 o If it is desirable to restrict multicast packets from entering and 506 leaving a multicast scope boundary, it is assumed that the router 507 at the boundary is a "boundary router" as described in [RFC2365]. 509 Scenarios are scope enumeration, address allocation, and multiple 510 sources. 512 3.3.1 Scope Enumeration 514 Applications that leave the choice of scope up to the user require 515 the ability to enumerate what scopes the host is operating within. 516 In addition, services that are assigned relative addresses require 517 the ability to enumerate what scopes the host is within; only then 518 will a host be able to apply the relative address to a scope. 520 Requirements: Application support software used to autoconfigure 521 multicast addresses 522 o MUST list which of the scopes (local, link-local, or site-local) 523 are available for hosts. 525 o MUST list per-scope address ranges that may be allocated. 527 3.3.2 Address Allocation 529 IP multicast address allocation (local, link-local and site-local 530 scopes only) requires an application to be able to request the use of 531 a suitable multicast address. Coordination among applications must 532 occur to avoid conflicting allocations of the same address. This 533 coordination must span the entire scope respective to the address. 534 When an allocated address is no longer required, that address MUST 535 become available for use again. 537 o MUST select a multicast address. 539 o MUST prevent conflicting allocations of the same address. 541 o MUST allow the multicast address to become available after the 542 address is no longer in use. 544 3.3.3 Multiple Sources 546 An intercom system inside a home is an example of a multiple source 547 IP multicast application. In this type of application, several 548 sources may be sending packets destined to the same IP multicast 549 address. 551 This multiple source example illustrates the problem that a 552 particular address may continue to be valid, even after the host that 553 initially allocated the address is no longer present; the zeroconf 554 multicast address allocation must correctly support this type of 555 operation. In other words, if a host allocates a multicast address, 556 then leaves the multicast group, some other host must defend the 557 address. 559 Requirements: 561 o A host other than the allocating host MUST be able to defend or 562 otherwise maintain the allocation of a multicast address. 564 3.3.4 IPv6 Considerations 566 To date, no range has been reserved for source-specific addresses in 567 IPv6. See [SS6]. Hence, until such a range is reserved, dynamic 568 allocation of source-specific addresses applies only to IPv4. 570 To date, no range has been reserved for dynamic allocation of Link- 571 scoped addresses in IPv4. Hence, unless such a range is reserved, 572 dynamic allocation of link-scoped addresses applies only to IPv6. 574 3.4 Service Discovery Scenarios 576 Service discovery protocols allow users or software to discover and 577 select among available services. This removes the requirement that 578 the user or client software know a server's location in advance in 579 order for the client to communicate with the server. 581 Terms: 583 service: a particular logical function that may be invoked via some 584 network protocol, such as printing, storing a file on a remote 585 disk, or even perhaps requesting delivery of a pizza. 587 service characteristics: Characteristics provide a finer granularity 588 of description to differentiate services beyond just the service 589 type. For example if the service type is printer, the 590 characteristics may be color, pages printed per second, location, 591 etc. 593 service discovery protocol: A service discovery protocol enables 594 clients to discover servers (or peers to find other peers) of a 595 particular service. A service discovery protocol is an 596 application layer protocol that relies on network and transport 597 protocol layers. 599 service protocol: A service protocol is used between the client and 600 the server after service discovery is complete. 602 The scenarios are the discovery of a simple printer service. 604 3.4.1 Printer Service 606 Network-enabled printers allow various network clients to submit 607 print jobs. A service discovery protocol MUST allow a printer 608 service to be discovered by devices needing to print. This requires 609 a service type as well as a service identifier to distinguish 610 instances of a single service type. Service discovery MUST be 611 independent from any particular printing protocol such as lpd, raw- 612 tcp, ipp. 614 Printers vary in their characteristics such as location, status, dots 615 per inch, etc. Discovering a service based on these characteristics 616 SHOULD be part of the service discovery protocol. 618 Service discovery MUST complete in a timely (10s of seconds) manner. 620 Requirements: 622 o MUST allow a service to be discovered. 624 o MUST discover via service identifier and/or service type. 626 o MUST discover services without use of a service-specific protocol. 628 o SHOULD discover via service characteristics. 630 o MUST complete in a timely (10s of seconds) manner. 632 3.4.2 IPv6 Considerations 634 Service discovery protocols have no zeroconf related differences for 635 IPv4 and IPv6. 637 4. Security Considerations 639 Zeroconf protocols are intended to operate in a local scope, in 640 networks containing one or more IP subnets, and potentially in 641 parallel with standard configured network protocols. 643 Application protocols running on networks employing zeroconf 644 protocols will be subject to the same sets of security issues 645 identified for standard configured networks. Examples are: denial of 646 service due to the unauthenticated nature of IPv4 ARP and lack of 647 confidentiality unless IPSec-ESP, TLS, or similar is used. However, 648 networks employing zeroconf protocols do have different security 649 characteristics and the subsequent sections attempt to draw out some 650 of the implications. 652 Security schemes usually rely on some sort of configuration. 653 Security mechanisms for zeroconf network protocols should be designed 654 in keeping with the spirit of zeroconf, thus making it easy for the 655 user to exchange keys, set policy, etc. It is preferable that a 656 single security mechanism be employed that will allow simple 657 configuration of all the various security parameters that may be 658 required. 660 Generally speaking, security mechanisms in IETF protocols are 661 mandatory to implement. A particular implementation might permit a 662 network administrator to turn off a particular security mechanism 663 operationally. However, implementations should be "secure out of the 664 box" and have a safe default configuration. 666 Zeroconf protocols MUST NOT be any less secure than related current 667 IETF-Standard protocols. This consideration overrides the goal of 668 allowing systems to obtain configuration automatically. Security 669 threats to be considered include both active attacks (e.g. denial of 670 service) and passive attacks (e.g. eavesdropping). Protocols that 671 require confidentiality and/or integrity should include integrated 672 confidentiality and/or integrity mechanisms or should specify the use 673 of existing standards-track security mechanisms (e.g. TLS [RFC2246], 674 ESP [RFC1827], AH [RFC2402]) appropriate to the threat. 676 4.1 The Basic in/out Security Policy 678 The claim/collide approach to resource allocation is attractive in 679 the zeroconf environment. To operate securely, hosts allocating 680 resources need to ensure that messages indicating that a network 681 resource is in use are authenticated. Hosts soliciting for a name or 682 service must also be able to authenticate the responses they receive. 683 A message is considered "authenticated" if it can be proved to have 684 been sent by a member of a group of devices running zeroconf 685 protocols. Note that in general, devices running zeroconf protocols 686 must trust the other devices in the group because any device may 687 claim to be using an address or name, or advertising a service. 688 Zeroconf security mechanisms must at a minimum be able to distinguish 689 between messages originating from a device "inside" the group or a 690 device "outside" the group. 692 Requirement: 694 o Security schemes for zeroconf protocols MUST be able to implement 695 a basic "inside/outside" security policy. 697 Access control mechanisms within a zeroconf network are beyond the 698 scope of this document. 700 4.2 Security Scenarios 702 In the next few sections, several scenarios are examined to highlight 703 the security implications of employing zeroconf protocols in various 704 environments. 706 4.2.1 Use on an isolated, secure network link 708 In this scenario all the devices in the network are connected to a 709 secure link (e.g. a control network in a car, or a private network 710 between two devices used for configuration). The link might be a 711 separate physical wire or shared media with layer-2 security enabled 712 (e.g. wireless or power-line networks). Any host that has access to 713 the link is trusted and any packet received from the secure link is 714 considered to be authenticated. In this case, the inside/outside 715 policy is implemented by controlling access to the link itself. 717 4.2.2 Use on a shared (insecure) link 719 In this scenario, a group of devices use zeroconf protocols on 720 link(s) they share with other devices who are NOT part of the group. 721 Various pieces of network configuration MUST be consistent across all 722 hosts sharing the link (e.g. addresses, netmask, routing 723 information) in order for communication to occur at all. 724 Consequently, hosts inside the group are potentially at risk from 725 hosts outside their group when they try to configure such information 726 (e.g. via ARP insecurity). Host names and service identifiers MUST 727 be unique within a group, but with authentication may not need to be 728 unique across the link. Assuming that requests and responses can be 729 associated with a group and authenticated, solicitations and 730 responses for host names and services that are not located inside the 731 group can be ignored. 733 4.2.3 Use in conjunction with configured protocols 735 Zeroconf protocols are likely to be used in conjunction with 736 configured network protocols. In general, zeroconf protocols must 737 not allocate resources from the same address or name spaces used by 738 configured network protocols. Locally allocated zeroconf network 739 resources must not mask global assigned resources. 741 Some questions for further discussion: 743 o Anything else to add here? 745 o What might be appropriate MUST/SHOULD requirements? 747 o Do we wish to restrict the operation of specific zeroconf 748 protocols in particular cases (e.g. the mDNS case, were it is 749 disabled if and DNS configuration information is present) 751 o Do we wish to imply that zeroconf protocols may only be used to 752 configure IP addresses in specific restricted ranges? (e.g. 753 private addresses, 169.254/16) 755 o What about "configured protocols" that may delegate an address or 756 name space to a zeroconf protocol for allocation? 758 5. IANA Considerations 760 No known IANA considerations arise from this document. 762 6. Acknowledgments 764 Thanks to Peter Ford and Stuart Cheshire for hosting the NITS 765 (Networking In The Small) BOF that was the catalyst to forming the 766 Zeroconf Working Group. 768 Thanks to Erik Guttman and Stuart Cheshire for forming and chairing 769 the Zeroconf Working Group, which is responsible for this document. 771 Thanks to Erik Guttman for providing key input to the service 772 discovery and the security sections. 774 Thanks to Dave Thaler for providing key input to the IP multicast 775 address allocation sections. 777 Thanks to Stuart Cheshire for providing key input to the introduction 778 and IP interface configuration sections. 780 Thanks to Myron Hattig for acting as editor for previous versions of 781 this document. 783 Additional recognition goes the following people for their 784 influential contributions to this document and its predecessors: 785 Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob Quinn, 786 John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl Auerbach, 787 Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland, and Bernard 788 Aboba, Ran Atkinson. 790 References 792 [I-D.holbrook-ssm-arch] Cain, B. and H. Holbrook, "Source- 793 Specific Multicast for IP", draft- 794 holbrook-ssm-arch-03 (work in 795 progress), November 2001. 797 [I-D.ietf-ipngwg-uni-based-mcast] Haberman, B. and D. Thaler, 798 "Unicast-Prefix-based IPv6 799 Multicast Addresses", draft-ietf- 800 ipngwg-uni-based-mcast-03 (work in 801 progress), October 2002. 803 [RFC0826] Plummer, D., "Ethernet Address 804 Resolution Protocol: Or converting 805 network protocol addresses to 806 48.bit Ethernet address for 807 transmission on Ethernet 808 hardware", STD 37, RFC 826, 809 November 1982. 811 [RFC1034] Mockapetris, P., "Domain names - 812 concepts and facilities", STD 13, 813 RFC 1034, November 1987. 815 [RFC1035] Mockapetris, P., "Domain names - 816 implementation and specification", 817 STD 13, RFC 1035, November 1987. 819 [RFC1123] Braden, R., "Requirements for 820 Internet Hosts - Application and 821 Support", STD 3, RFC 1123, October 822 1989. 824 [RFC1827] Atkinson, R., "IP Encapsulating 825 Security Payload (ESP)", RFC 1827, 826 August 1995. 828 [RFC2026] Bradner, S., "The Internet 829 Standards Process -- Revision 3", 830 BCP 9, RFC 2026, October 1996. 832 [RFC2119] Bradner, S., "Key words for use in 833 RFCs to Indicate Requirement 834 Levels", BCP 14, RFC 2119, March 835 1997. 837 [RFC2131] Droms, R., "Dynamic Host 838 Configuration Protocol", RFC 2131, 839 March 1997. 841 [RFC2246] Dierks, T., Allen, C., Treese, W., 842 Karlton, P., Freier, A. and P. 843 Kocher, "The TLS Protocol Version 844 1.0", RFC 2246, January 1999. 846 [RFC2251] Wahl, M., Howes, T. and S. Kille, 847 "Lightweight Directory Access 848 Protocol (v3)", RFC 2251, December 849 1997. 851 [RFC2365] Meyer, D., "Administratively 852 Scoped IP Multicast", BCP 23, RFC 853 2365, July 1998. 855 [RFC2401] Kent, S. and R. Atkinson, 856 "Security Architecture for the 857 Internet Protocol", RFC 2401, 858 November 1998. 860 [RFC2402] Kent, S. and R. Atkinson, "IP 861 Authentication Header", RFC 2402, 862 November 1998. 864 [RFC2461] Narten, T., Nordmark, E. and W. 865 Simpson, "Neighbor Discovery for 866 IP Version 6 (IPv6)", RFC 2461, 867 December 1998. 869 [RFC2462] Thomson, S. and T. Narten, "IPv6 870 Stateless Address 871 Autoconfiguration", RFC 2462, 872 December 1998. 874 [RFC2535] Eastlake, D., "Domain Name System 875 Security Extensions", RFC 2535, 876 March 1999. 878 [RFC2541] Eastlake, D., "DNS Security 879 Operational Considerations", RFC 880 2541, March 1999. 882 [RFC2608] Guttman, E., Perkins, C., 883 Veizades, J. and M. Day, "Service 884 Location Protocol, Version 2", RFC 885 2608, June 1999. 887 [RFC2730] Hanna, S., Patel, B. and M. Shah, 888 "Multicast Address Dynamic Client 889 Allocation Protocol (MADCAP)", RFC 890 2730, December 1999. 892 [RFC2931] Eastlake, D., "DNS Request and 893 Transaction Signatures ( 894 SIG(0)s)", RFC 2931, September 895 2000. 897 Author's Address 899 Aidan Williams 900 Motorola Australian Research Centre 901 Locked Bag 5028 902 Botany, NSW 1455 903 Australia 905 Phone: +61 2 9666 0500 906 EMail: Aidan.Williams@motorola.com 907 URI: http://www.motorola.com.au/marc/ 909 Full Copyright Statement 911 Copyright (C) The Internet Society (2002). All Rights Reserved. 913 This document and translations of it may be copied and furnished to 914 others, and derivative works that comment on or otherwise explain it 915 or assist in its implementation may be prepared, copied, published 916 and distributed, in whole or in part, without restriction of any 917 kind, provided that the above copyright notice and this paragraph are 918 included on all such copies and derivative works. However, this 919 document itself may not be modified in any way, such as by removing 920 the copyright notice or references to the Internet Society or other 921 Internet organizations, except as needed for the purpose of 922 developing Internet standards in which case the procedures for 923 copyrights defined in the Internet Standards process must be 924 followed, or as required to translate it into languages other than 925 English. 927 The limited permissions granted above are perpetual and will not be 928 revoked by the Internet Society or its successors or assigns. 930 This document and the information contained herein is provided on an 931 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 932 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 933 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 934 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 935 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 937 Acknowledgement 939 Funding for the RFC Editor function is currently provided by the 940 Internet Society.