idnits 2.17.1 draft-ietf-dhc-ipv4-autoconfig-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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 == Line 343 has weird spacing: '...Options and ...' == Line 348 has weird spacing: '...r, "Key words...' == Line 358 has weird spacing: '... Option to D...' == Line 359 has weird spacing: '...uration in I...' -- 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 (April 14, 1999) is 9144 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCPAC' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 3 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-04.txt @Home Network 3 Expires October 19, 1999 April 14, 1999 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 13 working documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute 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 20 reference material or to cite them other than as "work in progress." 22 To view the list Internet-Draft Shadow Directories, see 23 http://www.ietf.org/shadow.html. 25 Distribution of this memo is unlimited. 27 Abstract 29 With operating systems appearing in more and more devices, as well 30 as computers appearing in more and more aspects of everyday life, 31 communication between networked devices is increasingly important. 32 The communication mechanism between these devices must be able to 33 not only support the office LAN environment, but must also scale to 34 larger WANS and the internet. 36 This draft describes a method by which a host may automatically give 37 itself a link-local IPv4 address, so that it will be able to use IP 38 applications in the absence of an IP address management mechanism, 39 such as DHCP. This mechanism is in use today by a few operating 40 systems, and additional information on those implementations is also 41 provided. 43 1. Introduction 45 Now that networked applications are becoming more prevalent, 46 operating systems are migrating towards more scalable network 47 protocols such as IP, allowing them to work in all sizes of 48 environments. However, there is a price to pay for this migration 49 -- IP requires configuration that other protocols (IPX, Appletalk) 50 do not require. 52 Dynamic creation of usable ad-hoc networks is very useful when there 53 are only a few machines on the entire network. (For example, a 54 dentist's office may only have a couple of machines.) In order to 55 allow a site such as this to use IP, the machines must each be 56 configured with an IP address. OS's wish to retain the minimal 57 configuration that was necessary under their non-IP network stacks. 59 Dynamic configuration protocols such as DHCP [DHCP] allow a site 60 administrator to take care of the network configuration for a 61 machine remotely. By requesting network parameters via DHCP, the 62 site administrator may provide all information necessary without the 63 host's owner having to do anything. However, not all sites have a 64 central administrator to take care of this. 66 To accommodate unmanaged networks, the OS may decide to 67 intelligently choose an IP address for itself. These addresses are 68 only valid for the local network. 70 This document describes a method by which an OS may determine 71 whether or not to autoconfigure itself an IP address, as well as how 72 to inter-operate cleanly with an existing managed infrastructure, 73 allowing a host to easily move between managed and unmanaged network 74 segments. 76 1.1. Conventions Used in the Document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [KEYWORDS]. 82 1.2. Terminology 84 Site Administrator 85 A Site Administrator is the person or organization 86 responsible for handing out IP addresses to client 87 machines. 89 DHCP Client A DHCP Client is an Internet host using DHCP to 90 obtain configuration parameters such as a network 91 address. 93 DHCP Server A DHCP Server is an Internet host that returns 94 configuration parameters to DHCP Clients. 96 1.3. Usage Clarification 98 This document describes a method by which a host may automatically 99 choose an IPv4 address in the absence of a central service to 100 maintain and hand out addresses. This is not designed to replace 101 this functionality, but to basicly provide it in small networks. 103 This SHOULD NOT be used for large-scale networks. As more and more 104 machines begin to use this mechanism on a network, startup times for 105 these machines will begin to increase, as the chance of collisions 106 will rise. 108 Addresses allocated by this mechanism MUST NOT be routed by any 109 network device. The addresses are designed to be link local 110 addresses. Link local address are to be, by definition, restricted 111 to the local network segment. Allocation of link-local addresses in 112 an IPv6 network is described in [IPv6SAC]. 114 Finally, it should be noted that this functionality is designed to 115 work on a host that is running a DHCP Client. Hosts that are not 116 running a DHCP Client are not considered in this draft, and MUST NOT 117 attempt to use these mechanisms to configure an IP address, as these 118 no-dhcp-client hosts will not interoperate with the existing 119 infrastructure correctly. (This mechanism relies on the DHCP Server 120 for some information, and if a host can not receive this 121 information, it will not be fully informed.) 123 2. To Choose or Not To Choose 125 The first thing an Internet host should do is attempt to get an 126 administratively assigned address using DHCP. Only after the DHCP 127 process fails should a host use the methods later for 128 autoconfiguration. 130 2.1. Obtaining an Address via DHCP 132 A host begins by requesting an IP address via DHCP [DHCP]. This is 133 done by sending out a DHCPDISCOVER message, with various tags set 134 indicating what options the DHCP Client would like to receive 135 information for [DHCPOPT]. The DHCP Client SHOULD also send the 136 DHCP AutoConfigure option described in [DHCPAC]. 138 According to [DHCP], Section 4.4.1, the amount of time over which a 139 DHCP Client should listen for DHCPOFFERS is implementation 140 dependant. During this time, if a DHCPOFFER is received, network 141 configuration MUST occur as described in [DHCP] and [DHCPAC]. 143 If, during this time, no valid DHCPOFFERS are received, the DHCP 144 Client is free to autoconfigure an IP address according to section 3 145 of this document. 147 2.2. Rebinding an Existing IP Address 149 If the DHCP Client already has an existing IP address, it MUST 150 follow the instructions outlined in [DHCP]. If the client winds up 151 back in the INIT state, refer to section 2.1 of this document. 153 3. Choosing an IP Address 155 Once a DHCP Client has determined it must auto-configure an IP 156 address, it chooses an address. The algorithm for choosing an 157 address is implementation dependant. The address range to use MUST 158 be "169.254/16", which is registered with the IANA as the LINKLOCAL 159 net. 161 If choosing an address in this range, the DHCP Client MUST NOT use 162 the first 256 or the last 256, as these are reserved for future use. 164 When an address is chosen, the DHCP Client MUST test to see if the 165 address is already in use. If the network address appears to be in 166 use, the client MUST choose another address, and try again. The 167 client MUST keep choosing addresses until it either finds one, or it 168 has tried more then the autoconfig-retry count. The autoconfig- 169 retry count is implementation specific, and should be based on the 170 algorithm used for choosing an IP address. This retry count is 171 present to make sure that DHCP Clients auto-configuring on busy 172 auto-configured network segments do not loop infinitely looking for 173 an IP address. 175 3.1. Determining Whether or Not an Address is in Use 177 If the client is on a network that supports ARP, the client may 178 issue an ARP request for the suggested address. When broadcasting 179 an ARP request for the suggested address, the client MUST fill in 180 its own hardware address as the sender's hardware address, and all 181 0s as the sender's IP address, to avoid confusing ARP caches in 182 other hosts on the same subnet. This ARP request with a sender IP 183 address of all 0s is referred to as an "ARP probe". 185 While waiting for a possible response to this request, the client 186 MUST also listen for other ARP probes for the same address (but not 187 from its own hardware address). This will occur if two (or more) 188 hosts are attempting to autoconfigure the exact same address. If 189 the client receives a response to the ARP request, or sees another 190 ARP probe for the same address, it MUST consider the address as 191 being in use, and move on. 193 Clients SHOULD randomize their IP address selection algorithm, to 194 help keep clients from becoming stuck in a loop with other clients 195 while trying to allocate an address. Algorithm designers MUST make 196 sure that their algorithm will not cause the client IP selection 197 process to become stuck when interoperating with any other possible 198 algorithms. 200 4. Ongoing Checks for a DHCP Server 202 When the client originally sent out it's request, there may have 203 been a network problem stopping the DHCP Server from responding. To 204 make sure this is not the case, a host with an auto-configured IP 205 address MUST keep checking for an active DHCP Server. To do this, 206 the host MUST attempt to fetch an IP address as described in section 207 1 of this document. 209 When rechecking, if the host has determined no DHCP Server is 210 responding, it MUST wait a period of time and try again. This 211 interval is tunable. The suggested default for Ethernet 212 implementations is to check every 5 minutes. 214 If the host receives a response from a DHCP Server, it MUST respond 215 and attempt to obtain a lease from the server (per the DHCP 216 specification). If the client is successful in obtaining a new 217 lease, and the internet host does not support multiple addresses on 218 the interface being configured, it MUST drop any existing auto- 219 configured IP address, and all active connections, while moving to 220 the new address. If the internet host does support multiple 221 addresses on the interface, it MAY keep the auto-configured address 222 active. 224 If the DHCP response is an AutoConfigure [DHCPAC] response set to 225 "DoNOTAutoConfigure", the host MUST drop all connections, give up 226 any existing auto-configured IP address, and continue checking for a 227 DHCP server. 229 WARNING: If the client drops all connections, the user may lose data 230 being access over the existing connections. The operating system 231 SHOULD do everything it can to allow existing clients to finish 232 using all existing connections before closing them. It SHOULD NOT 233 allocate any further connections using the auto-configured IP 234 address. 236 5. Current Vendor Implementations 238 As of this writing, Microsoft and Apple have operating systems that 239 contain this functionality. Descriptions of the implementation 240 dependant parts are listed below. 242 5.1. Microsoft Windows 98 244 With the initial release of Windows 98, Microsoft introduced auto- 245 configuration functionality. When developed, the AutoConfig 246 [DHCPAC] specification did not exist, so the initial release does 247 not contain this functionality. 249 The Win98 DHCP Client sends out a total of 4 DHCPDISCOVERs, with an 250 inter-packet interval of 6 seconds. When no response is received 251 after all 4 packets (24 seconds), it will auto-configure an address. 253 The auto-configure retry count for Windows 98 is 10. After trying 254 10 auto-configured IP addresses, and finding all are taken, the host 255 will boot without an IP address. 257 5.2. Apple MacOS 8.5 259 MacOS 8.5 sends three DHCPDISCOVER packets, with timeouts of 4, 8, 260 and then 16 seconds. When no response is received from all of these 261 requests (28 seconds), it will auto-configure. 263 The auto-configure retry count for MacOS 8.5 is 10. After trying 10 264 auto-configured IP addresses, and finding all are taken, the host 265 will boot without an IP address. 267 6. Security Considerations 269 The use of this functionality may open a network host to new Denial 270 Of Service (DOS) attacks. In particular, a host that previously did 271 not have an IP address, and no IP stack running, was not succeptable 272 to IP based DOS attacks, as there was no IP stack configured to 273 interpret these packets. 275 However, the addition of this functionality to an OS may cause IP 276 stacks to be capable of receiving and interpreting information that 277 the host was not previously configured to receive. As this host is 278 now interpreting IP communications, it is now open to IP based DOS 279 attacks. 281 Another security concern is the DOS attack that may be made on the 282 local subnet which stops all machines from being able to allocate an 283 IP address. A malicious host on the local wire may listen for ARP 284 probes, and respond with it's own ARP probe. This will stop the 285 auto-configuring machine from using that address, and it will move 286 on to the next one. Eventually, it will run out of addresses to 287 attempt, and will give up. The use of DHCP removes this attack, 288 leaving only the concerns described in [DHCP]. 290 Finally, machines that rely on this for communication over a large 291 network may allocate the same address if the network itself is 292 segmented when the machines boot. If the link between two machines 293 is down when they boot, they may both auto-configure the same 294 address. However, when the network link returns, there will be 295 numerous problems (ARP caches, etc.) There is currently no way to 296 solve this auto-configuration problem without causing all hosts 297 involved to re-autoconfigure IP addresses. The use of DHCP to 298 configure hosts on a subnet will solve this, and hosts that 299 implement this configuration mechanism will behave appropriately on 300 a DHCP managed network in which the DHCP server is not initially 301 available. 303 7. Acknowledgments 305 I'd like to thank Microsoft and Apple for their help in writing this 306 document. 308 8. Copyright 310 Copyright (C) The Internet Society 1999. All Rights Reserved. 312 This document and translations of it may be copied and furnished to 313 others, and derivative works that comment on or otherwise explain it 314 or assist in its implementation may be prepared, copied, published 315 and distributed, in whole or in part, without restriction of any 316 kind, provided that the above copyright notice and this paragraph 317 are included on all such copies and derivative works. However, this 318 document itself may not be modified in any way, such as by removing 319 the copyright notice or references to the Internet Society or other 320 Internet organizations, except as needed for the purpose of 321 developing Internet standards in which case the procedures for 322 copyrights defined in the Internet Standards process must be 323 followed, or as required to translate it into languages other than 324 English. 326 The limited permissions granted above are perpetual and will not be 327 revoked by the Internet Society or its successors or assigns. 329 This document and the information contained herein is provided on an 330 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 331 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 332 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 333 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 334 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 336 9. References 338 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 339 March 1997 341 343 [DHCPOPT] Alexander, S. and Droms, R., "DHCP Options and BOOTP 344 Vendor Extension", RFC 2132, March 1997 346 348 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 349 Requirement Levels", RFC 2119, March 1997 351 353 [IPv6SAC] Thomson, S. and Narten, T., "IPv6 Stateless Address 354 Autoconfiguration", RFC 2462, December 1998 356 358 [DHCPAC] Troll, R., "DHCP Option to Disable Stateless Auto- 359 Configuration in IPv4 Clients", RFC Work in progress, January 360 1999 362 364 10. Author's Address 366 Ryan Troll 367 @Home Network 368 425 Broadway 369 Redwood City, CA 94063 371 Phone: (650) 569-6031 372 EMail: rtroll@corp.home.net