Recognize occupied addresses, competing Probes and echoes
03Conflict checking examines ARP packets received on the interface being tested. The sender-IP test and the competing-Probe test have different requirement levels.
Separate echo: sender IP 0.0.0.0 and matching target, but sender hardware matches one of our interfaces. The competing-Probe check does not report a conflict from that echo.
Source for this drawing: RFC 5227 · Read RFC section 2.1.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Existing claims are MUST conflicts; a competing Probe is a SHOULD conflict.
- From the start of probing through the final2 second wait, any received ARP Request or Reply whose sender IP is the candidate MUST be treated as an occupied address.
- An incoming ARP Probe targeting the same candidate, with sender hardware unlike every hardware address of this host’s interfaces, SHOULD similarly be treated as a conflict.
- The all-interface hardware check prevents an echoed copy of this host’s own Probe from being mistaken for a competitor. The Protocol Address and Hardware Address fields serve different checks.
These are three independent received-packet examples, not successive messages from one peer. In the sender-IP rule, do not add a hardware inequality that the probing rule does not require. The bounded model assumes valid IPv4 ARP on the indicated interface, not arbitrary Ethernet validation.
Read the RFC section ↗