idnits 2.17.1 draft-ietf-zeroconf-reqts-03.txt: -(735): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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. == There are 11 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages 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. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 106 has weird spacing: '...in this docum...' == Line 1221 has weird spacing: '...Network 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 (March 10, 2000) is 8812 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: 'Mcast DNS' is mentioned on line 156, but not defined == Missing Reference: 'STD3' is mentioned on line 181, but not defined == Missing Reference: 'STD4' is mentioned on line 182, but not defined == Missing Reference: 'RFC 1812' is mentioned on line 184, but not defined == Missing Reference: 'TBD' is mentioned on line 1082, but not defined == Unused Reference: 'STD 3' is defined on line 1149, but no explicit reference was found in the text == Unused Reference: 'STD 4' is defined on line 1152, but no explicit reference was found in the text == Unused Reference: 'MCAST DNS' is defined on line 1224, but no explicit reference was found in the text == Unused Reference: 'NAT WG' is defined on line 1241, 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 (-07) exists of draft-ietf-malloc-madcap-05 == Outdated reference: A later version (-02) exists of draft-thaler-zeroconf-multicast-00 -- Possible downref: Normative reference to a draft: ref. 'AutoMcast' == Outdated reference: A later version (-05) exists of draft-ietf-dhc-ipv4-autoconfig-04 -- Possible downref: Normative reference to a draft: ref. 'AutoNet' == Outdated reference: A later version (-02) exists of draft-manning-multicast-dns-01 -- Possible downref: Normative reference to a draft: ref. 'MCAST DNS' -- Possible downref: Normative reference to a draft: ref. 'MiniDHCP' == 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. 'DNSEXT WG' -- Possible downref: Non-RFC (?) normative reference: ref. 'MALLOC WG' Summary: 10 errors (**), 0 flaws (~~), 23 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Zeroconf WG M. Hattig 3 Internet Engineering Task Force Editor 4 INTERNET DRAFT Intel Corp. 5 Expires September 2000 March 10, 2000 7 Zeroconf Requirements 8 draft-ietf-zeroconf-reqts-03.txt 10 Status of This Memo 12 This document is a submission by the Zeroconf Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be 14 submitted to the zeroconf@merit.edu mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are 20 working documents of the Internet Engineering Task Force (IETF), 21 its areas, and its working groups. Note that other groups may 22 also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Abstract 38 Many common TCP/IP protocols such as DHCP, DNS, MADCAP, and LDAP 39 must be configured and maintained by an administrative staff. This 40 is unacceptable for emerging networks such as home networks, small 41 office networks, automobile networks, airplane networks, or adhoc 42 networks at conferences, emergency relief stations, and many 43 others. For these networks, an administrative staff will not exist 44 and the users of these networks neither have the time nor 45 inclination to learn network administration skills. Instead, these 46 networks need protocols that require zero user configuration and 47 administration. This document is part of an effort to define such 48 zero configuration (zeroconf) protocols. 50 Before embarking on defining zeroconf protocols, protocol 51 requirements are needed. This document presents requirements for 52 zeroconf protocols in four areas: IP host configuration, domain 53 name to IP address resolution, IP multicast address allocation, 54 and service discovery. The requirements for these four areas 55 result from examining everyday use or scenarios of these 56 protocols. 58 An additional part of the overall zeroconf protocol effort 59 includes a separate profiles document that is a companion to this 60 requirements document. The profile document matches existing 61 protocols with the requirements. If existing protocols do not meet 62 the requirements then new zeroconf protocols must be created. 64 Table of Contents 66 1 Introduction................................................2 67 1.1 Reading This Document.....................................3 68 1.2 Background Information....................................3 69 1.3 Zeroconf Protocols........................................4 70 2 Scenarios & Requirements....................................9 71 2.1 IP Host Configuration.....................................9 72 2.2 Domain Name to IP Address Resolution Scenarios...........12 73 2.3 IP Multicast Address Allocation Scenarios................15 74 2.4 Service Discovery Scenarios..............................18 75 3 Security Considerations & Requirements.....................20 76 3.1 IP Host Configuration....................................21 77 3.2 Domain Name to IP Address Resolution.....................21 78 3.3 IP Multicast Address Allocation..........................22 79 3.4 Service Discovery........................................22 80 3.5 IPv6 Considerations......................................22 81 4 IANA Considerations........................................22 82 5 Full Copyright Statement...................................22 83 6 Acknowledgements...........................................23 84 7 References.................................................24 86 1 Introduction 88 This document presents requirements for zeroconf protocols in four 89 areas: IP host configuration, domain name to IP address 90 resolution, IP multicast address allocation, and service 91 discovery. Security issues and the transitions between a zeroconf 92 protocol and a non-zeroconf protocol are also discussed within 93 each protocol area. 95 The major sections to this requirements document are the 96 Introduction, Scenarios & Requirements, and Security 97 Considerations & Requirements. The introduction provides the 98 background information, terms, and assumptions so the scenarios 99 can be understood. The Scenarios & Requirements section lists 100 requirements that result from examining everyday usage scenarios 101 of protocols. The security section lists threats and security 102 requirements for all four protocol areas. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 105 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 106 in this document are to be interpreted as described in [RFC 107 2119]. 109 1.1 Reading This Document 111 Because this document deals with four distinct protocol areas, 112 many sections are divided into these areas. These areas are: 113 - IP host configuration 114 - Domain name to IP address resolution 115 - IP multicast address allocation 116 - Service discovery 118 With the exception of the introduction, a reader only interested 119 in particular areas only needs to read about those areas. However, 120 all readers should read the introduction to understand the flow of 121 the document and various global assumptions. 123 Specifically, the introduction provides the necessary background 124 information to support the scenarios and requirements sections. 125 This introduction includes reference information, restrictions, 126 assumptions, and terms. 128 The Scenarios & Requirements section is divided into protocol 129 areas. Within each area is a representative set of everyday usage 130 scenarios that generate unique requirements. A summary of all 131 requirements finishes each protocol area subsection. 133 The Security Considerations & Requirements section lists threats 134 and security requirements for each protocol area. 136 1.2 Background Information 138 The below references are divided by protocol area with additional 139 references for security and general knowledge. Note that some IETF 140 working groups are listed because they specify protocols that 141 impact zeroconf protocols. All readers should be familiar with the 142 general knowledge references. 144 IP host configuration: 145 - [AutoNet] Ipv4 Auto-Configuration I-D 146 - [MiniDHCP] Auto-Addressing in Multi-segment Networks I-D 147 - [RFC 1918] RFC 1918 Private Addresses 148 - [RFC 2131] RFC 2131 DHCP 149 - [RFC 2132] RFC 2132 DHCP Options 150 - [RFC 2462] IPv6 Auto-Configuration 151 - [RFC 2461] IPv6 Neighbor Discovery 152 - [IPv6 WG] Next Generation (Ipv6) WG 153 - [DHC WG] Dynamic Host Configuration WG 155 Domain name to IP address resolution: 156 - [Mcast DNS] Multicast DNS I-D 157 - [RFC 1001] NETBIOS: CONCEPTS AND METHODS 158 - [RFC 1002] NETBIOS: DETAILED SPECIFICATIONS 159 - [RFC 1034] RFC 1034 DNS 160 - [DNSEXT WG] DNS Extension WG 162 Multicast address allocation: 163 - [AutoMcast] Multicast Address Allocation in Auto-Configured 164 Networks I-D 165 - [RFC 2730] RFC 2730 MADCAP 166 - [RFC 2365] RFC 2365 Administratively Scoped Multicast Address 167 - [MALLOC WG] Multicast Address Allocation WG 169 Service discovery: 170 - [SSDP] Simple Service Discovery Protocol I-D 171 - [RFC 2608] RFC 2608 Service Location Protocol v2 172 - [RFC 2609] RFC 2609 SLP Schemes 174 Security: 175 - [RFC 2316] RFC 2316, IAB Security Architecture Workshop 176 - [RFC 2401] RFC 2401, Security Architecture for IP 177 - [RFC 2411] RFC 2411, IP Security Document Roadmap 178 - [RFC 2504] RFC 2504, User's Security Handbook 180 General knowledge: 181 - [STD3] RFC 1122 Requirements for Internet Hosts - Comm Layers 182 - [STD4] RFC 1123 Requirements for Internet Hosts - App Layers 183 - [RFC 1458] RFC 1458 Requirements for Multicast Protocols 184 - [RFC 1812] RFC 1812 Requirements for Internet Gateways 186 1.3 Zeroconf Protocols 188 Below are strict definitions of zeroconf protocol and a non- 189 zeroconf protocol. Also discussed are how a host transitions 190 between a zeroconf protocol and non-Zeroconf protocol within a 191 single area as well as coexistence of protocols in different 192 areas. Then, additional subsections state the assumptions and 193 restrictions for each protocol area. 195 1.3.1 Definitions 197 A zeroconf protocol requires no user configuration and does not 198 rely on information received from a centralized server. 200 A non-zeroconf protocol requires user configuration or relies on 201 information received from a centralized server. 203 1.3.2 Transitions 205 Below is a discussion of three possible transitions that a host 206 SHOULD consider when using a zeroconf protocol. Basically, the 207 host must be able to determine when to change from using the 208 zeroconf protocol to the non-zeroconf protocol, or vice-versa. In 209 addition, if the host moves from one network to another network 210 and both networks are using a zeroconf protocol, the host must 211 know to re-initialize or restart the zeroconf protocol. 213 The first transition is a zeroconf to non-zeroconf transition. 214 This type of transition may occur either if a host moves to a new 215 network that does not use a zeroconf protocol when the old network 216 used a zeroconf protocol. Or if the host stays on the same network 217 but a non-zeroconf server comes online within that network. For 218 example, if a DHCP server comes online after hosts are configured 219 with a zeroconf IP host configuration protocol then hosts MUST re- 220 configure with DHCP. 222 The second transition is the opposite of the first; it is a non- 223 zeroconf to zeroconf transition. This may occur if a host moves to 224 a different network or when a non-zeroconf server goes offline 225 within a network. 227 The third transition occurs if a host moves from one network to 228 another network when both networks use a zeroconf protocol. For 229 example, if a person is using a laptop in her home network with a 230 zeroconf protocol, then she takes that laptop to her neighbor's 231 home network that uses the same zeroconf protocol, then the laptop 232 must automatically adapt to the zeroconf protocol operating in the 233 new network. 235 Another subtle example of this third of transition is if the 236 network topology changes significantly as when a bridge gets 237 installed between two existing networks. In this case, if the 238 networks are utilizing a zeroconf IP host configuration protocol, 239 the protocol MUST allow the hosts to detect addressing conflicts 240 and possibly reconfigure. 242 1.3.3 Coexistence 244 A zeroconf protocol in one area MUST be able to coexist with a 245 non-zeroconf protocol in another area. 247 To illustrate this point, suppose there are standard zeroconf and 248 non-zeroconf protocols for IP host configuration and domain name 249 to IP address resolution. 251 For IP host configuration, the zeroconf protocol is "protocol-A." 252 The non-zeroconf protocol is "protocol-B", supported by a fully 253 conformant "protocol-B" server. 255 For domain name to IP address resolution, the zeroconf protocol is 256 "protocol-C". The non-zeroconf protocol is "protocol-D" supported 257 by a fully conformant "protocol-D" server. 259 Within a single network, the IP host configuration zeroconf 260 protocol-A MUST be able to coexist with the domain name to IP 261 address resolution non-zeroconf protocol-D. 263 In contrast, zeroconf and non-zeroconf protocols from a single 264 area MUST NOT be able to coexist during normal operation. They MAY 265 coexist during a transition, but the coexistence period MUST be 266 minimal. 268 1.3.4 IP Host Configuration 270 In this document, IP host configuration really is the 271 configuration of an interface on an IP host. That is, IP host 272 configuration is complete when a host is able to use an IP 273 address, netmask, and default route on an interface. IP host 274 configuration is required before almost any IP communication can 275 take place through a single interface on a host. 277 DHCP is the common IP host configuration solution deployed today. 278 DHCP consists of servers and clients. The client discovers the 279 server, and then the server offers configuration parameters to 280 clients. It is assumed that all zeroconf IP host configuration 281 schemes will coexistence with DHCP. DHCP is the non-zeroconf 282 solution for IP host configuration. 284 The definitions needed for the IP host configuration scenarios 285 are: 287 IP subnet � a single logic IP network that may span multiple layer 288 2 networks. All hosts on a single logical IP network have the 289 identical result when performing the following operations 290 (HostIPAddr & netmask). In addition, all hosts on the single 291 logical subnet have a unique result when performing the following 292 operation (HostIPAddr & ~netmask) (inverse netmask). 294 internet - multiple IP subnets connected by routers. This may be 295 the global Internet or a private internet. 297 Network - general term that may apply to IP subnet, internet, 298 Internet, or a layer 2 network. The context in which this term is 299 used defines its meaning. 301 1.3.5 Domain name to IP address resolution 303 Web browsing to an URL utilizes domain name to IP address 304 resolution. When a user enters a host name to download a file with 305 FTP, the entered name is resolved to an IP address. Domain name to 306 IP address resolution allows applications and users to remain 307 blissfully unaware of IP addresses. 309 DNS is the common way to resolve names. DNS consists of servers 310 that maintain resource records; a record maps a domain name to an 311 IP address. In addition, resolvers (i.e. clients) on hosts query 312 the DNS servers for the information in resource records. Name 313 servers have authority for particular zones. A zone covers a 314 complete set or a subset of a domain. If a server cannot directly 315 resolve a name, it passes the request onto another DNS server or 316 returns the IP address of another DNS server back to the resolver 317 so the resovler can query the DNS server it just learned about. 318 DNS is the non-zeroconf solution for domain name to IP address 319 resolution. 321 It is assumed that sub-domain delegation is not done within the 322 zone that a zeroconf domain name to IP address resolution protocol 323 is performed. In other words, a zone includes all of the names in 324 its domain. 326 In addition, it is assumed a zeroconf domain name to IP address 327 resolution protocol will only be used if a DNS server is not 328 present or a host is not configured with a DNS server. It is also 329 assumed that TCP/IP networking connectivity to other zones MAY 330 exist and those other zones have DNS servers. Furthermore, this 331 also assumes that a special router exists at the edge of these two 332 zones and is able to convert between the zeroconf and non-zeroconf 333 domain name to IP address resolution protocols. 335 A default domain is the domain considered �local� to a host. 337 1.3.6 IP Multicast Address Allocation 339 Examples of emerging multicast applications include audio/video 340 (e.g. TV), bulk news, and intra-home intercom system. These 341 applications require an IP multicast address prior to sending IP 342 multicast packets. In most cases, the IP multicast address is 343 unique per application source. The scope of the multicast address 344 determines if a multicast packet gets transmitted beyond certain 345 administrative domains, which are separated by a boundary router 346 as defined in RFC 2365. 348 MADCAP is the non-Zeroconf IP multicast address allocation 349 solution. MADCAP is a client/server protocol that operates much 350 like DHCP. In addition, the client may define a range from which 351 the IP multicast address is allocated by passing a scope along 352 with the client�s allocation request. 354 Zeroconf solutions are only concerned with IP multicast addresses 355 scoped as Local (i.e. 239.255.0.0/16), link-local, node-local, and 356 any scope of single-source IP multicast addresses. It is assumed 357 that an RFC 2365 defined boundary router appropriately controls 358 multicast packets from physically entering and leaving scope 359 boundaries. 361 1.3.7 Service Discovery 363 Service discovery protocols have proven to be critical to the 364 usability of networks. AppleTalk/NBP, NetBIOS/SMB and IPX/SAP are 365 good real-world examples of this. Services from printing to gaming 366 are easily found on these networks. 368 Unlike the other protocol areas in this document, service 369 discovery will not likely have separate zeroconf and non-zeroconf 370 protocols; one protocol will serve both. 372 Also unlike the other protocol areas, no service discovery 373 protocol has been as widely deployed as DNS or DHCP. Service 374 Location Protocol version 2 (SLPv2) is defined in Standards Track 375 RFC 2608. An Internet-Draft defines Simple Service Discovery 376 Protocols (SSDP), which is another service discovery protocol. 378 Service discovery definitions are: 380 Process - A process is an implementation of an algorithm in 381 software, hardware, or a combination of software and hardware. 383 Registry - A process that acts as an intermediary between a client 384 and a server. Servers 'register' service advertisements and other 385 pertinent information (e.g. authentication info, announcement 386 criteria) with registries, then the service may be discovered from 387 the registry instead of from a server. 389 Registry update - A message that contains updated registry 390 information. It may cause one or more registry entries to be 391 deleted, added, or modified. 393 Server - A process that offers services to clients. A server can 394 make its service(s) known to clients by means of a service 395 discovery protocol. 397 Service - A service is set of processes that utilize a particular 398 protocol. Services range from printing to transferring a file to 399 providing on-line pizza order and delivery. 401 Service Advertisement Packet - An unsolicited packet issued by a 402 server or registry. The advertisement provides the service 403 identifier, service type, and possibly service characteristics. 405 Service Characteristics � Characteristics provide a finer 406 granularity of description by which to differentiate services 407 beyond just the service type. For example if the service type is 408 printer, the characteristics may be color, pages printed per 409 second, location, etc. 411 Service Discovery Protocol - A service discovery protocol enables 412 a client (or clients) to discover a server (or servers) of a 413 particular service. A service discovery protocol is an application 414 layer protocol that relies on network and transport protocol 415 layers. 417 Service Identifier - A service identifier allows clients, servers, 418 advertisers, discoverers, and registries to uniquely identify an 419 instance of a service type. 421 Service Protocol - A service protocol is used between the client 422 and the server after service discovery is complete. 424 Service Solicitation - A request packet made by a client to obtain 425 a response packet that indicates a service is present. The 426 response may come from a service or a registry. 428 Service Type � A service type allows clients, servers, 429 advertisers, discoverers, and registries to uniquely identify a 430 type of service such as a printer service. 432 2 Scenarios & Requirements 434 This section lists everyday usage scenarios that lead to 435 requirements for zeroconf protocols. There is a subsection for 436 each of the four protocol areas. Within each protocol area 437 representative scenarios are discussed and requirements are 438 identified. Also, within each area is a summary of the 439 requirements and an IPv6 considerations section. 441 2.1 IP Host Configuration 443 IP Host configuration determines the appropriate values for an IP 444 interface's IP address, netmask, and default route. Then the host 445 must operate with those values. The scenarios in this section are 446 ping, bridge install, and transitions between zeroconf IP host 447 configuration and DHCP. 449 2.1.1 Ping 450 Ping consists of one host sending an ICMP echo request to another 451 host, then the other host replying with an ICMP echo reply. Ping 452 has two sub-scenarios: ping to a host on local IP subnet and ping 453 to a host off the local IP subnet. 455 When sending a ping, a host performs the AND operation on the 456 netmask and the destination IP address then compares that result 457 with the result of an AND operation on the host's IP address and 458 netmask. Here is representative C code: 460 ((HostIPAddr & netmask) == (DestIPAddr & netmask)) 462 If the result of this compare is FALSE, then the host forwards the 463 packet to the default router because the destination address is 464 off the local IP subnet. If the result is TRUE, then the host 465 sends an ARP request to resolve the destination IP address to a 466 hardware address within the local IP subnet. 468 These steps are important to show that a ping to a host on a local 469 IP subnet presents different requirements than a ping to a host on 470 a non-local IP subnet. The zeroconf IP host configuration MUST 471 allow ping to succeed in either case if it is possible within the 472 TCP/IP connectivity provided by a given network. The specific 473 protocol requirements follow: 475 Netmask requirements: 476 - All hosts on an IP subnet MUST have a common netmask. 478 IP address requirements: 479 - The result of (HostIPAddr & netmask) must be the same value for 480 all hosts on an IP subnet 481 - The result of (HostIPAddr & ~netmask) (inverse netmask) must be 482 unique for all hosts on an IP subnet 484 Default route requirements: 485 - A default route is not required for communication within the 486 local subnet. 487 - A default route is required for communication off the local 488 subnet. 490 Note that by definition, IP subnet numbers must be unique within 491 an internet, thus no address duplication between hosts on 492 different subnets can exist. Managing IP subnet numbers is not the 493 function of an IP host configuration protocol; it is the function 494 of a router or another entity aware of an entire internet. 495 Zeroconf IP Host configuration does not include configuration of 496 routers; however, zeroconf IP host configuration MAY utilize a 497 configured router to retrieve the default route or the netmask. 498 Hosts could subsequently determine the IP subnet number with the 499 netmask. 501 Note that a ping from a host using a private address (as defined 502 in RFC 1918) to a globally unique IP address on the Internet does 503 not add additional requirements to the zeroconf IP host 504 configuration protocol. Instead, it places additional requirements 505 on the specialized router that sits between the internet using the 506 private address space and the global Internet. The requirements of 507 this specialized router are outside the scope of this document. 509 2.1.2 Bridge Installed 511 This scenario starts with two completely operational standalone 512 networks. After initial IP host configuration with zeroconf 513 protocols, these two networks become one when a bridge gets 514 installed between them. 516 Two problems arise. The first is that hosts now may have duplicate 517 IP addresses. Note, that this is not considered a major problem 518 because the occurrence of duplicate addresses can be made 519 statically improbably if the netmask is the same for all networks 520 and allows for a large number of hosts (e.g. netmask of 521 255.255.0.0). 523 Another problem is that the hosts on the two networks are not 524 using the same netmask or that all hosts do not have the same 525 result of (HostIPAddr & netmask) operation as was shown to be a 526 requirement for ping. Note this assumes that a network with 527 multiple IP subnets operating over a single layer-2 network is not 528 desirable. 530 These problems create unique requirements for the bridge install 531 scenario. Specifically, the zeroconf IP host configuration 532 protocol MUST provide hosts with the ability to detect duplicate 533 IP addresses even after initial configuration. Once detected, one 534 of the hosts must choose a new IP address and ensure that the new 535 IP address is unique. In addition, the protocol MUST consolidate 536 two IP subnets into a single IP subnet. 538 2.1.3 Zeroconf and non-Zeroconf Transitions 540 DHCP is the non-zeroconf IP host configuration protocol. Hosts 541 MUST be able to transition between DHCP and the zeroconf IP host 542 configuration protocol by detecting the presences or absence of a 543 DHCP server. Barring any new DHCP option, the most likely 544 mechanism is a DHCP discovery message. 546 If DHCP is detected while using zeroconf IP host configuration, 547 the host must start utilizing DHCP. If DHCP is no longer detected 548 while using DHCP, the host must start utilizing the zeroconf IP 549 host configuration protocol. 551 2.1.4 Requirements Summary 553 Zeroconf IP host configuration protocol requirements are: 554 - The protocol MUST allow all hosts on an IP subnet to have a 555 common netmask. 556 - The protocol MUST allow all hosts on an IP subnet to choose an 557 IP address such that the result of the (HostIPAddr & netmask) 558 operation is the same value for all hosts on an IP subnet. 559 - The protocol MUST allow all hosts on an IP subnet to choose an 560 IP address such that the result of the (HostIPAddr & ~netmask) 561 operation (inverse netmask) is unique among all hosts on an IP 562 subnet. 563 - The protocol MUST allow hosts to operate without choosing a 564 default route to communicate with other hosts on their local 565 subnet. 566 - The protocol MUST allow hosts to choose a default route if it is 567 available. 568 - The protocol MUST allow the host to defend the address it 569 chooses. 570 - The protocol MUST provide hosts the ability to detect duplicate 571 IP addresses after initial configuration. 572 - The protocol MUST be able to consolidate two IP subnets into a 573 single IP subnet. 574 - The protocol MUST allow a host to detect that DHCP is and is not 575 in use. 576 - The protocol MUST allow a host to transition from the zeroconf 577 protocol to DHCP if DHCP is detected while using zeroconf IP 578 host configuration. 579 - The protocol MUST allow a host to transition from DHCP to the 580 zeroconf protocol if while using DHCP the DHCP server is no 581 longer detected. 583 2.1.5 IPv6 Considerations 585 IPv6 allows a host to select an appropriate IP address, netmask, 586 and find a default route, thus if a network is using IPv6, there 587 already exists a zeroconf IP host configuration solution. 589 2.2 Domain Name to IP Address Resolution Scenarios 591 Domain name to IP address resolution consists of a host making a 592 query that contains a host name, and then the response to the 593 query contains the IP address to complete the resolution. 595 The zeroconf problem with DNS is that the host must be configured 596 with the IP address of a DNS server. This allows the host to send 597 a unicast DNS request to a DNS server, then its simplest form, the 598 DNS server responds with the IP address. 600 The zeroconf goal for domain name to IP address resolution is to 601 remove the need for the host to configure the IP address of a DNS 602 server. 604 The first scenarios are to resolve a name of a host that resides 605 within the zeroconf domain and then to resolve a name that resides 606 outside the zeroconf domain. 608 Another scenario below is a host determining its name and default 609 domain. Once a name is selected, the host must ensure the name is 610 unique within its default domain. This is an ancillary issue for 611 domain name to IP address resolution that will most likely result 612 in a protocol that is independent from protocols that resolve 613 domain names to IP addresses. 615 The final scenarios are transitions between using DNS and the 616 zeroconf domain name to IP address resolution protocol. 618 2.2.1 Name Resolution 620 The zeroconf domain name to IP address resolution protocol MUST 621 resolve a name to an IP address without a host being configured 622 with the IP address of a DNS server. This includes names within 623 the same domain as the host that is using the zeroconf protocol as 624 well as names within other domains. 626 2.2.2 Name and default domain selection 628 A name selection protocol is necessary so that all host within a 629 domain have unique names. Once a host chooses a name, it MUST then 630 determine if the name is in use. If the host requires a unique 631 name, the host selects a different name and again determines if 632 the name is unique. This process continues until the host has a 633 name that is unique within a domain. 635 A host MUST determine its default domain and the default domain 636 MUST be the same for all hosts within the domain. 638 The zeroconf name resolution protocol must become active 639 periodically to check the validity of name. One example of when 640 this is necessary is when previously disconnected yet operational 641 networks now become connected by the installation of a router or a 642 bridge. 644 2.2.3 Zeroconf and non-Zeroconf Transitions 646 DNS is the non-zeroconf domain name to IP address resolution 647 protocol. There are four transitional cases to consider. 649 The first is a zeroconf to non-zeroconf transition that occurs 650 when the host is first configured with the IP address of the DNS 651 server and the host can actually reach the DNS server (i.e. the 652 DNS server responds to requests). 654 The second is a non-zeroconf to zeroconf transition that occurs 655 when for some reason the DNS server can no longer be reached. One 656 such reason may be that the host is moved to a network without 657 connectivity to the DNS server. In this case the zeroconf domain 658 name to IP address resolution protocol MUST be invoked. 660 The third transition is from zeroconf back to non-zeroconf. This 661 occurs when the DNS server becomes reachable again. Following the 662 above example, the host is moved back to the original network with 663 connectivity to the DNS server. 665 The final transition is a non-zeroconf to zeroconf transition that 666 occurs when the IP address of the DNS server is removed from the 667 host. 669 These transitions generate the following requirements: 670 - The zeroconf protocol MUST operate when a host is not configured 671 to use a DNS server. 672 - If configured to use DNS the host MUST be able to detect the 673 presence and the absence of a DNS server. 674 - If the DNS server becomes absent after configuration, the host 675 MUST use the zeroconf protocol. 676 - If the DNS server becomes present after being absent, the host 677 MUST use DNS. 679 2.2.4 Requirements Summary 681 Zeroconf Domain name to IP address protocol requirements are: 682 - The protocol MUST resolve a name to an IP address without a host 683 being configured with the IP address of a DNS server. This 684 includes names within the same domain as the host that is using 685 the zeroconf protocol as well as names within other domains. 686 - The protocol MUST allow the host to defend the name it chooses. 687 - The protocol MUST operate when a host is not configured to use a 688 DNS server. 689 - If configured to use DNS the host MUST be able to detect the 690 presence and the absence of a DNS server. 691 - If the DNS server becomes absent after configuration, the host 692 MUST use the zeroconf protocol. 693 - If the DNS server becomes present after being absent, the host 694 MUST use DNS. 696 Zeroconf name selection protocol requirements are: 698 - Processing within a host is responsible for choosing a host 699 name. This includes selecting the initial name as well as 700 selecting subsequent names if a name proves to be a duplicate. 701 - The protocol MUST allow the host to determine if the name is in 702 use by another host within the default domain. At various times 703 a host MUST actively determine if another host is using its 704 name. 705 - The protocol MUST remain within the domain of the hosts using 706 the protocol. 707 - The protocol MUST allow hosts to create or determine the 708 existence of a default domain. 709 - The protocol MUST ensure all hosts operating within a domain use 710 the same default domain. 712 2.2.5 IPv6 Considerations 714 Domain name to IP address resolution protocols as well as name and 715 default domain selection have no zeroconf related differences for 716 IPv4 and IPv6. 718 2.3 IP Multicast Address Allocation Scenarios 720 IP multicast is used to conserve bandwidth and reduce complexity 721 in the source. Bandwidth is conserved because a sender only sends 722 a single packet, then a large number of receivers receive that 723 packet. The unicast alternative requires the source to send 724 individual packets to each destination; this consumes more 725 bandwidth. In addition, unicasting increases the complexity of the 726 source because the source must maintain a list of the individual 727 destinations. 729 All IP multicast addresses allocated are from the scopes of Local 730 (i.e. 239.255.0.0/16), link-local, node-local, and Single-source 731 IP multicast addresses of any scope. Descriptions of �Scope 732 Enumeration� and �Allocate Node-scoped or Single-Source Global IP 733 multicast address� do not result in requirement but do provide 734 important information about IP multicast operations. The scenarios 735 of �Allocate Link-scoped or Local-Scope IP multicast�, �Allocate 736 IP Multicast Address Used by Multiple Sources�, then the 737 transitions between zeroconf and MADCAP generate protocol 738 requirements. 740 2.3.1 Scope Enumeration 742 Applications that leave the choice of scope up to the user require 743 the ability to enumerate what scopes the host is within [RFC 744 2771]. 746 In addition, services that are assigned relative addresses [RFC 747 2365] also require the ability to enumerate what scopes the host 748 is within, then a host is able to apply the relative address to a 749 scope. 751 When enumerating scopes, the following scopes may be assumed to 752 exist in all cases (assuming well-known ranges have been reserved 753 by IANA). 754 - Node-Local 755 - Link-Local 756 - Local (i.e., the Zeroconf area) 757 - Single-source global 759 The zeroconf IP multicast address allocation protocol requirements 760 are: 761 - A host MUST be able to obtain the set of scope names, for all 762 scopes it is within. 763 - A host MUST be able to obtain the set of address ranges for all 764 scopes it is within. 766 2.3.2 Allocate Node-scoped or Single-Source Global IP multicast 767 address 769 Each host is always responsible for allocating its own Node-scoped 770 and Single-source Global multicast addresses, regardless of 771 whether it is use of zeroconf protocols since there is no 772 coordination between devices for such allocation, no protocol is 773 involved, and there are no protocol requirements. 775 Allocating (global) single-source addresses is only possible if 776 the host has already acquired a global unicast IP address. 778 To date, no range has been reserved for dynamic allocation of 779 Single-source addresses in IPv6. Hence, until such a range is 780 reserved, dynamic allocation of Single-source addresses applies 781 only to IPv4. 783 2.3.3 Allocate Link-scoped or Local-Scope IP multicast address 785 Address allocation at the Link and larger scopes requires 786 coordination to avoid address collisions. To allocate an address, 787 the host specifies a given scope, the number of addresses it 788 desires, and the lifetime for which it desires. 790 To date, no range has been reserved for dynamic allocation of 791 Link-scoped addresses in IPv4. Hence, unless such a range is 792 reserved, dynamic allocation of Link-scoped addresses applies only 793 to IPv6. 795 Collision detection must span the entire Link for Link-scope 796 allocations, and must span the entire locally scoped internet for 797 Local-scope allocations. The protocol should include the ability 798 for a host to choose addresses, determine if they are in use, and 799 choose different addresses if so. 801 The collision detection protocol must become active at various 802 times such as when previously disconnected yet operational 803 networks now become connected by the installation of a router or 804 bridge. 806 The zeroconf IP multicast address allocation protocol requirements 807 are: 808 - A host that wishes to allocate a multicast address with a given 809 scope and lifetime MUST select an address. 810 - A host MUST determine if the address has been allocated by 811 another host. 812 - A host MUST participate to defend the addresses it allocates. 813 - At various times a host MUST actively determine if another host 814 has allocated an address it has allocated. 815 - Routers MUST route this protocol to ensure it spans the entire 816 local scope. 818 2.3.4 Multiple Source 820 An intercom system inside a home is an example of a multiple 821 source IP multicast application. In this type of application, 822 several sources may be sending packets destined to the same IP 823 multicast address. 825 Here, the first source that needs the IP address MUST allocate the 826 address, yet it may not be the host that deallocates the multicast 827 address. This is because the first source may leave the multicast 828 group before all the other sources stop sending packets to that IP 829 multicast address. This requires, the last source using the IP 830 multicast address to deallocate the IP multicast address after it 831 is done sending. 833 The zeroconf IP multicast address allocation protocol requirements 834 are: 835 - When more than one source uses an IP multicast address, the last 836 host acting as a source for the IP multicast address MUST 837 deallocate the IP multicast address. 839 2.3.5 Zeroconf and non-Zeroconf Transitions 841 MADCAP is the non-zeroconf IP multicast address allocation 842 protocol. Hosts MUST be able to transition between MADCAP and the 843 zeroconf IP multicast address allocation protocol by detecting (or 844 not detecting) the presences of a MADCAP server. 846 If MADCAP is detected while using zeroconf IP multicast address 847 allocation, the host must start utilizing MADCAP. If MADCAP is no 848 longer detected while using MADCAP, the host must start utilizing 849 the zeroconf IP multicast address allocation protocol. 851 2.3.6 Requirements Summary 853 Zeroconf IP multicast address allocation protocol requirements 854 are: 855 - A host that wishes to allocate a multicast address with a given 856 scope and lifetime MUST select an address. 857 - A host MUST determine if the address has been allocated by 858 another host. 859 - A host MUST participate to defend the addresses it allocates. 860 - At various times a host MUST actively determine if another host 861 has allocated an address it has allocated. 862 - Routers MUST route this protocol to ensure it spans the entire 863 locally scoped internet. 864 - The protocol MUST allow the last source that uses a multicast 865 address to deallocate the multicast address regardless of which 866 node allocated the address. 867 - If MADCAP is detected while using zeroconf IP multicast address 868 allocation, the host must start utilizing MADCAP. 869 - If MADCAP is no longer detected while using MADCAP, the host 870 must start utilizing the zeroconf IP multicast address 871 allocation protocol. 873 2.3.7 IPv6 Considerations 875 To date, no range has been reserved for dynamic allocation of 876 Single-source addresses in IPv6. Hence, until such a range is 877 reserved, dynamic allocation of Single-source addresses applies 878 only to IPv4. 880 To date, no range has been reserved for dynamic allocation of 881 Link-scoped addresses in IPv4. Hence, unless such a range is 882 reserved, dynamic allocation of Link-scoped addresses applies only 883 to IPv6. 885 2.4 Service Discovery Scenarios 887 [MODIFY MODIFY MODIFY ] As stated earlier, there is not really a 888 non-zeroconf service discovery protocol; instead, the service 889 discovery protocol must scale to larger networks. For this reason 890 there are no transitional scenarios related to service discovery. 891 The scenarios are the discovery of a simple printer service and 892 the discovery of a printer manager that consolidates many printer 893 services. 895 2.4.1 Printer Service 897 Networked enabled printers allow various networked clients to 898 submit print jobs. A service discovery protocol MUST allow a 899 printing client to discover the printer service. This requires a 900 service type as well as a service identifier to distinguish 901 instances of a single service type. 903 Discovery MUST be possible by either the client actively 904 soliciting the server or by the server advertising then the client 905 passively listening for the advertisements. Once a client finds 906 the printer, it can utilize different printing protocols such as 907 raw tcp, lpd, and ipp. 909 Printers vary in their characteristics such as location, status, 910 dots per inch, drivers, etc. Discovering these characteristics 911 MUST be part of the service discovery protocol. Some service 912 specific protocols allow the client and server to negotiate the 913 use of these characteristics after the service is found; thus, 914 alleviating the need for the service discovery protocol to 915 discover by characteristic. However, characteristic discovery MUST 916 be part of the service discovery protocol for those services 917 without capability negotiation. 919 Within a short number of seconds after activating a print server, 920 a user who is actively browsing for a printer MUST be able to see 921 the device appear in a browser window, or a user application such 922 as a spreadsheet MUST be able to begin using the print service. 923 This requires the service discovery to be timely. 925 In the case of a printer service, a printer may be temporarily 926 taken off-line for repair or everyday maintenance. This requires 927 clients to be able to rediscover a service. 929 A discovery protocol itself MUST NOT require configuration. Note 930 that configuration of the service discovery protocol is not to be 931 confused with the configuration of the client or server protocol 932 which places no requirements on the service discover protocol. 934 2.4.2 Printer Manager 936 A printer manager acts as a proxy to various printers. A printer 937 manager improves scalability by providing a single location from 938 which clients can find all printers. 940 In addition, a printer manager provides an evolutionary path for 941 service discovery deployment. For example, if an existing printer 942 does not support the zeroconf service discovery protocol, the 943 printer manager can use a legacy printer specific protocol to 944 learn the existence and characteristics of a printer then expose 945 that printer and its characteristics through the zeroconf service 946 discovery protocol. This allows new printer clients that support 947 the service discovery protocol to discover legacy printers that do 948 not support the zeroconf service discovery protocol. 950 A print manager requires a registry to cache information about 951 services and characteristics of services. Clients MUST be able to 952 extract data from the registry without knowledge that they are 953 talking to a registry. In other words, the client and server sides 954 of the service discovery protocol MUST NOT be any different 955 whether a registry is involved or not. Registry updates that 956 maintain the registry are required of the service discovery 957 protocol but are optionally implemented for a particular service; 958 this allows legacy protocols or the zeroconf service discovery 959 protocol to update and maintain the registry. 961 2.4.3 Requirements Summary 963 Zeroconf service discovery protocol requirements are: 964 - The protocol MUST allow a client to discover the service by a 965 service type, service identifier, and service characteristics. 966 - The protocol MUST support solicitations and advertisements. 967 - The protocol MUST be independent from any particular service. 968 - The protocol MUST allow timely discovery of a service. 969 - The protocol MUST allow clients to rediscover a service. 970 - The protocol MUST NOT require user configuration. 971 - The protocol MUST allow for registry. 972 - The protocol MUST allow the client and server sides of the 973 protocol to interact identically with and without a registry. 974 - The protocol MUST include optional mechanisms to update a 975 registry. 977 2.4.4 IPv6 Considerations 979 Service discovery protocols have no zeroconf related differences 980 for IPv4 and IPv6. 982 3 Security Considerations & Requirements 984 By definition security requires configuration. Security examples 985 include a configured key for payload encryption, user entered 986 passwords for conditional access, and an administrator configures 987 port mappings to enable a protocol to traverse a firewall. The 988 configuration required by security is in direct conflict with the 989 design goals of zeroconf protocols; however, security requirements 990 take precedence over zeroconf protocol design goals. 992 Given this reality, this section focuses on the minimal 993 configuration necessary to make zeroconf protocols secure. In 994 addition, this section describes four types of general threats and 995 how those general threats apply to each protocol area. 997 The general threats are: 999 Hoarding: Hosts claim all available resources, whether they plan 1000 to use them or not. This is a form of denial of service attack. 1002 Masquerading: Hosts can respond to requests that they should not 1003 so they can masquerade as another host. 1005 Antagonistic Server: A server could offer support for a critical 1006 service but intentionally misconfigure hosts on the network. 1008 3.1 IP Host Configuration 1010 Threats include: 1011 - A host could hoard IP addresses. 1013 If secure zeroconf IP host configuration is required, all hosts 1014 MUST be certifiable as valid participants. In addition, a host 1015 MUST be configured with some security information. Furthermore, 1016 some security information must be part of every zeroconf IP host 1017 configuration packet. 1019 Here is an example to illustrate: All hosts are registered as 1020 valid security participants by the manufactures before the product 1021 ships. In addition the product is shipped with a private key. 1022 Before the secure device communicates with another secure device 1023 it gets the other device�s registered info, then submits that 1024 registered info to the registration authority to get the devices 1025 public key. Of course this request is encrypted. From that point 1026 on all packets are encrypted using a public key and a private key. 1028 3.2 Domain Name to IP Address Resolution 1030 Potential threats include: 1031 - A host could masquerade by responding to names requests 1032 illegitimately. 1033 - A host could hoard names by responding to all 'claim' requests. 1035 Hosts MUST be able to be configured to use a zeroconf protocol for 1036 domain name to IP address resolution securely. For example, a 1037 'reply' from the resolution protocol could be accompanied by 1038 a 'signature' which could be verified before being accepted. 1039 The security configuration would have to provide the server 1040 portion of the protocol with the data needed to produce a 1041 'signature' which could only be produced if in possession of the 1042 configuration data. 1044 3.3 IP Multicast Address Allocation 1046 Potential threats include: 1047 - A host could hoard multicast addresses by denying others the 1048 ability to obtain them. 1049 - A host could snoop to learn all used IP multicast addresses in 1050 use then reconfigure the border router to allow IP multicast 1051 data to go beyond the desired boundary. 1053 Hosts MUST be able to be configured to use a zeroconf protocol for 1054 multicast address allocation securely. For example, a claim and 1055 defend protocol used for multicast address allocation would have 1056 to include security data with all messages. A host in the 1057 zeroconf network could verify that another host's claim was 1058 legitimate or not. 1060 3.4 Service Discovery 1062 Potential threats include: 1063 - Servers could masquerade by responding to service discovery 1064 requests that they shouldn't respond to. 1065 - A host could pose as an antagonistic service discovery 1066 'infrastructure element.' Some service discovery protocols 1067 offer a 'registry', 'directory', 'proxy' or other 1068 infrastructure element for scalability. 1070 The service discovery protocol MUST provide mechanisms that allow 1071 a client to determine if both the service it discovers and the 1072 service discovery protocol infrastructure it uses to discover 1073 services are 'legitimate.' 1075 The service discovery protocol MUST provide mechanisms that allow 1076 a client to determine if both the service it discovers and the 1077 service discovery protocol infrastructure it uses to discover 1078 services are 'legitimate.' 1080 3.5 IPv6 Considerations 1082 [TBD] 1084 4 IANA Considerations 1086 There are no known IANA considerations arising from this document. 1088 5 Full Copyright Statement 1090 Copyright (C) The Internet Society (1997). All Rights Reserved. 1092 This document and translations of it may be copied and furnished 1093 to others, and derivative works that comment on or otherwise 1094 explain it or assist in its implementation may be prepared, 1095 copied, published and distributed, in whole or in part, without 1096 restriction of any kind, provided that the above copyright notice 1097 and this paragraph are included on all such copies and derivative 1098 works. However, this document itself may not be modified in any 1099 way, such as by removing the copyright notice or references to the 1100 Internet Society or other Internet organizations, except as needed 1101 for the purpose of developing Internet standards in which case the 1102 procedures for copyrights defined in the Internet Standards 1103 process must be followed, or as required to translate it into 1104 languages other than English. 1106 The limited permissions granted above are perpetual and will not 1107 be revoked by the Internet Society or its successors or assigns. 1109 This document and the information contained herein is provided on 1110 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1111 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1112 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1113 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1114 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1115 PURPOSE." 1117 6 Acknowledgements 1119 Thanks to Peter Ford for hosting the first BOF that was the 1120 catalyst to forming the Zeroconf Working Group. 1122 Thanks to Erik Guttman and Stuart Cheshire for forming and 1123 chairing the Zeroconf Working Group, which is responsible for this 1124 document. 1126 Thanks to Erik Guttman for providing key input to the service 1127 discovery and the security sections. 1129 Thanks to Dave Thaler for providing key input to the IP multicast 1130 address allocation sections. 1132 Additional recognition goes the following people for their 1133 influential contributions to this document and its predecessors: 1134 Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob 1135 Quinn, John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl 1136 Auerbach, Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland, 1137 and Bernard Aboba. 1139 Editor: 1141 Myron Hattig 1142 Intel Corporation 1143 2111 NE 25th Ave. JF3 206 1144 Hillsboro, OR 97124 1145 myron.hattig@intel.com 1147 7 References 1149 [STD 3] R. Braden Requirements for Internet Hosts -- 1150 Communication Layers RFC 1122, STD 3, October 1989 1152 [STD 4] R. Braden, Requirements for Internet Hosts -- 1153 Application and Support RFC 1123, STD 4 October 1989 1155 [RFC 1001] PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP 1156 TRANSPORT: CONCEPTS AND METHODS, RFC 1001 March, 1987 1158 [RFC 1002] PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP 1159 TRANSPORT: DETAILED SPECIFICATIONS, RFC 1002, March 1160 1987 1162 [RFC 1034] P. Mockapetris, Domain Names - Concepts and 1163 Facilities, RFC 1034, November 1987 1165 [RFC 1458] R. Braudes, Requirements for Multicast Protocols, RFC 1166 1458, May 1993 1168 [RFC 1918] D. Karrenberg, et al, Address Allocation for Private 1169 Internets, RFC 1918, Feb 1996 1171 [RFC 2026] S. Bradner, The Internet Standards Process -- 1172 Revision 3, RFC 2026 Oct 1996 1174 [RFC 2119] S. Bradner. Key words for use in RFCs to Indicate 1175 Requirement Levels. RFC 2119, March 1997. 1177 [RFC 2131] R. Droms. Dynamic Host Configuration Protocol. RFC 1178 2131, March 1997. 1180 [RFC 2132] S. Alexander, R. Droms DHCP Options and BOOTP Vendor 1181 Extension RFC 2132, March 1997. 1183 [RFC 2316] S. Bellovin, Report of the IAB Security Architecture 1184 Workshop, RFC 2316, April 1998 1186 [RFC 2365] D. Meyer Administratively Scoped Multicast Address 1187 RFC 2365,July 1998. 1189 [RFC 2401] S. Kent, Security Architecture for the Internet 1190 Protocol, RFC 2401, Nov 1998 1192 [RFC 2411] R. Thayer, IP Security Document Roadmap, RFC 2411, 1193 Nov 1998 1195 [RFC 2461] T. Narten, E. Nordmark, W. Simpson Neighbor 1196 Discovery for IP Version 6 (IPv6) RFC 2461, December 1197 1998. 1199 [RFC 2462] S. Thomson, T. Narten IPv6 Address Autoconfiguration 1200 RFC 2462, December 1998. 1202 [RFC 2504] E. Guttman, Users' Security Handbook, RFC 2504, Feb. 1203 1999 1205 [RFC 2608] E. Guttman, C. Perkins, J. Veizades, and M. Day. 1206 Service Location Protocol version 2. RFC 2608, June 1207 1999. 1209 [RFC 2609] E. Guttman, C. Perkins, J. Kempf Service Templates 1210 and service: Schemes, RFC 2609, June 1999. 1212 [RFC 2730] iS. Hanna, B. Patel, M. Shah, Multicast Address 1213 Dynamic Client Allocation Protocol (MADCAP) draft- 1214 ietf-malloc-madcap-05.txt Dec 1999. 1216 [AutoMcast] D. Thaler, B. Adoba, Multicast Address Allocation in 1217 Auto-Configured Networks, draft-thaler-zeroconf- 1218 multicast-00.txt, Oct 1999. A work in progress 1220 [AutoNet] R. Troll Automatically Choosing an IP Address in an 1221 Ad-Hoc IPv4 Network draft-ietf-dhc-ipv4-autoconfig- 1222 04.txt April, 1999. A work in progress. 1224 [MCAST DNS] B. Woodcock, B. Manning Multicast Discovery of DNS 1225 Services draft-manning-multicast-dns-01.txt 1226 December, 1998. A work in progress. 1228 [MiniDHCP] Bernard Aboba, Auto-Addressing in Multi-segment 1229 Networks, draft-aboba-zeroconf-multi-00.txt, Oct 1230 1999. A work in progress. 1231 [SSDP] Y. Goland et al, Simple Service Discovery Protocol, 1232 draft-cai-ssdp-v1-02.txt, June 1999, A work in 1233 progress. 1235 [IPv6 WG] IP Next Generation WG, 1236 www.ietf.org/html.charters/ipngwg-charter.html. 1238 [DHC WG] Dynamic Host Configuration WG, 1239 www.ietf.org/html.charters/dhc-charter.html. 1241 [NAT WG] Network Address Translation WG, 1242 www.ietf.org/html.charters/nat-charter.html. 1244 [DNSEXT WG] DNS Extension WG, 1245 http://www.ietf.org/html.charters/dnsext-charter.html 1247 [MALLOC WG] Multicast Allocation WG Charter, 1248 www.ietf.org/html.charters/malloc-charter.html.