RFC 5227

IPv4 Address Conflict Detection

📅 published July 2008, from ietf

RFC 5227: IPv4 Address Conflict Detection 💖

Okay bestie, title drop!! 🎀 This is RFC 5227, IPv4 Address Conflict Detection, written by S. Cheshire of Apple Inc. ✨ It came out of the Network Working Group in July 2008 and is a Standards Track doc 🦋 It updates RFC 826, the ARP spec, and the header doesn't list anything it obsoletes. Now let's get into it!! 🫶

Status of This Memo 📜

So this is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💅 To check where this protocol stands in standardization, look at the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Abstract ✨

Okay, the big problem: when two hosts on the same link try to use the same IPv4 address at the same time, things go wrong for one or both of them 😭 The exception is the rare case where someone arranged it ahead of time on purpose. This doc covers two things. First, (i) a simple precaution a host can take in advance so the mistake doesn't happen. Second, (ii) if it happens anyway, a simple way for a host to passively notice after the fact that it's happened, so the host or the admin can fix it 🔥

Table of Contents 🧚

   1. Introduction ....................................................2
      1.1. Conventions and Terminology Used in This Document ..........4
      1.2. Relationship to RFC 826 ....................................5
           1.2.1. Broadcast ARP Replies ...............................7
      1.3. Applicability ..............................................7
   2. Address Probing, Announcing, Conflict Detection, and Defense ....9
      2.1. Probing an Address ........................................10
           2.1.1. Probe Details ......................................10
      2.2. Shorter Timeouts on Appropriate Network Technologies ......11
      2.3. Announcing an Address .....................................12
      2.4. Ongoing Address Conflict Detection and Address Defense ....12
      2.5. Continuing Operation ......................................14
      2.6. Broadcast ARP Replies .....................................14
   3. Why Are ARP Announcements Performed Using ARP Request
      Packets and Not ARP Reply Packets? .............................15
   4. Historical Note ................................................17
   5. Security Considerations ........................................17
   6. Acknowledgments ................................................18
   7. References .....................................................18
      7.1. Normative References ......................................18
      7.2. Informative References ....................................19

1. Introduction ✨

Historically, accidentally giving two Internet hosts the same IP address has been an annoying, hard-to-diagnose problem 😩

That's kind of a shame, because the existing Address Resolution Protocol (ARP) already gives a host an easy way to catch this and report it to the user 💁‍♀️ The DHCP spec [RFC2131] briefly mentions ARP's role in spotting misconfiguration. Here are the three excerpts from RFC 2131 it uses:

the client SHOULD probe the newly received address, e.g., with ARP
The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address)
If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server

Here's the tea 🍵 DHCP doesn't really tell implementers anything useful. It doesn't say how many ARP packets to send, how far apart to send them, how long to wait before deciding an address is safe, or even which kinds of packets a host should be listening for to figure that out. It also leaves open what a host should do if it decided an address was safe and then discovers it was wrong 😳 And it doesn't cover pathological cases, like a DHCP server that keeps OFFERing the same address even after it's been DECLINEd multiple times.

To be fair, the DHCP authors might have figured those answers were too simple and obvious to bother writing down 🙄 But that left a bunch of protocol design work to every individual implementer. This doc fixes that by clearly specifying the required actions for:

Figuring out whether using an address is likely to cause a conflict. That includes (a) the case where another host on the same link is already actively using the address, and (b) the case where two hosts are about to start using the same address at the same time and both are probing to see if it's safe (Section 2.1.).
Passively detecting later that another host on the network is accidentally using the same address. Even if every host avoids addresses that are already in use, conflicts can still happen if two hosts were out of communication during initial interface configuration. That could happen with wireless interfaces if the hosts are temporarily out of range, or with Ethernet if the link between two Ethernet hubs isn't working at configuration time. A well-designed host handles not just conflicts found during configuration, but also conflicts found later, for as long as it's using the address (Section 2.4.).
Rate-limiting address acquisition attempts when there's an excessive number of repeated conflicts (Section 2.1.).

ACD isn't just for DHCP clients, bestie 🌸 No matter how an address got configured, whether a human typed it in, a DHCP server handed it over, or some other config source provided it, conflict detection is useful. When a conflict is detected, the configuring agent should be told about the error. If a human is configuring, that could be an error message on a screen, a Simple Network Management Protocol (SNMP) notification, or a text message to a mobile phone 📱 If it's a DHCP server, the notification is a DHCP DECLINE message sent to the server. If it's some other software, the notification is an error indication to that software, telling it the address it picked conflicts with another host. The software can stop network operation, or it can automatically pick a new address so the host gets IP connectivity back ASAP 🚀

Allocation of IPv4 Link-Local Addresses [RFC3927] can be seen as a special case of this mechanism, where the configuring agent is a pseudo-random number generator, and when it's told about a conflict it just picks a different random number and tries again 🎲 This is basically how IPv4 Link-Local Addressing was actually built in Mac OS 9 back in 1998 💀 If the DHCP client didn't get a response from any DHCP server, it would just make up a fake response with a random 169.254.x.x address. If the ARP module reported a conflict for that address, the DHCP client tried again and made up a new random 169.254.x.x address as many times as it took to succeed. Building ACD in as a standard feature of the networking stack means half the work for IPv4 Link-Local Addressing is already done 👑

1.1. Conventions and Terminology Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. Those are the official BCP 14 key words, so they're the ones with real force 🫡

Whenever this document says 'sender IP address' or 'target IP address' in the context of an ARP packet, it means the ARP packet fields the ARP spec [RFC826] calls 'ar$spa' (Sender Protocol Address) and 'ar$tpa' (Target Protocol Address). For the way this doc uses ARP, each of those fields always holds an IPv4 address 🧠

Here, an 'ARP Probe' is an ARP Request packet, broadcast on the local link, with an all-zero 'sender IP address'. The 'sender hardware address' MUST contain the hardware address of the interface sending the packet. The 'sender IP address' field MUST be set to all zeroes, so it doesn't pollute the ARP caches of other hosts on the same link in case the address turns out to already be in use by someone else 🙈 The 'target hardware address' field is ignored and SHOULD be set to all zeroes. The 'target IP address' field MUST be set to the address being probed. An ARP Probe asks a question ("Is anyone using this address?") and makes an implied statement ("This is the address I hope to use.") 🦋

An 'ARP Announcement' is also an ARP Request packet, broadcast on the local link, identical to the ARP Probe above, except that both the sender and target IP address fields contain the IP address being announced. It makes a stronger statement than a Probe, namely, "This is the address I am now using." 💜

The timing constants below are used in this protocol and are referenced in Section 2, which goes through how the protocol works in detail. The values listed here are fixed constants, not something implementers, operators, or end users are supposed to change 🙅‍♀️ They're given symbolic names so that future standards that want to reference this doc with different values can do so. At the moment, though, no such future standards exist 🌷

   PROBE_WAIT           1 second   (initial random delay)
   PROBE_NUM            3          (number of probe packets)
   PROBE_MIN            1 second   (minimum delay until repeated probe)
   PROBE_MAX            2 seconds  (maximum delay until repeated probe)
   ANNOUNCE_WAIT        2 seconds  (delay before announcing)
   ANNOUNCE_NUM         2          (number of Announcement packets)
   ANNOUNCE_INTERVAL    2 seconds  (time between Announcement packets)
   MAX_CONFLICTS       10          (max conflicts before rate-limiting)
   RATE_LIMIT_INTERVAL 60 seconds  (delay between successive attempts)
   DEFEND_INTERVAL     10 seconds  (minimum interval between defensive
                                    ARPs)

1.2. Relationship to RFC 826 ✨

okay so this section is basically the "we are NOT breaking RFC 826, promise" bit 💅 This document does not modify any of the protocol rules in RFC 826. It doesn't touch the packet format or what any of the fields mean. The existing rules for "Packet Generation" and "Packet Reception" still apply exactly as RFC 826 specifies 🫶

what this doc does add is:

a specific ARP Request that should be generated when an interface is configured, to discover if the address is already in use, and
an additional trivial test that should be performed on each received ARP packet, to help with passive ongoing conflict detection. this extra test adds no packets to the network (nothing extra gets sent!) and barely any CPU work for hosts 🧚, because every host implementing ARP is already required to process every received ARP packet under the Packet Reception rules in RFC 826. those rules already check whether the sender IP address of the ARP packet shows up in any entry in the host's ARP cache. the new test just checks whether the sender IP address is the host's own IP address. that can be as little as one extra machine instruction on lots of architectures, which is honestly iconic 😭

as RFC 826 already says, an ARP Request packet does two jobs at once, an assertion and a question:

Assertion: the fields ar$sha (Sender Hardware Address) and ar$spa (Sender Protocol Address) together make a claim: that the stated Protocol Address is mapped to the stated Hardware Address.
Question: the fields ar$tha (Target Hardware Address, zero) and ar$tpa (Target Protocol Address) together ask: for the stated Protocol Address, which Hardware Address is it mapped to?

this document clarifies what it means to have one of these without the other 🤔

some readers pointed out that it's probably impossible to ask a truly pure question, because asking anything always invites speculation about why you want to know. it's like pointing at an empty seat and asking "Is anyone sitting here?" which secretly means "...because if not, then I will." the same thing happens here. an ARP Probe with an all-zero sender IP address might look like an innocent "Is anyone using this address?" question, but an intelligent implementation that understands how IPv4 Address Conflict Detection works should recognize it as the setup for claiming the address 👀

so if that implementation is also asking the very same question at that exact moment, it should realize they can't both sit in the same seat, and it would be prudent to ask about some other seat 💀

1.2.1. Broadcast ARP Replies 📢

in some applications of IPv4 Address Conflict Detection (ACD), it may be advantageous to deliver ARP Replies using broadcast instead of unicast, because this lets address conflicts get detected sooner than they otherwise might 👑 for example, "Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927] uses ACD exactly as specified here, but it also specifies that ARP Replies should be sent using broadcast. in that context, the trade-off of more broadcast traffic in exchange for better reliability and fault-tolerance was judged to be worth it. there may be other future specifications where the same trade-off makes sense. more details are in Section 2.6, "Broadcast ARP Replies" 🌸

RFC 826 implies that replies to ARP Requests are usually delivered using unicast, but it's also acceptable to deliver ARP Replies using broadcast. the Packet Reception rules in RFC 826 say that the content of the ar$spa field should be processed before the ar$op field is examined. so any host that correctly implements the Packet Reception algorithm in RFC 826 will correctly handle ARP Replies delivered via link-layer broadcast ✨

1.3. Applicability 🎀

this spec applies to all IEEE 802 Local Area Networks (LANs) [802], including Ethernet [802.3], Token-Ring [802.5], and IEEE 802.11 wireless LANs [802.11]. it also applies to other link-layer technologies that run at data rates of at least 1 Mb/s, have a round-trip latency of at most one second, and use ARP [RFC826] to map from IP addresses to link-layer hardware addresses. wherever this document says "IEEE 802", the text applies equally to any of these network technologies 🦋

link-layer technologies that support ARP but run below 1 Mb/s or have latencies above one second will still work correctly with this protocol. they just more often have to deal with late conflicts that get detected after the Probing phase is already finished 😅 on these kinds of links, it may be desirable to specify different values for the following parameters:

(a) PROBE_NUM, PROBE_MIN, and PROBE_MAX, the number of, and interval between, ARP Probes, explained in Section 2.1.
(b) ANNOUNCE_NUM and ANNOUNCE_INTERVAL, the number of, and interval between, ARP Announcements, explained in Section 2.3.
(c) RATE_LIMIT_INTERVAL and MAX_CONFLICTS, controlling the maximum rate at which address claiming may be attempted, explained in Section 2.1.
(d) DEFEND_INTERVAL, the time interval between conflicting ARPs below which a host MUST NOT attempt to defend its address, explained in Section 2.4.

link-layer technologies that don't support ARP might be able to use other techniques for figuring out whether a particular IP address is currently in use. however, implementing Address Conflict Detection for those networks is outside the scope of this document 🙈

for the protocol in this document to be effective, not every host on the link has to implement it. for a given host implementing this spec to be protected against accidental address conflicts, the only requirement is that its peers on the same link correctly implement the ARP protocol as given in RFC 826. to be specific: when a peer host receives an ARP Request whose Target Protocol Address matches (one of) that host's IP address(es) configured on that interface, then as long as it properly responds with a correctly-formatted ARP Reply, the querying host will be able to detect that the address is already in use 🫶

these specs let hosts detect conflicts between two hosts using the same address on the same physical link. ACD does not detect conflicts between two hosts using the same address on different physical links, and honestly it shouldn't. for example, the address 10.0.0.1 [RFC1918] is used by countless devices on countless private networks all over the world, and that is not a conflict, because they're on different links 🌍 it would only be a conflict if two such devices were connected to the same link. and when that happens (as it sometimes does), it's a perfect example of when ACD is super useful for detecting and reporting (and/or automatically correcting) the error 💖

for the purposes of this document, a set of hosts is considered to be "on the same link" if:

when any host, A, from that set sends a packet to any other host, B, in that set, using unicast, multicast, or broadcast, the entire link-layer packet payload arrives unmodified, and
a broadcast sent over that link by any host from that set of hosts can be received by every other host in that set.

the link-layer header may be modified, like in Token Ring Source Routing [802.5], but the link-layer payload may not. specifically, if any device forwarding a packet modifies any part of the IP header or IP payload, then the packet is no longer considered to be on the same link. so a packet can pass through devices such as repeaters, bridges, hubs, or switches and still count as being on the same link for this document. it can't pass through a device like an IP router that decrements the TTL or otherwise modifies the IP header 🔥

wherever this document says "host", it applies equally to interfaces on routers or other multi-homed hosts, whether or not the host/router is currently forwarding packets. routers are often critical network infrastructure with an IP address that's locally well known and assumed to stay relatively constant. for example, the address of the default router is one of the parameters a DHCP server typically tells its clients. and (at least until mechanisms like DHCP Reconfigure [RFC3203] become widely implemented) there isn't any practical way for the DHCP server to tell clients if that address changes. so for devices like this, handling a conflict by picking a new IP address is not a good option 😭 in those cases, option (c) in Section 2.4 ("Ongoing Address Conflict Detection and Address Defense") applies 🧚

even when a device is manually configured with a fixed address, having some other device on the network claim the same IP address will pollute peer ARP caches and stop reliable communication. so it's still helpful to tell the operator. if a conflict is detected at the moment the operator sets the fixed manual address, it's helpful to inform the operator immediately. if a conflict is detected later, it's helpful to inform the operator through some appropriate asynchronous communication channel. even though reliable communication via the conflicted address isn't possible, it may still be possible to reach the operator through another channel that's still working. examples include another interface on the router, a dynamic IPv4 link-local address, a working IPv6 address, or even a completely different non-IP technology like a locally-attached screen or serial console 🌈

2. Address Probing, Announcing, Conflict Detection, and Defense 🔍

this section covers initial probing to safely figure out whether an address is already in use, announcing the chosen address, ongoing conflict checking, and the optional use of broadcast ARP Replies to get faster conflict detection 💅

2.1. Probing an Address 🦋

before a host starts using an IPv4 address (whether it came from manual configuration, DHCP, or some other means), a host implementing this specification MUST test to see if the address is already in use, by broadcasting ARP Probe packets. this also applies when a network interface goes from inactive to active, when a computer wakes from sleep, when a link-state change signals that an Ethernet cable has been connected, when an 802.11 wireless interface associates with a new base station, or when any other change in connectivity happens where a host becomes actively connected to a logical link ✨

a host MUST NOT perform this check periodically as a matter of course. that would waste network bandwidth, and it's unnecessary because hosts can passively discover conflicts, as described in Section 2.4 🫶

2.1.1. Probe Details

okay so, a host checks whether an address is already taken by broadcasting an ARP Request for the address it wants 📣 The client MUST fill in the sender hardware address field with the hardware address of the interface it's sending the packet through 🎀 The sender IP address MUST be all zeroes 🙈 that's so it doesn't mess up the ARP caches of other hosts on the same link if the address turns out to already belong to someone else 💀 The target hardware address gets ignored, so it SHOULD be all zeroes too 🧚 and the target IP address MUST be the address being probed 💖 An ARP Request built this way, with an all-zero sender IP address, is called an 'ARP Probe' 🦋

When the host is ready to start probing, it should wait a random amount of time chosen uniformly from zero up to PROBE_WAIT seconds 🌸 then it should send PROBE_NUM probe packets, each one spaced randomly and uniformly between PROBE_MIN and PROBE_MAX seconds apart ⏰ That random delay at the start is what keeps a bunch of hosts that power on at the same moment from all firing their first probes at once 🫶

If, during this window (from the beginning of probing until ANNOUNCE_WAIT seconds after the last probe goes out), the host receives any ARP packet (Request or Reply) on the interface being probed, and that packet's sender IP address is the address being probed for, then the host MUST treat this address as in use by some other host 🚫 and should tell the configuring agent (human operator, DHCP server, etc.) that the proposed address is not acceptable 💅

The host SHOULD similarly treat it as an address conflict if, during that same window, it gets any ARP Probe whose target IP address is the address being probed for, and whose sender hardware address doesn't match the hardware address of any of the host's interfaces 👀 This can happen when two (or more) hosts have been accidentally set up with the same address, for whatever reason, and they're both probing that address at the same time to see if it's safe to use 😭 It's giving "two people wearing the same outfit to prom" energy, and somebody has to back down 💜

NOTE: The check that the packet's sender hardware address is not the hardware address of any of the host's interfaces is super important ✨ Some kinds of Ethernet hub (often called a "buffered repeater") and many wireless access points may "rebroadcast" any received broadcast packets to all recipients, including the original sender itself 🔁 Because of that, this precaution is needed so a host doesn't get confused when it sees its own ARP packets echoed back to it 🙈

A host implementing this specification MUST take precautions to limit how fast it probes for new candidate addresses 🐢 If the host runs into MAX_CONFLICTS or more address conflicts on a given interface, then the host MUST limit its probing for new addresses on that interface to no more than one attempted new address per RATE_LIMIT_INTERVAL ⏳ This is there to stop catastrophic ARP storms in pathological failure cases, like a defective DHCP server that keeps handing the same address to every host that asks for one 🌪️ This rate limit doesn't only apply to conflicts found during the initial probing phase, either. It also covers conflicts found later, as described in Section 2.4 "Ongoing Address Conflict Detection and Address Defense" 🧠

If, by ANNOUNCE_WAIT seconds after the transmission of the last ARP Probe, no conflicting ARP Reply or ARP Probe has been received, then the host has successfully determined that the desired address may be used safely 🎉🦋

2.2. Shorter Timeouts on Appropriate Network Technologies

New network technologies might show up where shorter delays make more sense than the ones in this document 🚀 A later IETF publication may come out with guidelines for different values of PROBE_WAIT, PROBE_NUM, PROBE_MIN, and PROBE_MAX on those technologies 📚

If different hosts on a link end up using different timing parameters, that's totally fine, no drama 🫧 This protocol doesn't depend on every host on a link running the same version of it. Honestly, it doesn't even depend on every host running the protocol at all 🤷‍♀️ All that's required is that every host implements ARP as specified in RFC 826 and correctly answers the ARP Requests it receives 💌 If some hosts use different timing parameters, the only result is that some hosts configure their interfaces faster than others 🏎️ In the unlikely event that a conflict slips past the address probing phase, the Ongoing Address Conflict Detection described below in Section 2.4 will still catch it 🕵️‍♀️

2.3. Announcing an Address

Once a host has probed and figured out that the address it wants is safe to use, it MUST then announce that it's starting to use the address 📢 It does this by broadcasting ANNOUNCE_NUM ARP Announcements, spaced ANNOUNCE_INTERVAL seconds apart 🎀 An ARP Announcement is identical to the ARP Probe described above, except the sender and target IP addresses are both set to the host's newly selected IPv4 address 🪞 The whole point is to make sure other hosts on the link don't still have stale ARP cache entries left over from whichever host used that address before 🧹 The host may start legitimately using the IP address right after sending the first of the two ARP Announcements. Sending the second one can finish asynchronously, at the same time as whatever other networking stuff the host wants to do 🏃‍♀️💨

2.4. Ongoing Address Conflict Detection and Address Defense

Address Conflict Detection isn't just a one-and-done thing that happens when the interface first gets set up 🙅‍♀️ It's an ongoing process that runs for as long as the host is using an address 🔄 At any time, if a host receives an ARP packet (Request or Reply) where the sender IP address is one of the host's own IP addresses configured on that interface, but the sender hardware address doesn't match any of the host's own interface addresses, then that's a conflicting ARP packet 🚨 It basically means some other host also thinks it's validly using this address. To resolve the conflict, a host MUST respond to a conflicting ARP packet in one of the ways described in (a), (b), or (c) below 💁‍♀️

(a) When a conflicting ARP packet comes in, a host MAY choose to immediately stop using the address and signal an error to the configuring agent, as described above 🛑
(b) If a host has active TCP connections or other reasons to keep its IPv4 address, and it hasn't seen any other conflicting ARP packets within the last DEFEND_INTERVAL seconds, then it MAY try to defend its address 🛡️ To do that, it records the time the conflicting ARP packet was received, then broadcasts one single ARP Announcement, with its own IP and hardware addresses as the sender addresses of the ARP and its own IP address as the target IP address, and the target hardware address set to all zeroes 📣 After that, the host can keep using the address normally with no extra special steps 💕 BUT if this isn't the first conflicting ARP packet the host has seen, and the time recorded for the previous one is recent (within DEFEND_INTERVAL seconds), then the host MUST immediately stop using this address and signal an error to the configuring agent, as described above 🙅‍♀️ This is what stops two hosts from getting stuck in an endless loop, both trying to defend the same address 🔁💀
(c) If a host has been configured so it should never give up its address under any circumstances (maybe because it's the kind of device that needs a well-known, stable IP address, like a link's default router or a DNS server) then it MAY choose to defend its address indefinitely 👑 If a host like that gets a conflicting ARP packet, it should take appropriate steps to log useful information, like the source Ethernet address from the ARP packet, and tell an administrator about the problem 📝 The number of these notifications should be appropriately controlled so it doesn't send a flood of error reports 🌊 If the host hasn't seen any other conflicting ARP packets recently (within the last DEFEND_INTERVAL seconds), then it MUST record the time the conflicting ARP packet was received, and then broadcast one single ARP Announcement giving its own IP and hardware addresses 📣 After that, the host can keep using the address normally with no further special action ✨ BUT if this isn't the first conflicting ARP packet the host has seen, and the time recorded for the previous one is within DEFEND_INTERVAL seconds, then the host MUST NOT send another defensive ARP Announcement 🛑 This keeps two misconfigured hosts from getting stuck in an endless loop, flooding the network with broadcast traffic while they both try to defend the same address 📡💥

A host that wants reliable network operation MUST respond to conflicting ARP packets using (a), (b), or (c) above 🫶 Ignoring conflicting ARP packets leads to seemingly random network failures that are super hard to diagnose and really frustrating for human users 😤

Forced address reconfiguration can be disruptive and break TCP (and other transport-layer) connections 💔 That should be exceedingly rare, though. If inadvertent address duplication happens, disrupted communication is basically inevitable 😬 Two different hosts using the same IP address on the same network just can't operate reliably. Period 🙅‍♀️

Before giving up an address because of a conflict, hosts SHOULD actively try to reset any existing connections using that address 🔌 This helps reduce some of the security threats that address reconfiguration brings, which are covered in Section 5 🔐

For most client machines that don't need a fixed IP address, the best way to get useful communication back as fast as possible is to immediately ask the configuring agent (human user, DHCP client, etc.) for a new address as soon as the conflict is detected 🏃‍♀️💨 The single-ARP-Announcement defense from (b) helps a bit, since it gives one of the two conflicting hosts a better shot at keeping its address 🤞🦋

2.5. Continuing Operation ✨

okay bestie, so from the moment a host sends its very first ARP Announcement 🦋 until it stops using that IP address, the host MUST answer ARP Requests the usual way the ARP spec [RFC826] says. like, whenever a host gets an ARP Request that is not a conflicting ARP packet (the kind we talked about in Section 2.4 💅), and its 'target IP address' is (one of) the host's own IP address(es) configured on that interface, it MUST respond with an ARP Reply as described in RFC 826. 💖 This applies equally to standard ARP Requests with a non-zero sender IP address AND to Probe Requests with an all-zero sender IP address. no exceptions, periodt 💀

2.6. Broadcast ARP Replies 📡

so picture a network that's really well run 🧚, where the addresses are assigned by hand, or there's a reliable DHCP server and reliable DHCP clients. in that world, address conflicts should only happen in rare failure scenarios 🙈, so the passive monitoring from Section 2.4 is totally adequate. if two hosts are using the same IP address, then sooner or later one of them (or the other) will broadcast an ARP Request, the other one will see it, and the conflict gets caught and sorted out 🫶

BUT ngl there's a plot twist 😭. say hosts A and B were accidentally given the same IP address, X. now imagine that while they were both probing to see if the address was safe to use, the link between them was broken for some reason, so neither one caught the conflict when the interface was being configured. then the link comes back online, and a third host, C, broadcasts an ARP Request for address X. A and B don't know about any conflict, so BOTH of them send unicast ARP Replies to host C. host C sees both Replies and is like "wait, what??" 💀, but neither A nor B sees the other's Reply, so neither one immediately realises there's a conflict to fix. A and B stay clueless until one of them broadcasts an ARP Request of its own. that's the lowkey tea 🍓

if you want quicker conflict detection, you can have hosts send ARP Replies using link-level broadcast, instead of only sending ARP Requests via broadcast and Replies via unicast ✨. this is NOT RECOMMENDED for general use 🚫, but other specs that build on IPv4 ACD may choose to specify broadcast ARP Replies if it makes sense for them. for example, "Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927] specifies broadcast ARP Replies, because in that context, IPv4 ACD isn't just a backup check to catch failures of some other configuration method. IPv4 ACD is the ONLY configuration mechanism there 🦋

broadcasting Replies does bump up the broadcast traffic, but in the worst case by no more than a factor of two 📈. in traditional ARP, a unicast ARP Reply only shows up in response to a broadcast ARP Request, so sending those via broadcast means we make at most one broadcast Reply for each existing broadcast Request. on lots of networks, ARP is such a tiny slice of the total traffic that doubling it makes zero practical difference 💅. however, that's not true on every network, so broadcast ARP Replies SHOULD NOT be used universally 🙅‍♀️. they should only be used where the faster conflict detection is worth more than the extra broadcast traffic and the extra packet processing load on the hosts on the network 💜

3. Why Are ARP Announcements Performed Using ARP Request Packets and Not ARP Reply Packets? 🤔

so during the IETF's discussions on IPv4 Address Conflict Detection from 2000 to 2008 🕰️, people kept asking the same question: "Shouldn't ARP Announcements be done with gratuitous ARP Reply packets?"

honestly, that sounds reasonable at first 💖. a regular ARP Reply is an answer to a question. if no question was actually asked, then calling that reply "gratuitous" fits perfectly ✨.

the term "gratuitous reply" would seem to fit an ARP Announcement perfectly too: it's an answer to an implied question that nobody actually asked 🎀.

that all sounds good in theory, but in practice two things tip the scales toward ARP Request packets 💅. one is historical precedent, and the other is pragmatism.

the historical precedent is that (as described above in Section 4) Gratuitous ARP is documented in Stevens Networking [Ste94] as using ARP Request packets. BSD Unix, Microsoft Windows, Mac OS 9, Mac OS X, etc., all use ARP Request packets the way Stevens describes 🍎. at this point, trying to make them all switch to ARP Reply packets would be totally futile 🙃.

the practical reason is that ARP Request packets are more likely to work correctly with more existing ARP implementations 🔧, and some of those may not implement RFC 826 entirely correctly. the Packet Reception rules in RFC 826 say the opcode is the last thing to check during packet processing, so in theory it shouldn't matter 🤷‍♀️. but there could be "creative" implementations that process packets differently depending on the ar$op field, and there are several reasons why these are more likely to accept gratuitous ARP Requests than gratuitous ARP Replies:

An incorrect ARP implementation may expect that ARP Replies are only sent via unicast. RFC 826 does not say this, but an incorrect implementation may assume it. the "principle of least surprise" says that when there are two or more ways to solve a networking problem that are otherwise equally good, the one with the fewest unusual properties is the one most likely to have the fewest interoperability problems with existing implementations 🧁. an ARP Announcement needs to broadcast information to all hosts on the link. since ARP Request packets are always broadcast and ARP Reply packets are not, receiving an ARP Request via broadcast is less surprising than receiving an ARP Reply via broadcast 📢.
An incorrect ARP implementation may expect that ARP Replies are only received in response to ARP Requests that the implementation has issued recently. unexpected unsolicited Replies may be ignored 🙉.
An incorrect ARP implementation may ignore ARP Replies where ar$tha doesn't match its hardware address.
An incorrect ARP implementation may ignore ARP Replies where ar$tpa doesn't match its IP address.

in summary, there are more ways a buggy ARP implementation could plausibly reject an ARP Reply (which usually happens because the client asked for it) than an ARP Request (which is already expected to show up unsolicited) 🌸. bestie, that's the whole logic 🦋

4. Historical Note 📜

some readers have claimed that "Gratuitous ARP", as described in Stevens [Ste94], provides duplicate address detection and makes ACD unnecessary. this is incorrect 🙅‍♀️. what Stevens describes as Gratuitous ARP is the exact same packet this document calls an 'ARP Announcement', just with a more descriptive name ✨. this traditional Gratuitous ARP implementation sends only a single ARP Announcement when an interface is first configured 😬. the result? the victim (the existing address holder) logs an error, and the offender keeps going, often without even noticing any problem 💀. both machines then typically go on to use the same IP address and fail to operate properly, because they're each constantly resetting the other's TCP connections 🥲. the human admin is expected to spot the log message on the victim machine and fix the damage after the fact. usually that means physically walking over to the machines, since in this state neither one can keep a TCP connection open long enough to do anything useful over the network 🏃‍♀️

Gratuitous ARP does not actually provide effective duplicate address detection 🚫. and (as of January 2008) many of the top results for a Google search for the phrase "Gratuitous ARP" are articles explaining how to disable it 😭.

BUT implementers of IPv4 Address Conflict Detection should know that, as of this writing, Gratuitous ARP is still widely deployed 🌍. the steps described in Sections 2.1 and 2.4 of this document help make a host robust against misconfiguration and address conflicts, even when the other host is not playing by the same rules 👑

5. Security Considerations 🔐

okay this part is serious, so stay with me 🫶. IPv4 Address Conflict Detection (ACD) is based on ARP [RFC826], so it inherits the security vulnerabilities of that protocol 😱. a malicious host may send fraudulent ARP packets on the network and interfere with the correct operation of other hosts. for example, it's super easy for a host to answer every ARP Request with a Reply giving its own hardware address, which basically claims ownership of every address on the network 💀

this specification makes that existing ARP vulnerability no worse, and in some ways it makes things better 🌈. instead of failing silently with no indication of why, hosts implementing this specification either try to reconfigure automatically, or at least tell the human user what's happening ✨

⚠️ if a host willingly selects a new address in response to an ARP conflict, as described in Section 2.4, subsection (a), this potentially makes it easier for malicious attackers on the same link to hijack TCP connections 😱. having the host actively reset any existing connections before abandoning an address helps reduce this risk 🛡️

6. Acknowledgments 🫶

this document came out of Zeroconf Working Group discussions on IPv4 Link-Local Addressing [RFC3927] 🧚. during that work it wasn't clear to many participants which parts of link-local address management were specific to that particular problem space (e.g., random selection of an address), and which parts were generic and applicable to all IPv4 address configuration mechanisms (e.g., the detection of address conflicts) 🤔. the following people made valuable comments during that work and/or the later editing of this document, and they are amazing 💖: Bernard Aboba, Randy Bush, Jim Busse, James Carlson, Alan Cox, Spencer Dawkins, Pavani Diwanji, Ralph Droms, Donald Eastlake III, Alex Elder, Stephen Farrell, Peter Ford, Spencer Giacalone, Josh Graessley, Erik Guttman, Myron Hattig, Mike Heard, Hugh Holbrook, Richard Johnson, Kim Yong-Woon, Marc Krochmal, Rod Lopez, Rory McGuire, Satish Mundra, Thomas Narten, Erik Nordmark, Randy Presuhn, Howard Ridenour, Pekka Savola, Daniel Senie, Dieter Siegmund, Valery Smyslov, Mark Townsley, Oleg Tychev, and Ryan Troll 👑🌸

7. References 📚

7.1. Normative References 💅

[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982. 🦋

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💜

7.2. Informative References ✨

okay so these are the "for more context, bestie" sources 📚 nothing here is required reading, but they're the receipts behind the story 🫶

[802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.

[802.3] ISO/IEC 8802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3-1996), 1996.

[802.5] ISO/IEC 8802-5 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 5: Token ring access method and physical layer specifications, (also ANSI/IEEE Std 802.5-1998), 1998.

[802.11] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1999, 1999.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.

[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001.

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.

[Ste94] W. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.

Author's Address 🎀

Here's where you can find Stuart, the author, and his contact info:

Stuart Cheshire
Apple Inc.
1 Infinite Loop
Cupertino
California 95014
USA

Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org

Full Copyright Statement 💜

Copyright (C) The IETF Trust (2008). The rights are all tucked into BCP 78. Except for what's set out there, the authors keep all their rights 🦋

The legal disclaimer, word for word because it really matters:

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🌸

The IETF isn't picking a side on whether any patents or other IP rights covering the tech in this doc are valid or how far they reach, or whether you could get a license for them. It also isn't claiming it searched for any of that stuff. If you want the rules on IP in RFCs, check out BCP 78 and BCP 79 🧚

If you want copies of IPR disclosures sent to the IETF Secretariat, or the licensing assurances people have made, or the results of trying to get a general license for implementers or users, look in the IETF's online IPR repository at http://www.ietf.org/ipr.

The IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that could cover tech needed to build this standard to tell them about it. Send that info to ietf-ipr@ietf.org ✨

📦 where this page comes from

ietf: rfc5227 2008-07
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms