RFC 826 · November 1982 · D. Plummer
An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware
Index fetched 2026-10-19 from rfc-editor.org
How it works
Built by hand from RFC 826. Every arrow, step and field cites the RFC sentence it comes from, and an automated test checks each quote against the RFC text. Provisional: not yet reviewed by a second engineer. Help verify this visual
RFC 826 Let there exist machines X and Y that are on the same 10Mbit Ethernet cable.
1. Machine X → Machine Y: ares_op$REQUEST
X has no table entry for Y's protocol address, so it builds a REQUEST carrying its own hardware and protocol addresses plus Y's protocol address, leaves the target hardware address unset, and broadcasts it.
RFC 826(ar$op) = ares_op$REQUEST (ar$sha) = EA(X) (ar$spa) = IPA(X) (ar$tha) = don't care (ar$tpa) = IPA(Y) and broadcasts this packet to everybody on the cable.
2. Machine Y → Machine X: ares_op$REPLY
Y sees it is the target, records X's mapping, then turns the same packet into a REPLY: it swaps the sender and target fields, puts its own addresses in the sender fields and sends it straight back to X, not broadcast.
RFC 826Swap hardware and protocol fields, putting the local hardware and protocol addresses in the sender fields. Set the ar$op field to ares_op$REPLY Send the packet to the (new) target hardware address on the same hardware on which the request was received.
Not shown: The Ethernet transmission-layer header in front of the ARP data (destination, sender, type = ether_type$ADDRESS_RESOLUTION); The full receive algorithm (hardware/protocol checks, Merge_flag and translation-table updates before the opcode is examined); Network monitoring and debugging use of ARP; Table aging and timeouts, which the RFC places outside the protocol's scope.
Lineage
Text
Loading the RFC text…