ARP (Address Resolution Protocol) asks, within the same network (one subnet), "what is the MAC address of the host that owns this IP?". IP is the L3 logical address and MAC is the L2 physical address, and Ethernet can only deliver frames by MAC address. So every IP conversation triggers ARP behind the scenes to translate the destination IP into a MAC. This article covers why ARP is needed, the resolution flow, the cache, why it stays inside one subnet, gratuitous ARP, and how the lack of authentication enables ARP spoofing — plus the defenses.
What ARP is — the bridge between L3 and L2 #
Each layer uses a different kind of address: apps use a hostname, the IP layer uses an IP address, and the Ethernet layer uses a MAC address. DNS resolves hostname -> IP, but the final step of IP -> MAC is filled in, on the spot, by ARP.
An IP address is the "room number"; a MAC address is the actual "desk". Mail (a frame) only arrives once it lands on a desk. Shouting across the floor "whose desk handles room 301?" (Request) and having that person raise their hand "this is my desk" (Reply) — that is ARP.
Why it is needed — Ethernet only delivers by MAC #
When you send data, the IP packet is wrapped in an Ethernet frame (encapsulation) before it hits the wire. That frame header has a field for the destination MAC address, and if it is blank the switch has no idea which port to send the frame out of.
| Layer | Address used | How it is resolved |
|---|---|---|
| L7 App | Hostname (example.com) | DNS |
| L3 Network | IP address (192.168.1.1) | Routing |
| L2 Data Link | MAC address (aa:bb:cc:..) | ARP |
So ARP exists to fill the one last blank: "I know the IP, but the MAC is empty."
The flow — Request is broadcast, Reply is unicast #
It is simple: "ask everyone, only the owner answers" — one round trip.
ff:ff:ff:ff:ff:ff (everyone) and asks "who has 192.168.1.1? tell 192.168.1.5 (= me)" across the whole segment. Every device under the same switch receives it.The ARP cache — don't ask every time #
Broadcasting every time would be wasteful, so results are cached for tens of seconds to a few minutes. You can inspect it.
# Windows / older Linux
$ arp -a
? (192.168.1.1) at aa:bb:cc:dd:ee:ff [ether] on eth0
? (192.168.1.20) at 11:22:33:44:55:66 [ether] on eth0
# Modern Linux (iproute2)
$ ip neigh
192.168.1.1 dev eth0 lladdr aa:bb:cc:dd:ee:ff REACHABLE
States like REACHABLE / STALE indicate whether the entry was recently used and is still alive. When an entry goes stale, ARP re-confirms it.
Only within one subnet — for remote hosts, resolve the gateway's MAC #
The single most important point: ARP is broadcast, so it cannot cross a router (it only works within the same subnet). So how do you talk to a host on another network?
The answer: you ARP not for the destination itself but for the MAC of the default gateway (router). Like "mail going far away goes to the local post office first", the frame is handed to the router, which forwards it toward the next hop.
When you can't reach a host on the same segment, first check with ip neigh whether its MAC resolved. FAILED or INCOMPLETE means L2 delivery failed (cable, switch, VLAN mismatch, etc.). If everything remote is dead, check whether the gateway's ARP resolved.
Gratuitous ARP — answering when nobody asked #
Gratuitous ARP (GARP) is a special ARP that broadcasts your own "IP<->MAC" unsolicited. It has three main uses.
- Duplicate IP detection — at boot, announce "I'm using this IP"; if another host has it, the conflict is detected.
- Failover — in a redundant setup, when a standby is promoted it announces "the MAC for this virtual IP has changed" so switches update their forwarding (VRRP / keepalived, etc.).
- ARP cache update — refresh the tables around you.
Handy — but this "first to speak wins" nature is exactly what the next attack builds on.
ARP spoofing — the weakness of an unauthenticated design #
ARP has no mechanism to verify the sender. A host that receives a Reply overwrites its cache without checking authenticity. That is what ARP spoofing / ARP poisoning exploits.
arpspoof / ettercap / bettercap are the classic tools.Even if ARP spoofing steals the path, if the traffic is encrypted with TLS the contents can't be read and tampering is rejected by certificate validation. The assumption "you can't trust a host just because it's on the same LAN" (a zero-trust mindset) is exactly why HTTPS is mandatory even on a café or corporate LAN.
Defenses — reject fake ARP on the network side #
| Defense | How it works | Where |
|---|---|---|
| DAI (Dynamic ARP Inspection) | The switch checks ARP against the DHCP-snooping ledger and drops mismatched IP<->MAC | Enterprise switches (best) |
| Static ARP | Hard-code IP<->MAC for critical hosts and forbid overwrites | Servers / gateways |
| Port security | Limit the number/value of MACs learned per port | Access switches |
| Detection (arpwatch, etc.) | Watch for IP<->MAC changes and alert | Monitoring host |
Fundamentally, a two-pronged approach is realistic: segmentation so untrusted devices aren't on the same segment (VLANs, [[vlan]]), plus upper-layer encryption (TLS).
Summary — five things to remember #
- ARP resolves IP -> MAC and is foundational to IPv4. It's indispensable because Ethernet only delivers by MAC.
- The flow is Request (broadcast) -> Reply (unicast) -> cache.
- It works only within one subnet. For remote hosts, ARP for the gateway's MAC.
- With no authentication, ARP spoofing enables MITM.
- Defenses are DAI / static ARP / port security plus upper-layer TLS encryption.
- IPv6 has no ARP; NDP (Neighbor Discovery over ICMPv6) plays the same role.
