IPv4 Address Conflict Detection
updates
- rfc-826 — An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware
Extracted elements (23)
ARP Announcements use ARP Request packets rather than ARP Reply packets for two reasons: (1) historical precedent — Stevens [Ste94] and all major OS implementations (BSD, Windows, Mac OS) use Request packets; (2) pragmatism — incorrect ARP implementations are more likely to reject unsolicited broadcast Replies (expecting Replies only via unicast or only in response to recent Requests) than to reject broadcast Requests, which are already expected unsolicited.
Probes are spaced with a random initial delay (0–PROBE_WAIT) so that a large number of hosts powered on simultaneously do not all send initial probe packets at the same moment, preventing synchronized ARP storms at boot time.
The ARP Probe uses an all-zero 'sender IP address' to avoid polluting ARP caches on other hosts in the case where the probed address turns out to be already in use; if the sender IP were set to the desired address, other hosts would cache the mapping before the probe confirmed the address is safe to use.
ACD does not require all hosts on the link to implement this specification; it only requires that peers correctly implement RFC 826 ARP. If a peer correctly responds to ARP Requests targeting its address, the probing host can detect the conflict even if the peer does not implement ACD.
Traditional 'Gratuitous ARP' (a single ARP Announcement on interface configuration, as described in Stevens [Ste94]) does not provide effective duplicate address detection: the victim logs an error, but both hosts continue trying to use the same address, continually resetting each other's TCP connections.
When receiving an echoed-back ARP probe (e.g., from a buffered repeater or wireless access point that rebroadcasts to all recipients including the sender), a host MUST check that the 'sender hardware address' does not match any of its own interfaces before treating the packet as a conflict signal.
A host MUST NOT perform ARP probing periodically as a matter of course, as this would waste network bandwidth and is unnecessary given passive conflict detection via ongoing monitoring.
At any time, if a host receives an ARP packet where the 'sender IP address' matches the host's own address but the 'sender hardware address' does not match, the host MUST respond by either (a) ceasing to use the address, (b) defending once if not defended within DEFEND_INTERVAL, or (c) defending indefinitely for fixed-address infrastructure. Ignoring conflicting ARP packets is not acceptable.
Before abandoning an address due to a conflict, hosts SHOULD actively attempt to reset any existing connections using that address, to mitigate the TCP hijacking security risk posed by address reconfiguration.
Before using any IPv4 address (whether from manual configuration, DHCP, or any other source), a host MUST test to see if the address is already in use by broadcasting ARP Probe packets. This also applies when an interface transitions from inactive to active, when waking from sleep, or when any connectivity change occurs.
Broadcast ARP Replies are NOT RECOMMENDED for general use; they increase broadcast traffic. They SHOULD NOT be used universally but may be appropriate where faster conflict detection outweighs the cost of increased broadcast load, as specified in RFC 3927 for link-local addressing.
During probing, if the host receives any ARP packet (Request or Reply) where the 'sender IP address' is the address being probed, the host MUST treat the address as in use and indicate to the configuring agent that the address is not acceptable.
From the time a host sends its first ARP Announcement until it ceases using the address, the host MUST answer ARP Requests as required by RFC 826, including Probe Requests with all-zero sender IP addresses.
Having successfully probed, a host MUST announce use of the address by broadcasting ANNOUNCE_NUM ARP Announcements spaced ANNOUNCE_INTERVAL seconds apart. The host may begin using the address immediately after sending the first announcement.
If a host experiences MAX_CONFLICTS (10) or more address conflicts on a given interface, it MUST limit the rate at which it probes for new addresses to no more than one new address per RATE_LIMIT_INTERVAL (60 seconds), to prevent catastrophic ARP storms from defective DHCP servers.
When defending an address (option b or c in Section 2.4), if a second conflicting ARP packet is received within DEFEND_INTERVAL seconds of the previous one, the host MUST NOT send another defensive ARP Announcement, to prevent both hosts from flooding the network in an endless broadcast loop.
An 'ARP Announcement' is an ARP Request broadcast identical to an ARP Probe except both sender and target IP address fields contain the host's newly selected IPv4 address. It conveys the stronger statement 'This is the address I am now using.'
An 'ARP Probe' is an ARP Request broadcast on the local link with the 'sender IP address' (ar$spa) set to all zeroes and the 'target IP address' (ar$tpa) set to the address being probed. The all-zero sender IP prevents polluting ARP caches if the address is already in use.
Timing constants governing the ACD protocol: PROBE_WAIT=1s, PROBE_NUM=3, PROBE_MIN=1s, PROBE_MAX=2s, ANNOUNCE_WAIT=2s, ANNOUNCE_NUM=2, ANNOUNCE_INTERVAL=2s, MAX_CONFLICTS=10, RATE_LIMIT_INTERVAL=60s, DEFEND_INTERVAL=10s. These are fixed constants not modifiable by implementers or operators.
ACD inherits ARP's security vulnerabilities: a malicious host can send fraudulent ARP packets, including answering all ARP Requests with its own hardware address to claim ownership of every address on the network. This specification does not worsen the existing ARP vulnerability but improves visibility by causing hosts to either reconfigure automatically or alert the user rather than failing silently.
If a host selects a new address in response to an ARP conflict (option (a) in Section 2.4), this potentially makes it easier for malicious attackers on the same link to hijack TCP connections by forcing address reconfiguration. Actively resetting existing connections before abandoning an address mitigates this risk.
ACD proceeds through three phases: (1) Probing — wait random 0–PROBE_WAIT seconds, then send PROBE_NUM probes spaced PROBE_MIN–PROBE_MAX apart; (2) Announcing — if no conflict after ANNOUNCE_WAIT seconds post-last-probe, broadcast ANNOUNCE_NUM announcements ANNOUNCE_INTERVAL apart; (3) Ongoing conflict detection — monitor for conflicting ARP packets for the full duration the address is in use.
In an ARP Probe: 'sender hardware address' (ar$sha) MUST contain the sending interface's hardware address; 'sender IP address' (ar$spa) MUST be all zeroes; 'target hardware address' (ar$tha) is ignored and SHOULD be set to all zeroes; 'target IP address' (ar$tpa) MUST be set to the address being probed.