Skip to content

ARP

DHCP just handed a device an IP address. That address is enough for the device to know, in the abstract, that it wants to send traffic to 192.168.1.1. It's nowhere near enough to actually put a frame on the wire — Ethernet doesn't run on IP addresses at all, and the MAC address article already named the protocol that closes this gap without going into how it actually works. This is that protocol.

The one question ARP answers

ARP — Address Resolution Protocol, defined in RFC 826 — answers exactly one question: "which device on this local network segment holds this IP address, and what's its MAC address?" Nothing more. It doesn't route, doesn't carry application data, and has no concept of anything beyond the local segment — which is precisely why it exists as its own separate protocol rather than being folded into IP or Ethernet: IP handles addressing across networks, Ethernet handles delivery on the wire, and something distinct has to bridge exactly those two layers where they meet.

A device that already has an IP address to reach — its default gateway, or another host on the same subnet — checks its own ARP cache first, the same ip neigh show table introduced when MAC address covered reading it. Only on a cache miss does ARP actually do any work on the wire.

Request and reply, broadcast and unicast

An ARP exchange is two packets, structured very differently from each other:

sudo tcpdump -i eth0 -n arp

12:03:10.001233 ARP, Request who-has 192.168.1.1 tell 192.168.1.42, length 28
12:03:10.001890 ARP, Reply 192.168.1.1 is-at 5c:1a:6f:22:4b:e0, length 46

The request — "who has 192.168.1.1? tell 192.168.1.42" — is sent to the broadcast MAC address ff:ff:ff:ff:ff:ff, because the sender has no way to address the one device that actually holds that IP; it doesn't know that device's MAC address yet, which is the entire reason it's asking. Every device on the segment receives the broadcast, but only the one whose own IP address matches actually replies.

The reply is unicast, sent directly back to the requester's MAC address, since by this point the replying device has learned it from the request packet itself. This asymmetry — broadcast question, targeted answer — is the whole shape of ARP: broadcast is only needed for the one thing nobody yet knows an address for, and everything after that can be addressed directly.

What's actually in each packet

An ARP packet carries five fields relevant in practice, on top of a hardware- and protocol-type pair that's essentially always Ethernet and IPv4 on a modern network:

  • Opcode — 1 for a request, 2 for a reply.
  • Sender hardware address and sender protocol address — the MAC and IP address of whoever sent this packet.
  • Target hardware address and target protocol address — who the packet is addressed to; in a request, the target hardware address is left blank (all zeros), since that's precisely the field the whole exchange exists to fill in.

Every device on the segment updates its own ARP cache from every ARP packet it observes, not just replies addressed to it — a request broadcast to everyone also tells everyone else on the segment the sender's own IP-to-MAC mapping, learned for free without a dedicated exchange of their own.

Gratuitous ARP: announcing an address nobody asked about

A device can send an ARP packet unprompted, with its own IP address as both sender and target — a gratuitous ARP. Nobody asked, and no reply is expected; the point is purely to update every other device's cache proactively. Two situations use this in practice:

  • Duplicate address detection. A device that's just been assigned an address (by DHCP or statically) sends a gratuitous ARP for its own IP. If another device on the segment replies claiming that same address, the newly configured device knows immediately that a conflict exists, before it ever sends real traffic under a contested address.
  • Failover. When a virtual IP address moves from one physical device to another — a common pattern in high-availability setups, where a standby server takes over a shared address after the primary fails — the new holder sends a gratuitous ARP announcing the move, so every switch and host on the segment updates its cache immediately rather than waiting for stale entries to expire and be re-resolved the slow way.

ARP doesn't exist in IPv6

Everything above is specific to IPv4. IPv6 replaces ARP entirely with Neighbor Discovery Protocol, which runs as a set of ICMPv6 message types instead of its own separate protocol — a design choice that folds address resolution into the same control-message framework IPv6 already needs for other purposes. The job is identical; the mechanism and the packet format are not. This course covers ICMP next, which is the right moment to note the connection, even though the details of Neighbor Discovery itself sit outside this course's scope.

Practical scenario: a spoofed gateway redirects traffic

A shared office network suddenly has intermittent, unexplained slowness reaching the internet, though the internal network works fine. Checking the ARP cache on an affected machine turns up something wrong:

ip neigh show 192.168.1.1

192.168.1.1 dev eth0 lladdr aa:bb:cc:dd:ee:ff REACHABLE

The legitimate gateway's MAC address, confirmed by checking the router directly, is 5c:1a:6f:22:4b:e0 — not this. Something on the segment has been sending gratuitous ARP replies claiming to be 192.168.1.1, and because ARP has no authentication built in at all — any device can claim any IP address, and every other device simply believes the most recent reply it saw — every machine that received the forged announcement now sends its internet-bound traffic to the wrong MAC address first. This is ARP spoofing (or ARP cache poisoning), the mechanism behind a large class of local-network man-in-the-middle attacks, and it works precisely because ARP was designed for a trusted, cooperative local segment, with no way built in to ask "prove you're actually the device you claim to be."

Fixing an active instance means finding and removing the offending device — a specific host is sending these forged replies, and identifying which one usually means comparing MAC addresses seen in a packet capture against the network's known device inventory. Preventing recurrence is a switch-configuration matter (features like Dynamic ARP Inspection validate ARP packets against a known-good binding table before forwarding them) rather than anything fixable from an individual host.

Common mistakes

  • Confusing ARP with DNS. Both "resolve" one kind of identifier into another, but DNS maps names to IP addresses globally and recursively, while ARP maps IP addresses to MAC addresses on a single local segment and nothing further.
  • Assuming an ARP reply is authenticated. It isn't, at the protocol level — anything claiming to be a given IP address is simply believed by default, which is exactly the property ARP spoofing exploits.
  • Treating a stale ARP entry as a hardware fault. An entry marked STALE in ip neigh show is completely normal — it means the cache hasn't confirmed that mapping recently, not that anything is broken; it gets re-verified automatically before its next use.

Practice exercises

  1. Run sudo tcpdump -i any -n arp while pinging a device on your own local network for the first time in a while, and identify the request and reply packets by opcode.
  2. Explain why an ARP request has to be broadcast, while an ARP reply doesn't — tie your answer to what each side of the exchange does and doesn't know at that point.
  3. A teammate says gratuitous ARP is "just ARP with no real purpose, since nobody asked for it." Using the duplicate-address-detection and failover cases above, explain what it's actually for.

ARP resolves an address. It says nothing about whether a host is actually reachable, or how far away it is, or what went wrong when a packet doesn't arrive — that diagnostic layer belongs to a different protocol entirely, one that rides directly on top of IP itself: Introduction to ICMP.

Sources