OneNoughtOne
0/240
Loading content...
Read aloud is unavailable in this browser.
Every time you send data across a network—whether it's loading a webpage, sending an email, or streaming video—your packets must traverse a fundamental boundary. They must cross from the logical realm of IP addresses (carefully designed, hierarchically organized, network-agnostic identifiers) into the physical realm of hardware addresses (MAC addresses burned into network interface cards, flat namespaces, completely unrelated to network topology).
This is the core problem ARP solves.
Without ARP, the entire Internet protocol stack collapses. Your computer knows someone's IP address, but the Ethernet frame cannot be constructed without the destination's MAC address. IP routing gets the packet to the correct network; ARP gets the packet to the correct machine on that network.
By the end of this page, you will understand why ARP exists, how it bridges the gap between network layer addressing and data link layer addressing, the fundamental concepts of address resolution, and why this seemingly simple protocol is critical infrastructure for all IP-based communication.
To fully appreciate ARP, we must first understand why two different addressing systems exist and why neither can replace the other.
The OSI Model Separation
The network architecture deliberately separates addressing concerns across layers:
This separation isn't an accident or legacy baggage—it's an intentional design decision that provides crucial flexibility. IP addresses can be reassigned, moved between networks, and organized hierarchically for efficient routing. MAC addresses provide stable, unique identifiers for actual hardware, enabling communication even when IP configurations fail or change.
| Characteristic | IP Address (Layer 3) | MAC Address (Layer 2) |
|---|---|---|
| Length | 32 bits (IPv4) / 128 bits (IPv6) | 48 bits (with 64-bit EUI-64 extension) |
| Format | Dotted decimal (192.168.1.100) | Hexadecimal separated by colons (00:1A:2B:3C:4D:5E) |
| Assignment | Software-configured, assigned by network admin or DHCP | Hardware-burned by manufacturer (OUI + device ID) |
| Scope | Global—routable across the entire Internet | Local—only meaningful within the same broadcast domain |
| Hierarchy | Hierarchical—network prefix + host portion | Flat—no inherent structure for routing |
| Persistence | Can change (DHCP lease, network move) | Permanent (though can be spoofed in software) |
| Used By | Routers for inter-network forwarding | Switches for intra-network frame delivery |
Using only MAC addresses would make routing impossible—routers would need tables with billions of entries. Using only IP addresses would mean hardware couldn't communicate without full IP stack configuration. The layered approach provides the best of both worlds: efficient hierarchical routing at Layer 3 and reliable local delivery at Layer 2.
Address resolution is the process of mapping one type of address to another. In the context of ARP, this means translating a known network layer address (IP) into an unknown data link layer address (MAC).
The Fundamental Question ARP Answers:
"I know the IP address of the device I want to communicate with. What is its MAC address so I can construct an Ethernet frame?"
This question arises constantly during normal network operation. Every IP packet encapsulated in an Ethernet frame requires knowing the destination MAC address. Without it, the frame cannot be properly addressed and the switch/bridge infrastructure cannot deliver it to the correct port.
ARP performs IP → MAC resolution. The reverse (MAC → IP) is handled by RARP (Reverse ARP), which historically helped diskless workstations discover their IP addresses during boot. RARP has been largely superseded by BOOTP and DHCP, but the concept of bidirectional resolution remains important.
ARP operates as a Layer 2.5 protocol—it sits conceptually between the network layer and the data link layer. It uses Layer 2 frames to carry its messages but resolves Layer 3 addresses. This unique positioning makes it essential infrastructure for IP networking.
Protocol Identification
0x08060x8035When an Ethernet frame carries ARP, the Type field in the Ethernet header is set to 0x0806, distinguishing it from regular IP traffic (0x0800) and IPv6 traffic (0x86DD).
ARP Packet Structure
The ARP packet format is defined in RFC 826 and is remarkably elegant in its simplicity. Despite being designed in 1982, it remains virtually unchanged because it accomplishes its purpose efficiently.
The packet contains 28 bytes (for IPv4 over Ethernet) organized into fixed fields that describe the hardware type, protocol type, operation code, and the four critical addresses involved in any resolution:
| Field | Size (bytes) | Description |
|---|---|---|
| Hardware Type (HTYPE) | 2 | Type of hardware address (1 = Ethernet, 6 = IEEE 802, etc.) |
| Protocol Type (PTYPE) | 2 | Type of protocol address (0x0800 = IPv4) |
| Hardware Address Length (HLEN) | 1 | Length of hardware address in bytes (6 for MAC) |
| Protocol Address Length (PLEN) | 1 | Length of protocol address in bytes (4 for IPv4) |
| Operation (OPER) | 2 | Operation code: 1 = Request, 2 = Reply |
| Sender Hardware Address (SHA) | 6 | MAC address of the sender |
| Sender Protocol Address (SPA) | 4 | IP address of the sender |
| Target Hardware Address (THA) | 6 | MAC address of the target (0 in requests) |
| Target Protocol Address (TPA) | 4 | IP address of the target |
While we focus on IPv4 over Ethernet, ARP's design is protocol-agnostic. The HTYPE and PTYPE fields allow ARP to map any network layer protocol to any data link layer protocol. This flexibility, though rarely used today, was critical during the era of multiple competing networking standards.
One might ask: "Why not just configure a static table of IP-to-MAC mappings?" This approach exists (static ARP entries) but is impractical for several reasons:
Why Static Mapping Fails at Scale
The Dynamic Solution
ARP provides an elegant dynamic solution:
This dynamic approach trades a small amount of network traffic (ARP requests and replies) for massive operational simplicity.
Static ARP entries are still valuable in specific scenarios: securing critical servers against ARP spoofing attacks, ensuring routers always reach their peers, or in embedded systems with fixed network topology. Modern switches also offer features like 'Dynamic ARP Inspection' that combine dynamic learning with security validation.
Understanding where ARP fits in the packet transmission process illuminates its critical role. When an IP packet must be sent, the operating system's network stack must make a series of decisions:
The Transmission Decision Tree
Key Insight: ARP Only Resolves Next-Hop Addresses
A critical concept many newcomers miss: ARP only resolves the next-hop MAC address, never the final destination (unless they're the same). Consider this scenario:
Host A does NOT ARP for 8.8.8.8—that address is on a remote network. Instead:
ARP is NOT end-to-end. The source IP and destination IP in a packet remain constant as it traverses the Internet. But the source MAC and destination MAC change at every hop. Each router ARPs for its next hop independently. This is why MAC addresses are described as 'locally significant.'
ARP messages are encapsulated in Ethernet frames, and understanding this encapsulation reveals important operational details.
Ethernet Frame Carrying ARP
When a host sends an ARP request, the Ethernet frame structure includes:
| Field | Value | Explanation |
|---|---|---|
| Destination MAC | FF:FF:FF:FF:FF:FF | Broadcast address—all hosts on segment receive the frame |
| Source MAC | Sender's MAC | The host initiating the ARP request |
| EtherType | 0x0806 | Indicates payload is ARP (not IP, not IPv6) |
| Payload | ARP Packet (28 bytes) | Contains the ARP request with all four addresses |
| FCS | 4-byte CRC | Frame Check Sequence for error detection |
For ARP Reply:
Unlike the request, ARP replies are unicast—they're sent directly to the MAC address of the original requester, not broadcast to everyone:
| Field | Value | Explanation |
|---|---|---|
| Destination MAC | Requester's MAC | Directly addressed to who asked |
| Source MAC | Responder's MAC | The host answering the request |
| EtherType | 0x0806 | Still ARP |
| Payload | ARP Reply Packet | Operation code 2, now with target MAC filled in |
This unicast behavior is important for efficiency—broadcasts consume bandwidth on all hosts, while unicast replies only involve the two parties.
ARP broadcasts are confined to a single broadcast domain. Routers do NOT forward ARP requests—they terminate them. This is why ARP only works within a local subnet. If hosts need to communicate across subnets, they must go through a router, which handles ARP independently on each of its interfaces.
ARP was formally specified in RFC 826 by David C. Plummer in November 1982. The document, titled "An Ethernet Address Resolution Protocol," is remarkably concise—just four pages—yet has remained the authoritative specification for over four decades.
Key Historical Context:
RFC 826 is one of the most readable and educational RFCs ever written. At just four pages, it's an excellent example of how to specify a protocol clearly and completely. It's recommended reading for any networking student or professional.
While ARP serves IPv4, IPv6 does not use ARP. Instead, IPv6 employs the Neighbor Discovery Protocol (NDP), defined in RFC 4861. NDP is more sophisticated and addresses several ARP limitations.
Why IPv6 Replaced ARP:
| Aspect | ARP (IPv4) | NDP (IPv6) |
|---|---|---|
| Resolution Method | Broadcast ARP Request | Multicast Neighbor Solicitation |
| Address Scope | Uses broadcast (all hosts receive) | Uses solicited-node multicast (only interested hosts) |
| Efficiency | All hosts must process all requests | Only hosts with matching addresses process |
| Security | No built-in security | Can use SEND (Secure Neighbor Discovery) |
| Additional Functions | Only address resolution | Also handles router discovery, prefix discovery, duplicate detection |
| Protocol Layer | Layer 2.5 (separate EtherType) | ICMPv6 (integrated into IP) |
| Packet Format | Standalone ARP packet | ICMPv6 message types 135, 136 |
Solicited-Node Multicast
One of NDP's clever optimizations is the use of solicited-node multicast addresses. Instead of broadcasting to everyone, NDP sends Neighbor Solicitation messages to a multicast group derived from the target's IPv6 address. Only hosts with IPv6 addresses ending in the same 24 bits are members of that group—dramatically reducing unnecessary processing.
For example, to resolve 2001:db8::1:2:3:4, the solicited-node multicast address is FF02::1:FF03:0004, and only hosts with addresses ending in 03:0004 listen to that group.
Despite IPv6's improvements, ARP remains essential infrastructure because IPv4 is still ubiquitous. Most networks run dual-stack (IPv4 and IPv6 simultaneously), meaning both ARP and NDP operate concurrently. Understanding ARP is not legacy knowledge—it's current operational necessity.
We've established the conceptual foundation of ARP—the protocol that makes IP over Ethernet possible. Let's consolidate the key takeaways:
What's Next:
Now that we understand what ARP is and why it exists, we'll dive into its operation—the detailed mechanics of how ARP requests and replies are generated, transmitted, and processed. We'll trace through the exact sequence of events when a host needs to resolve an address.
You now understand the Address Resolution Protocol's purpose and architectural position. ARP is the invisible infrastructure that enables every IP packet to reach its local destination. Next, we'll examine exactly how ARP operations work, step by step.