Read

ARP — turning IP addresses into MAC addresses

When you send a packet to 10.0.0.42 over Ethernet, the kernel needs to know which physical machine on the wire that IP belongs to. That's the job of ARP (RFC 826).

Request / reply

The protocol fits in one Ethernet frame:

Sender:    "Who has 10.0.0.42? Tell 10.0.0.1"         (broadcast)
Target:    "10.0.0.42 is at aa:bb:cc:dd:ee:ff"        (unicast reply)

The on-the-wire packet is small but rigid (EtherType 0x0806):

The cache

You don't broadcast every time. Each host keeps an ARP cache: IP → (MAC, age). Entries live ~60s (Stevens vol 1, ch 4). If the answer isn't cached, the resolver:

1. Queues the outgoing packet.
2. Sends an ARP request (broadcast).
3. When the reply arrives, fills the cache and dequeues the packet.

This is why the first packet to a new host has higher latency — you're paying an extra round trip on the LAN.

Why you need it

The Internet was designed so that layer 3 (IP) is independent of layer 2 (Ethernet, Wi-Fi, ATM…). ARP is the bridge: it lets IP say "deliver to 10.0.0.42" without knowing how Ethernet addresses work.

Failure modes

• Stale entry: a server reboots and gets a different NIC. Old peers send to a dead MAC until the cache expires.
• ARP spoofing: anyone on the LAN can send a forged reply ("10.0.0.1 is at my MAC"). This is how local MITM attacks bootstrap.
• Storms: a misconfigured switch can flood ARP requests, melting the LAN.

In your build, you'll implement a tiny cache: ENTRY adds a static entry, QUERY looks one up (and emits an ARP request line if missing), and REPLY records an inbound reply.