ARP explained: how IPv4 finds MAC addresses, gratuitous ARP, proxy ARP and ARP spoofing

Why ARP is needed

Applications know IP addresses, but an Ethernet frame needs a destination MAC address. The Address Resolution Protocol (ARP) bridges that gap for IPv4 on the local link. IPv6 does the same job with Neighbour Discovery instead.

The key question a host asks first is: is the destination on my own subnet? It compares the destination with its own address and subnet mask.

• Same subnet: the host ARPs for the destination itself.
• Different subnet: the host ARPs for its default gateway, and sends the frame to the gateway's MAC with the far destination's IP inside.

The request and reply

1. The host checks its ARP cache. If there is an entry, it uses it and stops.
2. If not, it sends an ARP request to the broadcast MAC FF:FF:FF:FF:FF:FF: "who has 192.168.1.1? Tell 192.168.1.20."
3. Every host in the VLAN receives it. Only the owner of 192.168.1.1 answers, with a unicast ARP reply containing its MAC.
4. The requester stores the mapping in its cache and sends the waiting packet. The owner usually caches the requester's details too.

Entries expire so that the cache stays accurate when hardware changes: Windows and Linux keep unused entries for seconds to minutes, while Cisco routers default to four hours. You can see the cache with these commands:

arp -a                      (Windows)
ip neigh show               (Linux)
show ip arp                 (Cisco IOS)
show mac address-table      (Cisco switch: which port the MAC is on)

Special kinds of ARP

ARP spoofing and how to stop it

ARP trusts whatever it hears. An attacker on the same VLAN can send forged replies saying "the gateway's IP is at my MAC". Victims then send their traffic to the attacker, who can read or alter it before passing it on: a classic on-path (man-in-the-middle) attack. It only works inside the local broadcast domain, which is one more reason to keep VLANs small.

• Dynamic ARP Inspection (DAI) on switches checks ARP messages against the DHCP snooping binding table and drops forged ones.
• DHCP snooping must be on first, because DAI relies on its table.
• Encryption (HTTPS, SSH, VPNs) means intercepted traffic is still unreadable.
• Static ARP entries work for a few critical devices but do not scale.

Real-world example: after a firewall was replaced, users in one VLAN could not reach the internet for several hours while others were fine. The core switch still held the old firewall's MAC in its ARP cache for the gateway address. Clearing the entry (clear ip arp 192.168.50.1) fixed it at once. The new firewall had not sent a gratuitous ARP, so nothing told the switch the MAC had changed.

Exam tip: questions often ask which MAC address a host puts in a frame for a remote server. The answer is always the default gateway's MAC, never the far server's, because ARP only works inside the local broadcast domain.

Reverse ARP and how it led to DHCP

ARP answers "which MAC address owns this IP address?". RARP (Reverse ARP, RFC 903, 1984) asked the opposite question: "I know my MAC address, what is my IP address?". It was designed for diskless workstations that had no storage to keep their own settings. The workstation broadcast a RARP request, and a RARP server on the same segment looked up the MAC address in a table and replied with an IP address.

RARP had serious limits: it worked at Layer 2, so it could not cross a router and needed a server on every segment; it returned only an IP address, with no mask, gateway or DNS server; and every MAC address had to be typed into the server by hand. BOOTP (bootstrap protocol) replaced it by running over UDP, which relay agents can forward between subnets, and by returning more settings. DHCP then extended BOOTP with leases and automatic address pools, and it is what networks use today; see DHCP explained. You will not configure RARP on modern equipment, but it still appears in exam questions and in the EtherType list (0x8035).