idnits 2.17.1 draft-cheshire-ipv4-acd-01.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. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 2002) is 8047 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Stuart Cheshire 2 Document: draft-cheshire-ipv4-acd-01.txt Apple Computer 3 Expires 5th October 2002 5th April 2002 5 IPv4 Address Conflict Detection 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), 14 its areas, and its working groups. Note that other groups may 15 also 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 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 When two hosts on the same link attempt to use the same IPv4 address 33 at the same time (except in rare special cases where this has been 34 arranged by prior coordination) problems ensue for one or both hosts. 35 This document describes (i) a simple precaution that a host can take 36 in advance to help prevent this misconfiguration from happening, and 37 (ii) if this misconfiguration does occur, a simple mechanism by which 38 a host can passively detect after-the-fact that it has happened, so 39 that the host may respond to rectify the problem. 41 1. Introduction 43 Historically, accidentally configuring two Internet hosts with the 44 same IP address has often been an annoying and hard-to-diagnose 45 problem. 47 This is unfortunate, because the existing ARP protocol provides 48 an easy way for a host to detect this kind of misconfiguration and 49 report it to the user. The DHCP specification [RFC 2131] briefly 50 mentions the role of ARP in detecting misconfiguration: 52 the client SHOULD probe the newly received address, 53 e.g., with ARP. 55 The client SHOULD perform a final check on the parameters 56 (e.g., ARP for allocated network address) 57 If the client detects that the address is already in use 58 (e.g., through the use of ARP), the client MUST send 59 a DHCPDECLINE message to the server 61 if the client is on a network that supports ARP, the client 62 may issue an ARP request for the suggested request [sic]. 63 When broadcasting an ARP request for the suggested address, 64 the client must fill in its own hardware address as the sender's 65 hardware address, and 0 as the sender's IP address, to avoid 66 confusing ARP caches in other hosts on the same subnet. If the 67 network address appears to be in use, the client MUST send a 68 DHCPDECLINE message to the server. The client SHOULD broadcast 69 an ARP reply to announce the client's new IP address and clear 70 any outdated ARP cache entries in hosts on the client's subnet. 72 Unfortunately, the DHCP specification does not give any guidance to 73 implementers concerning the number of ARP packets to send, the 74 interval between packets, the total time to wait before concluding 75 that an address may safely be used, or indeed even which kinds of 76 packets a host should be listening for, in order to make this 77 determination. It leaves unspecified the action a host should take 78 if, after concluding that an address may safely be used, it 79 subsequently discovers that it was wrong. It also fails to specify 80 what precautions a DHCP client should take to guard against 81 pathological failure cases, such as DHCP server that repeatedly 82 OFFERs the same address, even though it has been DECLINEd multiple 83 times. 85 The authors of the DHCP specification may have thought the answers to 86 these questions too obvious to mention; however, experience has shown 87 that even amongst intelligent experienced protocol implementers, 88 these issues are the subject of debate. This draft seeks to end this 89 ambiguity by clearly specifying the required actions for: 91 1. Determining whether use of an address is likely to lead to an 92 addressing conflict. This includes (a) the case where the address 93 is already actively in use by another host on the same link, and 94 (b) the case where two hosts are inadvertently about to begin 95 using the same address, and both are simultaneously in the process 96 of probing to determine whether the address may safely be used. 98 2. Subsequent passive detection that another host on the network is 99 inadvertently using the same address. Even if all hosts observe 100 precautions to avoid using an address that is already in use, 101 conflicts can still occur if two hosts are out of communication at 102 the time of initial interface configuration. This could occur with 103 wireless network interfaces if the hosts are temporarily out of 104 range, or with Ethernet interfaces if the link between two 105 Ethernet hubs is not functioning at the time of address 106 configuration. A well-designed host will handle not only conflicts 107 detected during interface configuration, but also conflicts 108 detected later, for the entire duration of the time that the host 109 is using the address. 111 3. Rate-limiting in the case of an excessive number of repeated 112 conflicts. 114 The utility of IPv4 Address Conflict Detection is not limited to DHCP 115 clients. No matter how an address was configured, whether via manual 116 entry by a human user, via information received from a DHCP server, 117 or via any other source of configuration information, detecting 118 conflicts is useful. Upon detecting a conflict, the configuring agent 119 should be notified of the error. In the case where the configuring 120 agent is a human user, that notification may take the form of an 121 error message on a screen, an SNMP trap, or an error message sent via 122 pager. In the case of a DHCP server, that notification takes the form 123 of a DHCP DECLINE message sent to the server. In the case of 124 configuration by some other kind of software, that notification takes 125 the form of an error indication to the software in question, to 126 inform it that the address it selected is in conflict with some other 127 host on the network. The configuring software may choose to cease 128 network operation, or it may automatically select a new address so 129 that the host may re-establish IP connectivity as soon as possible. 131 The specifications described in this document have been implemented 132 in Mac OS, Windows and other platforms for many years, and work 133 successfully. 135 1.1. Conventions and Terminology Used in this Document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in "Key words for use in 140 RFCs to Indicate Requirement Levels" [RFC 2119]. 142 Wherever this document uses the term "sender IP address" or "target 143 IP address" in the context of an ARP packet, it is referring to the 144 fields of the ARP packet identified in the ARP specification [RFC 145 826] as "ar$spa" (Sender Protocol Address) and "ar$tpa" (Target 146 Protocol Address) respectively. For the usage of ARP described in 147 this document, each of these fields always contains an IP address. 149 In this document, the term "ARP Probe" is used to refer to an ARP 150 request packet, broadcast on the local link, with an all-zero 'sender 151 IP address'. The 'sender hardware address' MUST contain the hardware 152 address of the interface sending the packet. The 'target hardware 153 address' field is ignored and SHOULD be set to all zeroes. The 154 'target IP address' field MUST be set to the address being probed. 156 In this document, the term "ARP Announcement" is used to refer to 157 an ARP request packet, broadcast on the local link, identical to 158 the ARP probe described above, except that both the sender and 159 target IP address fields contain the IP address being announced. 161 1.2 Relationship to RFC 826 163 This draft does not modify any of the protocol rules in RFC 826. 164 It does not modify the packet format, or the meaning of any of 165 the fields. As specified in RFC 826, an ARP Request packet 166 serves two functions, an assertion and a question: 168 * Assertion: 169 The fields "ar$sha" (Sender Hardware Address) and "ar$spa" (Sender 170 Protocol Address) together serve as an assertion of a fact, that 171 the stated Protocol Address is mapped to the stated Hardware 172 Address. 174 * Question: 175 The fields "ar$tha" (Target Hardware Address, zero) and "ar$tpa" 176 (Target Protocol Address) serve as a question, asking, for the 177 stated Protocol Address, to which Hardware Address it is mapped. 179 This draft clarifies what it means to have one without the other. 181 1.2.1 ARP Probe 183 This draft standardizes the widely-used natural interpretation of 184 an ARP Request where the Target Protocol Address is non-zero but the 185 Sender Protocol Address is zero, namely that it is a question without 186 an associated assertion (an "ARP Probe"). 188 1.2.2 ARP Announcement 190 This draft standardizes the widely-used natural interpretation of 191 an ARP Request where the Sender and Target Protocol Address fields 192 contain the same address, namely that it is an assertion without an 193 associated question (an "ARP Announcement"). 195 1.2.3 Broadcast Replies 197 The last line of the "Packet Reception" rules in RFC 826 says: 199 "Send the packet to the (new) target hardware address" 201 This line of text implies unicast delivery, but does not explicitly 202 and categorically prohibit broadcast, since sending a packet via 203 broadcast is a perfectly valid way of causing that packet to be 204 successfully delivered to the desired destination (and others). 205 Indeed, on a traditional coaxial Ethernet, all packets are sent via 206 physical broadcast on the cable; the destination address in the 207 Ethernet header is used by each receiving station to filter out 208 packets it has no interest in receiving. The "Packet Reception" rules 209 in RFC 826 specify that the content of the "ar$spa" field should be 210 processed *before* examining the "ar$op" field, so any host that 211 correctly implements the Packet Reception algorithm specified in RFC 212 826 will correctly handle ARP replies delivered via link-layer 213 broadcast. 215 1.3. Applicability 217 The specifications in this document apply to any link-layer network 218 technology that uses ARP [RFC 826] to map from IP addresses to 219 link-layer hardware addresses. 221 2. Address Probing, Announcing, Conflict Detection and Defense 223 This section describes initial probing to safely determine whether 224 an address is already in use, ongoing conflict checking, and optional 225 use of broadcast ARP replies to provide faster conflict detection. 227 2.1 Probing an Address 229 Before beginning to use an IP address (whether received from manual 230 configuration, DHCP, or some other means), a host may test to see if 231 the address is already in use, using ARP probes. 233 A host probes to see if an address is already in use by broadcasting 234 an ARP request for the desired address. The client MUST fill in the 235 'sender hardware address' field of the ARP request with the hardware 236 address of the interface through which it is sending the packet. 237 The 'sender IP address' field MUST be set to all zeroes, to avoid 238 polluting ARP caches in other hosts on the same link in the case 239 where the address turns out to be already in use by another host. 240 The 'target hardware address' field is ignored and SHOULD be set to 241 all zeroes. The 'target IP address' field MUST be set to the address 242 being probed. An ARP request constructed this way with an all-zero 243 'sender IP address' is referred to as an "ARP probe". 245 When ready to begin probing, the host should then wait for a random 246 time interval selected uniformly in the range zero to two seconds, 247 and should then send four probe packets, spaced two seconds apart. 248 This initial random delay helps ensure that a large number of hosts 249 powered on at the same time do not all send their initial probe 250 packets simultaneously. 252 If during this period, from the beginning of the probing process 253 until two seconds after the last probe packet is sent, the host 254 receives any ARP packet (request *or* reply) where the packet's 255 'sender IP address' is the address being probed for, then the host 256 MUST treat this address as being in use by some other host, and 257 should indicate to the configuring agent (human operator, DHCP 258 server, etc.) that the proposed address is not acceptable. In 259 addition, if during this period the host receives any ARP probe where 260 the packet's 'target IP address' is the address being probed for, and 261 the packet's 'sender hardware address' is not the hardware address of 262 any of the host's interfaces, then the host MUST similarly treat this 263 as an address conflict and signal an error to the configuring agent 264 as above. This can occur if two (or more) hosts have, for whatever 265 reason, been inadvertently configured with the same address, and both 266 are simultaneously in the process of probing that address to see if 267 it can safely be used. 269 A host should maintain a counter of the number of conflicts it has 270 experienced in the process of trying to configure an interface, and 271 if the number of conflicts exceeds ten then the host MUST limit the 272 rate at which it probes for new addresses to no more than one new 273 address per minute. This is to prevent catastrophic ARP storms in 274 pathological failure cases, such as a defective DHCP server that 275 repeatedly assigns the same address to every host that asks for one. 277 If, by two seconds after the transmission of the last ARP probe 278 no conflicting ARP reply has been received, then the host has 279 successfully determined that the desired address may be used safely. 281 2.2 Shorter Timeouts on Appropriate Network Technologies 283 The time values specified above are intended for use on technologies 284 such as Ethernet, where switches that implement Spanning Tree 285 [802.1d] often silently discard all packets for several seconds. The 286 time values specified above result in a delay of 8-10 seconds before 287 a chosen IP address may be used. For a desktop machine using DHCP, 288 this may not be a great problem, but for other types of device, 289 particularly portable hand-held wireless devices, a ten-second delay 290 before networking services becomes available may not be acceptable. 291 For this reason, shorter time values may be used on network 292 technologies that allow the device to determine when the link has 293 become active and can be reasonably trusted to deliver packets 294 reliably. On these network technologies the recommended time values 295 are: The host should first wait for a random time interval selected 296 uniformly in the range 0-200 milliseconds, and then send four probe 297 packets, waiting 200 milliseconds after each probe, making a total 298 delay of 800-1000 milliseconds before a chosen IP address may be 299 used. 301 Should future versions of the IEEE Spanning Tree Protocol be enhanced 302 to inform clients when the link is ready to begin forwarding packets, 303 then the shorter time values may be used on these networks too. 305 2.3 Announcing an Address 307 Having determined that a desired address may be used safely, a host 308 should then announce that it is commencing to use this address by 309 broadcasting two ARP announcements, spaced two seconds apart. An ARP 310 announcement is identical to the ARP probe described above, except 311 that now the sender and target IP addresses are both set to the 312 host's newly selected IP address. The purpose of these ARP 313 announcements is to make sure that other hosts on the link do not 314 have stale ARP cache entries left over from some other host that may 315 previously have been using the same address. 317 2.4 Ongoing Address Conflict Detection and Address Defense 319 Address conflict detection should not be limited to only the time of 320 initial interface configuration, when a host is sending ARP probes. 321 Address conflict detection is an ongoing process that is in effect 322 for as long as a host is using an address. At any time, if a host 323 receives an ARP packet (request *or* reply) where the 'sender IP 324 address' is the host's own IP address, but the 'sender hardware 325 address' does not match any of the host's own interface addresses, 326 then this is a conflicting ARP packet, indicating some other unknown 327 host also thinks it is validly using this address. To resolve the 328 address conflict, a host must respond to a conflicting ARP packet as 329 described in either (a) or (b) below: 331 (a) Upon receiving a conflicting ARP packet, a host MAY elect to 332 immediately cease using the address, and signal an error to the 333 configuring agent as described above, or 335 (b) If a host currently has active TCP connections or other reasons 336 to prefer to keep the same IP address, and it has not seen any other 337 conflicting ARP packets recently (for Ethernet, within the last ten 338 seconds) then it MAY elect to attempt to defend its address. 339 To defend its address, the host first records the time that the 340 conflicting ARP packet was received, and then broadcasts one single 341 ARP announcement, giving its own IP and hardware addresses. Having 342 done this, the host can then continue to use the address normally 343 without any further special action. However, if this is not the first 344 conflicting ARP packet the host has seen, and the time recorded for 345 the previous conflicting ARP packet is recent (within ten seconds for 346 Ethernet) then the host MUST immediately cease using this address and 347 signal an error to the configuring agent as described above. This is 348 necessary to ensure that two hosts do not get stuck in an endless 349 loop with both hosts trying to defend the same address. 351 A host wishing to provide reliable network operation must respond to 352 conflicting ARP packets as described in either (a) or (b) above. 353 Ignoring conflicting ARP packets results in seemingly random network 354 failures which can be hard to diagnose and very frustrating for human 355 users. 357 Forced address reconfiguration may be disruptive, causing TCP 358 connections to be broken. However, it is expected that such 359 disruptions will be rare, and if inadvertent address duplication 360 happens, then disruption of communication is inevitable. It is not 361 possible for two different hosts using the same IP address on the 362 same network to operate reliably. 364 Immediately configuring a new address as soon as the conflict is 365 detected is the best way to restore useful communication as quickly 366 as possible. The mechanism described above of broadcasting a single 367 ARP announcement to defend the address mitigates the problem 368 somewhat, by helping to improve the chance that one of the two 369 conflicting hosts may be able to retain its address. 371 2.5 Broadcast ARP Replies 373 In a carefully-run network with manually-assigned addresses, or 374 a network with a reliable DHCP server and reliable DHCP clients, 375 address conflicts should occur only in rare failure scenarios, 376 so the passive monitoring described above in Section 2.3 is adequate. 377 If two hosts are using the same IP address, then sooner or later one 378 or other host will broadcast an ARP request, which the other will 379 see, allowing the conflict to be detected and consequently resolved. 381 It is possible however, that a conflicting configuration may persist 382 for a short time before it is detected. Suppose that two hosts A and 383 B have been inadvertently assigned the same IP address X. Suppose 384 further that at the time they were both probing to determine whether 385 the address could safely be used, the communication link between them 386 was non-functional for some reason, so neither detected the conflict 387 at interface-configuration time. Suppose now that the communication 388 link is restored, and a third host C broadcasts an ARP request for 389 address X. Unaware of any conflict, both hosts A and B will send 390 unicast ARP replies to host C. Host C will see both replies, and may 391 be a little confused, but neither host A nor B will see the other's 392 reply, and neither will immediately detect that there is a conflict 393 to be resolved. Hosts A and B will continue to be unaware of the 394 conflict until one or other broadcasts an ARP request of their own. 396 If quicker conflict detection is desired, this can be achieved by 397 having hosts send ARP replies using link-level broadcast, instead 398 of sending only ARP requests via broadcast, and replies via unicast. 400 Sending both requests and replies via broadcast potentially doubles 401 the ARP traffic load on each host on the network. On many networks, 402 ARP traffic is such an insignificant proportion of the total traffic 403 that doubling it makes no practical difference. However, this may not 404 be true of all networks, so broadcast ARP replies should not be used 405 universally. Broadcast ARP replies should be used where the benefit 406 of faster conflict detection outweighs the cost of slightly increased 407 packet processing load on the participant network hosts. 409 3. Security Considerations 411 The ARP protocol [RFC 826] is insecure. A malicious host may send 412 fraudulent ARP packets on the network, interfering with the correct 413 operation of other hosts. For example, it is easy for a host to 414 answer all ARP requests with responses giving its own hardware 415 address, thereby claiming ownership of every address on the network. 417 4. IANA Considerations 419 This document has no IANA-related considerations. 421 5. Acknowledgements 423 This document arose as a result of discussions on link-local 424 addressing, where it was not clear to many readers which elements of 425 link-local address management were specific to that particular 426 problem, and which elements were generic and applicable to all IPv4 427 address configuration mechanisms. The following people made valuable 428 comments in the course of that work: Bernard Aboba, Jim Busse, Pavani 429 Diwanji, Donald Eastlake 3rd, Peter Ford, Spencer Giacalone, Josh 430 Graessley, Erik Guttman, Myron Hattig, Hugh Holbrook, Richard 431 Johnson, Kim Yong-Woon, Rod Lopez, Satish Mundra, Thomas Narten, Erik 432 Nordmark, Howard Ridenour, Daniel Senie, Dieter Siegmund, Valery 433 Smyslov and Ryan Troll. 435 6. Copyright 437 Copyright (C) The Internet Society 8th March 2000. 438 All Rights Reserved. 440 This document and translations of it may be copied and furnished to 441 others, and derivative works that comment on or otherwise explain it 442 or assist in its implementation may be prepared, copied, published 443 and distributed, in whole or in part, without restriction of any 444 kind, provided that the above copyright notice and this paragraph are 445 included on all such copies and derivative works. However, this 446 document itself may not be modified in any way, such as by removing 447 the copyright notice or references to the Internet Society or other 448 Internet organizations, except as needed for the purpose of 449 developing Internet standards in which case the procedures for 450 copyrights defined in the Internet Standards process must be 451 followed, or as required to translate it into languages other than 452 English. 454 The limited permissions granted above are perpetual and will not be 455 revoked by the Internet Society or its successors or assigns. 457 This document and the information contained herein is provided on an 458 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 459 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 460 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 461 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 462 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 464 7. References 466 [802.1d] ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges". 468 [RFC 826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 469 Converting Network Addresses to 48-bit Ethernet Address 470 for Transmission on Ethernet Hardware", STD 37, RFC 826, 471 November 1982. 473 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 474 Requirement Levels", RFC 2119, March 1997. 476 [RFC 2131] R. Droms, "Dynamic Host Configuration Protocol", 477 RFC 2131, March 1997. 479 8. Author's Address 481 Stuart Cheshire 482 Apple Computer, Inc. 483 1 Infinite Loop 484 Cupertino 485 California 95014 486 USA 488 Phone: +1 408 974 3207 489 EMail: rfc@stuartcheshire.org