How ARP Works and Why It Enables Spoofing

ARP - the Address Resolution Protocol - is one of the oldest and simplest protocols still in daily use on every local network. It solves a fundamental problem: translating Layer 3 addresses (IP) to Layer 2 addresses (MAC). But it does so with absolutely no authentication, and that design decision from 1982 is why ARP spoofing remains one of the most effective LAN attacks four decades later.

The Problem ARP Solves

Ethernet frames are addressed using MAC (Media Access Control) addresses - 48-bit identifiers burned into network interface hardware. When your computer wants to send a packet to another device on the same subnet, it needs the destination's MAC address to construct the Ethernet frame.

But applications and the IP stack work with IP addresses, not MAC addresses. When your computer wants to reach 192.168.1.1, it knows the IP but not the corresponding MAC address. ARP bridges this gap.

ARP operates at the boundary between Layer 2 (data link) and Layer 3 (network). It is not part of IP, not part of Ethernet - it sits between them, translating addresses from one layer to the other.

ARP Request and Reply

The ARP exchange is straightforward:

ARP Request (broadcast). The device that needs a MAC address sends an ARP request to the broadcast MAC address (ff:ff:ff:ff:ff:ff). Every device on the local network receives this frame. The request contains:

• Sender MAC address (the requester's MAC)
• Sender IP address (the requester's IP)
• Target MAC address (set to 00:00:00:00:00:00 - unknown)
• Target IP address (the IP being resolved)

The request essentially says: "I am 192.168.1.50 (MAC aa:bb:cc:dd:ee:ff). Who has 192.168.1.1? Tell me your MAC address."

ARP Reply (unicast). The device that owns the target IP responds directly to the requester (not broadcast). The reply contains the target's MAC address, completing the mapping.

Every device that receives the ARP request also caches the sender's IP-to-MAC mapping. This is an optimization - if device A asks about device B, device B now knows how to reach device A without a separate ARP exchange.

sequenceDiagram
    participant A as Device A - 192.168.1.50
    participant SW as Network Switch
    participant B as Device B - 192.168.1.1
    participant C as Device C - 192.168.1.75
    A->>SW: ARP Request - broadcast - Who has 192.168.1.1?
    SW->>B: ARP Request delivered
    SW->>C: ARP Request delivered
    Note over C: Not my IP - ignore but cache sender
    B->>B: That is my IP
    B->>A: ARP Reply - unicast - 192.168.1.1 is at 11:22:33:44:55:66
    Note over A: Cache - 192.168.1.1 = 11:22:33:44:55:66
    Note over B: Cache - 192.168.1.50 = aa:bb:cc:dd:ee:ff
    A->>B: Ethernet frame to 11:22:33:44:55:66 carrying IP packet

Figure 1 - The ARP request-reply exchange with a broadcast request and unicast reply

The ARP Cache

Every device maintains an ARP cache (also called an ARP table) that stores recently resolved IP-to-MAC mappings. When a device needs to send a packet, it checks the cache first. If the mapping exists, it uses it immediately without sending an ARP request.

ARP cache entries have a timeout, typically between 15 seconds and 20 minutes depending on the operating system. When an entry expires, the device must send a new ARP request the next time it needs that mapping.

You can view your ARP cache on most systems:

• Linux/macOS: arp -a or ip neigh show
• Windows: arp -a

The cache is the target of ARP spoofing attacks. If an attacker can insert a false entry into the cache, the victim will send traffic to the wrong MAC address - the attacker's MAC - instead of the legitimate destination.

Gratuitous ARP

A gratuitous ARP is an ARP reply that nobody asked for. A device sends it to announce or update its own IP-to-MAC mapping to the entire network. The destination MAC is the broadcast address, and both the sender and target IP are the same.

Gratuitous ARP has legitimate uses:

• IP conflict detection - when a device gets a new IP, it sends a gratuitous ARP to see if anyone else claims the same address
• Failover - when a standby server takes over from a failed primary, it sends a gratuitous ARP to update all cached mappings to point to the new MAC address
• NIC replacement - when a server gets a new network card (new MAC, same IP), a gratuitous ARP updates all caches

But gratuitous ARP is also the primary mechanism for ARP spoofing. An attacker sends unsolicited ARP replies to overwrite legitimate cache entries with the attacker's MAC address.

The Vulnerability

ARP has no authentication mechanism. None. When a device receives an ARP reply, it updates its cache unconditionally. There is no verification that the reply came from the actual owner of the IP address. There is no signature, no certificate, no shared secret.

This is not an implementation bug - it is the protocol's design. ARP was created in 1982 (RFC 826) for small, trusted networks where every device was physically controlled by the same organization. Authentication was not considered necessary.

The problem is that modern networks are anything but small and trusted. A coffee shop WiFi network, a conference WiFi, a university dormitory network - these are shared environments where any connected device can send ARP packets to any other connected device.

graph TD
    subgraph "Normal ARP Flow"
        V1[Victim] -->|Traffic to gateway| GW1[Gateway - 192.168.1.1]
        GW1 -->|Traffic to victim| V1
    end
    subgraph "ARP Spoofing Attack"
        ATK[Attacker] -->|Fake ARP - I am 192.168.1.1| V2[Victim]
        ATK -->|Fake ARP - I am victim IP| GW2[Gateway]
        V2 -->|Traffic meant for gateway| ATK
        ATK -->|Forward to real gateway| GW2
        GW2 -->|Traffic meant for victim| ATK
        ATK -->|Forward to victim| V2
    end
    subgraph "Result"
        R1[Attacker sees all traffic] --> R2[Can modify packets in transit]
        R2 --> R3[Victim notices nothing]
    end

Figure 2 - Normal ARP resolution versus an ARP spoofing man-in-the-middle attack

ARP Spoofing in Practice

An ARP spoofing attack positions the attacker as a man-in-the-middle between the victim and the gateway. The attack works in two steps:

Step 1: Poison the victim's ARP cache. The attacker sends a gratuitous ARP reply to the victim: "192.168.1.1 (the gateway) is at [attacker's MAC]." The victim updates its ARP cache and now sends all gateway-bound traffic to the attacker.

Step 2: Poison the gateway's ARP cache. The attacker sends a gratuitous ARP reply to the gateway: "[victim's IP] is at [attacker's MAC]." The gateway now sends all traffic destined for the victim to the attacker instead.

The attacker enables IP forwarding on their machine so traffic flows through them transparently. The victim and gateway communicate normally - they just do not realize every packet passes through the attacker's machine. The attacker must continue sending spoofed ARP replies at regular intervals because cache entries expire.

With this position, the attacker can:

• Read all unencrypted traffic (HTTP, DNS, FTP, telnet)
• Capture credentials sent in plaintext
• Modify packets in transit (injecting JavaScript, altering downloads)
• Selectively drop packets (denial of service)
• Redirect DNS responses to phishing sites

HTTPS protects against content inspection and modification (the attacker sees encrypted bytes), but the attacker can still observe connection metadata - which servers the victim connects to, when, and how much data is transferred.

Defenses

Static ARP entries are the most secure defense - manually mapping IP to MAC addresses and marking them as permanent. But this is impractical on any network with more than a handful of devices, as every change requires manual updates on every machine.

Dynamic ARP Inspection (DAI) is the enterprise solution. Available on managed switches, DAI validates ARP packets against the DHCP snooping binding table. If an ARP reply claims a different MAC for an IP than what DHCP assigned, the switch drops the packet. This requires managed network infrastructure.

ARP spoofing detection software monitors the ARP cache for suspicious changes - like the gateway's MAC address suddenly changing to a different value. Tools like arpwatch and XArp can alert on these events.

VPN is the most practical defense on untrusted networks. Even if an attacker performs ARP spoofing, all they see is encrypted VPN tunnel traffic. They cannot read, modify, or selectively redirect the contents.

802.1X port authentication ensures only authorized devices can connect to the network in the first place, reducing (but not eliminating) the risk of rogue devices performing ARP attacks.

For security researchers studying ARP behavior, tools like the BLEShark Nano provide visibility into what is happening on the local network segment. Understanding ARP at the packet level is fundamental to both attacking and defending Layer 2 networks.