How ARP Works: Address Resolution Protocol Explained

ARP (Address Resolution Protocol) is the protocol that maps IP addresses to MAC (Media Access Control) addresses on a local network. Every time your computer sends a packet to another device on the same subnet, it needs the destination's MAC address to construct the Ethernet frame. ARP is how it discovers that MAC address. Without ARP, IP networking over Ethernet would not function — the link layer would have no way to deliver packets to the correct physical interface.

ARP is defined in RFC 826 (1982) and operates at the boundary between Layer 2 (data link) and Layer 3 (network) of the OSI model. It is one of the oldest protocols still in daily use on every network in the world. Despite its simplicity, ARP has significant security implications that every network engineer should understand.

Why ARP Exists: The Two-Address Problem

IP networks use IP addresses for logical addressing — your machine is 192.168.1.50, the router is 192.168.1.1. But Ethernet, Wi-Fi, and other link-layer technologies use MAC addresses — 48-bit hardware addresses burned into every network interface card (NIC). A MAC address looks like a4:83:e7:2f:01:cc.

When Host A wants to send an IP packet to Host B on the same local network, it constructs an Ethernet frame. That frame needs a destination MAC address in its header. Host A knows Host B's IP address (from the application, a DNS lookup, or routing table), but it does not know Host B's MAC address. ARP solves this by providing a mechanism to ask: "Who has IP address 192.168.1.75? Tell me your MAC address."

This problem only arises for destinations on the same subnet. When the destination is on a different subnet, Host A sends the frame to its default gateway (the router), and the router handles forwarding from there. But even in that case, ARP is needed — Host A still needs the MAC address of the gateway itself.

The ARP Request/Reply Flow

ARP operates in two steps: a broadcast request, and a unicast reply.

1. ARP Request (broadcast) — Host A constructs an ARP request containing its own IP and MAC address (the sender) and the target IP address it wants to resolve. The target MAC field is set to all zeros (unknown). This request is sent as an Ethernet broadcast (ff:ff:ff:ff:ff:ff), meaning every device on the local network segment receives it.
2. ARP Reply (unicast) — The host that owns the target IP address responds with a unicast ARP reply directed back to Host A's MAC address. The reply contains the target's MAC address, completing the mapping.
3. Cache entry created — Host A stores the IP-to-MAC mapping in its local ARP cache (also called ARP table). Subsequent packets to the same IP address use the cached MAC address without another ARP exchange.

All other hosts on the network that received the broadcast request silently discard it (though they may update their own ARP caches if they already have an entry for Host A).

The ARP Packet Format

ARP packets are not IP packets. They are carried directly inside Ethernet frames with EtherType 0x0806. The ARP message format is designed to be protocol-agnostic — it can theoretically map any network-layer address to any link-layer address — but in practice it is used almost exclusively for IPv4-to-Ethernet mappings.

The ARP packet has these fields:

The total ARP payload is 28 bytes for IPv4/Ethernet. Including the 14-byte Ethernet header, a minimal ARP frame is 42 bytes — well below the Ethernet minimum of 64 bytes, so it gets padded. The Ethernet header's EtherType field is set to 0x0806 to identify the payload as ARP (as opposed to 0x0800 for IPv4 or 0x86DD for IPv6).

A key design detail: ARP requests carry the sender's MAC and IP, not just the target's IP. This allows the recipient to populate its own ARP cache with the sender's mapping even before replying. It is an optimization that reduces future ARP traffic — if Host B will need to send traffic back to Host A soon, it already knows Host A's MAC address.

The ARP Cache

Every host maintains an ARP cache (or ARP table) — an in-memory mapping of IP addresses to MAC addresses. When a host needs to send a packet to a local IP, it first checks its ARP cache. If a valid entry exists, it uses the cached MAC address immediately. If no entry exists, it sends an ARP request.

ARP cache entries have a timeout, typically between 15 and 30 minutes depending on the operating system. After the timeout expires, the entry is removed and a new ARP exchange occurs the next time traffic is sent to that IP. This mechanism handles the case where a device's MAC address changes — for example, when a NIC is replaced, a virtual machine migrates, or a device physically moves to a different port on the network.

On Linux, you can view the ARP cache with:

$ ip neigh show
192.168.1.1 dev eth0 lladdr 00:1a:2b:3c:4d:5e REACHABLE
192.168.1.75 dev eth0 lladdr b8:27:eb:4a:dc:10 STALE
192.168.1.90 dev eth0 lladdr c0:ff:ee:00:11:22 DELAY

On macOS and BSD:

$ arp -a
? (192.168.1.1) at 00:1a:2b:3c:4d:5e on en0 ifscope [ethernet]
? (192.168.1.75) at b8:27:eb:4a:dc:10 on en0 ifscope [ethernet]

On Windows:

> arp -a
Interface: 192.168.1.50 --- 0x4
  Internet Address    Physical Address    Type
  192.168.1.1         00-1a-2b-3c-4d-5e   dynamic
  192.168.1.75        b8-27-eb-4a-dc-10   dynamic
  192.168.1.255       ff-ff-ff-ff-ff-ff   static

The cache entry states have specific meanings. REACHABLE means the entry has been recently confirmed (a reply was received or bidirectional traffic was observed). STALE means the timeout has elapsed but the entry has not yet been removed — it will be used for the next packet but triggers a new ARP request in the background. DELAY means the kernel is waiting briefly before sending a new ARP request, in case an upper-layer confirmation (like a TCP ACK) arrives first. INCOMPLETE means an ARP request was sent but no reply has come back.

ARP and the Default Gateway

When your machine wants to reach an IP address outside its local subnet — for example, querying 8.8.8.8 — it does not ARP for 8.8.8.8. Instead, the IP routing table tells the machine to send the packet to the default gateway (typically the local router). The machine then ARPs for the router's IP address to get the router's MAC address. The resulting Ethernet frame has the router's MAC as the destination but the remote server's IP in the IP header.

This is a fundamental concept: the destination MAC address changes at every hop, but the destination IP stays the same (in normal IP forwarding). Each router along the path uses ARP (or its equivalent) on its local segment to find the next hop's MAC address, constructs a new Ethernet frame, and forwards the packet.

This is why when you look up a route in a BGP looking glass, you see the path in terms of autonomous systems and IP addresses — MAC addresses are purely local and get rewritten at every hop. They never appear in routing tables or AS paths.

Proxy ARP

Proxy ARP (RFC 1027) is a technique where a router answers ARP requests on behalf of hosts on a different subnet. The router replies with its own MAC address, causing the requesting host to send traffic to the router, which then forwards it to the actual destination.

Consider this scenario: Host A is on subnet 192.168.1.0/24 and wants to reach Host D at 192.168.2.50. Normally, Host A would recognize that 192.168.2.50 is on a different subnet and route the packet through its default gateway. But if Host A is misconfigured with a /16 mask instead of /24, it believes 192.168.2.50 is on the same local network and sends an ARP request for it.

Without proxy ARP, this fails — the ARP broadcast never reaches the other subnet, and Host A cannot communicate with Host D. With proxy ARP enabled on the router, the router sees the ARP request, determines that it can reach 192.168.2.50 via its other interface, and replies with its own MAC address. Host A happily sends traffic to the router's MAC, and the router forwards it correctly.

Proxy ARP use cases include:

• Legacy compatibility — allowing hosts with incorrect subnet masks to communicate
• VPN and dial-in — making remote clients appear to be on the local network
• Network migration — bridging subnets during renumbering
• Transparent firewalls — inserting a device into the network path without changing IP topology

Proxy ARP is generally considered a legacy mechanism. It obscures subnet boundaries and can complicate troubleshooting. Modern networks prefer proper routing and gateway configuration. Most enterprise routers have proxy ARP disabled by default.

Gratuitous ARP

A gratuitous ARP is an ARP message that a host sends without being asked. It takes two forms:

• Gratuitous ARP request — A host sends an ARP request for its own IP address. The sender and target IP fields are both the host's IP. Since the host is asking "who has my IP?", no reply is expected unless there is an IP conflict.
• Gratuitous ARP reply — A host sends an unsolicited ARP reply announcing its own IP-to-MAC mapping, without any preceding request.

Gratuitous ARP serves several important purposes:

• IP conflict detection — When a host boots or acquires an IP via DHCP, it sends a gratuitous ARP for its own address. If another host replies, there is a duplicate IP — the host can alert the user or decline the address.
• ARP cache update — If a host's MAC address changes (e.g., NIC replacement, VM migration, or failover), a gratuitous ARP causes all other hosts on the segment to update their cached entry for that IP.
• High-availability failover — This is one of the most important uses. In an HSRP, VRRP, or CARP failover scenario, the standby router takes over the virtual IP address. It immediately sends a gratuitous ARP to update all hosts' ARP caches, so traffic flows to the new active router. Without gratuitous ARP, hosts would continue sending traffic to the old router's MAC address until their ARP cache entries expired — causing minutes of outage.
• Network load balancers — When a virtual IP migrates between servers, gratuitous ARP ensures the switch forwards traffic to the correct port.

ARP Spoofing and Poisoning Attacks

ARP was designed in 1982 for small, trusted networks. It has no authentication mechanism whatsoever. Any host on the local network can send ARP replies claiming any IP-to-MAC mapping, and other hosts will blindly accept it. This fundamental weakness enables ARP spoofing (also called ARP poisoning) — one of the most common Layer 2 attacks.

How ARP Spoofing Works

An attacker on the local network sends forged ARP replies to two targets. For example, the attacker tells Host A that the gateway's IP address maps to the attacker's MAC address, and tells the gateway that Host A's IP maps to the attacker's MAC. Both devices update their ARP caches with the false information.

Now all traffic between Host A and the gateway flows through the attacker. This is a classic man-in-the-middle (MITM) position. The attacker can:

• Eavesdrop — read unencrypted traffic (HTTP, FTP, Telnet, DNS queries)
• Modify — alter packets in transit (inject malicious content, redirect DNS, modify downloads)
• Deny service — drop packets instead of forwarding them, severing the victim's connectivity
• Session hijack — steal session cookies or authentication tokens from unencrypted connections

Tools like arpspoof, ettercap, and bettercap automate this attack. On an unprotected network, it takes seconds to execute.

Defenses Against ARP Spoofing

Several countermeasures exist, operating at different layers:

• Dynamic ARP Inspection (DAI) — A switch-level feature available on managed enterprise switches (Cisco, Juniper, Arista). DAI intercepts all ARP packets and validates them against a trusted database — typically the DHCP snooping binding table, which maps IP addresses to MAC addresses based on observed DHCP exchanges. ARP packets that do not match are dropped. This is the most effective defense.
• Static ARP entries — Critical mappings (e.g., the default gateway) can be configured as static ARP entries that cannot be overwritten by ARP replies. This works but does not scale and is difficult to maintain on large networks.
• 802.1X port authentication — Requires devices to authenticate before gaining network access, limiting who can send ARP packets in the first place.
• ARP watch / detection tools — Software like arpwatch or XArp monitors the network for suspicious ARP activity, such as a single MAC address claiming multiple IP addresses or frequent MAC-to-IP mapping changes.
• Encryption (TLS/HTTPS) — Does not prevent ARP spoofing, but renders intercepted traffic unreadable. TLS ensures confidentiality and integrity even if the attacker is in the packet path. This is why HTTPS matters — even on a compromised local network, encrypted traffic resists eavesdropping.
• VPNs — Encapsulating all traffic in an encrypted tunnel prevents an ARP spoofing attacker from reading or modifying the actual data, though they can still perform denial-of-service.

ARP in VLANs

A VLAN (Virtual Local Area Network) is a Layer 2 broadcast domain defined by the switch configuration rather than physical wiring. VLANs are deeply relevant to ARP because ARP operates via broadcast — and a VLAN boundary is a broadcast boundary.

ARP broadcasts are confined to the VLAN in which they originate. A host in VLAN 10 cannot ARP for a host in VLAN 20, even if both VLANs exist on the same physical switch. Traffic between VLANs must be routed at Layer 3 (through a router or Layer 3 switch), just like traffic between physical subnets.

This has important implications:

• Broadcast domain size — VLANs limit the number of hosts that receive each ARP broadcast. A flat network of 10,000 hosts would generate enormous ARP broadcast traffic; segmenting into VLANs of 200-500 hosts each keeps broadcast traffic manageable.
• Security isolation — ARP spoofing attacks are contained within a single VLAN. An attacker in the guest VLAN cannot poison ARP caches in the server VLAN. This is one reason network segmentation is a security best practice.
• VLAN hopping — In some misconfigured networks, an attacker can craft 802.1Q-tagged frames to inject traffic into other VLANs (double-tagging attack). If successful, this can bypass the VLAN-based ARP isolation. Proper trunk port configuration prevents this.

In modern data center fabrics using VXLAN (Virtual Extensible LAN), ARP presents additional challenges. VXLAN extends Layer 2 domains across an IP-routed underlay. ARP broadcasts must be replicated across all VXLAN Tunnel Endpoints (VTEPs) participating in the same virtual network — a process that can be expensive at scale. Modern EVPN-VXLAN fabrics solve this by distributing ARP information via BGP EVPN, allowing VTEPs to suppress ARP broadcasts and respond locally with cached information.

RARP, InARP, and ARP Variants

Several protocols extend or complement the basic ARP mechanism:

• RARP (Reverse ARP, RFC 903) — The inverse of ARP: a host knows its own MAC address but not its IP address, and broadcasts a RARP request to discover it. RARP was used by diskless workstations that needed to learn their IP at boot time. It has been entirely replaced by BOOTP and DHCP.
• InARP (Inverse ARP, RFC 2390) — Used in Frame Relay and ATM networks to map a known data-link identifier (DLCI or VPI/VCI) to an IP address. InARP operates on point-to-point virtual circuits rather than broadcast media and is still used in legacy WAN environments.
• UnARP — An extension proposed for removing stale entries from ARP caches when a host leaves the network. Not widely implemented; timeout-based expiration handles this in practice.
• ARP Mediation — Used in VPLS (Virtual Private LAN Service) environments where different attachment circuits use different encapsulations. The PE (Provider Edge) router mediates between Ethernet and non-Ethernet ARP formats.

ARP Performance and Scalability

On small to medium networks, ARP is negligible overhead. But at scale, ARP broadcast traffic becomes a real concern:

• Every host on the subnet receives and must process every ARP request, even if the request is not for them. On a network with 1,000 hosts, each actively communicating, the ARP broadcast rate can reach hundreds of packets per second.
• Switches must flood ARP broadcasts out every port in the VLAN. On large Layer 2 domains spanning many switches, this consumes bandwidth and CPU resources on every switch.
• The ARP cache on routers and hosts has finite capacity. A router serving a /16 subnet (65,534 possible hosts) could theoretically need 65,534 ARP entries — each requiring a broadcast to populate.

This is why network architects limit broadcast domain size. The general recommendation is to keep VLANs to a few hundred hosts maximum. Technologies like ARP suppression (in EVPN-VXLAN environments), proxy ARP on routers, and ARP rate limiting on switches help manage ARP traffic in larger deployments.

An extreme case is an ARP storm — a feedback loop where ARP requests trigger more ARP requests, often caused by misconfigured devices, loops, or scanning tools. ARP storm control on managed switches rate-limits ARP broadcasts to prevent this from consuming all available bandwidth.

IPv6 Neighbor Discovery Protocol (NDP): ARP's Replacement

IPv6 does not use ARP. Instead, it uses the Neighbor Discovery Protocol (NDP), defined in RFC 4861. NDP performs the same fundamental function — mapping IP addresses (IPv6) to MAC addresses — but it does so with a completely redesigned mechanism built on ICMPv6 rather than a separate protocol.

How NDP Works

NDP uses two ICMPv6 message types for address resolution:

1. Neighbor Solicitation (NS) — The IPv6 equivalent of an ARP request. Instead of broadcasting to every host, the NS message is sent to a solicited-node multicast address derived from the target IPv6 address. This address is formed by taking the last 24 bits of the target address and appending them to the prefix ff02::1:ff00:0/104. Only hosts whose addresses end with the same 24 bits receive the message — typically just one host. This is far more efficient than Ethernet broadcast.
2. Neighbor Advertisement (NA) — The IPv6 equivalent of an ARP reply. The target host responds with its link-layer address (MAC address).

NDP also handles additional functions that required separate protocols in IPv4:

• Router Discovery — Hosts discover routers via Router Solicitation (RS) and Router Advertisement (RA) messages, replacing the need for DHCP to provide gateway information.
• Stateless Address Autoconfiguration (SLAAC) — Hosts can automatically generate their own IPv6 addresses from router advertisements, with no DHCP server required.
• Duplicate Address Detection (DAD) — Before using an address, a host sends an NS for that address. If someone responds, the address is a duplicate. This replaces gratuitous ARP for conflict detection.
• Redirect — Routers can inform hosts of a better next-hop for a particular destination, equivalent to ICMP Redirect in IPv4 but integrated into the neighbor discovery process.

NDP Security: SEND

NDP suffers from similar trust issues as ARP — any host can send forged Neighbor Advertisements. The IPv6 ecosystem addressed this with SEND (SEcure Neighbor Discovery, RFC 3971), which uses Cryptographically Generated Addresses (CGAs) and RSA signatures to authenticate NDP messages. However, SEND has seen minimal deployment due to its complexity and computational overhead. In practice, RA Guard and ND Inspection on switches (analogous to ARP inspection) are the primary defenses.

NDP vs ARP: Key Differences

NDP is a clear architectural improvement, consolidating multiple IPv4 mechanisms (ARP, ICMP Router Discovery, DHCP relay) into a single coherent protocol. As IPv6 adoption continues to grow, NDP will gradually replace ARP — but given the slow pace of IPv4 deprecation, ARP will remain essential for years to come.

ARP in Practice: Common Scenarios

Network Troubleshooting

ARP issues are a common source of network problems. Symptoms and diagnostic approaches:

• "No ARP entry" / Incomplete — The host sent an ARP request but received no reply. Causes: target host is down, wrong subnet configuration, firewall blocking ARP, or the target is on a different VLAN. Check with arping or ip neigh.
• Duplicate IP address — Two hosts claim the same IP. The ARP cache flaps between two different MAC addresses. Most OSes log a warning: "ARP: duplicate IP address detected." Fix: check DHCP scope for overlaps with static assignments.
• ARP cache stale after failover — After a server failover or VM migration, clients hold the old MAC in their cache. Traffic goes to the wrong port until the cache expires. Fix: the new active host should send a gratuitous ARP. VRRP/HSRP do this automatically.
• Asymmetric ARP — Host A can ARP Host B, but Host B cannot ARP Host A. Usually caused by a misconfigured firewall or ACL on the switch blocking ARP in one direction.

ARP in Cloud and Virtualized Environments

In cloud environments like AWS, Azure, and GCP, ARP works differently than on physical networks. Cloud providers typically intercept ARP at the hypervisor level and respond with the virtual MAC address associated with each instance's virtual NIC. The "network" is software-defined — there is no physical Ethernet broadcast domain.

In container environments (Docker, Kubernetes), each container may have its own virtual Ethernet interface (veth pair) connected to a software bridge. ARP works normally within the bridge domain, but the bridge is entirely within the host kernel. Cross-host communication in overlay networks (Flannel, Calico, Cilium) typically uses VXLAN or IP-in-IP tunneling, with ARP proxied or suppressed at the tunnel endpoints.

ARP Timers and Tuning

Default ARP cache timeouts vary by operating system:

Linux tuning is done via sysctl:

# Base reachable time in milliseconds (default 30000)
net.ipv4.neigh.eth0.base_reachable_time_ms = 30000

# Maximum number of entries in the ARP cache
net.ipv4.neigh.default.gc_thresh3 = 4096

# Delay before probing a STALE entry (seconds)
net.ipv4.neigh.eth0.delay_first_probe_time = 5

On routers handling large subnets, tuning the ARP cache size (gc_thresh on Linux, arp timeout on Cisco) is essential to prevent cache overflow, which causes ARP resolution failures and intermittent connectivity.

Capturing and Analyzing ARP Traffic

ARP traffic is easy to capture and analyze with packet capture tools:

# Capture ARP packets with tcpdump
$ sudo tcpdump -i eth0 arp -nn
15:42:01 ARP, Request who-has 192.168.1.75 tell 192.168.1.50, length 28
15:42:01 ARP, Reply 192.168.1.75 is-at b8:27:eb:4a:dc:10, length 28

# Capture with Wireshark filter
arp

# Show only ARP requests
arp.opcode == 1

# Show only ARP replies
arp.opcode == 2

# Detect possible ARP spoofing (duplicate IP with different MAC)
arp.duplicate-address-detected

In Wireshark, ARP traffic analysis is often the first step in diagnosing Layer 2 connectivity issues. Patterns to look for include excessive ARP requests for the same target (indicating the target is unreachable), MAC address flapping (possible ARP spoofing or duplicate IP), and ARP storms (thousands of requests per second from misconfigured devices).

ARP and Network Security: The Bigger Picture

ARP's lack of authentication is part of a broader pattern in networking: many foundational protocols were designed for small, trusted environments and lack built-in security. BGP is another example — it was designed assuming all peers are trustworthy, which is why BGP hijacks are possible and why RPKI was developed as a countermeasure.

The parallel is instructive: just as RPKI adds cryptographic validation to BGP announcements, technologies like DAI and SEND add validation to ARP/NDP. And just as BGP security requires deployment across many networks to be fully effective, ARP security requires consistent enforcement across every switch in the network. A single unprotected switch port can be the entry point for an ARP spoofing attack.

The defense-in-depth approach is essential: segment networks with VLANs, enable DAI on managed switches, use 802.1X for port authentication, encrypt sensitive traffic with TLS, and monitor for anomalies. No single measure eliminates the risk, but together they make ARP-based attacks impractical.

Explore how IP addresses map to networks and autonomous systems using the god.ad looking glass. Look up any IP to see its BGP route, origin AS, and the AS path that traffic follows across the internet — the global routing layer that sits above the local ARP-resolved links described in this article.