idnits 2.17.1 draft-ietf-zeroconf-reqts-04.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. == 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 101 has weird spacing: '...in this docum...' == Line 1145 has weird spacing: '...Network draft...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The zeroconf service discovery protocol requirements for printer manager scenario are: - The protocol SHOULD allow for registry to cache information about services and characteristics of services. - The ability for clients to extract data from the registry without knowledge that it is talking to a registry. - A registry MUST not be required for all services. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Zeroconf service discovery protocol requirements are: - The protocol MUST allow the client to discover a service via service identifier and/or service type. - The protocol SHOULD allow the client to discover a service by characteristics. - The protocol MUST allow the client to discovery a service by actively soliciting the service. - The protocol MUST allow the client to discover a service by the client passively listening for advertisements. - The protocol MUST allow clients to rediscover a service. - Discovery MUST be timely (within seconds) when a service comes on line. - The protocol SHOULD allow services that are no longer active to notify clients in a time (within seconds) manner. - A service discovery protocol itself MUST NOT require configuration. - The protocol MUST be independent from any particular service. -The protocol SHOULD allow for registry to cache information about services and characteristics of services. - The ability for clients to extract data from the registry without knowledge that it is talking to a registry. - A registry MUST not be required for all services. -- 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 (July 14, 2000) is 8680 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'STD 3' is defined on line 1070, but no explicit reference was found in the text == Unused Reference: 'STD 4' is defined on line 1073, but no explicit reference was found in the text == Unused Reference: 'RFC 1001' is defined on line 1076, but no explicit reference was found in the text == Unused Reference: 'RFC 1002' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'RFC 1034' is defined on line 1083, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 1086, but no explicit reference was found in the text == Unused Reference: 'RFC 1458' is defined on line 1089, but no explicit reference was found in the text == Unused Reference: 'RFC 1918' is defined on line 1092, but no explicit reference was found in the text == Unused Reference: 'RFC 2131' is defined on line 1101, but no explicit reference was found in the text == Unused Reference: 'RFC 2132' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: 'RFC 2316' is defined on line 1107, but no explicit reference was found in the text == Unused Reference: 'RFC 2365' is defined on line 1110, but no explicit reference was found in the text == Unused Reference: 'RFC 2401' is defined on line 1113, but no explicit reference was found in the text == Unused Reference: 'RFC 2411' is defined on line 1116, but no explicit reference was found in the text == Unused Reference: 'RFC 2461' is defined on line 1119, but no explicit reference was found in the text == Unused Reference: 'RFC 2462' is defined on line 1123, but no explicit reference was found in the text == Unused Reference: 'RFC 2504' is defined on line 1126, but no explicit reference was found in the text == Unused Reference: 'RFC 2608' is defined on line 1129, but no explicit reference was found in the text == Unused Reference: 'RFC 2609' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'RFC 2730' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: 'AutoMcast' is defined on line 1140, but no explicit reference was found in the text == Unused Reference: 'AutoNet' is defined on line 1144, but no explicit reference was found in the text == Unused Reference: 'MCAST DNS' is defined on line 1148, but no explicit reference was found in the text == Unused Reference: 'MiniDHCP' is defined on line 1152, but no explicit reference was found in the text == Unused Reference: 'SSDP' is defined on line 1156, but no explicit reference was found in the text == Unused Reference: 'IPv6 WG' is defined on line 1158, but no explicit reference was found in the text == Unused Reference: 'DHC WG' is defined on line 1161, but no explicit reference was found in the text == Unused Reference: 'NAT WG' is defined on line 1164, but no explicit reference was found in the text == Unused Reference: 'DNSEXT WG' is defined on line 1167, but no explicit reference was found in the text == Unused Reference: 'MALLOC WG' is defined on line 1170, but no explicit reference was found in the text -- Duplicate reference: RFC1034, mentioned in 'RFC 1035', was also mentioned in 'RFC 1034'. ** 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' -- Possible downref: Non-RFC (?) normative reference: 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 (~~), 41 warnings (==), 13 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 January 2001 July 14, 2000 7 Zeroconf Requirements 8 draft-ietf-zeroconf-reqts-04.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 states zeroconf protocol 52 requirements for four protocol areas; this document does not 53 define specific protocols. The four areas are: IP host 54 configuration, domain name to IP address resolution, IP multicast 55 address allocation, and service discovery. The requirements for 56 these four areas result from examining everyday use or scenarios 57 of these protocols. 59 Table of Contents 61 1 Introduction................................................2 62 1.1 Reading This Document.....................................3 63 1.2 Zeroconf Protocols........................................3 64 2 Scenarios & Requirements....................................7 65 2.1 IP Host Configuration.....................................8 66 2.2 Domain Name to IP Address Resolution Scenarios...........10 67 2.3 IP Multicast Address Allocation Scenarios................13 68 2.4 Service Discovery Scenarios..............................16 69 3 Security Considerations & Requirements.....................19 70 3.1 IP Host Configuration....................................19 71 3.2 Domain Name to IP Address Resolution.....................20 72 3.3 IP Multicast Address Allocation..........................20 73 3.4 Service Discovery........................................20 74 3.5 IPv6 Considerations......................................21 75 4 IANA Considerations........................................21 76 5 Full Copyright Statement...................................21 77 6 Acknowledgements...........................................21 78 7 References.................................................22 80 1 Introduction 82 This document presents requirements for zeroconf protocols in four 83 areas: IP host configuration, domain name to IP address 84 resolution, IP multicast address allocation, and service 85 discovery. Security issues and the transitions between a zeroconf 86 protocol and a non-zeroconf protocol are also discussed within 87 each protocol area. 89 The major sections in this document are the Introduction, 90 Scenarios & Requirements, and Security Considerations & 91 Requirements. The introduction provides the background 92 information, references, terms, and assumptions to ensure a clear 93 understanding of the subsequent sections. The Scenarios & 94 Requirements section walks through protocol scenarios and then 95 lists the requirements of the protocol needed to accomplish the 96 scenario. The Security section lists threats and security 97 requirements. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 100 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 101 in this document are to be interpreted as described in [RFC 102 2119]. 104 1.1 Reading This Document 106 Most of the document can be read selectively based on the reader's 107 protocol area of interest. To encourage this, much of the document 108 is organized around the four protocol areas: 109 - IP host configuration 110 - Domain name to IP address resolution 111 - IP multicast address allocation 112 - Service discovery 114 1.2 Zeroconf Protocols 116 Below are strict definitions of a zeroconf protocol and a non- 117 zeroconf protocol. Also discussed are the transitions between a 118 zeroconf protocol and non-Zeroconf. Finally, a section discusses 119 how protocols with a centralized server may be zeroconf protocols. 121 1.2.1 Definitions 123 A zeroconf protocol requires no user configuration. 125 A non-zeroconf protocol requires user configuration. 127 [Editor's Note: The definition of a ZC protocol is a key output of 128 this document. Be aware that the definition has changed from the 129 previous version of this document. This change prompted section 130 1.3.5 Centralized Servers. This editor's note will be removed in 131 the next version of this draft.] 133 1.2.2 Transitions 135 Transition is the act of determining when to change from using the 136 zeroconf protocol to the non-zeroconf protocol, or vice-versa. 137 Transition support is not required of a zeroconf protocol nor does 138 a device require transition support if the device supports the 139 zeroconf protocol. Below is a discussion of three possible 140 transitions that a host SHOULD consider when using a zeroconf 141 protocol. 143 The first transition is a zeroconf to non-zeroconf transition. 144 This type of transition may occur either if a host moves to a new 145 network that does not use a zeroconf protocol when the old network 146 used a zeroconf protocol. Or if the host stays on the same network 147 but a new server comes online within that network. For example, if 148 a DHCP server comes online after hosts are configured with a 149 zeroconf IP host configuration protocol then hosts MUST re- 150 configure with DHCP. 152 The second transition is the opposite of the first; it is a non- 153 zeroconf to zeroconf transition. This may occur if a host moves 154 between networks or when a server goes offline within a network. 156 The third transition occurs if a device moves from one network to 157 another network when both networks use a zeroconf protocol. For 158 example, if a person is using a laptop in her home network with a 159 zeroconf protocol, then she takes that laptop to her neighbor's 160 home network that uses the same zeroconf protocol: the laptop must 161 automatically adapt to the new network. 163 Another subtle example of this third of transition is if the 164 network topology changes significantly as when a bridge gets 165 installed between two existing networks. In this case, if the 166 networks are utilizing a zeroconf IP host configuration protocol, 167 the protocol SHOULD allow the hosts to detect addressing conflicts 168 and possibly reconfigure. 170 1.2.3 Coexistence 172 A zeroconf protocol in one area MUST be able to coexist with a 173 non-zeroconf protocol in another area. 175 To illustrate this point, suppose there are standard zeroconf and 176 non-zeroconf protocols for IP host configuration and domain name 177 to IP address resolution. 179 For IP host configuration, the zeroconf protocol is "protocol-A." 180 The non-zeroconf protocol is "protocol-B", supported by a fully 181 conformant "protocol-B" server. 183 For domain name to IP address resolution, the zeroconf protocol is 184 "protocol-C". The non-zeroconf protocol is "protocol-D" supported 185 by a fully conformant "protocol-D" server. 187 Within a single network, the IP host configuration zeroconf 188 protocol-A MUST be able to coexist with the domain name to IP 189 address resolution non-zeroconf protocol-D. 191 In contrast, zeroconf and non-zeroconf protocols from a single 192 area MUST NOT be able to coexist during normal operation. They MAY 193 coexist during a transition, but the coexistence period MUST be 194 minimal. 196 1.2.4 Scalability 198 Scalability is not of great concern because it is expected that 199 zeroconf protocols will operate in networks of limited size. In 200 addition, it is likely that as a network grows, the owners of that 201 network will migrate to using non-zeroconf protocols before 202 scalability becomes an issue. For this reason, this document 203 mentions little of scalability requirements. 205 1.2.5 Centralized Servers 207 This subsection illustrates how a protocol that takes advantage of 208 a centralized server may be a zeroconf protocol. This is 209 illustrated using DHCP in a home network. 211 Centralized servers such as DHCP servers are being deployed in 212 home networks to relieve user configuration. However, networks 213 accidentally operating with multiple DHCP servers present new 214 configuration challenges. Today's solution is for a person to 215 configure one of the DHCP servers to stop operating; since a user 216 must do something (turn off a DHCP server) this is a non-zeroconf 217 solution. 219 In order for a centralized server protocol to be zeroconf while 220 operating with multiple servers, there must be mechanisms to 221 ensure all clients use the appropriate server. Of course, these 222 mechanisms must operate without any user configuration. 224 1.2.6 IP Host Configuration 226 IP host configuration is the configuration of an interface on an 227 IP host, which always includes an IP address and sometimes an 228 netmask and default route. IP host configuration is required 229 before almost any IP communication can take place. 231 DHCP is the common IP host configuration solution deployed today. 232 Zeroconf IP host configuration schemes MUST peacefully coexistence 233 with DHCP. 235 The definitions needed for the IP host configuration scenarios 236 are: 238 IP subnet - a single logic IP network that may span multiple link 239 layer networks. 241 internet - multiple IP subnets connected by routers. 243 Network - general term that may apply to link layer, IP subnet, or 244 internet. 246 1.2.7 Domain name to IP address resolution 248 DNS is the common way to resolve names to IP addresses. Zeroconf 249 domain name to IP address resolution protocols MUST peacefully 250 coexistence with DNS. 252 It is assumed that sub-domain delegation is not done within the 253 zone that a zeroconf domain name to IP address resolution protocol 254 is performed. In other words, a zeroconf zone contains all of the 255 names in its domain. 257 In addition, it is assumed a zeroconf domain name to IP address 258 resolution protocol will only be used if a DNS server is not 259 present or a host is not configured with the IP address of a DNS 260 server. It is also assumed that TCP/IP networking connectivity to 261 other zones MAY exist and those other zones have DNS servers. 262 Furthermore, it is assumed that a special device or application 263 exists at the edge of these two zones and is able to convert 264 between the zeroconf and non-zeroconf domain name to IP address 265 resolution protocols. 267 1.2.8 IP Multicast Address Allocation 269 IP multicast is used to conserve bandwidth and reduce complexity 270 in the multicast source. MADCAP is the default IP multicast 271 address allocation protocol. Zeroconf IP multicast address 272 allocation protocols MUST peacefully coexist with MADCAP. 274 Zeroconf solutions are only concerned with IP multicast addresses 275 scoped as Local (i.e. 239.255.0.0/16), link-local, node-local, and 276 Single-source IP multicast addresses of any scope. It is assumed 277 that a boundary router (as described in RFC 2365) is present to 278 appropriately control multicast packets from entering and leaving 279 the scope boundaries. 281 1.2.9 Service Discovery 283 Service discovery protocols have proven to be critical to the 284 usability of networks. AppleTalk/NBP, NetBIOS/SMB and IPX/SAP have 285 improved the utility services from printing to gaming are easily 286 found on these networks. Service Location Protocol version 2 287 (SLPv2) is defined in Standards Track RFC 2608, and an Internet- 288 Draft defines Simple Service Discovery Protocols (SSDP). 290 Service discovery definitions are: 292 Process - A process is an implementation of an algorithm in 293 software, hardware, or a combination of software and hardware. 295 Registry - A process that acts as an intermediary between 296 discoverers and advertisers. Servers 'register' service 297 advertisements and other pertinent (e.g. authentication info, 298 announcement criteria) with registries, then the service may be 299 discovered from the registry instead of from a server. 301 Registry update - A message that contains updated registry 302 information. It may cause one or more registry entries to be 303 deleted, added, or modified. 305 Server - A process that offers services to clients. A server can 306 make its service(s) known to clients by means of a service 307 discovery protocol. 309 Service - A service is a set of processes that utilize a 310 particular protocol. Services range from printing to transferring 311 a file to providing on-line pizza order and delivery. 313 Service Advertisement Packet - An unsolicited packet issued by a 314 server or registry. The advertisement provides the service 315 identifier and possibly service characteristics. 317 Service Characteristics - Characteristics provide a finer 318 granularity of description to differentiate services beyond just 319 the service type. For example if the service type is printer, the 320 characteristics may be color, pages printed per second, location, 321 etc. 323 Service Discovery Protocol - A service discovery protocol enables 324 a client (or clients) to discover a server (or servers) of a 325 particular service. A service discovery protocol is an application 326 layer protocol that relies on network and transport protocol 327 layers. 329 Service Identifier - A service identifier allows clients, servers, 330 advertisers, discoverers, and registries to uniquely identify an 331 instance of a service. 333 Service Protocol - A service protocol is used between the client 334 and the server after service discovery is complete. 336 Service Solicitation - A request packet made by a client to obtain 337 a response packet that indicates a service is present. The 338 response may come from a service or a registry. 340 Service Type - A service type allows clients, servers, 341 advertisers, discoverers, and registries to uniquely identify a 342 type of service such as a printer service. 344 2 Scenarios & Requirements 346 This section lists zeroconf scenarios that lead to requirements 347 for protocols. There is a subsection for each of the four protocol 348 areas. Within each protocol area representative scenarios are 349 discussed and requirements are identified. It is possible to state 350 an endless number of scenarios but unless those scenarios yield 351 additional requirements, there is no point of discussing such 352 scenarios. Also, within each area is a summary of the requirements 353 and an IPv6 considerations section. 355 2.1 IP Host Configuration 357 DHCP is the non-zeroconf IP Host configuration protocol. The 358 problems preventing DHCP from being a zeroconf protocol are: the 359 DHCP server may not be present and if multiple DHCP servers are 360 present they may provide conflicting configuration. 362 The scenarios in this section are ping and bridge install. Since 363 DHCP is the non-zeroconf IP host configuration protocol, the 364 Zeroconf and non-Zeroconf Transitions section discusses 365 transitioning between zeroconf IP host configuration and DHCP. 367 2.1.1 Ping 369 Ping consists of one host sending an ICMP echo request to another 370 host, then the other host replying with an ICMP echo reply. Ping 371 has two sub-scenarios: ping to a host on local IP subnet and ping 372 to a host off the local IP subnet. 374 When sending a ping (or any other IP packet for that matter), a 375 host performs the AND operation on the netmask and the destination 376 IP address then compares that result with the result of an AND 377 operation on the host's IP address and netmask. 379 ((HostIPAddr & netmask) == (DestIPAddr & netmask)) 381 If the result of this compare is FALSE, then the host forwards the 382 packet to the default router because the destination address is 383 off the local IP subnet. If the result is TRUE, then the host 384 sends an ARP request to resolve the destination IP address to a 385 hardware address within the local IP subnet. 387 These steps are important to show the expected utilization and 388 values of a netmask and the default route. Specifically, the 389 values for the IP address, netmask, and default route within a 390 host must be chosen such that the following statements are true: 391 - All hosts on an IP subnet have a common netmask. 392 - When a host computes (HostIPAddr & netmask) the result is 393 identical for all hosts on a single IP subnet. 394 - When a host computes (HostIPAddr & ~netmask) (inverse netmask) 395 the result is unique for all hosts on an IP subnet. 396 - All hosts get a default route that is used for communication 397 with other IP hosts off the local subnet. 399 In addition IP subnets must somehow be unique on different IP 400 subnets within an internet over which the zeroconf IP host 401 configuration protocol is operating; this insures unique IP 402 addresses (regardless of the value of the host portion of the IP 403 address) across the entire internet. 405 The zeroconf IP host configuration protocol only defines packets 406 sent over a wire and the associated semantics. Here are zeroconf 407 IP host configuration protocol requirements to satisfy ping: 408 - The ability to determine the netmask for an IP subnet. 409 - The ability to determine the default route for an IP subnet. 410 - The ability to have unique IP addresses within an IP subnet. 411 - The ability to have unique IP subnets within an internet. 413 2.1.2 Bridge Installed 415 This scenario starts with two completely operational standalone 416 networks in which IP host configuration was completed with 417 zeroconf IP host configuration protocols. These two networks 418 become one after a bridge is installed between them. 420 This creates two problems. First, hosts may have duplicate IP 421 addresses. Second, there may be competing netmask and default 422 route values that disrupt communication. 424 The bridge scenario results in the following protocol 425 requirements: 426 - The ability to avoid or resolve contention among netmasks. 427 - The ability to avoid or resolve contention among default routes. 428 - The ability to avoid or resolve duplicate IP addresses within a 429 subnet. 430 - The ability to avoid or resolve duplicate IP subnets within an 431 internet. 433 2.1.3 Zeroconf and non-Zeroconf Transitions 435 DHCP is the non-zeroconf IP Host configuration protocol. Here are 436 examples of intermittent connectivity between zeroconf hosts and 437 DHCP servers that show the need for IP host configuration 438 transitions: 439 - DHCP servers in a PC that gets regularly power-cycled. 440 - A zeroconf capable device introduced into a network that has a 441 DHCP server. 442 - A zeroconf capable device removed from a network that has a DHCP 443 server. 445 These scenarios require the periodic actions as well as specific 446 actions at startup. The action is the same whether it be periodic 447 or at startup. The action is an attempt to discover a DHCP server. 448 If the DHCP server is discovered the host uses DHCP, otherwise the 449 host uses the zeroconf IP host configuration protocol. 451 IP host configuration zeroconf and non-zeroconf transitions 452 necessitate the following protocol requirements: 453 - The ability to detect the presence or absence of a DHCP server 454 at startup of a device and periodically after a devices starts. 456 2.1.4 Requirements Summary 458 Zeroconf IP host configuration protocol requirements are: 459 - The ability to determine the netmask for an IP subnet. 460 - The ability to determine the default route for an IP subnet. 461 - The ability to have unique IP addresses within an IP subnet. 462 - The ability to have unique IP subnets within an internet. 463 - The ability to avoid or resolve contention among netmasks. 464 - The ability to avoid or resolve contention among default routes. 465 - The ability to avoid or resolve duplicate IP addresses within a 466 subnet. 467 - The ability to avoid or resolve duplicate IP subnets within an 468 internet. 469 - The ability to detect the presence or absence of a DHCP server 470 at startup of a device and periodically after a devices starts. 472 2.1.5 IPv6 Considerations 474 IPv6 allows a host to select an appropriate IP address, netmask, 475 and find a default route, thus if a network is using IPv6, there 476 already exists a zeroconf IP host configuration solution. 478 2.2 Domain Name to IP Address Resolution Scenarios 480 DNS is the non-zeroconf domain name to IP address resolution 481 protocol. The problems with DNS preventing DNS from being a 482 zeroconf protocol are: user configuration of the IP address of a 483 DNS server in a client machine, user entering DNS resource records 484 in the DNS server, devices having unique names, and a DNS server 485 may not be accessible. 487 The scenarios in this section are web browsing, domain name 488 selection, and bridge install. Additional, transition scenarios 489 list requirements for transitioning between using DNS and using 490 the zeroconf domain name to IP address resolution protocol. 492 2.2.1 Web Browsing 494 Users browsing the WEB typically enter the name of a web server. 495 This name MUST be resolved to an IP address before any actual web 496 browsing occurs. The web server may be within the same domain as 497 the web browser or within a different domain. 499 The zeroconf domain name to IP address resolution protocol MUST 500 resolve a name to an IP address without a host being configured 501 with the IP address of a DNS server. This includes names within 502 the same domain as the host that is using the zeroconf protocol as 503 well as names within other domains. 505 The domain name to IP address resolution protocol requirements for 506 web browsing are: 507 - The ability to resolve a name to an IP address without the user 508 configuring the IP address of a DNS server. 509 - The user must not be required to enter a mapping of a domain 510 name to IP address into the DNS database. 512 2.2.2 Domain Name Selection 514 A domain name consists of a host name and the name of the domain 515 itself. A host has control over its host name, but some other 516 entity configures or determines the name of the domain. In fact 517 the name of the domain may not be available. A protocol is needed 518 to maintain unique host portions of a domain name and to possibly 519 learn the name of the domain. 521 Note that it may be desirable to have duplicate host names. Such 522 cases include server farms with load-balanced servers meant to 523 provide consistent response times during periods of high volume. 525 Here are the requirements for a name selection protocol: 526 - The ability to ensure a unique host name (assuming unique names 527 are desired) is selected. 528 - The ability to learn the name of the domain (assuming the name 529 of the domain is known). 531 2.2.3 Bridge Install 533 This scenario starts with two completely operational standalone 534 networks. After name selection is complete, these two networks 535 become one when a bridge is installed between the networks. 537 The bridge scenario results in the following protocol 538 requirements: 539 - The ability to periodically ensure the uniqueness of a selected 540 host name. 542 2.2.4 Zeroconf and non-Zeroconf Transitions 544 DNS is the non-zeroconf domain name to IP address resolution 545 protocol. There are four transitional cases to consider. Note that 546 unless a host is configured with the IP address of the DNS server, 547 none of these transitions can occur. 549 The first is a zeroconf to non-zeroconf transition that occurs 550 when the host is first configured with the IP address of the DNS 551 server and the host can actually reach the DNS server (i.e. the 552 DNS server responds to requests). 554 The second is a non-zeroconf to zeroconf transition that occurs 555 when for some reason the DNS server can no longer be reached. One 556 such reason may be that the host is moved to a network without 557 connectivity to the DNS server. In this case the zeroconf domain 558 name to IP address resolution protocol MUST be invoked. 560 The third transition is from zeroconf back to non-zeroconf. This 561 occurs when the DNS server becomes reachable again. Following the 562 above example, the host is moved back to the original network with 563 connectivity to the DNS server. 565 The final transition is a non-zeroconf to zeroconf transition that 566 occurs when the IP address of the DNS server is removed from the 567 host. 569 These transitions generate the following requirements: 570 - The ability to detect the presences or absence of DNS server 571 (applies only if the host is configured with the IP address of 572 the DNS server). The host must use DNS when the DNS server is 573 present and zeroconf domain name to IP address resolution when 574 the DNS server is not present. 576 2.2.5 Requirements Summary 578 The domain name to IP address resolution protocol requirements 579 are: 580 - The ability to resolve a name to an IP address without the user 581 configuring the IP address of a DNS server. This includes names 582 within the same domain as the requesting host as well as names 583 outside the domain as the requesting host. 584 - The user must not be required to enter a mapping of a domain 585 name to IP address. 586 - The ability to ensure a unique host name (assuming unique names 587 are desired) is selected. 588 - The ability to learn the name of the domain (assuming the name 589 of the domain is known). 590 - The ability to periodically ensure the uniqueness of a selected 591 host name. 592 - The ability to detect the presences or absence of DNS server 593 (applies only if the host is configured with the IP address of 594 the DNS server). The host must use DNS when the DNS server is 595 present and zeroconf domain name to IP address resolution when 596 the DNS server is not present. 598 2.2.6 IPv6 Considerations 599 Domain name to IP address resolution protocols has no zeroconf 600 related differences for IPv4 and IPv6. 602 2.3 IP Multicast Address Allocation Scenarios 604 MADCAP is the non-zeroconf IP Multicast Address Allocation 605 protocol. The problems preventing MADCAP from being a zeroconf 606 protocol are: the MADCAP server may not be present and if multiple 607 MADCAP servers are present they may provide conflicting 608 configuration. 610 All IP multicast addresses allocated are from the scopes of Local 611 (i.e. 239.255.0.0/16), link-local, node-local, and Single-source 612 IP multicast addresses of any scope. Descriptions of "Scope 613 Enumeration" and "Allocate Node-scoped or Single-Source Global IP 614 multicast address" do not result in requirements but do provide 615 important information about IP multicast operations. The scenarios 616 of "Allocate Link-scoped or Local-Scope IP multicast", "Allocate 617 IP Multicast Address Used by Multiple Sources", then the 618 transitions between zeroconf and MADCAP generate protocol 619 requirements. 621 2.3.1 Scope Enumeration 623 Applications that leave the choice of scope up to the user require 624 the ability to enumerate what scopes the host is within [RFC 625 2771]. 627 In addition, services that are assigned relative addresses [RFC 628 2365] require the ability to enumerate what scopes the host is 629 within, then a host is able to apply the relative address to a 630 scope. 632 When enumerating scopes, the following scopes may be assumed to 633 exist in all cases (assuming well-known ranges have been reserved 634 by IANA). 635 - Node-Local 636 - Link-Local 637 - Local (i.e., the Zeroconf area) 638 - Single-source global 640 The zeroconf IP multicast address allocation protocol requirements 641 are: 642 - The ability for a host to obtain the set of scope names, for all 643 scopes it is within. 644 - The ability for a host able to obtain the set of address ranges 645 for all scopes it is within. 647 2.3.2 Allocate Node-scoped or Single-Source Global IP multicast 648 address 650 Each host is always responsible for allocating its own Node-scoped 651 and Single-source Global multicast addresses, regardless of 652 whether it is use of zeroconf protocols since there is no 653 coordination between devices for such allocation, no protocol is 654 involved, and there are no protocol requirements. 656 Allocating (global) single-source addresses is only possible if 657 the host has already acquired a global unicast IP address. 659 To date, no range has been reserved for dynamic allocation of 660 Single-source addresses in IPv6. Hence, until such a range is 661 reserved, dynamic allocation of Single-source addresses applies 662 only to IPv4. 664 2.3.3 Allocate Link-scoped or Local-Scope IP multicast address 666 Address allocation at the Link and larger scopes requires 667 coordination to avoid address collisions. To allocate an address, 668 the host specifies a given scope, the number of addresses it 669 desires, and the lifetime for which it desires. 671 To date, no range has been reserved for dynamic allocation of 672 Link-scoped addresses in IPv4. Hence, unless such a range is 673 reserved, dynamic allocation of Link-scoped addresses applies only 674 to IPv6. 676 Collision detection must span the entire Link for Link-scope 677 allocations, and must span the entire locally scoped internet for 678 Local-scope allocations. The protocol should include the ability 679 for a host to choose addresses, determine if they are in use, and 680 choose different addresses if so. 682 The collision detection protocol must become active at various 683 times such as when previously disconnected yet operational 684 networks now become connected by the installation of a router or 685 bridge. 687 The zeroconf IP multicast address allocation protocol requirements 688 are: 689 - The ability for a host to select a multicast address with a 690 given scope and lifetime. 691 - The ability for a host to determine if the address has been 692 allocated by another host. 693 - The ability for a host to defend the addresses it allocates. 694 - The ability for a host to determine if another host has 695 allocated an address that has been allocated by itself; this 696 SHOULD be done periodically. 698 - The protocol MUST be routable to ensure it spans the entire 699 local scope. 701 2.3.4 Multiple Source 703 An intercom system inside a home is an example of a multiple 704 source IP multicast application. In this type of application, 705 several sources may be sending packets destined to the same IP 706 multicast address. 708 Here, the first source that needs the IP address MUST allocate the 709 address, yet it may not be the host that deallocates the multicast 710 address. This is because the first source may leave the multicast 711 group before all the other sources stop sending packets to that IP 712 multicast address. This requires, the last source using the IP 713 multicast address to deallocate the IP multicast address after it 714 is done sending. 716 The zeroconf IP multicast address allocation protocol requirements 717 are: 718 - The ability for the last host acting as a source to deallocate 719 the IP multicast address. 721 2.3.5 Zeroconf and non-Zeroconf Transitions 723 MADCAP is the non-zeroconf IP multicast address allocation 724 protocol. Hosts MUST be able to transition between MADCAP and the 725 zeroconf IP multicast address allocation protocol by detecting (or 726 not detecting) the presences of a MADCAP server. 728 If MADCAP is detected while using zeroconf IP multicast address 729 allocation, the host must start utilizing MADCAP. If MADCAP is no 730 longer detected while using MADCAP, the host must start utilizing 731 the zeroconf IP multicast address allocation protocol. 733 The transition requirements are: 734 - The ability to detect the presence or absence of a MADCAP server 735 at startup of a device and periodically after a device starts. 737 2.3.6 Requirements Summary 739 Zeroconf IP multicast address allocation protocol requirements 740 are: 741 - The ability for a host to obtain the set of scope names, for all 742 scopes it is within. 743 - The ability for a host able to obtain the set of address ranges 744 for all scopes it is within. 745 - The ability for a host to select a multicast address with a 746 given scope and lifetime. 748 - The ability for a host to determine if the address has been 749 allocated by another host. 750 - The ability for a host to defend the addresses it allocates. 751 - The ability for a host to determine if another host has 752 allocated an address that has been allocated by itself; this 753 SHOULD be done periodically. 754 - The protocol MUST be routable to ensure it spans the entire 755 local scope. 756 - The ability for the last host acting as a source to deallocate 757 the IP multicast address. 758 - The ability to detect the presence or absence of a MADCAP server 759 at startup of a device and periodically after a device starts. 761 2.3.7 IPv6 Considerations 763 To date, no range has been reserved for dynamic allocation of 764 Single-source addresses in IPv6. Hence, until such a range is 765 reserved, dynamic allocation of Single-source addresses applies 766 only to IPv4. 768 To date, no range has been reserved for dynamic allocation of 769 Link-scoped addresses in IPv4. Hence, unless such a range is 770 reserved, dynamic allocation of Link-scoped addresses applies only 771 to IPv6. 773 2.4 Service Discovery Scenarios 775 As stated earlier, there is no non-zeroconf service discovery 776 protocol, thus there are no particular zeroconf problems with an 777 zeroconf protocol. In addition, there are no zeroconf to non- 778 zeroconf transition scenarios. 780 The scenarios are the discovery of a simple printer service and 781 the discovery of a printer manager that consolidates many printer 782 services. 784 2.4.1 Printer Service 786 Networked enabled printers allow various networked clients to 787 submit print jobs. A service discovery protocol MUST allow a 788 printing client to discover the printer service. This requires a 789 service type as well as a service identifier to distinguish 790 instances of a single service type. 792 Printers vary in their characteristics such as location, status, 793 dots per inch, drivers, etc. Discovering these characteristics 794 SHOULD be part of the service discovery protocol. Some service 795 specific protocols allow the client and server to negotiate the 796 use of these characteristics after the service is found; thus, 797 alleviating the need for the service discovery protocol to 798 discover by characteristic. However, characteristic discovery 799 SHOULD be part of the service discovery protocol for those 800 services without capability negotiation. 802 Discovery MUST be possible by either the client actively 803 soliciting the service or by the service advertising then the 804 client passively listening for the advertisements. Once a client 805 finds the printer, it can utilize different printing protocols 806 such as raw tcp, lpd, and ipp. 808 Within a short number of seconds after activating a print server, 809 a user who is actively browsing for a printer MUST be able to see 810 the device appear in a browser window, or a user application such 811 as a spreadsheet MUST be able to begin using the print service. 812 This requires the service discovery to be timely. 814 In the case of a printer service, a printer may be temporarily 815 taken off-line for repair or everyday maintenance. This requires 816 clients to be able to rediscover a service. 818 The zeroconf service discovery protocol requirements for this 819 scenario are: 820 - The protocol MUST allow the client to discover a service via 821 service identifier and/or service type. 822 - The protocol SHOULD allow the client to discover a service by 823 characteristics. 824 - The protocol MUST allow the client to discovery a service by 825 actively soliciting the service. 826 - The protocol MUST allow the client to discover a service by the 827 client passively listening for advertisements. 828 - The protocol MUST allow clients to rediscover a service. 829 - Discovery MUST be timely (within seconds) when a service comes 830 on line. 831 - The protocol SHOULD allow services that are no longer active to 832 notify clients in a time (within seconds) manner. 833 - A service discovery protocol itself MUST NOT require 834 configuration. 835 - The protocol MUST be independent from any particular service. 837 2.4.2 Printer Manager 839 A printer manager acts as a proxy to various printers. A printer 840 manager improves scalability by providing a single location from 841 which clients can find all printers. 843 In addition, a printer manager provides an evolutionary path for 844 service discovery deployment. For example, if an existing printer 845 does not support the zeroconf service discovery protocol, the 846 printer manager can use a legacy printer specific protocol to 847 learn the existence and characteristics of a printer then expose 848 that printer and its characteristics through the zeroconf service 849 discovery protocol. This allows new printer clients that support 850 the service discovery protocol to discover legacy printers that do 851 not support the zeroconf service discovery protocol. 853 A print manager requires a registry to cache information about 854 services and characteristics of services. Clients MUST be able to 855 extract data from the registry without knowledge that they are 856 talking to a registry. In other words, the client and server sides 857 of the service discovery protocol MUST NOT be any different 858 whether a registry is involved or not. Registry updates that 859 maintain the registry are required of the service discovery 860 protocol but are optionally implemented for a particular service; 861 this allows legacy protocols or the zeroconf service discovery 862 protocol to update and maintain the registry. 864 The zeroconf service discovery protocol requirements for printer 865 manager scenario are: 866 - The protocol SHOULD allow for registry to cache information 867 about services and characteristics of services. 868 - The ability for clients to extract data from the registry 869 without knowledge that it is talking to a registry. 870 - A registry MUST not be required for all services. 872 2.4.3 Requirements Summary 874 Zeroconf service discovery protocol requirements are: 875 - The protocol MUST allow the client to discover a service via 876 service identifier and/or service type. 877 - The protocol SHOULD allow the client to discover a service by 878 characteristics. 879 - The protocol MUST allow the client to discovery a service by 880 actively soliciting the service. 881 - The protocol MUST allow the client to discover a service by the 882 client passively listening for advertisements. 883 - The protocol MUST allow clients to rediscover a service. 884 - Discovery MUST be timely (within seconds) when a service comes 885 on line. 886 - The protocol SHOULD allow services that are no longer active to 887 notify clients in a time (within seconds) manner. 888 - A service discovery protocol itself MUST NOT require 889 configuration. 890 - The protocol MUST be independent from any particular service. - 891 The protocol SHOULD allow for registry to cache information 892 about services and characteristics of services. 893 - The ability for clients to extract data from the registry 894 without knowledge that it is talking to a registry. 895 - A registry MUST not be required for all services. 897 2.4.4 IPv6 Considerations 899 Service discovery protocols have no zeroconf related differences 900 for IPv4 and IPv6. 902 3 Security Considerations & Requirements 904 By definition security requires configuration. Security examples 905 include a configured key for payload encryption, user entered 906 passwords for conditional access, and an administrator configures 907 port mappings to enable a protocol to traverse a firewall. The 908 configuration required by security is in direct conflict with the 909 design goals of zeroconf protocols; however, security requirements 910 take precedence over zeroconf protocol design goals. 912 Given this reality, this section focuses on the minimal 913 configuration necessary to make zeroconf protocols secure. In 914 addition, this section describes types of general threats and how 915 those general threats apply to each protocol area. 917 The general threats are: 919 Hoarding: Hosts claim all available resources, whether they plan 920 to use them or not. This is a form of denial of service attack. 922 Masquerading: Hosts can respond to requests that they should not 923 so they can masquerade as another host. 925 Antagonistic Server: A server could offer support for a critical 926 service but intentionally misconfigure hosts on the network. 928 3.1 IP Host Configuration 930 Threats include: 931 - A host could hoard IP addresses. 933 If secure zeroconf IP host configuration is required, all hosts 934 MUST be certifiable as valid participants. In addition, a host 935 MUST be configured with some security information. Furthermore, 936 some security information must be part of every zeroconf IP host 937 configuration packet. 939 Here is an example to illustrate: All hosts are registered as 940 valid security participants by the manufactures before the product 941 ships. In addition the product is shipped with a private key. 942 Before the secure device communicates with another secure device 943 it gets the other device's registered info, then submits that 944 registered info to the registration authority to get the devices 945 public key. Of course this request is encrypted. From that point 946 on all packets are encrypted using a public key and a private key. 948 3.2 Domain Name to IP Address Resolution 950 Potential threats include: 951 - A host could masquerade by responding to names requests 952 illegitimately. 953 - A host could hoard names by responding to all 'claim' requests. 955 Hosts MUST be able to be configured to use a zeroconf protocol for 956 domain name to IP address resolution securely. For example, a 957 'reply' from the resolution protocol could be accompanied by 958 a 'signature' that could be verified before being accepted. 959 The security configuration would have to provide the server 960 portion of the protocol with the data needed to produce a 961 'signature' that could only be produced if in possession of the 962 configuration data. 964 3.3 IP Multicast Address Allocation 966 Potential threats include: 967 - A host could hoard multicast addresses by denying others the 968 ability to obtain them. 969 - A host could snoop to learn all used IP multicast addresses in 970 use then reconfigure the border router to allow IP multicast 971 data to go beyond the desired boundary. 973 Hosts MUST be able to be configured to use a zeroconf protocol for 974 multicast address allocation securely. For example, a claim and 975 defend protocol used for multicast address allocation would have 976 to include security data with all messages. A host in the 977 zeroconf network could verify that another host's claim was 978 legitimate or not. 980 3.4 Service Discovery 982 Potential threats include: 983 - Servers could masquerade by responding to service discovery 984 requests that they shouldn't respond to. 985 - A host could pose as an antagonistic service discovery 986 'infrastructure element.' Some service discovery protocols 987 offer a 'registry', 'directory', 'proxy' or other 988 infrastructure element for scalability. 990 The service discovery protocol MUST provide mechanisms that allow 991 a client to determine if both the service it discovers and the 992 service discovery protocol infrastructure it uses to discover 993 services are 'legitimate.' 995 The service discovery protocol MUST provide mechanisms that allow 996 a client to determine if both the service it discovers and the 997 service discovery protocol infrastructure it uses to discover 998 services are 'legitimate.' 1000 3.5 IPv6 Considerations 1002 IPv6 has built in security, thus if a network is using IPv6, there 1003 already exists a security solution. 1005 4 IANA Considerations 1007 There are no known IANA considerations arising from this document. 1009 5 Full Copyright Statement 1011 Copyright (C) The Internet Society (2000). All Rights Reserved. 1013 This document and translations of it may be copied and furnished 1014 to others, and derivative works that comment on or otherwise 1015 explain it or assist in its implementation may be prepared, 1016 copied, published and distributed, in whole or in part, without 1017 restriction of any kind, provided that the above copyright notice 1018 and this paragraph are included on all such copies and derivative 1019 works. However, this document itself may not be modified in any 1020 way, such as by removing the copyright notice or references to the 1021 Internet Society or other Internet organizations, except as needed 1022 for the purpose of developing Internet standards in which case the 1023 procedures for copyrights defined in the Internet Standards 1024 process must be followed, or as required to translate it into 1025 languages other than English. 1027 The limited permissions granted above are perpetual and will not 1028 be revoked by the Internet Society or its successors or assigns. 1030 This document and the information contained herein is provided on 1031 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1032 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1033 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1034 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1035 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1036 PURPOSE." 1038 6 Acknowledgements 1040 Thanks to Peter Ford and Stuart Cheshire for hosting the first BOF 1041 that was the catalyst to forming the Zeroconf Working Group, which 1042 is responsible for this document. 1044 Thanks to Erik Guttman and Stuart Cheshire for forming and 1045 chairing the Zeroconf Working Group. 1047 Thanks to Erik Guttman for providing key input to the service 1048 discovery and the security sections. 1050 Thanks to Dave Thaler for providing key input to the IP multicast 1051 address allocation sections. 1053 Additional recognition goes the following people for their 1054 influential contributions to this document and its predecessors: 1055 Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob 1056 Quinn, John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl 1057 Auerbach, Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland, 1058 and Bernard Aboba. 1060 Editor: 1062 Myron Hattig 1063 Intel Corporation 1064 3585 SW 198th Avenue 1065 Hillsboro, OR 97124 1066 myron.hattig@intel.com 1068 7 References 1070 [STD 3] R. Braden Requirements for Internet Hosts -- 1071 Communication Layers RFC 1122, STD 3, October 1989 1073 [STD 4] R. Braden, Requirements for Internet Hosts -- 1074 Application and Support RFC 1123, STD 4 October 1989 1076 [RFC 1001] PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP 1077 TRANSPORT: CONCEPTS AND METHODS, RFC 1001 March, 1987 1079 [RFC 1002] PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP 1080 TRANSPORT: DETAILED SPECIFICATIONS, RFC 1002, March 1081 1987 1083 [RFC 1034] P. Mockapetris, Domain Names - Concepts and 1084 Facilities, RFC 1034, November 1987 1086 [RFC 1035] P. Mockapetris, Domain Names - Implementations and 1087 Specifications, RFC 1034, November 1987 1089 [RFC 1458] R. Braudes, Requirements for Multicast Protocols, RFC 1090 1458, May 1993 1092 [RFC 1918] D. Karrenberg, et al, Address Allocation for Private 1093 Internets, RFC 1918, Feb 1996 1095 [RFC 2026] S. Bradner, The Internet Standards Process -- 1096 Revision 3, RFC 2026 Oct 1996 1098 [RFC 2119] S. Bradner. Key words for use in RFCs to Indicate 1099 Requirement Levels. RFC 2119, March 1997. 1101 [RFC 2131] R. Droms. Dynamic Host Configuration Protocol. RFC 1102 2131, March 1997. 1104 [RFC 2132] S. Alexander, R. Droms DHCP Options and BOOTP Vendor 1105 Extension RFC 2132, March 1997. 1107 [RFC 2316] S. Bellovin, Report of the IAB Security Architecture 1108 Workshop, RFC 2316, April 1998 1110 [RFC 2365] D. Meyer Administratively Scoped Multicast Address 1111 RFC 2365,July 1998. 1113 [RFC 2401] S. Kent, Security Architecture for the Internet 1114 Protocol, RFC 2401, Nov 1998 1116 [RFC 2411] R. Thayer, IP Security Document Roadmap, RFC 2411, 1117 Nov 1998 1119 [RFC 2461] T. Narten, E. Nordmark, W. Simpson Neighbor 1120 Discovery for IP Version 6 (IPv6) RFC 2461, December 1121 1998. 1123 [RFC 2462] S. Thomson, T. Narten IPv6 Address Autoconfiguration 1124 RFC 2462, December 1998. 1126 [RFC 2504] E. Guttman, Users' Security Handbook, RFC 2504, Feb. 1127 1999 1129 [RFC 2608] E. Guttman, C. Perkins, J. Veizades, and M. Day. 1130 Service Location Protocol version 2. RFC 2608, June 1131 1999. 1133 [RFC 2609] E. Guttman, C. Perkins, J. Kempf Service Templates 1134 and service: Schemes, RFC 2609, June 1999. 1136 [RFC 2730] iS. Hanna, B. Patel, M. Shah, Multicast Address 1137 Dynamic Client Allocation Protocol (MADCAP) draft- 1138 ietf-malloc-madcap-05.txt Dec 1999. 1140 [AutoMcast] D. Thaler, B. Adoba, Multicast Address Allocation in 1141 Auto-Configured Networks, draft-thaler-zeroconf- 1142 multicast-00.txt, Oct 1999. A work in progress 1144 [AutoNet] R. Troll Automatically Choosing an IP Address in an 1145 Ad-Hoc IPv4 Network draft-ietf-dhc-ipv4-autoconfig- 1146 04.txt April, 1999. A work in progress. 1148 [MCAST DNS] B. Woodcock, B. Manning Multicast Discovery of DNS 1149 Services draft-manning-multicast-dns-01.txt 1150 December, 1998. A work in progress. 1152 [MiniDHCP] Bernard Aboba, Auto-Addressing in Multi-segment 1153 Networks, draft-aboba-zeroconf-multi-00.txt, Oct 1154 1999. A work in progress. 1156 [SSDP] www.upnp.org 1158 [IPv6 WG] IP Next Generation WG, 1159 www.ietf.org/html.charters/ipngwg-charter.html. 1161 [DHC WG] Dynamic Host Configuration WG, 1162 www.ietf.org/html.charters/dhc-charter.html. 1164 [NAT WG] Network Address Translation WG, 1165 www.ietf.org/html.charters/nat-charter.html. 1167 [DNSEXT WG] DNS Extension WG, 1168 http://www.ietf.org/html.charters/dnsext-charter.html 1170 [MALLOC WG] Multicast Allocation WG Charter, 1171 www.ietf.org/html.charters/malloc-charter.html.