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