idnits 2.17.1 draft-cheshire-ipv4-acd-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 826. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 844. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 850. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The draft header indicates that this document updates RFC14th, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC826, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC826, updated by this document, for RFC5378 checks: 1982-11-01) -- 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 (August 2008) is 5726 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: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Stuart Cheshire 2 Category: Standards Track Apple Inc. 3 Updates: 826 14th February 2008 4 Expires 14th August 2008 6 IPv4 Address Conflict Detection 7 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 When two hosts on the same link attempt to use the same IPv4 address 35 at the same time (except in rare special cases where this has been 36 arranged by prior coordination) problems ensue for one or both hosts. 37 This document describes (i) a simple precaution that a host can take 38 in advance to help prevent this misconfiguration from happening, and 39 (ii) if this misconfiguration does occur, a simple mechanism by which 40 a host can passively detect after-the-fact that it has happened, so 41 that the host or administrator may respond to rectify the problem. 43 Table of Contents 45 [Insert Table of Contents here] 47 1. Introduction 49 Historically, accidentally configuring two Internet hosts with the 50 same IP address has often been an annoying and hard-to-diagnose 51 problem. 53 This is unfortunate, because the existing ARP protocol provides 54 an easy way for a host to detect this kind of misconfiguration and 55 report it to the user. The DHCP specification [RFC2131] briefly 56 mentions the role of ARP in detecting misconfiguration, as 57 illustrated in the following three excerpts from RFC 2131: 59 o the client SHOULD probe the newly received address, 60 e.g., with ARP. 62 o The client SHOULD perform a final check on the parameters 63 (e.g., ARP for allocated network address) 65 o If the client detects that the address is already in use 66 (e.g., through the use of ARP), the client MUST send 67 a DHCPDECLINE message to the server 69 Unfortunately, the DHCP specification does not give any guidance to 70 implementers concerning the number of ARP packets to send, the 71 interval between packets, the total time to wait before concluding 72 that an address may safely be used, or indeed even which kinds of 73 packets a host should be listening for, in order to make this 74 determination. It leaves unspecified the action a host should 75 take if, after concluding that an address may safely be used, it 76 subsequently discovers that it was wrong. It also fails to specify 77 what precautions a DHCP client should take to guard against 78 pathological failure cases, such as a DHCP server that repeatedly 79 OFFERs the same address, even though it has been DECLINEd multiple 80 times. 82 The authors of the DHCP specification may have been justified in 83 thinking at the time that the answers to these questions seemed 84 too simple, obvious and straightforward to be worth mentioning, but 85 unfortunately this left some of the burden of protocol design to each 86 individual implementer. This document seeks to remedy this omission 87 by clearly specifying the required actions for: 89 1. Determining whether use of an address is likely to lead to an 90 addressing conflict. This includes (a) the case where the address 91 is already actively in use by another host on the same link, and 92 (b) the case where two hosts are inadvertently about to begin 93 using the same address, and both are simultaneously in the process 94 of probing to determine whether the address may safely be used. 95 (Section 2.1.) 97 2. Subsequent passive detection that another host on the network is 98 inadvertently using the same address. Even if all hosts observe 99 precautions to avoid using an address that is already in use, 100 conflicts can still occur if two hosts are out of communication at 101 the time of initial interface configuration. This could occur 102 with wireless network interfaces if the hosts are temporarily out 103 of range, or with Ethernet interfaces if the link between two 104 Ethernet hubs is not functioning at the time of address 105 configuration. A well-designed host will handle not only 106 conflicts detected during interface configuration, but also 107 conflicts detected later, for the entire duration of the time 108 that the host is using the address. (Section 2.4.) 110 3. Rate-limiting of address acquisition attempts in the case of 111 an excessive number of repeated conflicts. (Section 2.1.) 113 The utility of IPv4 Address Conflict Detection (ACD) is not limited 114 to DHCP clients. No matter how an address was configured, whether 115 via manual entry by a human user, via information received from a 116 DHCP server, or via any other source of configuration information, 117 detecting conflicts is useful. Upon detecting a conflict, the 118 configuring agent should be notified of the error. In the case 119 where the configuring agent is a human user, that notification may 120 take the form of an error message on a screen, an SNMP notification, 121 or an error message sent via text message to a mobile phone. In the 122 case of a DHCP server, that notification takes the form of a DHCP 123 DECLINE message sent to the server. In the case of configuration by 124 some other kind of software, that notification takes the form of an 125 error indication to the software in question, to inform it that the 126 address it selected is in conflict with some other host on the 127 network. The configuring software may choose to cease network 128 operation, or it may automatically select a new address so that the 129 host may re-establish IP connectivity as soon as possible. 131 Allocation of IPv4 Link-Local Addresses [RFC3927] can be thought of 132 as a special-case of this mechanism, where the configuring agent is 133 a pseudo-random number generator, and the action it takes upon being 134 notified of a conflict is to pick a different random number and try 135 again. In fact, this is exactly how IPv4 Link-Local Addressing was 136 implemented in Mac OS 9 back in 1998. If the DHCP client failed to 137 get a response from any DHCP server, it would simply make up a fake 138 response containing a random 169.254.x.x address. If the ARP module 139 reported a conflict for that address, then the DHCP client would try 140 again, making up a new random 169.254.x.x address as many times as 141 was necessary until it succeeded. Implementing ACD as a standard 142 feature of the networking stack has the side-effect that it means 143 that half the work for IPv4 Link-Local Addressing is already done. 145 1.1 Conventions and Terminology Used in this Document 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in "Key words for use in 150 RFCs to Indicate Requirement Levels" [RFC2119]. 152 Wherever this document uses the term "sender IP address" or "target 153 IP address" in the context of an ARP packet, it is referring to the 154 fields of the ARP packet identified in the ARP specification [RFC826] 155 as "ar$spa" (Sender Protocol Address) and "ar$tpa" (Target Protocol 156 Address) respectively. For the usage of ARP described in this 157 document, each of these fields always contains an IPv4 address. 159 In this document, the term "ARP Probe" is used to refer to an ARP 160 Request packet, broadcast on the local link, with an all-zero 'sender 161 IP address'. The 'sender hardware address' MUST contain the hardware 162 address of the interface sending the packet. The 'sender IP address' 163 field MUST be set to all zeroes, to avoid polluting ARP caches in 164 other hosts on the same link in the case where the address turns out 165 to be already in use by another host. The 'target hardware address' 166 field is ignored and SHOULD be set to all zeroes. The 'target IP 167 address' field MUST be set to the address being probed. An "ARP 168 Probe" conveys both a question ("Is anyone using this address?") 169 and an implied statement ("This is the address I hope to use."). 171 In this document, the term "ARP Announcement" is used to refer to 172 an ARP Request packet, broadcast on the local link, identical to 173 the ARP Probe described above, except that both the sender and 174 target IP address fields contain the IP address being announced. 175 It conveys a stronger statement than an "ARP Probe", namely, 176 "This is the address I am now using." 178 The following timing constants used in this protocol are referenced 179 in Section 2, which describes the operation of the protocol in 180 detail. (Note that the values listed here are fixed constants; 181 they are not intended to be modifiable by implementers, operators, 182 or end users. These constants are given symbolic names here to 183 facilitate the writing of future standards that may want to reference 184 this document with different values for these named constants; 185 however at the present time no such future standards yet exist.) 187 PROBE_WAIT 1 second (initial random delay) 188 PROBE_NUM 3 (number of probe packets) 189 PROBE_MIN 1 second (minimum delay until repeated probe) 190 PROBE_MAX 2 seconds (maximum delay until repeated probe) 191 ANNOUNCE_WAIT 2 seconds (delay before announcing) 192 ANNOUNCE_NUM 2 (number of announcement packets) 193 ANNOUNCE_INTERVAL 2 seconds (time between announcement packets) 194 MAX_CONFLICTS 10 (max conflicts before rate limiting) 195 RATE_LIMIT_INTERVAL 60 seconds (delay between successive attempts) 196 DEFEND_INTERVAL 10 seconds (minimum interval between defensive 197 ARPs). 199 1.2 Relationship to RFC 826 201 This document does not modify any of the protocol rules in RFC 826. 202 It does not modify the packet format, or the meaning of any 203 of the fields. The existing rules for "Packet Generation" and 204 "Packet Reception" still apply exactly as specified in RFC 826. 206 This document expands on RFC 826 by specifying: 208 (1) that a specific ARP Request should be generated when an interface 209 is configured, to discover if the address is already in use, and 211 (2) an additional trivial test that should be performed on each 212 received ARP packet, to facilitate passive ongoing conflict 213 detection. This additional test creates no additional packet 214 overhead on the network (no additional packets are sent) and 215 negligible additional CPU burden on hosts, since every host 216 implementing ARP is *already* required to process every received 217 ARP packet according to the "Packet Reception" rules specified in 218 RFC 826. These rules already include checking to see if the 219 sender IP address of the ARP packet appears in any of the entries 220 in the host's ARP cache; the additional test is simply to check 221 to see if the sender IP address is the host's *own* IP address, 222 potentially as little as a single additional machine instruction 223 on many architectures. 225 As already specified in RFC 826, an ARP Request packet serves two 226 functions, an assertion and a question: 228 * Assertion: 229 The fields "ar$sha" (Sender Hardware Address) and "ar$spa" (Sender 230 Protocol Address) together serve as an assertion of a fact, that 231 the stated Protocol Address is mapped to the stated Hardware 232 Address. 234 * Question: 235 The fields "ar$tha" (Target Hardware Address, zero) and "ar$tpa" 236 (Target Protocol Address) serve as a question, asking, for the 237 stated Protocol Address, to which Hardware Address it is mapped. 239 This document clarifies what it means to have one without the other. 241 Some readers pointed out that it is probably impossible to ask any 242 truly pure question; asking any question necessarily invites 243 speculation about why the interrogator wants to know the answer. 244 Just as someone pointing to an empty seat and asking, "Is anyone 245 sitting here?" implies an unspoken "... because if not then I will," 246 the same is true here. An ARP Probe with an all-zero 'sender IP 247 address' may ostensibly be merely asking an innocent question ("Is 248 anyone using this address?"), but an intelligent implementation that 249 knows how IPv4 Address Conflict Detection works should be able to 250 recognize this question as the precursor to claiming the address. 252 Consequently, if that implementation is also at that exact moment in 253 the process of asking the very same question, it should recognize 254 that they can't both sit in the same seat, so it would be prudent to 255 ask about some other seat. 257 1.2.1 Broadcast ARP Replies 259 In some applications of IPv4 Address Conflict Detection (ACD), it 260 may be advantageous to deliver ARP Replies using broadcast instead of 261 unicast because this allows address conflicts to be detected sooner 262 than might otherwise happen. For example, "Dynamic Configuration of 263 IPv4 Link-Local Addresses" [RFC3927] uses ACD exactly as specified 264 here, but additionally specifies that ARP Replies should be sent 265 using broadcast, because in that context the trade-off of increased 266 broadcast traffic in exchange for improved reliability and 267 fault-tolerance was deemed to be an appropriate one. There may be 268 other future specifications where the same trade-off is appropriate. 269 Additional details are given in 2.6 "Broadcast ARP Replies". 271 RFC 826 implies that replies to ARP Requests are usually delivered 272 using unicast, but it is also acceptable to deliver ARP Replies using 273 broadcast. The "Packet Reception" rules in RFC 826 specify that the 274 content of the "ar$spa" field should be processed *before* examining 275 the "ar$op" field, so any host that correctly implements the Packet 276 Reception algorithm specified in RFC 826 will correctly handle ARP 277 Replies delivered via link-layer broadcast. 279 1.3 Applicability 281 This specification applies to all IEEE 802 Local Area Networks (LANs) 282 [802], including Ethernet [802.3], Token-Ring [802.5] and IEEE 802.11 283 wireless LANs [802.11], as well as to other link-layer technologies 284 that operate at data rates of at least 1 Mbps, have a round-trip 285 latency of at most one second, and use ARP [RFC826] to map from IP 286 addresses to link-layer hardware addresses. Wherever this document 287 uses the term "IEEE 802", the text applies equally to any of these 288 network technologies. 290 Link-layer technologies that support ARP but operate at rates below 291 1 Mbps or latencies above one second will still work correctly with 292 this protocol, but more often may have to handle late conflicts 293 detected after the Probing phase has completed. On these kinds 294 of link, it may be desirable to specify different values for the 295 following parameters: 297 (a) PROBE_NUM, PROBE_MIN, and PROBE_MAX, the number of, and interval 298 between, ARP Probes, explained in Section 2.1.1. 300 (b) ANNOUNCE_NUM and ANNOUNCE_INTERVAL, the number of, and interval 301 between, ARP announcements, explained in Section 2.3. 303 (c) RATE_LIMIT_INTERVAL and MAX_CONFLICTS, controlling the maximum 304 rate at which address claiming may be attempted, explained in 305 Section 2.1.1. 307 (d) DEFEND_INTERVAL, the time interval between conflicting ARPs below 308 which a host MUST NOT attempt to defend its address, explained in 309 Section 2.4. 311 Link-layer technologies that do not support ARP may be able to use 312 other techniques for determining whether a particular IP address is 313 currently in use. However, implementing Address Conflict Detection 314 for such networks is outside the scope of this document. 316 For the protocol specified in this document to be effective, 317 it is not necessary that every host on the link implements it. 318 For a given host implementing this specification to be protected 319 against accidental address conflicts, all that is required is that 320 the peers on the same link correctly implement the ARP protocol as 321 given in RFC 826. To be specific, when a peer host receives an ARP 322 Request where the Target Protocol Address of the ARP Request matches 323 (one of) that host's IP address(es) configured on that interface, 324 then as long as it properly responds with a correctly-formatted ARP 325 Reply, the querying host will be able to detect that the address is 326 already in use. 328 The specifications in this document allow hosts to detect conflicts 329 between two hosts using the same address on the same physical link. 330 ACD does not detect conflicts between two hosts using the same 331 address on different physical links, and indeed it should not. 332 For example, the address 10.0.0.1 [RFC1918] is in use by countless 333 devices on countless private networks throughout the world, and this 334 is not a conflict, because they are on different links. It would 335 only be a conflict if two such devices were to be connected to the 336 same link, and when this happens (as it sometimes does), this is a 337 perfect example of a situation where ACD is extremely useful to 338 detect and report (and/or automatically correct) this error. 340 For the purposes of this document, a set of hosts is considered to 341 be "on the same link" if: 343 - when any host A from that set sends a packet to any other host B 344 in that set, using unicast, multicast, or broadcast, the entire 345 link-layer packet payload arrives unmodified, and 347 - a broadcast sent over that link by any host from that set of hosts 348 can be received by every other host in that set 350 The link-layer *header* may be modified, such as in Token Ring Source 351 Routing [802.5], but not the link-layer *payload*. In particular, if 352 any device forwarding a packet modifies any part of the IP header or 353 IP payload then the packet is no longer considered to be on the same 354 link. This means that the packet may pass through devices such as 355 repeaters, bridges, hubs or switches and still be considered to be on 356 the same link for the purpose of this document, but not through a 357 device such as an IP router that decrements the TTL or otherwise 358 modifies the IP header. 360 Where this document uses the term "host" it applies equally to 361 interfaces on routers or other multi-homed hosts, regardless of 362 whether the host/router is currently forwarding packets. In many 363 cases a router will be critical network infrastructure with an IP 364 address that is locally well known and assumed to be relatively 365 constant. For example, the address of the default router is one of 366 the parameters that a DHCP server typically communicates to its 367 clients, and (at least until mechanisms like DHCP Reconfigure 368 [RFC3203] become widely implemented) there isn't any practical way 369 for the DHCP server to inform clients if that address changes. 370 Consequently, for such devices handling conflicts by picking a new IP 371 address is not a good option. In those cases, option (c) in Section 372 2.4 "Ongoing Address Conflict Detection and Address Defense" below 373 applies. 375 However, even when a device is manually configured with a fixed 376 address, having some other device on the network claiming to have the 377 same IP address will pollute peer ARP caches and prevent reliable 378 communication, so it is still helpful to inform the operator. If a 379 conflict is detected at the time the operator sets the fixed manual 380 address then it is helpful to inform the operator immediately; if a 381 conflict is detected subsequently it is helpful to inform the 382 operator via some appropriate asynchronous communications channel. 383 Even though reliable communication via the conflicted address is not 384 possible, it may still be possible to inform the operator via some 385 other communication channel that is still operating, such as via some 386 other interface on the router, via a dynamic IPv4 link-local address, 387 via a working IPv6 address, or even via some completely different 388 non-IP technology such as a locally-attached screen or serial 389 console. 391 2. Address Probing, Announcing, Conflict Detection and Defense 393 This section describes initial probing to safely determine whether an 394 address is already in use, announcing the chosen address, ongoing 395 conflict checking, and optional use of broadcast ARP Replies to 396 provide faster conflict detection. 398 2.1 Probing an Address 400 Before beginning to use an IPv4 address (whether received from manual 401 configuration, DHCP, or some other means), a host implementing this 402 specification MUST test to see if the address is already in use, by 403 broadcasting ARP Probe packets. This also applies when a network 404 interface transitions from an inactive to an active state, when a 405 computer awakes from sleep, when a link-state change signals that an 406 Ethernet cable has been connected, when an 802.11 wireless interface 407 associates with a new base station, or any other change in 408 connectivity where a host becomes actively connected to a logical 409 link. 411 A host MUST NOT perform this check periodically as a matter of 412 course. This would be a waste of network bandwidth, and is 413 unnecessary due to the ability of hosts to passively discover 414 conflicts, as described in Section 2.4. 416 2.1.1 Probe Details 418 A host probes to see if an address is already in use by broadcasting 419 an ARP Request for the desired address. The client MUST fill in the 420 'sender hardware address' field of the ARP Request with the hardware 421 address of the interface through which it is sending the packet. The 422 'sender IP address' field MUST be set to all zeroes, to avoid 423 polluting ARP caches in other hosts on the same link in the case 424 where the address turns out to be already in use by another host. 425 The 'target hardware address' field is ignored and SHOULD be set to 426 all zeroes. The 'target IP address' field MUST be set to the address 427 being probed. An ARP Request constructed this way with an all-zero 428 'sender IP address' is referred to as an "ARP Probe". 430 When ready to begin probing, the host should then wait for a random 431 time interval selected uniformly in the range zero to PROBE_WAIT 432 seconds, and should then send PROBE_NUM probe packets, each of these 433 probe packets spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. 434 This initial random delay helps ensure that a large number of hosts 435 powered on at the same time do not all send their initial probe 436 packets simultaneously. 438 If during this period, from the beginning of the probing process 439 until ANNOUNCE_WAIT seconds after the last probe packet is sent, the 440 host receives any ARP packet (Request *or* Reply) on the interface 441 where the probe is being performed where the packet's 'sender IP 442 address' is the address being probed for, then the host MUST treat 443 this address as being in use by some other host, and should indicate 444 to the configuring agent (human operator, DHCP server, etc.) that the 445 proposed address is not acceptable. 447 In addition, if during this period the host receives any ARP Probe 448 where the packet's 'target IP address' is the address being probed 449 for, and the packet's 'sender hardware address' is not the hardware 450 address of any of the host's interfaces, then the host SHOULD 451 similarly treat this as an address conflict and signal an error to 452 the configuring agent as above. This can occur if two (or more) 453 hosts have, for whatever reason, been inadvertently configured with 454 the same address, and both are simultaneously in the process of 455 probing that address to see if it can safely be used. 457 NOTE: The check that the packet's 'sender hardware address' is not 458 the hardware address of any of the host's interfaces is important. 459 Some kinds of Ethernet hub (often called a "buffered repeater") and 460 many wireless access points may "rebroadcast" any received broadcast 461 packets to all recipients, including the original sender itself. For 462 this reason, the precaution described above is necessary to ensure 463 that a host is not confused when it sees its own ARP packets echoed 464 back. 466 A host implementing this specification MUST take precautions to limit 467 the rate at which it probes for new candidate addresses: If the host 468 experiences MAX_CONFLICTS or more address conflicts on a given 469 interface, then the host MUST limit the rate at which it probes for 470 new addresses on this interface to no more than one attempted new 471 address per RATE_LIMIT_INTERVAL. This is to prevent catastrophic ARP 472 storms in pathological failure cases, such as a defective DHCP server 473 that repeatedly assigns the same address to every host that asks for 474 one. This rate limiting rule applies not only to conflicts 475 experienced during the initial probing phase, but also to conflicts 476 experienced later, as described in Section 2.4 "Ongoing Address 477 Conflict Detection and Address Defense". 479 If, by ANNOUNCE_WAIT seconds after the transmission of the last ARP 480 Probe no conflicting ARP Reply or ARP Probe has been received, then 481 the host has successfully determined that the desired address may be 482 used safely. 484 2.2 Shorter Timeouts on Appropriate Network Technologies 486 Network technologies may emerge for which shorter delays are 487 appropriate than those required by this document. A subsequent IETF 488 publication may be produced providing guidelines for different values 489 for PROBE_WAIT, PROBE_NUM, PROBE_MIN and PROBE_MAX on those 490 technologies. 492 If the situation arises where different hosts on a link are using 493 different timing parameters, this does not cause any problems. This 494 protocol is not dependent on all hosts on a link implementing the 495 same version of the protocol; indeed, this protocol is not dependent 496 on all hosts on a link implementing the protocol at all. All that is 497 required is that all hosts implement ARP as specified in RFC 826, and 498 correctly answer ARP Requests they receive. In the situation where 499 different hosts are using different timing parameters, all that will 500 happen is that some hosts will configure their interfaces quicker 501 than others. In the unlikely event that an address conflict is not 502 detected during the address probing phase, the conflict will still be 503 detected by the Ongoing Address Conflict Detection described below in 504 Section 2.4. 506 2.3 Announcing an Address 508 Having probed to determine that a desired address may be used safely, 509 a host implementing this specification MUST then announce that it 510 is commencing to use this address by broadcasting ANNOUNCE_NUM ARP 511 announcements, spaced ANNOUNCE_INTERVAL seconds apart. An ARP 512 announcement is identical to the ARP Probe described above, except 513 that now the sender and target IP addresses are both set to the 514 host's newly selected IPv4 address. The purpose of these ARP 515 announcements is to make sure that other hosts on the link do not 516 have stale ARP cache entries left over from some other host that may 517 previously have been using the same address. The host may begin 518 legitimately using the IP address immediately after sending the first 519 of the two ARP announcements, and the sending of the second ARP 520 announcement may be completed asynchronously, concurrent with other 521 networking operations the host may wish to perform. 523 2.4 Ongoing Address Conflict Detection and Address Defense 525 Address conflict detection is not limited to only the time of initial 526 interface configuration, when a host is sending ARP Probes. Address 527 conflict detection is an ongoing process that is in effect for as 528 long as a host is using an address. At any time, if a host receives 529 an ARP packet (Request *or* Reply) where the 'sender IP address' is 530 (one of) the host's own IP address(es) configured on that interface, 531 but the 'sender hardware address' does not match any of the host's 532 own interface addresses, then this is a conflicting ARP packet, 533 indicating some other host also thinks it is validly using this 534 address. To resolve the address conflict, a host MUST respond to a 535 conflicting ARP packet as described in either (a), (b) or (c) below: 537 (a) Upon receiving a conflicting ARP packet, a host MAY elect to 538 immediately cease using the address, and signal an error to the 539 configuring agent as described above, or 541 (b) If a host currently has active TCP connections or other reasons 542 to prefer to keep the same IPv4 address, and it has not seen any 543 other conflicting ARP packets within the last DEFEND_INTERVAL 544 seconds, then it MAY elect to attempt to defend its address by 545 recording the time that the conflicting ARP packet was received, and 546 then broadcasting one single ARP announcement, giving its own IP and 547 hardware addresses as the sender addresses of the ARP. Having done 548 this, the host can then continue to use the address normally without 549 any further special action. However, if this is not the first 550 conflicting ARP packet the host has seen, and the time recorded for 551 the previous conflicting ARP packet is recent, within DEFEND_INTERVAL 552 seconds, then the host MUST immediately cease using this address and 553 signal an error to the configuring agent as described above. This is 554 necessary to ensure that two hosts do not get stuck in an endless 555 loop with both hosts trying to defend the same address. 557 (c) If a host has been configured such that it should not give up its 558 address under any circumstances (perhaps because it is the kind of 559 device that needs to have a well-known stable IP address, such as a 560 link's default router, or a DNS server) then it MAY elect to defend 561 its address indefinitely. If such a host receives a conflicting ARP 562 packet, then it should take appropriate steps to log useful 563 information such as source Ethernet address from the ARP packet, and 564 inform an administrator of the problem. The number of such 565 notifications should be appropriately controlled to prevent an 566 excessive number of error reports being generated. If the host has 567 not seen any other conflicting ARP packets recently within the last 568 DEFEND_INTERVAL seconds then it MUST record the time that the 569 conflicting ARP packet was received, and then broadcast one single 570 ARP announcement, giving its own IP and hardware addresses. Having 571 done this, the host can then continue to use the address normally 572 without any further special action. However, if this is not the 573 first conflicting ARP packet the host has seen, and the time recorded 574 for the previous conflicting ARP packet is within DEFEND_INTERVAL 575 seconds then the host MUST NOT send another defensive ARP 576 announcement. This is necessary to ensure that two misconfigured 577 hosts do not get stuck in an endless loop flooding the network with 578 broadcast traffic while they both try to defend the same address. 580 A host wishing to provide reliable network operation MUST respond to 581 conflicting ARP packets as described in (a), (b) or (c) above. 582 Ignoring conflicting ARP packets results in seemingly random network 583 failures which can be hard to diagnose and very frustrating for human 584 users. 586 Forced address reconfiguration may be disruptive, causing TCP 587 (and other transport-layer) connections to be broken. However, 588 such disruptions should be exceedingly rare, and if inadvertent 589 address duplication happens, then disruption of communication is 590 inevitable. It is not possible for two different hosts using the 591 same IP address on the same network to operate reliably. 593 Before abandoning an address due to a conflict, hosts SHOULD actively 594 attempt to reset any existing connections using that address. This 595 mitigates some security threats posed by address reconfiguration, as 596 discussed in Section 3. 598 For most client machines that do not need a fixed IP address, 599 immediately requesting the configuring agent (human user, DHCP 600 client, etc.) to configure a new address as soon as the conflict is 601 detected is the best way to restore useful communication as quickly 602 as possible. The mechanism described above of broadcasting a single 603 ARP announcement to defend the address mitigates the problem 604 somewhat, by helping to improve the chance that one of the two 605 conflicting hosts may be able to retain its address. 607 2.5 Continuing Operation 609 From the time a host sends its first ARP announcement, until the 610 time it ceases using that IP address, the host MUST answer ARP 611 Requests in the usual way required by the ARP specification [RFC826]. 612 Specifically, this means that whenever a host receives an ARP 613 Request, that's not a conflicting ARP packet as described above in 614 Section 2.4, where the 'target IP address' of the ARP Request is 615 (one of) the host's own IP address(es) configured on that interface, 616 the host MUST respond with an ARP Reply as described in RFC 826. 617 This applies equally for both standard ARP Requests with non-zero 618 sender IP address and Probe Requests with all-zero sender IP address. 620 2.6 Broadcast ARP Replies 622 In a carefully-run network with manually-assigned addresses, or 623 a network with a reliable DHCP server and reliable DHCP clients, 624 address conflicts should occur only in rare failure scenarios, 625 so the passive monitoring described above in Section 2.4 is adequate. 626 If two hosts are using the same IP address, then sooner or later one 627 or other host will broadcast an ARP Request, which the other will 628 see, allowing the conflict to be detected and consequently resolved. 630 It is possible however, that a conflicting configuration may persist 631 for a short time before it is detected. Suppose that two hosts A and 632 B have been inadvertently assigned the same IP address X. Suppose 633 further that at the time they were both probing to determine whether 634 the address could safely be used, the communication link between them 635 was non-functional for some reason, so neither detected the conflict 636 at interface-configuration time. Suppose now that the communication 637 link is restored, and a third host C broadcasts an ARP Request for 638 address X. Unaware of any conflict, both hosts A and B will send 639 unicast ARP Replies to host C. Host C will see both Replies, and may 640 be a little confused, but neither host A nor B will see the other's 641 Reply, and neither will immediately detect that there is a conflict 642 to be resolved. Hosts A and B will continue to be unaware of the 643 conflict until one or other broadcasts an ARP Request of their own. 645 If quicker conflict detection is desired, this may be achieved by 646 having hosts send ARP Replies using link-level broadcast, instead of 647 sending only ARP Requests via broadcast, and Replies via unicast. 648 This is NOT RECOMMENDED for general use, but other specifications 649 building on IPv4 ACD may choose to specify broadcast ARP Replies if 650 appropriate. For example, "Dynamic Configuration of IPv4 Link-Local 651 Addresses" [RFC3927] specifies broadcast ARP Replies because in that 652 context, detection of address conflicts using IPv4 ACD is not merely 653 a backup precaution to detect failures of some other configuration 654 mechanism; detection of address conflicts using IPv4 ACD is the sole 655 configuration mechanism. 657 Sending ARP Replies using broadcast does increase broadcast traffic, 658 but in the worst case by no more than a factor of two. In the 659 traditional usage of ARP, a unicast ARP Reply only occurs in response 660 to a broadcast ARP Request, so sending these via broadcast instead 661 means that we generate at most one broadcast Reply in response to 662 each existing broadcast Request. On many networks, ARP traffic is 663 such an insignificant proportion of the total traffic that doubling 664 it makes no practical difference. However, this may not be true of 665 all networks, so broadcast ARP Replies SHOULD NOT be used 666 universally. Broadcast ARP Replies should be used where the benefit 667 of faster conflict detection outweighs the cost of increased 668 broadcast traffic and increased packet processing load on the 669 participant network hosts. 671 3. Why are ARP Announcements performed using ARP Request packets 672 and not ARP Reply packets? 674 During IETF deliberation of IPv4 Address Conflict Detection from 2000 675 to 2007, a question that kept being asked repeatedly was, "Shouldn't 676 ARP Announcements be performed using gratuitous ARP Reply packets?" 678 On the face of it, this seems reasonable. A conventional ARP Reply 679 is an answer to a question. If in fact no question had been asked, 680 then it would be reasonable to describe such a reply as gratuitous. 681 The term "gratuitous reply" would seem to apply perfectly to an ARP 682 Announcement: an answer to an implied question that in fact no one 683 asked. 685 However reasonable this may seem in principle, in practice there are 686 two reasons that swing the argument in favour of using ARP Request 687 packets. One is historical precedent, and the other is practicality. 689 The historical precedent is that, as described above in Section 4, 690 Gratuitous ARP is described in Stevens Networking [Ste94] as using 691 ARP Request packets. BSD Unix, Microsoft Windows, Mac OS 9, 692 Mac OS X, etc., all use ARP Request packets as described in Stevens. 693 At this stage, trying to mandate that they all switch to using ARP 694 Reply packets would be futile. 696 The practical reason is that ARP Request packets are more likely to 697 work correctly with more existing ARP implementations, some of which 698 may not implement RFC 826 correctly. The Packet Reception rules in 699 RFC 826 state that the opcode is the last thing to check in packet 700 processing, so it really shouldn't matter, but there may be 701 "creative" implementations that have different packet processing 702 depending on the ar$op field, and there are several reasons why these 703 are more likely to accept gratuitous ARP Requests than gratuitous ARP 704 Replies: 706 * An incorrect ARP implementation may expect that ARP Replies are 707 only sent via unicast. RFC 826 does not say this, but an incorrect 708 implementation may assume it, and the "principle of least surprise" 709 dictates that where there are two or more ways to solve a 710 networking problem that are otherwise equally good, the one with 711 the fewest unusual properties is the one likely to have the fewest 712 interoperability problems with existing implementations. An ARP 713 Announcement needs to broadcast information to all hosts on the 714 link. Since ARP Request packets are always broadcast, and ARP 715 Reply packets are not, receiving an ARP Request packet via 716 broadcast is less surprising than receiving an ARP Reply packet via 717 broadcast. 719 * An incorrect ARP implementation may expect that ARP Replies are 720 only received in response to ARP Requests that have been issued 721 recently by that implementation. Unexpected unsolicited Replies 722 may be ignored. 724 * An incorrect ARP implementation may ignore ARP Replies where 725 ar$tha doesn't match its hardware address. 727 * An incorrect ARP implementation may ignore ARP Replies where 728 ar$tpa doesn't match its IP address. 730 In summary, there are more ways that an incorrect ARP implementation 731 might plausibly reject an ARP Reply (which usually occurs as a result 732 of being solicited by the client) than an ARP Request (which is 733 already expected to occur unsolicited). 735 4. Historical Note 737 Some readers have claimed that "Gratuitous ARP" as described in 738 Stevens [Ste94] provides duplicate address detection, making ACD 739 unnecessary. This is incorrect. What Stevens describes as 740 Gratuitous ARP is the exact same packet that this document refers to 741 by the more descriptive term "ARP Announcement". This traditional 742 Gratuitous ARP implementation sends only a single ARP Announcement 743 when an interface is first configured. The result is that the victim 744 (the existing address holder) logs an error, and the offender 745 continues operation, often without even detecting any problem. Both 746 machines then typically proceed to try to use the same IP address, 747 and fail to operate properly because they are each constantly 748 resetting the other's TCP connections. The human administrator is 749 expected to notice the log message on the victim machine and repair 750 the damage after the fact. Typically this has to be done by 751 physically going to the machines in question, since in this state 752 neither is able to keep a TCP connection open for long enough to do 753 anything useful over the network. 755 Gratuitous ARP does not in fact provide effective duplicate address 756 detection and (as of January 2008) many of the top results for a 757 Google search for the phrase "Gratuitous ARP" are articles describing 758 how to disable it. 760 However, implementers of IPv4 Address Conflict Detection should be 761 aware that, as of this writing, Gratuitous ARP is still widely 762 deployed. The steps described in Sections 2.1 and 2.4 of this 763 document help make a host robust against misconfiguration and address 764 conflicts, even when the other host is *not* playing by the same 765 rules. 767 5. IANA Considerations 769 This specification does not request the creation of any new parameter 770 registries, nor does it require any other IANA assignments. 772 6. Security Considerations 774 IPv4 Address Conflict Detection (ACD) is based on ARP [RFC826] and 775 inherits the security vulnerabilities of this protocol. A malicious 776 host may send fraudulent ARP packets on the network, interfering with 777 the correct operation of other hosts. For example, it is easy for a 778 host to answer all ARP Requests with Replies giving its own hardware 779 address, thereby claiming ownership of every address on the network. 781 This specification makes this existing ARP vulnerability no worse, 782 and in some ways makes it better: Instead of failing silently with no 783 indication why, hosts implementing this specification either attempt 784 to reconfigure automatically, or at least inform the human user of 785 what is happening. 787 If a host willingly selects a new address in response to an ARP 788 conflict, as described in Section 2.4 subsection (a), this 789 potentially makes it easier for malicious attackers on the same link 790 to hijack TCP connections. Having a host actively reset any existing 791 connections before abandoning an address helps mitigate this risk. 793 7. Acknowledgments 795 This document arose as a result of Zeroconf Working Group discussions 796 on IPv4 Link-Local Addressing [RFC3927], where it was not clear to 797 many participants which elements of link-local address management 798 were specific to that particular problem space (e.g., random 799 selection of an address), and which elements were generic and 800 applicable to all IPv4 address configuration mechanisms (e.g. the 801 detection of address conflicts). The following people made valuable 802 comments in the course of that work and/or the subsequent editing of 803 this document: Bernard Aboba, Randy Bush, Jim Busse, James Carlson, 804 Alan Cox, Spencer Dawkins, Pavani Diwanji, Ralph Droms, Donald 805 Eastlake 3rd, Alex Elder, Stephen Farrell, Peter Ford, Spencer 806 Giacalone, Josh Graessley, Erik Guttman, Myron Hattig, Mike Heard, 807 Hugh Holbrook, Richard Johnson, Kim Yong-Woon, Marc Krochmal, Rod 808 Lopez, Satish Mundra, Thomas Narten, Erik Nordmark, Randy Presuhn, 809 Howard Ridenour, Pekka Savola, Daniel Senie, Dieter Siegmund, Valery 810 Smyslov, Mark Townsley, Oleg Tychev and Ryan Troll. 812 8. Copyright Notice 814 Copyright (C) The IETF Trust (2008). 816 This document is subject to the rights, licenses and restrictions 817 contained in BCP 78, and except as set forth therein, the authors 818 retain all their rights. 820 This document and the information contained herein are provided on an 821 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 822 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 823 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 824 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 825 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 826 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 828 9. Intellectual Property Notice 830 The IETF takes no position regarding the validity or scope of any 831 Intellectual Property Rights or other rights that might be claimed to 832 pertain to the implementation or use of the technology described in 833 this document or the extent to which any license under such rights 834 might or might not be available; nor does it represent that it has 835 made any independent effort to identify any such rights. Information 836 on the procedures with respect to rights in RFC documents can be 837 found in BCP 78 and BCP 79. 839 Copies of IPR disclosures made to the IETF Secretariat and any 840 assurances of licenses to be made available, or the result of an 841 attempt made to obtain a general license or permission for the use of 842 such proprietary rights by implementers or users of this 843 specification can be obtained from the IETF on-line IPR repository at 844 http://www.ietf.org/ipr. 846 The IETF invites any interested party to bring to its attention any 847 copyrights, patents or patent applications, or other proprietary 848 rights that may cover technology that may be required to implement 849 this standard. Please address the information to the IETF at 850 ietf-ipr@ietf.org. 852 10. Normative References 854 [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 855 Converting Network Addresses to 48-bit Ethernet Address 856 for Transmission on Ethernet Hardware", STD 37, RFC 826, 857 November 1982. 859 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 860 Requirement Levels", RFC 2119, March 1997. 862 11. Informative References 864 [802] IEEE Standards for Local and Metropolitan Area Networks: 865 Overview and Architecture, ANSI/IEEE Std 802, 1990. 867 [802.3] ISO/IEC 8802-3 Information technology - Telecommunications 868 and information exchange between systems - Local and 869 metropolitan area networks - Common specifications - Part 870 3: Carrier Sense Multiple Access with Collision Detection 871 (CSMA/CD) Access Method and Physical Layer Specifications, 872 (also ANSI/IEEE Std 802.3-1996), 1996. 874 [802.5] ISO/IEC 8802-5 Information technology - Telecommunications 875 and information exchange between systems - Local and 876 metropolitan area networks - Common specifications - Part 877 5: Token ring access method and physical layer 878 specifications, (also ANSI/IEEE Std 802.5-1998), 1998. 880 [802.11] Information technology - Telecommunications and information 881 exchange between systems - Local and metropolitan area 882 networks - Specific Requirements Part 11: Wireless LAN 883 Medium Access Control (MAC) and Physical Layer (PHY) 884 Specifications, IEEE Std. 802.11-1999, 1999. 886 [RFC1918] Rekhter, et al, "Address Allocation for Private Internets", 887 RFC 1918, February 1996. 889 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", 890 RFC 2131, March 1997. 892 [RFC3203] Y. T'Joens, C. Hublet, and P. De Schrijver, 893 "DHCP Reconfigure Extension", RFC 3203, December 2001. 895 [RFC3927] S. Cheshire, B. Aboba, E. Guttman, 896 "Dynamic Configuration of IPv4 Link-Local Addresses", 897 RFC 3927, May 2005. 899 [Ste94] W. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols", 900 Addison-Wesley, 1994. 902 12. Author's Address 904 Stuart Cheshire 905 Apple Inc. 906 1 Infinite Loop 907 Cupertino 908 California 95014 909 USA 911 Phone: +1 408 974 3207 912 EMail: rfc@stuartcheshire.org