ARP maps IP addresses to MAC addresses within a LAN — without it, you can't actually deliver a packet to a physical machine even if you know its IP.

* ARP resolves IP→MAC: broadcast the question, unicast the reply, cache it. *

The core problem:

• The network you're talking on (Ethernet, WiFi) speaks MAC addresses (Layer 2)
• The applications you run speak IP addresses (Layer 3)
• When you want to send 192.168.1.5 something, the NIC needs to know: which MAC address does that correspond to?

How ARP solves it:

1. Host wants to send to 192.168.1.5 — checks its ARP cache
2. Cache miss → sends an ARP Request as a broadcast: "Who has 192.168.1.5?"
3. The host with that IP replies with its MAC: "192.168.1.5 is at AA:BB:CC:DD:EE:FF"
4. Sender stores the mapping in its ARP cache for future use

Why it's needed only on a LAN:

• ARP only works within a single broadcast domain (LAN segment)
• For traffic going to other networks, the host ARPs for the default gateway's MAC instead — the gateway then handles the rest of the journey via routing

Inspect/clear the ARP cache:

arp -a       # view ARP table (Windows/Linux)
arp -d       # delete entries (Windows, requires admin)
ip neigh     # modern Linux equivalent

Tip: The classic "Layer 2 vs Layer 3" confusion clears up if you remember: routers operate on IP, switches operate on MAC. ARP is the bridge between them.

Go deeper:

• Address Resolution Protocol (Wikipedia) — full packet-format breakdown, ARP cache behaviour, and the spoofing attacks built on it.
• RFC 826 — An Ethernet Address Resolution Protocol — the original 1982 spec; short enough to read end-to-end and see exactly why the target-MAC field starts empty.