🔗 03-03: ARP Protocol Recap¶

📌 What Problem Does ARP Solve?¶

Devices on a LAN (Local Area Network) actually need two addresses to talk to each other:

An IP address (Layer 3) — used for logical, routable addressing (e.g., 192.168.1.10)
A MAC address (Layer 2) — a physical, hardware-burned address used by Ethernet/Wi-Fi to actually deliver a frame to the right NIC (e.g., AA:BB:CC:11:22:33)

👉 When your computer wants to send a packet to 192.168.1.20 on the same LAN, it knows the IP address — but Ethernet frames are delivered using MAC addresses. Something has to translate one into the other.

That something is ARP — the Address Resolution Protocol.

💡 Analogy: Think of the IP address like someone's name ("Alice") and the MAC address like their exact seat number in a classroom. Knowing someone's name doesn't tell the delivery person where to physically hand a note — ARP is like shouting "Which seat is Alice in?" and having Alice shout back her seat number.

🔄 How ARP Works: Request and Reply¶

ARP operates with a simple two-message exchange:

1. ARP Request (Broadcast)¶

When Host A wants to reach 192.168.1.20 but doesn't know its MAC address, it sends an ARP Request:

Who has 192.168.1.20? Tell 192.168.1.10

This is sent as an Ethernet broadcast (destination MAC FF:FF:FF:FF:FF:FF)
Every device on the LAN receives and processes it
Only the device that actually owns 192.168.1.20 is expected to respond

2. ARP Reply (Unicast)¶

The owner of 192.168.1.20 responds directly to the requester:

192.168.1.20 is at AA:BB:CC:11:22:33

This is sent as a unicast frame straight back to Host A
Host A now stores this mapping for future use

Host A (192.168.1.10)                Host B (192.168.1.20)
        │                                     │
        │──── ARP Request (broadcast) ───────▶│  "Who has .20?"
        │                                     │
        │◀──── ARP Reply (unicast) ───────────│  ".20 is at AA:BB:CC:..."
        │                                     │

🗄️ The ARP Cache (ARP Table)¶

Doing a broadcast request for every single packet would be wasteful, so every device keeps an ARP cache — a local table mapping IP addresses to MAC addresses, with each entry kept for a limited time (the ARP cache timeout, often on the order of minutes).

Viewing the ARP Cache¶

# Linux / macOS
ip neigh
arp -a

# Windows
arp -a

Example output:

Address           HWtype  HWaddress            Flags   Iface
192.168.1.1       ether   AA:BB:CC:00:00:01    C       eth0
192.168.1.20      ether   AA:BB:CC:11:22:33    C       eth0

👉 Before sending any packet, a device first checks its ARP cache. Only if there's no entry (a cache miss) does it bother broadcasting an ARP Request.

🧮 Worked Example: Resolving an IP to a MAC¶

Let's walk through a concrete scenario on the LAN 192.168.1.0/24:

Alice's laptop (192.168.1.10) wants to send a packet to Bob's desktop (192.168.1.20). Her ARP cache has no entry for .20.
Alice's NIC broadcasts: ARP Request: Who has 192.168.1.20? Tell 192.168.1.10 (AA:11:11:11:11:11)
Every device on the LAN receives the broadcast frame and inspects it. The router, printer, and any other hosts silently ignore it because the target IP isn't theirs.
Bob's desktop recognizes 192.168.1.20 as its own IP, and replies directly to Alice: ARP Reply: 192.168.1.20 is at BB:22:22:22:22:22
Alice's machine stores 192.168.1.20 → BB:22:22:22:22:22 in its ARP cache.
Alice's NIC now builds an Ethernet frame with destination MAC BB:22:22:22:22:22, encapsulating the IP packet destined for 192.168.1.20, and sends it — no further ARP lookup needed until the cache entry expires.

💡 This same process happens even for traffic leaving the LAN: your computer doesn't ARP for the final destination IP if it's off-network — it ARPs for the MAC address of its default gateway (the router), and lets the router handle forwarding from there.

⚠️ Why ARP Has Zero Authentication¶

Here's the critical design flaw that the rest of this module builds on: ARP was designed in an era (1982, RFC 826) when LANs were assumed to be trusted environments. As a result, ARP has no built-in security whatsoever:

No authentication — any device can claim to own any IP address. There is no signature, password, or credential proving "I really am 192.168.1.20."
No integrity checking — ARP replies aren't checked against anything besides "does this look like a well-formed ARP reply."
Replies are trusted even when unsolicited. Many operating systems will accept a "gratuitous ARP" reply (one that wasn't even requested) and update their cache anyway — a feature meant to help hosts announce IP changes efficiently, but easily abused.
Broadcast nature means everyone hears every request, which is efficient, but it also means the attack surface (who can respond) includes every device on the segment.

👉 In short: ARP operates entirely on trust. A host receiving a reply saying "192.168.1.1 is at THIS mac address" has no way to verify that claim is actually true.

🔥 This is precisely the weakness that ARP spoofing / ARP cache poisoning exploits — an attacker simply sends forged ARP replies claiming to own an IP address (like the default gateway), and victims believe it unconditionally. We cover this attack in full in 03-04: ARP Spoofing Attacks.

📌 Key Takeaways¶

ARP (Address Resolution Protocol) maps IP addresses (Layer 3) to MAC addresses (Layer 2) so Ethernet frames can actually be delivered on a LAN.
The exchange is a broadcast ARP Request ("Who has this IP?") followed by a unicast ARP Reply ("This IP is at this MAC").
Devices cache resolved mappings in an ARP cache/table to avoid repeating the broadcast for every packet, with entries expiring after a timeout.
Off-LAN traffic still uses ARP — hosts resolve the MAC address of the default gateway/router, not the final destination.
ARP was designed for trusted networks and has no authentication or integrity verification — any device can claim any IP address.
Many systems even accept unsolicited ("gratuitous") ARP replies, updating their cache without ever having asked.
This complete lack of authentication is the root cause that makes ARP spoofing possible, covered next in 03-04: ARP Spoofing Attacks.