Under RFC 5227 IPv4 address conflict detection, how does an ARP Probe differ from an ARP Announcement, and why does the probe carry sender IP 0.0.0.0?
answer
- ask first, then claim
- all-zero sender IP
- do not pollute other caches
- three probes, two announcements
- keep listening while the address lives
basics
~10 sAn ARP Probe asks whether an IPv4 address is free, with sender IP 0.0.0.0 so it cannot overwrite anyone's cache; an ARP Announcement then claims it, with sender IP equal to target IP.
solid answer
~50 sBoth are broadcast ARP Requests carrying the host's real MAC and the candidate address as target IP; they differ in the **sender IP**. An **ARP Probe** sets it to `0.0.0.0`: it asks "is anyone using this?" without asserting ownership, so if the address is taken, no neighbour's entry for the real owner gets overwritten by RFC 826's merge rule. An **ARP Announcement** sets sender IP = target IP: "this is now mine", deliberately refreshing caches. RFC 5227 has a host wait a random 0-1 second, send 3 probes spaced 1-2 seconds apart, and listen until 2 seconds after the last; any ARP whose sender IP is the candidate, or a rival probe from another MAC, means conflict. Otherwise it sends 2 announcements 2 seconds apart, then keeps watching for conflicts while it uses the address.
go deeper
Know that a host checks an IPv4 address is free before using it by asking the link, then announces it, and that the check exists because two hosts on one address break each other.
Explain the two packet shapes: probe with sender IP 0.0.0.0, announcement with sender IP equal to target IP, and why the zero sender protects the real owner's entries in other caches.
Walk the RFC 5227 timeline and the ongoing defence options: what counts as a conflict, why probing is not periodic, and why infrastructure addresses defend while clients give up.
Judge what ACD buys and what it does not: it turns silent duplicate-address failures into detected ones at a few seconds of boot cost, but leaves ARP's trust model untouched.
## Why a separate standard was needed RFC 826 defined how ARP resolves addresses but said nothing about checking that an IPv4 address is unused before taking it. The old habit, a single **gratuitous ARP** at boot, turned out to be a poor check: RFC 5227 records that the existing holder merely logged an error while the newcomer carried on, and both then reset each other's TCP connections. **RFC 5227, IPv4 Address Conflict Detection (ACD)**, fixes that without changing ARP's packet format or receive rules. It applies whenever an address is configured, manually or by DHCP, and again when a link comes up, the host wakes from sleep, or a wireless interface joins a new access point. ## Probe versus Announcement Both packets are **ARP Requests** (opcode `1`) broadcast on the local link, with the sender hardware address set to the interface's own MAC and the target hardware address ignored and set to zero. | Field | ARP Probe | ARP Announcement | |---|---|---| | Sender IP | `0.0.0.0` (all zeroes) | the address being claimed | | Target IP | the candidate address | the address being claimed | | Meaning | "Is anyone using this? I hope to." | "This is the address I am now using." | | Effect on neighbours' caches | none: no one has `0.0.0.0` cached | overwrites any existing entry for the address | The all-zero sender IP is the whole point of the probe. RFC 826's receive algorithm overwrites a cached entry whenever a packet's sender IP matches it. If a probe carried the candidate address as sender IP and that address already belonged to another host, every neighbour would repoint its entry to the prober and break the real owner's traffic before the prober even learned of the conflict. With `0.0.0.0` the probe updates nothing. The owner still answers it, because RFC 5227 requires hosts to reply to probes like any other request. ## The timeline RFC 5227 names fixed constants; it states they are not meant to be tuned by implementers or operators. 1. Wait a random time between 0 and `PROBE_WAIT` (1 second), so hosts powered on together do not probe in lockstep. 2. Send `PROBE_NUM` (3) probes, spaced randomly between `PROBE_MIN` (1 second) and `PROBE_MAX` (2 seconds) apart. 3. Keep listening until `ANNOUNCE_WAIT` (2 seconds) after the last probe. The address is in conflict if any ARP Request **or** Reply arrives whose sender IP is the candidate, or (a SHOULD) if another host's probe for the same address arrives from a MAC that is not one of this host's own (two hosts probing at once). 4. With no conflict, send `ANNOUNCE_NUM` (2) announcements, `ANNOUNCE_INTERVAL` (2 seconds) apart. The host may use the address right after the first one. Adding it up, the first announcement goes out roughly 4 to 7 seconds after probing starts. A host that hits `MAX_CONFLICTS` (10) conflicts must slow to one new candidate per `RATE_LIMIT_INTERVAL` (60 seconds), which stops an ARP storm when, for example, a faulty DHCP server hands everyone the same address. ## After the address is in use Probing happens once per configuration event; RFC 5227 says a host MUST NOT probe periodically. Detection continues **passively**: every received ARP packet is already processed under RFC 826, and ACD adds one test, whether its sender IP is this host's own address while its sender MAC is someone else's. When that happens, the host must do one of three things: - **(a) Give up**: stop using the address and tell the configuring agent. - **(b) Defend once**: if it has not seen a conflict within `DEFEND_INTERVAL` (10 seconds), broadcast one announcement and carry on; a second conflict inside that window means it must give up. - **(c) Defend indefinitely**: for devices that must keep a well-known address, such as a link's default router or a DNS server, announce at most once per `DEFEND_INTERVAL`, log the offender's MAC and alert an administrator. ## Related points - RFC 5227 does **not** make ARP secure; a malicious host can still answer every request. It inherits ARP's trust model. - ARP Replies are normally unicast, so two hosts with the same address may not see each other's replies. RFC 5227 permits broadcast replies for faster detection but says NOT RECOMMENDED for general use; RFC 3927 (IPv4 link-local addressing in `169.254/16`) does specify them, because there ACD is the only configuration mechanism. - IPv6 performs the equivalent check with Duplicate Address Detection: a Neighbor Solicitation sent from the unspecified address (RFC 4862).
- How does an IPv4 host under RFC 5227 tell its own echoed probe from a rival's probe for the same address?By the sender hardware address. Some hubs and many wireless access points rebroadcast frames to every station, including the sender. RFC 5227 treats a received probe for the candidate address as a conflict only when its sender MAC is not one of this host's own interfaces, so an echo of its own probe is ignored while a simultaneous prober is detected.
- Why does RFC 5227 let a default router defend its address indefinitely instead of giving it up?A router or DNS server needs a well-known, stable address; surrendering it to a misconfigured client would cut off the whole link. Option (c) lets it keep the address, broadcast at most one defending announcement per DEFEND_INTERVAL of 10 seconds so two defenders cannot flood the link, and log the offender's MAC for an administrator to fix.
saying these in an interview costs you the question
- An ARP Probe puts the candidate address in the sender IP field.
- Classic gratuitous ARP at boot is enough duplicate-address detection.
- Hosts should re-probe their address periodically to catch new conflicts.
- Only an ARP Reply to the probe counts as a conflict; requests are ignored.
- RFC 5227 authenticates ARP, so announcements can no longer be forged.