Why ARP Exists

Two address systems, and the translation between them

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Explain why a host needs a MAC address when it already knows the IP address
▸Read an ARP request and reply field by field in real bytes
▸Predict which address a host will ARP for, given a destination and a subnet mask

Before this lesson — it builds directly on:

TCP Foundations

It looks like wasteful duplication: every machine has a MAC address AND an IP address. Why not one? Because they solve different problems. A MAC address is fixed in hardware and cannot be organised — the machines on your office wire have addresses from a dozen manufacturers with nothing in common. That is fine for one wire, where you can just shout and see who answers. It is hopeless for the internet, where no router could possibly hold a list of every machine alive. An IP address is assigned, so it can be organised into blocks. A router only has to know 'anything starting 10.0.2 goes that way' rather than knowing every individual machine. So: IP addresses to find your way across the world, MAC addresses to make the final delivery on the last wire. ARP is the bridge between them.

✗ Common misunderstanding: ARP is part of IP, or runs on top of it.

Why that's wrong: An ARP packet has no IP header at all. It sits directly inside the Ethernet frame with EtherType 0x0806, alongside IP rather than inside it.

Correct model: ARP is a peer of IP at the same level, not a passenger. That is why it has its own address fields instead of using IP's.

The packets prove it: Open any ARP packet's layer list: Ethernet then ARP. There is no IPv4 layer to expand.

✗ Common misunderstanding: Every packet needs an ARP exchange first.

Why that's wrong: The result is cached. One resolution serves every packet to that address until the entry ages out, which can be minutes.

Correct model: ARP costs one round trip per cache lifetime, not per packet. Captures show far less ARP than people expect.

The packets prove it: The cache-hit scenario is the same ping as the first lesson with warm caches — two packets total, no ARP at all.

Watch these fields in the lab: eth.destinationMac · eth.sourceMac

MAC addressglossary: A 48-bit address identifying one network interface, written as six hex pairs (02:00:00:00:01:10). Normally assigned by the manufacturer, but settable in software — virtual interfaces, containers and phones doing per-network randomisation all use addresses that were never burned into anything. It means nothing beyond its own wire.
Broadcast: A frame addressed to ff:ff:ff:ff:ff:ff, which every station on the segment receives and examines. It is how you ask a question when you don't know who to ask.
Broadcast domainglossary: Everything a broadcast reaches. Switches extend it; routers stop it. Since ARP relies on broadcast, this is exactly the region ARP can resolve within.
ARP cacheglossary: The table of IP-to-MAC mappings a host has learned, each with an expiry timer. Run `arp -a` on almost any system to see yours.
EtherType: A two-byte field at the end of the Ethernet header saying what comes next. 0x0800 means an IP packet follows; 0x0806 means an ARP message. This is how a receiver knows which decoder to use.

Watch these fields in the lab: eth.etherType

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Why can't the network just use IP addresses all the way down and skip MAC addresses?

A host has just sent an ARP request and is waiting. What is happening to the data it wanted to send?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.