idnits 2.17.1 draft-ietf-dhc-ipv4-autoconfig-05.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2, 2000) is 8792 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) ** Obsolete normative reference: RFC 2462 (ref. 'IPv6SAC') (Obsoleted by RFC 4862) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Dynamic Host Configuration WG Ryan Troll 2 Document: draft-ietf-dhc-ipv4-autoconfig-05.txt Excite@Home 3 Expires September 7, 2000 March 2, 2000 5 Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are work- 13 ing documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also dis- 15 tribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet- Drafts as refer- 20 ence material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Distribution of this memo is unlimited. 30 Abstract 32 With operating systems appearing in more and more devices, as well 33 as computers appearing in more and more aspects of everyday life, 34 communication between networked devices is increasingly important. 35 The communication mechanism between these devices must be able to 36 not only support the office LAN environment, but must also scale to 37 larger WANS and the internet. 39 This draft describes a method by which a host may automatically give 40 itself a link-local IPv4 address, so that it will be able to use IP 41 applications in the absence of an IP address management mechanism, 42 such as DHCP. This mechanism is in use today by a few operating 43 systems, and additional information on those implementations is also 44 provided. 46 1. Introduction 48 Now that networked applications are becoming more prevalent, operat- 49 ing systems are migrating towards more scalable network protocols 50 such as IP, allowing them to work in all sizes of environments. 52 Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year] 54 However, there is a price to pay for this migration -- IP requires 55 configuration that other protocols (IPX, Appletalk) do not require. 57 Dynamic creation of usable ad-hoc networks is very useful when there 58 are only a few machines on the entire network. (For example, a 59 dentist's office may only have a couple of machines.) In order to 60 allow a site such as this to use IP, the machines must each be con- 61 figured with an IP address. OS's wish to retain the minimal confi- 62 guration that was necessary under their non-IP network stacks. 64 Dynamic configuration protocols such as DHCP [DHCP] allow a site 65 administrator to take care of the network configuration for a 66 machine remotely. By requesting network parameters via DHCP, the 67 site administrator may provide all information necessary without the 68 host's owner having to do anything. However, not all sites have a 69 central administrator to take care of this. 71 To accommodate unmanaged networks, the OS may decide to intelli- 72 gently choose an IP address for itself. These addresses are only 73 valid for the local network. 75 This document describes a method by which an OS may determine 76 whether or not to autoconfigure itself an IP address, as well as how 77 to inter-operate cleanly with an existing managed infrastructure, 78 allowing a host to easily move between managed and unmanaged network 79 segments. 81 1.1. Conventions Used in the Document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [KEYWORDS]. 87 1.2. Terminology 89 Site Administrator 90 A Site Administrator is the person or organiza- 91 tion responsible for handing out IP addresses to 92 client machines. 94 DHCP Client A DHCP Client is an Internet host using DHCP to 95 obtain configuration parameters such as a network 96 address. 98 DHCP Server A DHCP Server is an Internet host that returns 99 configuration parameters to DHCP Clients. 101 Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year] 103 1.3. Usage Clarification 105 This document describes a method by which a host may automatically 106 choose an IPv4 address in the absence of a central service to main- 107 tain and hand out addresses. This is not designed to replace this 108 functionality, but to basicly provide it in small networks. 110 This SHOULD NOT be used for large-scale networks. As more and more 111 machines begin to use this mechanism on a network, startup times for 112 these machines will begin to increase, as the chance of collisions 113 will rise. 115 Addresses allocated by this mechanism MUST NOT be routed by any net- 116 work device. The addresses are designed to be link local addresses. 117 Link local address are to be, by definition, restricted to the local 118 network segment. Allocation of link-local addresses in an IPv6 net- 119 work is described in [IPv6SAC]. 121 Finally, it should be noted that this functionality is designed to 122 work on a host that is running a DHCP Client. Hosts that are not 123 running a DHCP Client are not considered in this draft, and MUST NOT 124 attempt to use these mechanisms to configure an IP address, as these 125 no-dhcp-client hosts will not interoperate with the existing infras- 126 tructure correctly. (This mechanism relies on the DHCP Server for 127 some information, and if a host can not receive this information, it 128 will not be fully informed.) 130 2. To Choose or Not To Choose 132 The first thing an Internet host should do is attempt to get an 133 administratively assigned address using DHCP. Only after the DHCP 134 process fails should a host use the methods later for autoconfigura- 135 tion. 137 2.1. Obtaining an Address via DHCP 139 A host begins by requesting an IP address via DHCP [DHCP]. This is 140 done by sending out a DHCPDISCOVER message, with various tags set 141 indicating what options the DHCP Client would like to receive infor- 142 mation for [DHCPOPT]. The DHCP Client SHOULD also send the DHCP 143 AutoConfigure option described in [DHCPAC]. 145 According to [DHCP], Section 4.4.1, the amount of time over which a 146 DHCP Client should listen for DHCPOFFERS is implementation depen- 147 dant. During this time, if a DHCPOFFER is received, network confi- 148 guration MUST occur as described in [DHCP] and [DHCPAC]. 150 If, during this time, no valid DHCPOFFERS are received, the DHCP 152 Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year] 154 Client is free to autoconfigure an IP address according to section 3 155 of this document. 157 2.2. Rebinding an Existing IP Address 159 If the DHCP Client already has an existing IP address, it MUST fol- 160 low the instructions outlined in [DHCP]. If the client winds up 161 back in the INIT state, refer to section 2.1 of this document. 163 3. Choosing an IP Address 165 Once a DHCP Client has determined it must auto-configure an IP 166 address, it chooses an address. The algorithm for choosing an 167 address is implementation dependant. The address range to use MUST 168 be "169.254/16", which is registered with the IANA as the LINKLOCAL 169 net. 171 If choosing an address in this range, the DHCP Client MUST NOT use 172 the first 256 or the last 256, as these are reserved for future use. 174 When an address is chosen, the DHCP Client MUST test to see if the 175 address is already in use. If the network address appears to be in 176 use, the client MUST choose another address, and try again. The 177 client MUST keep choosing addresses until it either finds one, or it 178 has tried more then the autoconfig-retry count. The autoconfig- 179 retry count is implementation specific, and should be based on the 180 algorithm used for choosing an IP address. This retry count is 181 present to make sure that DHCP Clients auto-configuring on busy 182 auto-configured network segments do not loop infinitely looking for 183 an IP address. 185 3.1. Determining Whether or Not an Address is in Use 187 If the client is on a network that supports ARP, the client may 188 issue an ARP request for the suggested address. When broadcasting 189 an ARP request for the suggested address, the client MUST fill in 190 its own hardware address as the sender's hardware address, and all 191 0s as the sender's IP address, to avoid confusing ARP caches in 192 other hosts on the same subnet. This ARP request with a sender IP 193 address of all 0s is referred to as an "ARP probe". 195 While waiting for a possible response to this request, the client 196 MUST also listen for other ARP probes for the same address (but not 197 from its own hardware address). This will occur if two (or more) 198 hosts are attempting to autoconfigure the exact same address. If 199 the client receives a response to the ARP request, or sees another 200 ARP probe for the same address, it MUST consider the address as 201 being in use, and move on. 203 Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year] 205 Clients SHOULD randomize their IP address selection algorithm, to 206 help keep clients from becoming stuck in a loop with other clients 207 while trying to allocate an address. Algorithm designers MUST make 208 sure that their algorithm will not cause the client IP selection 209 process to become stuck when interoperating with any other possible 210 algorithms. 212 4. Ongoing Checks for a DHCP Server 214 When the client originally sent out it's request, there may have 215 been a network problem stopping the DHCP Server from responding. To 216 make sure this is not the case, a host with an auto-configured IP 217 address MUST keep checking for an active DHCP Server. To do this, 218 the host MUST attempt to fetch an IP address as described in section 219 1 of this document. 221 When rechecking, if the host has determined no DHCP Server is 222 responding, it MUST wait a period of time and try again. This 223 interval is tunable. The suggested default for Ethernet implementa- 224 tions is to check every 5 minutes. 226 If the host receives a response from a DHCP Server, it MUST respond 227 and attempt to obtain a lease from the server (per the DHCP specifi- 228 cation). If the client is successful in obtaining a new lease, and 229 the internet host does not support multiple addresses on the inter- 230 face being configured, it MUST drop any existing auto-configured IP 231 address, and all active connections, while moving to the new 232 address. If the internet host does support multiple addresses on 233 the interface, it MAY keep the auto-configured address active. 235 If the DHCP response is an AutoConfigure [DHCPAC] response set to 236 "DoNOTAutoConfigure", the host MUST drop all connections, give up 237 any existing auto-configured IP address, and continue checking for a 238 DHCP server. 240 WARNING: If the client drops all connections, the user may lose data 241 being access over the existing connections. The operating system 242 SHOULD do everything it can to allow existing clients to finish 243 using all existing connections before closing them. It SHOULD NOT 244 allocate any further connections using the auto-configured IP 245 address. 247 5. Current Vendor Implementations 249 As of this writing, Microsoft and Apple have operating systems that 250 contain this functionality. Descriptions of the implementation 251 dependant parts are listed below. 253 Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year] 255 5.1. Microsoft Windows 98 257 With the initial release of Windows 98, Microsoft introduced auto- 258 configuration functionality. When developed, the AutoConfig 259 [DHCPAC] specification did not exist, so the initial release does 260 not contain this functionality. 262 The Win98 DHCP Client sends out a total of 4 DHCPDISCOVERs, with an 263 inter-packet interval of 6 seconds. When no response is received 264 after all 4 packets (24 seconds), it will auto-configure an address. 266 The auto-configure retry count for Windows 98 is 10. After trying 267 10 auto-configured IP addresses, and finding all are taken, the host 268 will boot without an IP address. 270 5.2. Apple MacOS 8.5 272 MacOS 8.5 sends three DHCPDISCOVER packets, with timeouts of 4, 8, 273 and then 16 seconds. When no response is received from all of these 274 requests (28 seconds), it will auto-configure. 276 The auto-configure retry count for MacOS 8.5 is 10. After trying 10 277 auto-configured IP addresses, and finding all are taken, the host 278 will boot without an IP address. 280 6. Security Considerations 282 The use of this functionality may open a network host to new Denial 283 Of Service (DOS) attacks. In particular, a host that previously did 284 not have an IP address, and no IP stack running, was not succeptable 285 to IP based DOS attacks, as there was no IP stack configured to 286 interpret these packets. 288 However, the addition of this functionality to an OS may cause IP 289 stacks to be capable of receiving and interpreting information that 290 the host was not previously configured to receive. As this host is 291 now interpreting IP communications, it is now open to IP based DOS 292 attacks. 294 Another security concern is the DOS attack that may be made on the 295 local subnet which stops all machines from being able to allocate an 296 IP address. A malicious host on the local wire may listen for ARP 297 probes, and respond with it's own ARP probe. This will stop the 298 auto-configuring machine from using that address, and it will move 299 on to the next one. Eventually, it will run out of addresses to 300 attempt, and will give up. The use of DHCP removes this attack, 301 leaving only the concerns described in [DHCP]. 303 Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year] 305 Finally, machines that rely on this for communication over a large 306 network may allocate the same address if the network itself is seg- 307 mented when the machines boot. If the link between two machines is 308 down when they boot, they may both auto-configure the same address. 309 However, when the network link returns, there will be numerous prob- 310 lems (ARP caches, etc.) There is currently no way to solve this 311 auto-configuration problem without causing all hosts involved to 312 re-autoconfigure IP addresses. The use of DHCP to configure hosts 313 on a subnet will solve this, and hosts that implement this confi- 314 guration mechanism will behave appropriately on a DHCP managed net- 315 work in which the DHCP server is not initially available. 317 7. Acknowledgments 319 I'd like to thank Microsoft and Apple for their help in writing this 320 document. 322 8. Copyright 324 Copyright (C) The Internet Society 1999. All Rights Reserved. 326 This document and translations of it may be copied and furnished to 327 others, and derivative works that comment on or otherwise explain it 328 or assist in its implementation may be prepared, copied, published 329 and distributed, in whole or in part, without restriction of any 330 kind, provided that the above copyright notice and this paragraph 331 are included on all such copies and derivative works. However, this 332 document itself may not be modified in any way, such as by removing 333 the copyright notice or references to the Internet Society or other 334 Internet organizations, except as needed for the purpose of develop- 335 ing Internet standards in which case the procedures for copyrights 336 defined in the Internet Standards process must be followed, or as 337 required to translate it into languages other than English. 339 The limited permissions granted above are perpetual and will not be 340 revoked by the Internet Society or its successors or assigns. 342 This document and the information contained herein is provided on an 343 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 344 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 345 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 346 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 347 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 349 9. References 351 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 352 March 1997 354 Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year] 356 358 [DHCPAC] Troll, R., "DHCP Option to Disable Stateless Auto- 359 Configuration in IPv4 Clients", RFC 2563, May 1999 361 363 [DHCPOPT] Alexander, S. and Droms, R., "DHCP Options and BOOTP Ven- 364 dor Extension", RFC 2132, March 1997 366 368 [IPv6SAC] Thomson, S. and Narten, T., "IPv6 Stateless Address Auto- 369 configuration", RFC 2462, December 1998 371 373 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 374 Requirement Levels", RFC 2119, March 1997 376 378 10. Author's Address 380 Ryan Troll 381 Excite@Home Network 382 450 Broadway 383 Redwood City, CA 94063 385 Phone: (650) 556-6031 386 EMail: rtroll@excitehome.net