Address Resolution Protocol

Every time your computer communicates with another device on the local network, an elegant dance of discovery occurs—often completed in mere milliseconds, entirely invisible to users. This dance is ARP operation: the sequence of events that transforms an IP address question into a MAC address answer.

Understanding ARP's operational mechanics is essential for network troubleshooting. When network communication fails at the local level, the problem often traces back to ARP—failed resolutions, stale cache entries, or misconfigured addresses. Mastering ARP operation transforms mysterious failures into diagnosable, fixable issues.

ARP is a reactive protocol—it doesn't continuously run or poll; it activates only when specific conditions are met. Understanding these trigger conditions helps diagnose when and why ARP traffic appears on a network.

Primary Trigger: Outbound Packet Requires Unknown MAC

The fundamental trigger occurs when the IP layer hands a packet to the data link layer for transmission, but the required destination MAC address is unknown. The IP layer has determined the next-hop IP address (either the final destination for local delivery or a gateway for remote destinations), but this IP must be mapped to a MAC before the frame can be constructed.

Let's trace through a complete ARP operation from start to finish. Consider this scenario:

• Host A: IP 192.168.1.100, MAC AA:AA:AA:AA:AA:AA
• Host B: IP 192.168.1.200, MAC BB:BB:BB:BB:BB:BB
• Host A wants to send data to Host B, but A's ARP cache is empty

Step-by-Step Sequence:

Detailed Step Breakdown:

Step 1: Application initiates communication An application on Host A (e.g., a web browser) attempts to connect to 192.168.1.200. The socket call descends through the TCP/UDP layer to IP.

Step 2: IP layer routing decision The IP layer compares 192.168.1.200 against A's subnet mask (say, 255.255.255.0). Result: same subnet as 192.168.1.100. Conclusion: direct delivery to 192.168.1.200 (not via gateway).

Step 3: Data link layer receives packet IP passes the packet to the data link layer with instruction: "deliver to 192.168.1.200." The data link layer needs B's MAC to construct the Ethernet frame.

Step 4: ARP cache lookup The system checks its ARP cache for an entry mapping 192.168.1.200 → MAC. No entry found.

Step 5: ARP Request construction The system builds an ARP request packet:

• Hardware Type: 1 (Ethernet)
• Protocol Type: 0x0800 (IPv4)
• Operation: 1 (Request)
• Sender Hardware Address: AA:AA:AA:AA:AA:AA
• Sender Protocol Address: 192.168.1.100
• Target Hardware Address: 00:00:00:00:00:00 (unknown—that's the question)
• Target Protocol Address: 192.168.1.200

Step 6: Ethernet frame construction for broadcast

• Destination MAC: FF:FF:FF:FF:FF:FF (broadcast)
• Source MAC: AA:AA:AA:AA:AA:AA
• EtherType: 0x0806 (ARP)
• Payload: The ARP request packet

Step 7: Network transmission Frame is transmitted. All switches flood it to all ports in the broadcast domain. Every host receives the frame.

Step 8: Host processing (non-target hosts) Host C and others receive the frame, see EtherType 0x0806, parse the ARP request. They check: is 192.168.1.200 my IP? No. They discard the request. (Note: They may optionally cache A's mapping for future use.)

Step 9: Host B processing (target) Host B receives the frame. Same parsing. Check: is 192.168.1.200 my IP? YES.

Host B:

1. Caches A's mapping: 192.168.1.100 → AA:AA:AA:AA:AA:AA
2. Constructs an ARP reply

Step 10: ARP Reply construction

• Operation: 2 (Reply)
• Sender Hardware Address: BB:BB:BB:BB:BB:BB
• Sender Protocol Address: 192.168.1.200
• Target Hardware Address: AA:AA:AA:AA:AA:AA (from the request)
• Target Protocol Address: 192.168.1.100

Step 11: Ethernet frame construction for unicast reply

• Destination MAC: AA:AA:AA:AA:AA:AA (unicast to A)
• Source MAC: BB:BB:BB:BB:BB:BB
• EtherType: 0x0806
• Payload: The ARP reply

Step 12: Host A receives reply Host A receives the frame, parses the ARP reply, extracts B's MAC address, and adds the entry to its cache: 192.168.1.200 → BB:BB:BB:BB:BB:BB

Step 13: Original packet can now be sent The data link layer can now construct the original Ethernet frame with B's MAC address and transmit the queued data.

Let's examine the exact byte-level construction of ARP packets. Understanding this level of detail is essential for packet capture analysis and security research.

ARP Request Packet (Hexadecimal Representation)

ARP Reply Packet (Hexadecimal Representation)

When a host receives an ARP message (request or reply), it follows a specific processing algorithm. RFC 826 specifies this logic, and operating systems follow it with minor variations.

ARP Message Processing Algorithm:

Key Insights from the Algorithm:

1. Merge Before Check: The RFC specifies that the Sender's address pair should be used to update existing cache entries before checking if the target is the local host. This optimization means that if Host A already has Host B cached and receives an ARP from B (for any target), A's cache for B gets refreshed. This 'eager update' reduces future ARP traffic.

2. Cache on Request Processing: When a host receives an ARP request for its own IP, it always caches the sender's mapping—even if it wasn't already cached. This makes sense: if someone is asking for my MAC, they probably want to communicate with me, so I should cache them to prepare for the response.

3. Never Reply to Replies: A host does not generate an ARP reply in response to receiving an ARP reply. Replies are terminal—they conclude the exchange.

4. Unsolicited Cache Updates: The algorithm allows updating cache entries based on replies the host didn't request. This is the foundation of both Gratuitous ARP (benign) and ARP Spoofing (malicious).

Gratuitous ARP (GARP) is an ARP packet where:

• The Sender IP equals the Target IP
• The host is essentially asking for its own address

This might seem useless—why ask for your own MAC? But GARP serves several important purposes:

Gratuitous ARP Packet Structure:

Operation: 1 (Request) or 2 (Reply)
Sender IP: 192.168.1.100     (Same as Target)
Sender MAC: AA:AA:AA:AA:AA:AA
Target IP: 192.168.1.100     (Same as Sender)
Target MAC: 00:00:00:00:00:00 (ignored) or sender's MAC

ARP involves several timing parameters that affect network behavior. Understanding these is crucial for performance tuning and troubleshooting.

Key ARP Timers:

The Incomplete Entry Problem

When Host A sends an ARP request but receives no reply, the entry is marked 'incomplete.' Operating systems handle this differently:

1. Incomplete entries are temporary: After ~3 seconds with no reply, the entry is removed
2. Retries are limited: Typically 3 attempts before marking destination unreachable
3. Traffic is queued, then dropped: Packets destined for the incomplete entry are queued briefly, then dropped if resolution fails

Linux ARP State Machine:

Linux implements a sophisticated ARP state machine (actually part of the Neighbor Discovery subsystem shared with IPv6):

• NEW: Entry created, no resolution yet
• INCOMPLETE: Request sent, awaiting reply
• REACHABLE: Entry confirmed reachable (by upper-layer confirmation)
• STALE: Entry aged out but not yet removed
• DELAY: Using stale entry, scheduling refresh
• PROBE: Actively probing to verify entry
• FAILED: Resolution failed, entry will be removed

Proxy ARP is a technique where a router or gateway answers ARP requests on behalf of hosts located on different networks. This allows hosts to communicate across network boundaries as if they were on the same subnet—without explicit routing configuration on the hosts.

How Proxy ARP Works:

Scenario Walkthrough:

1. Host A (192.168.1.100) is configured with a wide mask (e.g., 255.255.0.0) making it believe 192.168.2.100 is local
2. A sends an ARP broadcast asking for 192.168.2.100's MAC
3. The router has Proxy ARP enabled and knows 192.168.2.100 is reachable via its other interface
4. Router sends an ARP reply with its own MAC address
5. Host A's cache now maps 192.168.2.100 → Router's MAC
6. A sends packets destined for B to the router, which forwards them to B

When Proxy ARP Is Useful:

• Legacy/Misconfigured Hosts: Hosts with wrong subnet masks can still communicate
• Dial-up/VPN Scenarios: PPP clients often rely on proxy ARP to reach local servers
• Network Migration: Temporarily maintains connectivity during subnet reorganization
• Address Conservation: Less common today, but avoids wasting /30 subnets on point-to-point links

Modern Ethernet networks use switches rather than hubs. Understanding how switches handle ARP traffic is essential for network design.

Switch Behavior with ARP:

The ARP Broadcast Problem at Scale

In large Layer 2 domains (thousands of hosts), ARP broadcasts become problematic:

• Every host processes every ARP request (CPU overhead)
• Broadcast storms possible if loops exist
• Significant portion of bandwidth consumed by control traffic
• Performance degrades as network grows

This is why large networks:

1. Use smaller VLANs (fewer hosts per broadcast domain)
2. Implement ARP suppression/proxy on ToR switches
3. Use EVPN/VXLAN fabrics that minimize broadcast replication
4. Move toward IPv6 with its more efficient NDP

We've explored the complete operational lifecycle of ARP—from trigger conditions through request/reply exchange to cache population. Let's consolidate the key takeaways:

What's Next:

With ARP operation fully understood, we'll examine the ARP cache in depth—how it's organized, managed, and tuned. We'll explore cache data structures, aging policies, and the various cache states that operating systems maintain.