Ethernet and ARP
ARP
How a device finds the MAC address behind an IP address on its own network.
A broadcast asks "who has 10.0.1.2?", and the owner answers with its MAC address. Answers are cached in the
neighbour table (ip neigh) for a while. For an address on another network, a device ARPs for its
gateway, never for the far address. ARP has no authentication: a device believes the answers it hears, which
is why managed switches can inspect ARP against known bindings.
How ARP works, step by step
Alice (10.0.1.10/24) wants to ping bob (10.0.1.11). Her routing table says bob is on her own network,
so the packet goes straight to him, in an Ethernet frame. A frame needs bob's MAC address, and alice does not have it.
- Alice checks her neighbour table. No entry for
10.0.1.11, so the ping waits in a queue. - She broadcasts an ARP request. The frame goes to
ff:ff:ff:ff:ff:ffwith EtherType0x0806. The ARP packet inside (RFC 826) says: hardware type 1 (Ethernet), protocol type0x0800(IPv4), operation 1 (request), sender MAC and IP = alice's, target IP =10.0.1.11, target MAC = all zeros, because that is the question. - Every device on the network reads it. Only the owner of
10.0.1.11answers. Bob also stores alice's MAC and IP from the request, so he will not need to ask about her. - Bob sends an ARP reply, unicast. Operation 2, sender = bob's MAC and IP, target = alice. It goes straight to alice's MAC.
- Alice caches the answer and sends the queued ping in a frame addressed to bob's MAC.
For an address on another network, alice never ARPs for it. Her route says via 10.0.1.2, so she ARPs for the
router and sends the frame to the router's MAC, with the far IP address still inside the packet. The router does the
same on its next network. IP addresses stay the same end to end; MAC addresses change at every hop.
What it looks like on a Linux machine
In the ARP and MAC addresses lab alice empties her table, pings bob, and a capture
shows both frames. tcpdump -e prints the MAC addresses, -nn keeps addresses as numbers:
$ tcpdump -e -nn -i eth0 arp
9e:3b:52:c1:07:4a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.1.11 tell 10.0.1.10, length 28
d2:65:0f:8e:21:b3 > 9e:3b:52:c1:07:4a, ethertype ARP (0x0806), length 42: Reply 10.0.1.11 is-at d2:65:0f:8e:21:b3, length 28
The answer lands in the neighbour table, the modern name for the ARP cache:
$ ip neigh show 10.0.1.11
10.0.1.11 dev eth0 lladdr d2:65:0f:8e:21:b3 REACHABLE
REACHABLE means recently confirmed. After about 30 seconds without confirmation (a random time around
base_reachable_time) it turns STALE: still used, but checked with a unicast request the next time it
matters (DELAY, then PROBE). ip neigh flush all empties the table; arp -n is the older view of the same data.
What goes wrong, and how you see it
Nobody has the address. Alice asks for 10.0.1.99 three times and gets silence. The entry goes
INCOMPLETE, then FAILED, and ping blames alice herself, because the packet never left:
From 10.0.1.10 icmp_seq=1 Destination Host Unreachable
$ ip neigh show 10.0.1.99
10.0.1.99 dev eth0 FAILED
The device is there but drops pings. A firewall on bob drops ICMP, so ping times out, yet his MAC is in alice's
table: ARP is answered below the IP firewall. arping -I eth0 10.0.1.11 asks the ARP question directly and gets
Unicast reply from 10.0.1.11.
Two devices claim one address. Each reply overwrites the other in everyone's table, and connections flip between
them. A careful device checks first with a probe from 0.0.0.0; arping -D does it by hand and exits 1 when
someone answers.
Someone lies. ARP has no authentication, and Linux accepts a reply that updates an entry it already has. An attacker who keeps telling alice "10.0.1.2 is at my MAC" receives everything she sends to the router. The ARP spoofing lab does exactly that; switches defend with dynamic ARP inspection.
Questions people ask
Is ARP layer 2 or layer 3? It sits between them. It travels directly in Ethernet frames, with no IP header, but its job is to map a layer 3 address to a layer 2 one.
Does ARP cross routers? No. Requests are broadcasts, and routers do not forward broadcasts. A host on another network is reached by ARPing for the gateway. Proxy ARP, where a router answers on behalf of hosts behind it, is the exception, and it is rarely turned on today.
What replaced ARP in IPv6? Neighbour discovery (RFC 4861): ICMPv6 neighbour solicitations sent to a
solicited-node multicast group instead of a broadcast, with the same states in ip -6 neigh.