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