Skip to main content
Explainer · networking

What is ARP? (Address Resolution Protocol, in plain English)

Your computer knows the IP address it wants to reach. Ethernet and Wi-Fi don't care about IP addresses — they only deliver frames to hardware addresses. ARP is the small, old, trusting protocol that bridges the gap, and almost every packet you send starts with it.

The problem ARP solves

Every device has two addresses, living at different layers. The IP address is logical and routable: it says where a device sits in the global topology, and routers use it to move packets across the world. The MAC address is physical — a link-layer address assigned to the network adapter, meaningful only on one segment.

When your laptop wants to send a packet to 192.168.1.1, it builds an IP packet with that destination — but it cannot put it on the wire yet. Ethernet and Wi-Fi don't deliver to IP addresses; they deliver frames to MAC addresses. To transmit at all, the laptop must wrap the packet in a frame addressed to the destination's hardware address, and it has no idea what that is.

That is the entire problem ARP solves: given an IPv4 address on the local network, find the MAC address that owns it. Specified in RFC 826 in 1982, ARP sits in the seam between layer 2 and layer 3 — not really part of either, but the thing that lets them talk.

How ARP works: shout, then listen

ARP is almost comically simple. There are two messages: a request and a reply.

The request

The host that needs an answer builds an ARP request and sends it to the Ethernet broadcast address, ff:ff:ff:ff:ff:ff, so every device on the local segment receives it. The request says, in effect: “Who has 192.168.1.1? Tell 192.168.1.42.” It carries the sender's own IP and MAC so the answer knows where to go, plus the target IP it is asking about. The target MAC field is left empty — that is the unknown being requested.

The reply

Every host inspects the request; the ones that don't own that IP drop it. The one host that does own 192.168.1.1 answers with an ARP reply, sent directly back to the requester rather than broadcast: “192.168.1.1 is at a4:2b:8c:11:04:9f.” The requester builds its Ethernet frame with that MAC as the destination, puts the IP packet inside, and transmits — all of it invisibly, before the first byte of your actual connection is sent.

The ARP cache

Broadcasting a question to the whole network before every packet would be absurdly wasteful, so hosts remember the answers. That memory is the ARP cache — also called the ARP table, or the neighbour table. Each entry maps one IP address to one MAC address, plus a timer.

Entries age out, typically after tens of seconds to a few minutes depending on the operating system and on whether the entry is in active use. Ageing matters: cards get swapped, devices get replaced, DHCP hands an address to a different machine. If entries lived forever, your host would keep sending frames to a MAC that no longer answers.

You can look at yours right now. On Windows, macOS, and most Linux systems:

arp -a

On modern Linux the preferred command is ip neigh show, which adds a per-entry state — REACHABLE for an entry recently confirmed to work, STALE for one that will be re-validated before it is trusted again. Either way the list will be short, and the reason is the most important thing to understand about ARP.

ARP is local-only — and that changes everything

An ARP request is a broadcast, and broadcasts do not cross routers. ARP therefore works only inside a single broadcast domain: your subnet, your VLAN, the set of devices that can hear each other's frames directly.

So what happens when you open a website hosted three continents away? Your machine compares the destination IP against its own IP and subnet mask. If the destination is on the local subnet, it ARPs for it. If it is not — and a remote web server never is — it does not ARP for that server at all. No device on your LAN owns the address, so nobody would reply.

Instead, your host consults its routing table, sees that off-subnet traffic goes to the default gateway, and ARPs for the gateway's MAC. The frame it sends carries the remote server's IP in the IP header but your router's MAC in the Ethernet header. The router strips that header, reads the IP destination, picks an outbound interface, and builds a brand-new frame with a brand-new destination MAC for the next hop — doing its own ARP on that link. Repeat, hop after hop, until the packet arrives.

Two consequences fall out. MAC addresses are rewritten at every hop while IP addresses stay fixed end to end, which is why a website sees your public IP but never your MAC address. And your ARP table holds your gateway, your printer, a NAS, a couple of machines on the LAN — and nothing else. That is why arp -a never lists the sites you were browsing.

Gratuitous ARP and the ARP probe

A gratuitous ARP is a message a host sends about its own address when nobody asked: “I am 192.168.1.1, and I am at this MAC.” Interfaces send one when they come up, and it is how high-availability setups fail over — when a backup router takes over a shared virtual IP, a gratuitous ARP makes every host update its cache immediately instead of waiting for the old entry to age out.

An ARP probe is the opposite: a host checking whether an address is already in use before claiming it. It asks about the address it wants while leaving its own sender-IP field all zeroes, so it cannot pollute anyone's cache with a claim it has not earned. If somebody answers, the address is taken. That is the mechanism behind the “another device on the network is using your IP address” warning, specified in RFC 5227.

ARP spoofing: the risk, and the defenses

Now the design flaw. ARP replies are unauthenticated — there is no way to prove you own the address you claim, and whoever answers is believed. A device already on your local network can therefore send forged replies claiming an IP it does not own, most usefully the default gateway's. Victims update their caches, start sending outbound traffic to the attacker's MAC, and the attacker sits in the middle of the conversation. This is ARP spoofing, or ARP cache poisoning, and it underpins many classic on-path (man-in-the-middle) attacks on a LAN.

The precondition is what matters for defenders: the attacker must already be on your broadcast domain. A stranger on the internet cannot do this to you. The threat is a compromised device, a rogue machine plugged into an office port, or an untrusted guest on shared Wi-Fi — which is exactly why public Wi-Fi has the reputation it does.

What actually protects you

IPv6 does not use ARP

ARP was not carried over into IPv6. The same job is handled by the Neighbor Discovery Protocol (NDP), specified in RFC 4861, which runs over ICMPv6 rather than as its own Ethernet protocol. The shape is familiar — a Neighbor Solicitation asks who owns an IPv6 address, and a Neighbor Advertisement answers — but the solicitation goes to a solicited-node multicast address derived from the target rather than to a broadcast, so only a small set of hosts has to process it. NDP also folds in router discovery, address autoconfiguration, and duplicate address detection.

The trust model is inherited, though: unauthenticated NDP is spoofable much as ARP is, which is why switches implement ND inspection and RA Guard as the IPv6 analogues of Dynamic ARP Inspection. The defenses above apply to both address families.

Frequently asked questions

How do I see my ARP cache?

Run arp -a. It works on Windows, macOS, and most Linux distributions, and prints every IP-to-MAC mapping your machine currently knows about. On modern Linux, ip neigh show is preferred and adds the state of each entry. Expect a short list: only devices on your own segment that you have recently talked to, almost always including your default gateway.

Why doesn't my ARP table contain the websites I visit?

Because ARP is local-only and never crosses a router. For a destination outside your subnet, your host does not ARP for the remote server — it ARPs for its default gateway's MAC and hands the frame off, and the router repeats the process on the next link. Your ARP table holds your router and your neighbours, never a remote web server.

Does IPv6 use ARP?

No. IPv6 has no ARP. The Neighbor Discovery Protocol does the same job over ICMPv6, using multicast solicitations and advertisements rather than broadcasts, and it also absorbs router discovery and duplicate address detection.

Related reading