idnits 2.17.1 draft-ietf-dhc-ipv4-autoconfig-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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: If choosing an address in this range, the DHCP Client MUST not use the first 256 or the last 256, as these are reserved for future use. -- 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 (September 1998) is 9352 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: 'IPv6SAC' is defined on line 260, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1971 (ref. 'IPv6SAC') (Obsoleted by RFC 2462) -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCPAC' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft: DHC-IPV4-AUTOCONFIG R. Troll 2 Document: draft-ietf-dhc-ipv4-autoconfig-00.txt September 1998 3 Expires: March 1999 5 Automaticly Choosing an IP Address in an Ad-Hoc IPv4 Network 7 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 27 West Coast). 29 Abstract 31 With operating systems appearing in more and more devices, as well 32 as computers appearing in more and more aspects of everyday life, 33 communication between networked devices is increasingly important. 34 The communication mechanism between these devices must be able to 35 not only support the office LAN environment, but must also scale to 36 larger WANS and the internet. 38 This draft describes a method by which a host may automaticly give 39 itself an IPv4 address, so that it will be able to use IP 40 applications in all of the above environments. This mechanism is 41 in use today by a few operating systems, and additional information 42 on those implementations is also provided. 44 1. Introduction 46 Now that networked applications are becoming more prevalent, 47 operating systems are migrating towards more scalable network 48 protocols such as IP, allowing them to work in all sizes of 49 environments. However, there is a price to pay for this migration 50 -- IP requires configuration that other protocols (IPX, Appletalk) 51 do not require. 53 Dynamic creation of usable ad-hoc networks is very useful when 54 there are only a few machines on the entire network. (For example, 55 a dentist's office may only have a couple of machines.) In order 56 to allow a site such as this to use IP, the machines must each be 57 configured with an IP address. OS's wish to retain the minimal 58 configuration that was necessary under their non-IP network stacks. 60 Dynamic configuration protocols such as DHCP [DHCP] allow a site 61 administrator to take care of the network configuration for a 62 machine remotely. By requesting network parameters via DHCP, the 63 site administrator may provide all information necessary without 64 the host's owner having to do anything. However, not all sites 65 have a central administrator to take care of this. 67 To accommodate smaller networks, the OS may decide to intelligently 68 choose an IP address for itself in the absence of a central 69 configuration mechanism. 71 This document describes a method by which an OS may determine 72 whether or not to auto-configure itself an IP address, as well as 73 how to inter-operate cleanly with an existing managed 74 infrastructure. 76 1.1 Conventions Used in the Document 78 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 79 in this document are to be interpreted as defined in "Key Words for 80 Use in RFCs to Indicate Requirement Levels" [KEYWORDS] 82 1.2 Terminology 84 Site Administrator 85 A Site Administrator is the person or 86 organization responsible for handing out IP 87 addresses to client machines. 89 DHCP Client A DHCP Client is an Internet host using DHCP to 90 obtain configuration parameters such as a 91 network address. 93 DHCP Server A DHCP Server is an Internet host that returns 94 configuration parameters to DHCP Clients. 96 2. To Choose or Not To Choose 98 The first thing an Internet host should do is request an IP address 99 via DHCP [DHCP]. This is done by sending out a DHCPDISCOVER 100 message, with various tags set indicating what options the DHCP 101 Client would like to receive information for [DHCPOPT]. The DHCP 102 Client SHOULD also send the DHCP AutoConfigure option described in 103 [DHCPAC]. 105 According to [DHCP], Section 4.4.1, the amount of time over which a 106 DHCP Client should listen for DHCPOFFERS is implementation 107 dependant. During this time, if a DHCPOFFER is received, network 108 configuration MUST occur as described in [DHCP] and [DHCPAC]. 110 If, during this time, no valid DHCPOFFERS are received, the DHCP 111 Client is free to auto-configure an IP address according to section 112 3 of this document. 114 2.1 Rebinding an Existing IP Address 116 If the DHCP Client already has an existing IP address, it MUST 117 follow the instructions outlined in [DHCP]. If the client winds up 118 back in the INIT state, refer to section 2 of this document. 120 3. Choosing an IP Address 122 Once a DHCP Client has determined it must auto-configure an IP 123 address, it chooses an address. The algorithm for choosing an 124 address is implementation dependant. The address range to use 125 SHOULD be "169.254/16", which is registered with the IANA as the 126 LINKLOCAL net. 128 If choosing an address in this range, the DHCP Client MUST not use 129 the first 256 or the last 256, as these are reserved for future 130 use. 132 When an address is chosen, the DHCP Client MUST test to see if the 133 address is already in use. For example, if the client is on a 134 network that supports ARP, the client may issue an ARP request for 135 the suggested request. When broadcasting an ARP request for the 136 suggested address, the client must fill in its own hardware address 137 as the sender's hardware address, and 0 as the sender's IP address, 138 to avoid confusing ARP caches in other hosts on the same subnet. 139 If the network address appears to be in use, the client MUST choose 140 another address, and try again. The client MUST keep choosing 141 addresses until it either finds one, or it has tried more then the 142 autoconfig-retry count. The autoconfig-retry count is 143 implementation specific, and should be based on the algorithm used 144 for choosing an IP address. This retry count is present to make 145 sure that DHCP Clients auto-configuring on busy auto-configured 146 network segments do not loop infinitely looking for an IP address. 148 4. Ongoing Checks for a DHCP Server 150 When the client originally sent out it's request, there may have 151 been a network problem stopping the DHCP Server from responding. 152 To make sure this is not the case, a DHCP Client with an auto- 153 configured IP address MUST keep checking for an active DHCP Server. 154 To do this, the DHCP Client MUST attempt to fetch an IP address as 155 described in section 1 of this document. 157 When rechecking, when the DHCP Client has determined no DHCP Server 158 is responding, it MUST wait a period of time and try again. For 159 Ethernet implementations, the DHCP Client SHOULD check every 5 160 minutes. 162 If the DHCP Client receives a response from a DHCP Server, it MUST 163 respond and attempt to obtain a lease from the server (per the DHCP 164 specification). If the client is successful in obtaining a new 165 lease, and the internet host does not support multiple addresses on 166 the interface being configured, it MUST drop any existing auto- 167 configured IP address, and all active connections, while moving to 168 the new address. If the internet host does support multiple 169 addresses on the interface, it MAY keep the auto-configured address 170 active. 172 If the DHCP response is an AutoConfigure [DHCPAC] response set to 173 "DoNOTAutoConfigure", the host MUST drop all connections, give up 174 any existing auto-configured IP address, and continue checking for 175 a DHCP server. 177 5. Current Vendor Implementations 179 As of this writing, Microsoft and Apple have operating systems that 180 contain this functionality. Descriptions of the implementation 181 dependant parts are listed below. 183 5.1. Microsoft Windows 98 185 With the initial release of Windows 98, Microsoft introduced auto- 186 configuration functionality. When developed, the AutoConfig 188 [DHCPAC] specification did not exist, so the initial release does 189 not contain this functionality. 191 The Win98 DHCP Client sends out a total of 4 DHCPDISCOVERs, with an 192 inter-packet interval of 6 seconds. When no response is received 193 after all 4 packets (24 seconds), it will autoconfigure an address. 195 The auto-configure retry count for Windows 98 is 10. After trying 196 10 auto-configured IP addresses, and finding all are taken, the 197 host will boot without an IP address. 199 5.2. Apple MacOS 8.5 201 MacOS 8.5 sends three DHCPDISCOVER packets, with timeouts of 4, 8, 202 and then 16 seconds. When no response is received from all of 203 these requests (28 seconds), it will autoconfigure. 205 6. Security Considerations 207 All of the existing DHCP security considerations apply here. This 208 functionality does not introduce any new security concerns. 210 7. Acknowledgments 212 I'd like to thank Microsoft and Apple for their help in writing 213 this document. 215 8. Copyright 217 Copyright (C) The Internet Society 1998. All Rights Reserved. 219 This document and translations of it may be copied and furnished to 220 others, and derivative works that comment on or otherwise explain 221 it or assist in its implementation may be prepared, copied, 222 published and distributed, in whole or in part, without restriction 223 of any kind, provided that the above copyright notice and this 224 paragraph are included on all such copies and derivative works. 225 However, this document itself may not be modified in any way, such 226 as by removing the copyright notice or references to the Internet 227 Society or other Internet organizations, except as needed for the 228 purpose of developing Internet standards in which case the 229 procedures for copyrights defined in the Internet Standards process 230 must be followed, or as required to translate it into languages 231 other than English. 233 The limited permissions granted above are perpetual and will not be 234 revoked by the Internet Society or its successors or assigns. 236 This document and the information contained herein is provided on 237 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 238 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 239 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 240 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 241 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 243 9. References 245 [DHCP] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 246 Bucknell University, March 1997. 248 250 [DHCPOPT] Alexander, S. and Droms, R., "DHCP Options and BOOTP 251 Vendor Extension", RFC 2132, March 1997. 253 255 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 256 Requirement Levels", RFC 2119, Harvard University, March 1997. 258 260 [IPv6SAC] Thomson, S. and Narten, T. "IPv6 Stateless Address 261 Autoconfiguration", RFC 1971, August 1996 263 265 [DHCPAC] Troll, R. "DHCP Option to Disable Stateless Auto- 266 Configuration in IPv4 Clients", RFC XXXXX, November 1998 268 270 10. Author's Address 272 Ryan Troll 273 Network Development 274 Carnegie Mellon 275 5000 Forbes Avenue 276 Pittsburgh, PA 15213 278 Phone: (412) 268-8691 279 EMail: ryan@andrew.cmu.edu 280 This document will expire March 1999