idnits 2.17.1 draft-ietf-zeroconf-reqts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 135 has weird spacing: '...in this docum...' == Line 1124 has weird spacing: '...Network draft...' == Line 1128 has weird spacing: '...Clients draft...' -- 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 (October 21, 1999) is 8947 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: 'STD3' is mentioned on line 188, but not defined == Missing Reference: 'STD4' is mentioned on line 189, but not defined == Missing Reference: 'RFC 1812' is mentioned on line 295, but not defined == Missing Reference: 'Mcast DNS' is mentioned on line 203, but not defined == Unused Reference: 'STD 3' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: 'STD 4' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: 'DisAuto' is defined on line 1127, but no explicit reference was found in the text == Unused Reference: 'MCAST DNS' is defined on line 1132, but no explicit reference was found in the text == Unused Reference: 'NAT WG' is defined on line 1151, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1458 ** Downref: Normative reference to an Informational RFC: RFC 2316 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2411 (Obsoleted by RFC 6071) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Downref: Normative reference to an Informational RFC: RFC 2504 == Outdated reference: A later version (-05) exists of draft-ietf-dhc-ipv4-autoconfig-04 -- Possible downref: Normative reference to a draft: ref. 'IPv4Auto' -- No information found for draft-ietf-autoconfig - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DisAuto' == Outdated reference: A later version (-02) exists of draft-manning-multicast-dns-01 -- Possible downref: Normative reference to a draft: ref. 'MCAST DNS' == Outdated reference: A later version (-07) exists of draft-ietf-malloc-madcap-05 == Outdated reference: A later version (-03) exists of draft-cai-ssdp-v1-02 -- Possible downref: Normative reference to a draft: ref. 'SSDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6 WG' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHC WG' -- Possible downref: Non-RFC (?) normative reference: ref. 'NAT WG' -- Possible downref: Non-RFC (?) normative reference: ref. 'DNS WG' -- Possible downref: Non-RFC (?) normative reference: ref. 'MALLOC WG' Summary: 10 errors (**), 0 flaws (~~), 18 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ZeroConf WG M. Hattig 2 Internet Engineering Task Force Editor 3 INTERNET DRAFT Intel Corp. 4 Expires April 2000 October 21, 1999 6 ZeroConf Requirements 7 draft-ietf-zeroconf-reqts-00.txt 9 Status of This Memo 11 This document is a submission by the ZeroConf Working Group of 12 the Internet Engineering Task Force (IETF). Comments should be 13 submitted to the zeroconf@merit.edu mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance 18 with all provisions of Section 10 of [RFC 2026]. Internet-Drafts 19 are working documents of the Internet Engineering Task Force 20 (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as "work 27 in progress." 29 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Zero Configuration (ZeroConf) Networks are a particular class of 38 TCP/IP networks that may be established in the home, in small 39 offices or even on an impromptu basis. ZeroConf Networks do not 40 have and should not be expected to have user configurable network 41 infrastructure such as DHCP servers, DNS and other administered 42 services. This is because typical ZeroConf network users neither 43 have the skill nor desire to configure, administer, or manage a 44 network. 46 This document presents ZeroConf protocol requirements for four 47 areas: IP host configuration, domain name to IP address 48 resolution, IP multicast address allocation, and service 49 discovery. Security issues overlay each area. ZeroConf protocols 50 in each these areas must transition easily to and from 51 administered protocols. 53 Table of Contents 55 1 Overview....................................................2 56 2 Introduction................................................3 57 2.1 Areas of work.............................................3 58 2.2 Reading This Document.....................................4 59 2.3 General Considerations....................................5 60 3 ZeroConf Network Architecture...............................6 61 3.1 Topologies................................................6 62 3.2 ZeroConf and non-ZeroConf Protocols......................12 63 3.3 Assumptions and Restrictions.............................13 64 4 Scenarios..................................................14 65 4.1 Single IP Network Host Configuration.....................14 66 4.2 Multiple IP Network Host Configuration...................15 67 4.3 Bridge Install between already operational IP Hosts......16 68 4.4 Router Install between already operational IP Hosts......16 69 4.5 IP Host Configuration with DHCP server...................17 70 4.6 Domain Name Resolution within an IP network..............18 71 4.7 IP Multicast Address Allocation..........................18 72 4.8 Service Discovery........................................19 73 4.9 Additional Potential Scenarios...........................20 74 5 Security Requirements......................................21 75 5.1 IP Host Configuration....................................21 76 5.2 Domain name to IP address resolution.....................21 77 5.3 Multicast Address allocation.............................21 78 5.4 Service Discovery........................................22 79 6 Additional Considerations..................................22 80 6.1 IANA Considerations......................................22 81 6.2 Internationalization Considerations......................22 82 6.3 Is service discovery conclusive?.........................22 83 6.4 Security Considerations..................................22 84 7 Full Copyright Statement...................................22 85 8 Editor.....................................................23 86 9 References.................................................23 88 1 Overview 90 Zero Configuration (ZeroConf) Networks are a particular class of 91 TCP/IP networks. These networks may be established in a home, in 92 a small office or even on an impromptu basis. ZeroConf networks 93 typically do not have and should not be expected to have user 94 configurable network infrastructure such as DHCP servers, DNS and 95 other administered services. This is because typical ZeroConf 96 network users neither have the skill nor desire to configure, 97 administer, or manage a network. 99 This document presents ZeroConf protocol requirements for four 100 areas: IP host configuration, domain name to IP address 101 resolution, IP multicast address allocation, and service 102 discovery. Security issues overlay each area. ZeroConf protocols 103 in each these areas must transition easily to and from 104 administered protocols. 106 This ZeroConf requirements document is a companion to a ZeroConf 107 profile document. This requirements document lists requirements 108 for protocols. The profile document relates the protocol 109 requirements to actual protocols. In some cases, a protocol may 110 meet all requirements to become the required protocol for 111 ZeroConf networks. When protocols are insufficient or multiple 112 protocols are competing, the profile document states the 113 requirements of the protocol and the relationship of the 114 requirements to the existing protocols. 116 In addition, the profile document shows how ZeroConf protocols 117 transition between operating in a ZeroConf network and operating 118 in a Non-ZeroConf network. Such transitions may be heavily 119 influenced by connectivity of the ZeroConf network to a non- 120 ZeroConf network such as the global Internet. 122 The major sections to this requirements document are the 123 Introduction, ZeroConf Network Architecture, Scenarios, and 124 Security sections. Since this document deals with so many aspects 125 of TCP/IP networking (i.e. service discovery to IP host 126 configuration), the introduction lists the necessary background 127 information and provides ideas for readers who wish to focus on 128 specific topics. The ZeroConf Network Architecture defines the 129 network assumed throughout this document. The scenarios clarify 130 the scope covered by the document and motivate particular 131 requirements of ZeroConf protocols. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 134 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described 136 in [RFC 2119]. 138 2 Introduction 140 This introduction specifically defines the term "Area", presents 141 how to best read this document (including references), and 142 presents general considerations for implementers of ZeroConf 143 protocols. 145 2.1 Areas of work 147 Throughout this document, when the word Area is capitalized, the 148 word is referring the four Areas of protocol work in which this 149 document focuses. These protocol Areas are: 150 - IP host configuration 151 - Domain name to IP address resolution 152 - IP multicast address 153 - Service discovery 155 2.2 Reading This Document 157 This document deals with a wide range of networking topics. All 158 readers may not be interested in all Areas. To help the reader 159 focus on particular interests, this section describes the 160 organization of the document, the background information for each 161 Area, and explains different types of requirements. 163 2.2.1 Organization 165 The first major section of this document defines the ZeroConf 166 Network Architecture assumed throughout this document and assumed 167 throughout the profile document. 169 The Scenarios Section scopes the overall ZeroConf problem space 170 to provide the framework for requirements of protocols. This 171 section identifies some but not all requirements of protocols. 172 This section mentions very little about specific protocols. There 173 is a common outline for each scenario. 175 The Security section lists security issues and requirements to 176 prevent security problems. 178 2.2.2 Background information 180 This section lists the background reference information for 181 general knowledge, IP host configuration, domain name to IP 182 address resolution, IP multicast address allocation, service 183 discovery, and security. All readers should be familiar with at 184 least the general knowledge references before reading this 185 document. 187 All readers should be familiar with the following documents: 188 - [STD3] RFC 1122 Requirements for Internet Hosts - Comm Layers 189 - [STD4] RFC 1123 Requirements for Internet Hosts - App Layers 190 - [RFC 1458] RFC 1458 Requirements for Multicast Protocols 191 - [RFC 1812] RFC 1812 Requirements for Internet Gateways 193 IP host configuration: 194 - [IPv4Auto] Ipv4 Auto-Configuration ID 195 - [RFC 1918] RFC 1918 Private Addresses 196 - [RFC 2131] RFC 2131 DHCP 197 - [RFC 2132] RFC 2132 DHCP Options 198 - [RFC 2462] IPv6 Auto-Configuration 199 - [RFC 2461] IPv6 Neighbor Discovery 200 - [IPv6 WG] Next Generation (Ipv6) WG 201 - [DHC WG] Dynamic Host Configuration WG 202 Domain name to IP address resolution: 203 - [Mcast DNS] Multicast DNS 204 - [RFC 1034] RFC 1034 DNS 205 - [DNS WG] DNS Update WG 207 Multicast address allocation: 208 - [MADCAP] Multicast Address Dynamic Client Alloc Protocol ID 209 - [RFC 2365] RFC 2365, Administratively Scoped Multicast Address 210 - [MALLOC WG] Multicast Address Allocation WG 212 Service discovery: 213 - [SSDP] Simple Service Discovery Protocol ID 214 - [RFC 2608] RFC 2608 Service Location Protcol v2 215 - [RFC 2609] RFC 2609 SLP Schemes 217 Security background information is: 218 - [RFC 2316] RFC 2316, IAB Security Architecture Workshop 219 - [RFC 2401] RFC 2401, Security Architecture for IP 220 - [RFC 2411] RFC 2411, IP Security Document Roadmap 221 - [RFC 2504] RFC 2504, User's Security Handbook 223 2.2.3 Requirements 225 This document identifies scenarios that drive the requirements 226 for protocols. The requirements for protocols then help identify 227 specific protocols. The ZeroConf profile document discusses 228 specific protocols; this ZeroConf requirements document only 229 discusses the requirements for those specific protocols. 231 Requirements for protocols may have device specific aspects. For 232 example, a router may automatically forward IP packets with a 233 particular UDP port number between IP networks to make sure 234 client requests reach a server on another IP network. To provide 235 the proper device context, device descriptions are given along 236 with particular device requirements when appropriate. 238 2.3 General Considerations 240 These considerations are for vendors of ZeroConf networking 241 software. 243 2.3.1 Continuing ZeroConfig Network Evolution 245 ZeroConf networks are in their infancy. Many people speculate 246 about which link layer technologies will be the most important, 247 which devices will be most widely deployed, which applications 248 will be the "killer", etc. etc. Because of this broad speculation 249 and unpredictability the ZeroConf WG has limited the complexity 250 of the networks it will consider. For example, at most a single 251 router is considered in a ZeroConf network. 253 These limitations are a practical matter to allow the WG to make 254 progress. Without such limitations, the load of speculation would 255 prevent the working group from addressing even simple matters. 257 Vendors should be aware of these limitations and implement in a 258 flexible way to allow their implementations to someday go beyond 259 the restrictions imposed by the ZeroConf WG. 261 2.3.2 Configuration, Administration, and Management 263 Ideally, user configuration, administration, and management do 264 not occur in a ZeroConf network; this is the primary goal of the 265 ZeroConf WG. In other words, ZeroConf networks should be self- 266 healing and self-correcting. Despite this, there may be cases 267 where minimal user intervention is necessary; the key word in 268 this sentence is "minimal". 270 2.3.3 Error Log Messages 272 A goal of the ZeroConf requirements is to automate basic 273 functions to the extent that they will be transparent to the 274 user. This will minimize the requirement for the user to either 275 enter information or be presented with and interpret error 276 conditions. It is quite likely, however, that error logging, and 277 network management may be implemented on hosts supporting 278 ZeroConf protocols. Further discussion of network management and 279 operational issues is beyond the scope of this requirements 280 document. 282 3 ZeroConf Network Architecture 284 This section describes network topologies considered by this 285 document and states assumptions about the operation of protocols 286 in the ZeroConf Network. 288 3.1 Topologies 290 ZeroConf networks follow the Internet Model as described in STD4. 291 Specifically, ZeroConf networks consist of bridges, routers 292 (gateways), hosts, link layer networks, and IP networks to form 293 internets. 295 Here is a summary of the terms in [RFC 1812] that apply to the 296 ZeroConf Network Architecture: 297 - Bridges route link layer packets (e.g. Ethernet packets) 298 between link layer networks (e.g. Ethernet) based on the 299 destination link layer addresses (e.g. 48-bit Ethernet address) 300 of a packet. 301 - Routers (a.k.a. gateways) route IP packets between IP networks 302 based on the destination IP address of a packet. 303 - An IP network consists of hosts with interfaces that share the 304 same network portion of the IP address. A single IP network may 305 physically consist of several link layer networks connected by 306 a bridge, but it is one logical IP network; the hosts remain 307 unaware of the bridge or multiple link layer networks. 308 - An internet consists of multiple IP networks connected by 309 routers. 310 - Autonomous Systems (AS) are internets with a single operational 311 and management organization (a.k.a. administrator), and a 312 common set of routing protocols among the routers. 314 A ZeroConf network is a single Autonomous System (AS). This 315 simple statement implies many things. For example, service 316 discovery queries, IP multicast packets, and other IP packets 317 must stay within a single autonomous system. Also, such packets 318 must not enter autonomous system; this avoids security problems. 319 For the rest of this document, the term ZeroConf Network equates 320 to a network within a single autonomous system and all that that 321 implies. 323 RFC 1812 defines different types of routers (e.g. transparent, 324 embedded). The ZeroConf Network Architecture has two different 325 types of routers. Both types of routers pass packets between IP 326 networks based on destination IP address (as one would expect). 328 The primary difference is that one of these routers resides at 329 the border between the ZeroConf and the Non-ZeroConf network; 330 thus this router must impose the restrictions necessary for the 331 ZeroConf network to remain a single autonomous system. This 332 router is called a "gateway" throughout the rest of this 333 document. 335 The second type of router routes between IP networks within the 336 ZeroConf Network. Thus, this router has no responsibilities 337 related to restricting the communication between ZeroConf and 338 Non-ZeroConf Networks. This device is simply called a "router" 339 throughout the rest of this document. 341 The ZeroConf Network Architecture is limited to at most one 342 router and/or at most one gateway. Zero routers and/or zero 343 gateways are also part of the ZeroConf Network Architecture. 345 Figures 1 and 2 show the simplest of ZeroConf networks considered 346 by this document. Enabling these types of simple TCP/IP networks 347 is among the primary motivations for this document. 349 ***************************************************** 350 * ZeroConf Network * 351 * * 352 * -------crossover-cable-------- * 353 * | | * 354 * | | * 355 * +------+ +------+ * 356 * | Host | | Host | * 357 * +------+ +------+ * 358 * * 359 ***************************************************** 361 Figure 1. Two hosts connected with a crossover cable. 363 This ZeroConf network has two hosts connected through a crossover 364 cable. A crossover cable between two hosts is the most common 365 impromptu ZeroConf network. 367 ***************************************************** 368 * ZeroConf Network * 369 * * 370 * -------[ HUB ]------- * 371 * | | | * 372 * | | | * 373 * +------+ +------+ +------+ * 374 * | Host | | Host | | Host | * 375 * +------+ +------+ +------+ * 376 * * 377 ***************************************************** 379 Figure 2. Three hosts connected with a network with hub 381 This ZeroConf network has a small number of hosts connected 382 through a hub. A hub between hosts is the most common fixed- 383 location ZeroConf network. This is the canonical ZeroConf 384 network. 386 Figure 3, Figure 4, and Figure 5 are examples of ZeroConf 387 Networks that highlight the difference between a router and a 388 gateway. Figure 5 is an example of a network not considered by 389 this document. All these figures include connectivity to non- 390 ZeroConf Network. Examples of a non-ZeroConf network are the 391 global Internet and a corporate LAN. 393 *************************** 394 * * 395 * Non-ZeroConf Network * 396 * * 397 *************************** 398 | 399 | 400 | 401 +----------------+ 402 **********************| Gateway |************************* 403 * ZeroConf Network +----------------+ * 404 * | * 405 * | * 406 * | +--------+ * 407 * --------------------------------| Bridge |--------------- * 408 * | | | +--------+ | | * 409 * | | | | | * 410 * | | | | | * 411 * +------+ +------+ +------+ +------+ +------+ * 412 * | Host | | Host | | Host | | Host | | Host | * 413 * +------+ +------+ +------+ +------+ +------+ * 414 * * 415 ***************************************************************** 417 Figure 3. Single Gateway and Single IP Network. 419 Figure 3 shows a single gateway and single IP network in the 420 ZeroConf Network. The gateway routes packets between the ZeroConf 421 Network and the Non-ZeroConf Network. The single IP network 422 consists of multiple link layer networks connected by a bridge. 424 *************************** 425 * * 426 * Non-ZeroConf Network * 427 * * 428 *************************** 429 | 430 | 431 | 432 +----------------+ 433 **********************| Gateway/Bridge |************************* 434 * ZeroConf Network +----------------+ * 435 * | | * 436 * | | * 437 * +--------+ | | * 438 * -----------| Router |---| |-------------------- * 439 * | | +--------+ | | | * 440 * | | | | | * 441 * | | | | | * 442 * +------+ +------+ +------+ +------+ +------+ * 443 * | Host | | Host | | Host | | Host | | Host | * 444 * +------+ +------+ +------+ +------+ +------+ * 445 * * 446 ***************************************************************** 448 Figure 4. Single Gateway, Single Router, and Two IP Networks. 450 Figure 4 shows a ZeroConf Network with a single gateway, a single 451 router, and two IP networks. The gateway/bridge device is a 452 gateway and a bridge. The bridge portion routes layer 2 packets 453 between the two link layer networks attached to the gateway 454 (within the ZeroConf network); these two link layers represent a 455 single IP network. The router routes IP packets between the two 456 IP networks within the ZeroConf Network. 458 *************************** 459 * * 460 * Non-ZeroConf Network * 461 * * 462 *************************** 463 | 464 | 465 | 466 +----------------+ 467 **********************| Gateway/Router |************************* 468 * ZeroConf Network +----------------+ * 469 * | | | * 470 * | | | * 471 * | | | * 472 * ------------------| | |---------------------- * 473 * | | | | | * 474 * | | | | | * 475 * | | | | | * 476 * +------+ +------+ +------+ +------+ +------+ * 477 * | Host | | Host | | Host | | Host | | Host | * 478 * +------+ +------+ +------+ +------+ +------+ * 479 * * 480 ***************************************************************** 482 Figure 5. Single Gateway, Single Router, and Three IP Networks. 484 Figure 5 shows a ZeroConf Network with a single gateway, a single 485 router, and three IP networks. The gateway/router device is a 486 gateway and a router. The router portion routes IP packets 487 between the three IP networks within the ZeroConf Network. The 488 gateway portion routes IP packets between the ZeroConf Network 489 and the non-ZeroConf Network. In ZeroConf Networks, routers route 490 within the ZeroConf; gateways route between a ZeroConf and a non- 491 ZeroConf (which are different autonomous systems); this is the 492 distinction between a router and a gateway. 494 *************************** 495 * * 496 * Non-ZeroConf Network * 497 * * 498 *************************** 499 | 500 | 501 | 502 +----------------+ 503 **********************| Gateway/Router |************************* 504 * ZeroConf Network +----------------+ * 505 * | | * 506 * | | * 507 * +---------+ | | * 508 * -----------| Router |---| |------------------- * 509 * | | +---------+ | | | * 510 * | | | | | * 511 * | | | | | * 512 * +------+ +------+ +------+ ------+ +------+ * 513 * | Host | | Host | | Host | | Host | | Host | * 514 * +------+ +------+ +------+ +------+ +------+ * 515 * * 516 ***************************************************************** 517 Figure 6. Single Gateway, Two Routers, and Three IP Networks. 519 Figure 6. shows a network that is NOT considered by this document 520 because two routers are present. The gateway/router device 521 includes a gateway and a router as in Figure 5. In addition, 522 there is a second router in the network. Multiple routers within 523 a single autonomous system create requirements beyond the scope 524 of the document. Such requirements are coordination between 525 routers and auto-configuration of routers. 527 There are no additional topological restrictions on the ZeroConf 528 Network Architecture. That is, there are no restrictions on the 529 number of hosts, number of host names, or the number of services. 531 3.2 ZeroConf and non-ZeroConf Protocols 533 In this document the term ZeroConf is overloaded. In addition to 534 ZeroConf (and non-ZeroConf) Networks, this document uses the 535 terms ZeroConf protocols and non-ZeroConf protocols. ZeroConf 536 Network is a concept, not really a physical entity. The concept 537 is that at some point in time one or more protocols within a 538 network are ZeroConf protocols. In addition, non-ZeroConf 539 protocols may coexist in this network with ZeroConf protocols. 540 That is, not ALL protocols in a ZeroConf Network are ZeroConf 541 protocols. 543 To illustrate this point, suppose there are standard protocols to 544 support ZeroConf requirements for IP host configuration and 545 domain name to IP address resolution. 547 For IP host configuration, the ZeroConf protocol is 548 'protocol-h.' The non-ZeroConf protocol is DHCP, supported by a 549 fully conformant DHCP server. 551 For domain name to IP address resolution, the protocol is 552 'protocol-d.' The non-Zeroconf protocol is DNS supported by a 553 fully conformant DNS server. 555 In a ZeroConf Network, both ZeroConf and non-ZeroConf protocols 556 may exist in separate Areas. For example, protocol-h may exist 557 with DNS (and a DNS server). 559 However, within a single Area only a ZeroConf or non-ZeroConf 560 protocol is used at a given point in time. Preference is always 561 given to the non-ZeroConf protocol if it is present. For example, 562 a DNS server implemented on a PC in the den is only available 563 when the PC is powered-up; hosts must detect when the DNS server 564 is present then use it; otherwise, they must use protocol-d. 566 The strict definition of a ZeroConf Network is a network that at 567 some point in time has one or more ZeroConf protocols. 569 3.3 Assumptions and Restrictions 571 The architectural assumptions and restrictions for the ZeroConf 572 Network Architecture are bounded by ZeroConf topologies and by 573 the protocols (ZeroConf and non-ZeroConf) that operate within the 574 ZeroConf Network. 576 Topological assumptions and restrictions are: 577 - No more than a single router exists in the ZeroConf network; 578 zero routers are acceptable but two routers are not. 579 - No more than a single gateway exists in the ZeroConf network; 580 zero gateways are acceptable but two gateways are not. 581 - No restrictions on the number of hosts or the number services 582 exist. 583 - A gateway prevents ZeroConf protocols from leaving the ZeroConf 584 network. 585 - A gateway prevents ZeroConf protocols from entering the 586 ZeroConf Network from a non-ZeroConf Network. 587 - A router must route ZeroConf protocols if the protocol is 588 required to span the entire ZeroConf network. 589 - A bridge connects similar link layer networks (e.g. HomePNA, 590 IEEE 802.11, HomeRF are similar because they are Ethernet-like) 591 - A router connects dissimilar link layer networks. (e.g. IEEE 592 1394-1995 is dissimilar from Ethernet) 593 - A gateway device includes a router or a bridge when necessary 594 and feasible. However, this may not be feasible for some 595 networking link layers that cannot span the entire distance 596 between the gateway and link layer specific hosts (e.g. ADSL 597 gateway in a den and IEEE 1394-1995 MP3 Player in a family 598 room). 600 Protocol assumptions within each Area of work are: 601 - A ZeroConf protocol exists. 602 - A non-ZeroConf protocol exists. 603 - A ZeroConf protocol transitions to non-ZeroConf protocol on a 604 well-defined trigger. 605 - A Non-ZeroConf protocol transitions to ZeroConf protocol on a 606 well-defined trigger. 607 - ZeroConf protocols re-initialize themselves on a well-defined 608 trigger. 610 4 Scenarios 612 This section lists ZeroConf scenarios. This section does not 613 discuss specific protocols. Instead this section lists scenarios 614 that provide a framework to produce requirements for protocols. 616 Each scenario begins with an explanation or overview of the 617 scenario. Then, the key points of the scenario are identified. 618 These key points help identify the most likely Area of work 619 related to the scenario. To consistently provide this 620 information, each scenario has the following outline: 621 - Overview 622 - Key Points 623 - Protocol Requirements 625 Temporary Note: These scenarios have not been agreed upon by the 626 ZeroConf WG, thus they will likely change. For this reason, only 627 the limited information is provided for each scenario in the 628 current draft. 630 4.1 Single IP Network Host Configuration 632 4.1.1 Overview 634 Hosts on a single IP network within the ZeroConf network 635 communicate to each other. To do this, hosts must configure their 636 IP address and net mask. This scenario is of utmost importance. 638 This scenario is most applicable to networks shown in Figures 1 639 and 2. 641 4.1.2 Key Points 642 This scenario deals with the Area of IP host configuration. 644 This scenario requires a unique host portion of the IP address 645 for each host. The network portion of the IP address must be the 646 same for each host. 648 4.1.3 Protocol Requirements 650 - Host numbers of IP addresses MUST be unique within a single IP 651 network. 652 - Network numbers of IP addresses MUST be equal within a single 653 IP network. 654 - IP addresses MUST be private and not globally routable such as 655 those listed in RFC 1918. 656 - IP address MAY be routable within the ZeroConf network, but 657 this is not required. 659 4.2 Multiple IP Network Host Configuration 661 4.2.1 Overview 663 This scenario does not include a DHCP server. Hosts on multiple 664 IP networks within a ZeroConf network communicate to each other. 665 To do this, hosts must configure their IP address, net mask, and 666 default route. 668 4.2.2 Key Points 670 This scenario deals with the Area of IP host configuration. 672 This scenario requires a unique host portion of the IP address 673 for each host on an IP network. The network number portion of an 674 IP address must be the same for each host on a single IP network. 675 The network number portion of the IP address must be the unique 676 within the ZeroConf network for each IP network. Each host must 677 be configured with a default route. 679 4.2.3 Protocol Requirements 681 - Host numbers of IP addresses MUST be unique within a single IP 682 network. 683 - Network numbers of IP addresses MUST be equal within a single 684 IP network. 685 - IP addresses MUST be private and not globally routable such as 686 those listed in RFC 1918. 687 - IP address MUST be routable within the ZeroConf network. 688 - IP network numbers MUST be unique within the entire ZeroConf 689 network. 690 - The host MUST configure a default route. 692 4.3 Bridge Install between already operational IP Hosts 694 4.3.1 Overview 696 This scenario does not include a DHCP server. Within a single IP 697 network, a bridge (or hub) is installed after IP hosts have been 698 configured to communicate on a single IP network. Two hosts on a 699 single IP network may now share the same IP address. In addition, 700 hosts on different link layer networks may not have been using 701 the same network number and now they must share the same network 702 number. 704 4.3.2 Key Points 706 This scenario deals with the Area of IP host configuration. 708 This is a special case of a previous scenario when IP hosts first 709 communicate on the same IP network. All the key points and 710 requirements to the previous scenario apply. In addition, host 711 must have the ability to re-configure their IP address and net 712 mask. 714 4.3.3 Protocol Requirements 716 - Hosts MUST re-configure IP address and net mask at various 717 times after initial configuration. 718 - All requirements in section 4.1.3. 720 4.4 Router Install between already operational IP Hosts 722 4.4.1 Overview 724 This scenario does not include a DHCP server. Within a ZeroConf 725 network, a router is installed after IP hosts have been 726 configured to communicate throughout the ZeroConf network. 727 Multiple IP networks within the ZeroConf network may now share 728 the same IP network number. 730 4.4.2 Key Points 732 This scenario deals with the Area of IP host configuration. 734 This is a special case of a previous scenario when hosts on a 735 multiple IP networks within a ZeroConf network communicate. All 736 the key points and requirements to the previous scenario apply. 737 In addition, host must have the ability to re-configure their IP 738 address, net mask, and default route. 740 4.4.3 Protocol Requirements 741 - Hosts MUST re-configure IP address, net mask, and default route 742 at various times after the initial configuration. 743 - All requirements in section 4.2.3. 745 4.5 IP Host Configuration with DHCP server 747 4.5.1 Overview 749 This scenario is for single IP network or multiple IP network 750 ZeroConf networks. Hosts communicate to each other. To do this, 751 hosts must get their IP address, net mask, and default route from 752 a DHCP server. There is only one DHCP server. 754 4.5.2 Key Points 756 This scenario deals with the Area of IP host configuration. 758 DHCP servers in ZeroConf networks do not require user 759 configuration. Servers allocate private addresses that are not 760 globally routable. However, the addresses must be routable 761 within the ZeroConf network. DHCP servers ensure a unique host 762 portion of the IP address for each host on an IP network. The 763 DHCP server ensures the network number portion of an IP address 764 is the same for each host on a single IP network. The DHCP 765 server must provide a default route to each host. All hosts must 766 implement a DHCP client. This places unique requirements on DHCP 767 servers as well as hosts. 769 If previously operation hosts achieve connectivity to the DHCP 770 server through the installation of a bridge or router, hosts must 771 somehow determine or learn about the presents of the DHCP server 772 and request the appropriate information from the DHCP server. 774 4.5.3 Protocol Requirements 776 - A DHCP server MUST be accessible by all hosts on the network. 777 - The DHCP server MUST require zero-configuration by a user. 778 - The DHCP server MUST only allocate private addresses that are 779 not globally routable such as those listed in RFC 1918. 780 - The DHCP server MUST ensure host numbers of IP addresses are 781 unique within a single IP network. 782 - The DHCP server MUST ensure network numbers of IP addresses are 783 equal within a single IP network. 784 - The DHCP server MAY ensure IP addresses are routable within the 785 ZeroConf network, but this is not required. 786 - All hosts MUST implement a DHCP client to retrieve their IP 787 address, net mask, and default route. 788 - Routers MUST implement DHCP rely agents. 790 4.6 Domain Name Resolution within an IP network 792 4.6.1 Overview 794 Domain names within the ZeroConf network must be resolved to IP 795 addresses. This enables one of the most basic of TCP/IP 796 networking paradigms of applications only being aware of host 797 names and not IP addresses. 799 4.6.2 Key Points 801 This scenario deals with the Area of domain name to IP address 802 resolution. 804 Name resolution must span the entire ZeroConf network, but be 805 limited by the gateway from leaving or entering the ZeroConf 806 network. This protocol should include the ability for a host to 807 choose a name, determine if the name is in use, and then choose a 808 different name if it is re-used. 810 The name resolution protocol must become active at various times 811 such as when previously disconnected yet operational networks now 812 become connected by the installation of a router or a bridge. 814 4.6.3 Protocol Requirements 816 - A host that wishes to be addressable by DNS name MUST select a 817 domain name. 818 - A host MUST determine if the domain name is in use by another 819 host. 820 - A host MUST participate to defend a name it uses. 821 - A host MUST be able to reconfigure its name in the case it was 822 unable to successfully defend the name it previously used. 823 - At various times a host MUST actively determine if another host 824 is using its name. 825 - Gateways MUST restrict this protocol from leaving or entering 826 the ZeroConf network. 827 - Routers MUST route this protocol to ensure it spans the entire 828 ZeroConf network. 830 4.7 IP Multicast Address Allocation 832 4.7.1 Overview 834 Numerous protocols have a need for dynamically allocated IP 835 multicast addresses. Traditionally these have been audio or video 836 streaming protocols; however, of late, data applications such as 837 stock quotes or hourly news are increasing sent encapsulated in 838 packets destined to IP multicast addresses. 840 4.7.2 Key Points 842 This scenario deals with the Area of domain name to IP address 843 resolution. 845 IP multicast address allocation protocol must be routed through 846 the entire ZeroConf network; however, the gateway limits this 847 protocol from leaving or entering the ZeroConf network. In 848 addition to limiting the multicast allocation protocol, the 849 gateway limits the packets that utilize the allocated IP 850 multicast addresses. 852 4.7.3 Protocol Requirements 854 - All hosts MUST allocate IP multicast address from the same 855 pool. 856 - The pool of IP multicast addresses MUST NOT be globally 857 accessible (e.g. Administratively scoped IP multicast addresses 858 in [RFC 2365]) 859 - Routers MUST route packets destined to this pool of IP 860 multicast addresses. 861 - Gateways MUST limit packets destined to this pool of IP 862 multicast addresses from leaving or entering the ZeroConf 863 network. 864 - One and only one host MUST be identified as the owner of each 865 allocated IP multicast address. 866 - The owner MUST deallocate the IP multicast address whenever 867 possible. 868 - Allocated IP multicast addresses MUST automatically become 869 deallocated if owner stops operating. 870 - Ownership MUST be able to pass from one host to another, in the 871 case the original owner wishes to stop participation in the use 872 of the IP multicast address and another host wishes to continue 873 participation in the use of the IP multicast address. 875 4.8 Service Discovery 877 4.8.1 Overview 879 A key component to the ZeroConf network is service discovery 880 without user-configured servers. This requires a common 881 definition a service and common methods for clients (hosts 882 wanting a service) to find service-specific servers (hosts 883 providing a service). When multiple servers provide the same 884 service, hosts and/or people must be able to pick a preferred 885 server based on service specific attributes, connectivity, 886 physical location of the server, or other metrics. 888 For example, a small business may have a high quality color 889 printer, a printer that prints a high number of pages per second, 890 or a printer in a particular office. A person may want to print 891 to the color printer, print to the fast printer, or the closest 892 printer. Of course, many other metrics may exist. 894 4.8.2 Key Points 896 This scenario deals with the Area of service discovery. 898 A service must be identifiable and instrumentable. 899 Instrumentation allows attributes to be identified and utilized 900 by people or programs. Clients should be able to discover 901 services through passive advertisements by the servers and 902 through active queries by the client. 904 4.8.3 Protocol Requirements 906 - A service MUST be identifiable. 907 - A service MAY be instrumentable. 908 - Servers MAY have the ability to advertise service. 909 - Servers MAY have the ability to respond to client queries. 910 - Clients MAY have the ability to use service advertisements. 911 - Clients MAY have the ability to query for services. 912 - Clients and servers MAY have the ability present the 913 instrumentation of a service to people. 914 - Clients and servers MAY have the ability to programmatically 915 use instrumentation of a service. 917 4.9 Additional Potential Scenarios 919 - A ZeroConf host accessing the global Internet through the 920 gateway. 921 - Multiple ZeroConf hosts simultaneously accessing the Internet 922 through the gateway. 923 - ZeroConf host accessing a corporate LAN through the gateway and 924 a corporate firewall. 925 - Allow access from the Internet to a ZeroConf server (e.g. 926 household WEB server). 927 - Allow access from the Internet to multiple ZeroConf servers 928 (e.g. family WEB server and individual family-member WEB 929 server). 930 - Host connecting to another ZeroConf network through a non- 931 ZeroConf network and a gateway at the border of each ZeroConf 932 network. 933 - Browsing and human friendly identifiers (service type name, 934 internationalization, attributes) 935 - Device Identification & Discovery 936 - ZeroConf host interoperates with Ad Hoc host via MANET. 937 - Behavior upon receiving router advertisements 938 5 Security Requirements 940 The principal goal of security requirements for ZeroConf 941 networking is to not make IP networking less secure than it is 942 without the use of ZeroConf protocols. This is challenging since 943 ZeroConf provides the ability for any host to obtain host 944 configuration, to discover and to use network resources. In the 945 case where ZeroConf access media is physically accessible (e.g. 946 wireless, powerline) or routed to additional network segments, 947 there is no longer any physical security. 949 The following sections are security considerations for the four 950 Areas which this document addresses. The threats fall into three 951 broad categories: 953 Hoarding: Hosts claim all available resources, whether they plan 954 to use them or not. This is a form of denial of service attack. 956 Masquerading: Hosts can respond to requests that they should not 957 so they can masquerade as another host. 959 Antagonistic Server: A server could offer support for a critical 960 service but intentionally misconfigure hosts on the network. 962 [TO DO: Add security requirements after potential threats have 963 been identified and selected as requiring attention by the 964 ZEROCONF Working Group.] 966 5.1 IP Host Configuration 968 Potential threats include: 969 - A host could hoard IP addresses, denying others access to the 970 network. 971 - A host could pose as an antagonistic DHCP server and 972 misconfigure other hosts on the network. 974 5.2 Domain name to IP address resolution 976 Potential threats include: 977 - A host could masquerade, responding to names requests 978 illigitimately. 979 - A host could hoard names, responding to all 'claim' requests. 980 - A host could pose as an antagonistic DNS server and fail to 981 resolve names correctly, or intentionally resolve them 982 incorrectly. 984 5.3 Multicast Address allocation 986 Potential threats include: 988 - A host could hoard multicast addresses, denying others the 989 ability to obtain them. 991 5.4 Service Discovery 993 Potential threats include: 994 - Servers could masquerade by responding to service discovery 995 requests which they shouldn't respond to. 996 - A host could pose as an antagonistic service discovery 997 'infrastructure element.' Some service discovery protocols 998 offer a 'registry', 'directory', 'proxy' or other 999 infrastructure element for scalability. 1001 6 Additional Considerations 1003 6.1 IANA Considerations 1005 There are no known IANA considerations arising from this 1006 document. 1008 6.2 Internationalization Considerations 1010 ZeroConf protocols may exchange human readable strings. Human 1011 readable strings may need to be internationalized. 1013 6.3 Is service discovery conclusive? 1015 When service discovery is successful, should the client be able 1016 to use the service, or do we assume that it may not be able to. 1017 In the former case service discovery finds only those services 1018 that match the client's capabilities and requirements. In the 1019 latter case the client may have to perform feature negotiation 1020 with the service - the result of which may be that the client is 1021 not able to use the service. 1023 6.4 Security Considerations 1025 ZeroConf security considerations are in Section 5 of this 1026 document. 1028 7 Full Copyright Statement 1030 Copyright (C) The Internet Society (1997). All Rights Reserved. 1032 This document and translations of it may be copied and furnished 1033 to others, and derivative works that comment on or otherwise 1034 explain it or assist in its implementation may be prepared, 1035 copied, published and distributed, in whole or in part, without 1036 restriction of any kind, provided that the above copyright notice 1037 and this paragraph are included on all such copies and derivative 1038 works. However, this document itself may not be modified in any 1039 way, such as by removing the copyright notice or references to 1040 the Internet Society or other Internet organizations, except as 1041 needed for the purpose of developing Internet standards in which 1042 case the procedures for copyrights defined in the Internet 1043 Standards process must be followed, or as required to translate 1044 it into languages other than English. 1046 The limited permissions granted above are perpetual and will not 1047 be revoked by the Internet Society or its successors or assigns. 1049 This document and the information contained herein is provided on 1050 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1051 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1052 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 1053 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 1054 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1055 PURPOSE." 1057 8 Editor 1059 Myron Hattig 1060 Intel Corporation 1061 2111 NE 25th Ave. 1062 Hillsboro, OR 97124 1063 myron.hattig@intel.com 1065 9 References 1067 [STD 3] R. Braden Requirements for Internet Hosts -- 1068 Communication Layers RFC 1122, STD 3, October 1989 1070 [STD 4] R. Braden, Requirements for Internet Hosts -- 1071 Application and Support RFC 1123, STD 4 October 1989 1073 [RFC 1034] P. Mockapetris, Domain Names - Concepts and 1074 Facilities, RFC 1034, November 1987 1076 [RFC 1458] R. Braudes, Requirements for Multicast Protocols, 1077 RFC 1458, May 1993 1079 [RFC 1918] D. Karrenberg, et al, Address Allocation for Private 1080 Internets, RFC 1918, Feb 1996 1082 [RFC 2026] S. Bradner, The Internet Standards Process -- 1083 Revision 3, RFC 2026 Oct 1996 1085 [RFC 2119] S. Bradner. Key words for use in RFCs to Indicate 1086 Requirement Levels. RFC 2119, March 1997. 1088 [RFC 2131] R. Droms. Dynamic Host Configuration Protocol. RFC 1089 2131, March 1997. 1091 [RFC 2132] S. Alexander, R. Droms DHCP Options and BOOTP 1092 Vendor Extension RFC 2132, March 1997. 1094 [RFC 2316] S. Bellovin, Report of the IAB Security Architecture 1095 Workshop, RFC 2316, April 1998 1097 [RFC 2365] D. Meyer Administratively Scoped Multicast Address 1098 RFC 2365,July 1998. 1100 [RFC 2401] S. Kent, Security Architecture for the Internet 1101 Protocol, RFC 2401, Nov 1998 1103 [RFC 2411] R. Thayer, IP Security Document Roadmap, RFC 2411, 1104 Nov 1998 1106 [RFC 2461] T. Narten, E. Nordmark, W. Simpson Neighbor 1107 Discovery for IP Version 6 (IPv6) RFC 2461, 1108 December 1998. 1110 [RFC 2462] S. Thomson, T. Narten IPv6 Address 1111 Autoconfiguration RFC 2462, December 1998. 1113 [RFC 2504] E. Guttman, Users' Security Handbook, RFC 2504, Feb. 1114 1999 1116 [RFC 2608] E. Guttman, C. Perkins, J. Veizades, and M. Day. 1117 Service Location Protocol version 2. RFC 2608, June 1118 1999. 1120 [RFC 2609] E. Guttman, C. Perkins, J. Kempf Service Templates 1121 and service: Schemes, RFC 2609, June 1999. 1123 [IPv4Auto] R. Troll Automatically Choosing an IP Address in an 1124 Ad-Hoc IPv4 Network draft-ietf-dhc-ipv4-autoconfig- 1125 04.txt April, 1999. A work in progress. 1127 [DisAuto] R. Troll, DHCP Option to Disable Stateless Auto- 1128 Configuration in IPv4 Clients draft-ietf- 1129 autoconfig-04.txt February, 1999. A work in 1130 progress. 1132 [MCAST DNS] B. Woodcock, B. Manning Multicast Discovery of DNS 1133 Services draft-manning-multicast-dns-01.txt 1134 December, 1998. A work in progress. 1136 [MADCAP] iS. Hanna, B. Patel, M. Shah Multicast Address 1137 Dynamic Client Allocation Protocol (MADCAP) draft- 1138 ietf-malloc-madcap-05.txt May 1999. A work in 1139 progress. 1141 [SSDP] Y. Goand et al, Simple Service Discovery Protocol, 1142 draft-cai-ssdp-v1-02.txt, June 1999, A work in 1143 progress. 1145 [IPv6 WG] IP Next Generation WG, 1146 www.ietf.org/html.charters/ipngwg-charter.html. 1148 [DHC WG] Dynamic Host Configuration WG, 1149 www.ietf.org/html.charters/dhc-charter.html. 1151 [NAT WG] Network Address Translation WG, 1152 www.ietf.org/html.charters/nat-charter.html. 1154 [DNS WG] DNS Update WG, www.ietf.org/html.charters/dnsind- 1155 charter.html 1157 [MALLOC WG] Multicast Allocation WG Charter, 1158 www.ietf.org/html.charters/malloc-charter.html.