6. ARP: turning IP addresses into MAC addresses

6.1 Why it exists

You have the next hop's IP (from routing). To build the Ethernet frame you need its MAC. ARP (Address Resolution Protocol, RFC 826) bridges Layer 3 to Layer 2 on IPv4 networks. (IPv6 uses NDP instead — Ch. 17.)

6.2 The exchange

Host A (192.168.1.50, MAC aa:aa) wants to reach 192.168.1.1

A --> BROADCAST (dst ff:ff:ff:ff:ff:ff):
      "ARP Request: Who has 192.168.1.1? Tell 192.168.1.50 (aa:aa)"

Router (192.168.1.1, MAC bb:bb) --> UNICAST to aa:aa:
      "ARP Reply: 192.168.1.1 is at bb:bb"

A caches: 192.168.1.1 -> bb:bb   (state REACHABLE, ~30 s on Linux, then STALE)

ARP frames use EtherType 0x0806 and are not IP packets — no IP header, no TTL, cannot cross a router. ARP scope = one broadcast domain.

6.3 The ARP cache and its states (Linux `ip neigh`)

State	Meaning
`REACHABLE`	Confirmed recently; use freely.
`STALE`	Entry exists but unconfirmed; used, then revalidated on next send.
`DELAY`	Waiting a moment for upper-layer (TCP ACK) confirmation before probing.
`PROBE`	Actively sending unicast ARP requests to reconfirm.
`FAILED`	No answer; will retry on demand.
`PERMANENT`	Static entry, never expires.

6.4 Gratuitous ARP

A host sends an unsolicited ARP reply/request for its own IP:

On boot or IP assignment → duplicate address detection (if someone replies, there's a conflict).
After a failover → tell every host "the IP 10.0.0.10 now lives at my MAC" so switches and hosts update their tables immediately. This is how VRRP/keepalived, cluster VIPs, and cloud "elastic IP" reattachment redirect traffic in <1 s.

6.5 Proxy ARP

A router answers ARP requests for IPs that are not its own, on behalf of hosts it can reach, making two subnets look like one. Mostly legacy; still seen in some VPN and hotspot setups.

6.6 Attacks: ARP spoofing / cache poisoning

ARP has no authentication. Any host can send "10.0.0.1 is at my MAC" and receivers will believe it. Result: attacker becomes a man-in-the-middle for the gateway. Tools: arpspoof, ettercap, bettercap. Defenses:

Dynamic ARP Inspection (DAI) on switches (validates ARP against the DHCP-snooping table).
Static ARP entries for critical gateways.
Encrypt everything end-to-end (TLS) so MITM yields ciphertext.
Port security / 802.1X.

6.7 War story

Two servers were configured with the same IP after a provisioning script bug. Symptoms: intermittent connection resets, arp output flapping between two MACs for that IP, kernel log neighbour ... is not permanent. Every gratuitous ARP from one server stole traffic from the other. Lesson: "IP address already in use" and flapping ip neigh output = duplicate IP or a failover event, not "random network weirdness."

Try it yourself

ip neigh show                       # current table + states
sudo tcpdump -i eth0 -n arp         # watch requests/replies live
ip neigh flush all                  # clear cache (forces re-ARP)
arping -I eth0 192.168.1.1          # manually probe a neighbor
sudo ip neigh add 192.168.1.1 lladdr bb:bb:bb:bb:bb:bb dev eth0 nud permanent