An application usually identifies a destination by hostname or IP address. Ethernet needs a destination MAC address before it can transmit a frame on the local network.
The Address Resolution Protocol, or ARP, connects those two forms of addressing for IPv4. Given the IPv4 address of a local next hop, ARP discovers the MAC address needed for the Ethernet frame.
ARP does not resolve every remote destination to a MAC address. For a server on another IP network, the sender resolves the MAC address of a local gateway. The remote server's MAC address remains relevant only on the server's own local network.
This local, next-hop behavior defines the purpose and scope of ARP.
ARP carries address-resolution messages directly inside Ethernet frames. It does not use an IP header, TCP, UDP, or transport ports.
Ethernet identifies an ARP payload with EtherType 0x0806:
An ARP message carries both protocol-layer and hardware-layer addresses. On Ethernet with IPv4, those are IPv4 and 48-bit MAC addresses.
ARP was designed to support other protocol and hardware address formats, which explains why its header contains type and length fields. Ethernet and IPv4 are the common combination described here.
IPv6 does not use ARP. It performs neighbor resolution through ICMPv6 Neighbor Discovery. The purpose is comparable, but the message format and delivery rules differ.
A host does not begin with ARP every time it sends an IPv4 packet. It first determines the local next hop and checks whether it already has a usable address mapping.
The workflow proceeds as follows:
The operating system can queue packets while resolution is in progress. If no reply arrives after a limited number of attempts, it marks the neighbor unreachable and reports a delivery failure to higher layers.
ARP resolves the local next-hop IPv4 address, which depends on whether the final IP destination is local or remote.
Consider two hosts on the same IPv4 network:
The client selects 192.0.2.20 as the next hop because the server is directly reachable on the local network. It resolves:
The resulting Ethernet frame targets the server directly.
Consider the same client contacting a remote API:
The operating system selects 192.0.2.1 as the local next hop. ARP resolves:
The frame and packet then contain different destination roles:
The client does not broadcast an ARP request for 203.0.113.20. ARP broadcasts remain within the local Layer 2 network, and a router does not forward them toward the remote API.
The following exchange resolves a gateway's address:
The client needs to send an IPv4 packet through 192.0.2.1, but its neighbor cache has no usable entry for that address.
It broadcasts an ARP request:
The target MAC field is commonly all zeroes because that value is the information being requested. Every interface in the local broadcast scope receives the frame, but only the interface that owns 192.0.2.1 needs to answer.
The gateway sends a unicast reply:
The exchange can be summarized as:
The reply gives the client enough information to construct the original data frame. ARP delivers no application data and establishes no end-to-end connection.
Loading simulation...
An ARP message for Ethernet and IPv4 is 28 bytes:
| Field | Size | Ethernet/IPv4 Value or Purpose |
|---|---|---|
| Hardware Type | 2 bytes | 1 for Ethernet |
| Protocol Type | 2 bytes | 0x0800 for IPv4 |
| Hardware Address Length | 1 byte | 6 for a 48-bit MAC address |
| Protocol Address Length | 1 byte | 4 for an IPv4 address |
| Operation | 2 bytes | 1 for request, 2 for reply |
| Sender Hardware Address | 6 bytes | Sender's MAC address |
| Sender Protocol Address | 4 bytes | Sender's IPv4 address |
| Target Hardware Address | 6 bytes | Target's MAC, or an unknown placeholder in a request |
| Target Protocol Address | 4 bytes | IPv4 address being queried or answered |
The header begins with four fields that define how to interpret the variable-length addresses.
Hardware Type, or HTYPE, identifies the link-layer technology.
Protocol Type, or PTYPE, uses the same value space as Ethernet EtherType. 0x0800 means IPv4.
Hardware Length, or HLEN, and Protocol Length, or PLEN, give the address sizes in bytes.
Operation, or OPER, identifies the message as a request or reply.
The four address fields then describe the sender and target. Their sizes come from HLEN and PLEN rather than being fixed by the generic ARP header.
All multi-byte numeric fields use network byte order, with the most significant byte first.
The 28-byte ARP request from the previous example can begin with these bytes:
Splitting the bytes by field gives:
The IPv4 octets appear directly in hexadecimal. c0 00 02 0a converts to decimal octets 192.0.2.10.
The Ethernet header appears before these bytes in a complete frame. It supplies the broadcast destination, client source MAC, and ARP EtherType. The ARP payload repeats the sender MAC because ARP needs to carry the logical mapping as protocol data.
An Ethernet/IPv4 ARP message occupies 28 bytes. Standard Ethernet requires at least 46 bytes in its payload field, so the sender adds 18 bytes of padding:
The padding does not belong to the ARP message. The HLEN and PLEN fields define the address sizes, and the known ARP structure ends after the target protocol address.
A host capture can display only 42 bytes for the Ethernet header plus ARP message if hardware adds padding after the capture point and removes the FCS before delivery to the operating system. Other captures show 60 bytes because they include padding but omit the FCS. A physical capture with the FCS shows the complete 64-byte minimum frame.
Broadcasting before every IPv4 packet would add unnecessary traffic and delay. Hosts store recent IP-to-MAC mappings in a neighbor cache, traditionally called the ARP cache for IPv4.
An entry associates three pieces of information:
The interface is part of the mapping because the same IPv4 address can appear on separate local networks.
Cache entries can be dynamic or static. Dynamic entries come from address-resolution activity and expire or require validation according to operating-system rules. Static entries remain until configuration removes them, but they require manual maintenance.
Timeouts are implementation-dependent. A host can keep an entry after recent confirmation, mark it stale when freshness is uncertain, and probe again when traffic needs it. An entry marked stale does not mean the mapping is wrong. It means the operating system needs new reachability evidence before treating it as recently confirmed.
Linux commonly reports states such as:
REACHABLE: Recent evidence confirms the neighbor.STALE: The entry exists, but recent reachability has not been confirmed.DELAY: The system is waiting briefly before active probing.PROBE: The system is sending requests to verify the neighbor.INCOMPLETE: Address resolution is still in progress.FAILED: Resolution attempts did not produce a usable result.State names and transitions differ across operating systems, but every implementation must balance cache reuse against stale information.
Linux displays IPv4 and IPv6 neighbor entries with:
An IPv4 entry can resemble:
The entry says that 192.0.2.1 is reachable through eth0 at MAC address 02:00:00:00:00:01.
To inspect one interface:
macOS can display IPv4 ARP entries with:
An entry can resemble:
A missing entry does not establish a fault. The host may not have communicated with that next hop recently, or an old dynamic entry may have expired. An incomplete or failed entry after active traffic provides stronger evidence of a resolution problem.
tcpdump can filter for ARP and include Ethernet headers:
Replace en0 with the active interface. A normal request and reply can appear as:
The first line exposes the Ethernet broadcast. The ARP payload identifies the target IPv4 address and the requester. The reply uses the requester's MAC as its Ethernet destination.
Adding -XX prints the link-layer header and payload bytes:
Wireshark uses the display filter:
More specific filters include:
Opcode 1 selects requests, while opcode 2 selects replies.
An ARP request already contains the sender's IPv4 and MAC addresses. The target therefore gains a mapping for the requester before sending the reply.
Other hosts also receive the broadcast request. Operating systems differ in how they use sender information from requests and unsolicited messages. Some update an existing entry, some create a new entry under limited conditions, and security settings can restrict acceptance.
The requester should verify that a reply has the expected protocol and hardware types, address lengths, and target information before accepting the mapping. ARP still provides no cryptographic proof that the claimed sender owns the IPv4 address.
Cache-learning rules affect both efficiency and security. Accepting more information can reduce future broadcasts, while accepting unauthenticated claims can install a false mapping.
ARP can check whether an IPv4 address is already in use and can announce a new mapping.
An ARP Probe checks a candidate address before assigning it. The sender uses 0.0.0.0 as its sender IPv4 address and places the candidate in the target IPv4 field:
Using 0.0.0.0 avoids claiming the candidate before conflict detection completes. A reply or conflicting announcement indicates that another host may already use the address.
An ARP Announcement, often called gratuitous ARP, broadcasts a host's current mapping. A common form uses an ARP request with the same address in both protocol-address fields:
Announcements support several operations:
Some systems also send unsolicited ARP replies. Implementations and network security policies determine whether recipients create or update cache entries from these messages.
With proxy ARP, one device answers an ARP request on behalf of another IPv4 destination.
For example, a host broadcasts a request for 192.0.2.50. A router or proxy replies with its own MAC address even though the destination belongs elsewhere. The host then sends frames for 192.0.2.50 to the proxy, which forwards the enclosed IP packets.
Proxy ARP can connect hosts across boundaries without changing their local addressing assumptions. It also hides the actual Layer 3 boundary and can make troubleshooting less direct. Its use should be deliberate and documented.
ARP has no authentication, signature, or trusted authority. A host can send a message claiming:
If another system accepts the claim, it can replace the legitimate gateway mapping with the attacker's MAC address. This is ARP spoofing or ARP cache poisoning.
The result depends on what the attacker does next:
Encrypted application protocols still protect their authenticated content when certificate or key validation remains intact. The attacker can observe traffic metadata and disrupt delivery, but a poisoned ARP entry alone does not defeat correctly validated encryption.
Common protections include static mappings for a small number of fixed systems, switch features that validate ARP claims against trusted address assignments, port-level access controls, local network isolation, and monitoring for unexpected mapping changes.
ARP security controls must know which IP-to-MAC relationships are allowed. Blindly accepting every request and reply preserves compatibility but provides no defense against false ownership claims.
Two interfaces using the same IPv4 address can produce symptoms that resemble ARP poisoning even when no attacker exists.
Both devices can answer requests for the shared address. Neighbor caches may alternate between their MAC addresses as new messages arrive. Connections can reach different systems over time, reset unexpectedly, or fail in one direction.
A capture can reveal the conflict:
ARP probes and announcements help detect duplicates, but prevention also depends on coordinated address assignment. Static configuration and automatic allocation systems must avoid assigning the same address to multiple active interfaces.
ARP never creates one end-to-end mapping between an internet client and a remote server. Each Ethernet network resolves its own local next hop.
On the client's Ethernet network, the client resolves its local router interface.
On the server's Ethernet network, the final router interface resolves the server.
Intermediate links perform their own link-layer delivery. Some may use ARP, while others may use a different local mechanism. The IP packet can cross all of them without carrying an ARP message from the client.
An ARP investigation should establish the selected next hop, request transmission, reply reception, and cache result.
On Linux:
For a remote destination, the result should identify a local gateway and outgoing interface. ARP should target that gateway rather than 203.0.113.20.
INCOMPLETE or FAILED after traffic indicates that resolution did not produce a usable mapping. A STALE entry can still be valid and may transition after new traffic.
The resulting patterns narrow the fault:
No request appears: The route selected another interface, a usable cache entry already exists, or the host did not attempt the expected traffic.
Requests repeat with no reply: The target can be offline, disconnected, filtered, assigned a different address, or outside the local Layer 2 scope.
A reply appears but the cache remains unusable: The reply fields may not match the pending request, a security policy may reject it, or duplicate claims may keep replacing the mapping.
The mapping resolves but IP traffic fails: ARP completed its local task. The remaining failure belongs to packet forwarding, filtering, transport, or the application.
Filter for all messages involving the affected address:
Multiple sender MAC addresses claiming the same IPv4 address indicate a duplicate configuration, failover transition, proxy behavior, or spoofing.
ARP resolves local next hops. A client contacting a remote server resolves its local gateway, not the server's remote MAC address.
ARP runs beside IPv4 rather than inside it. The Ethernet EtherType is 0x0806, and the message has no IP or transport header.
Requests are broadcast, while normal replies are unicast. The request uses a broadcast because the target MAC is unknown. The reply already knows the requester's MAC.
An ARP cache entry is temporary local state. It applies to one interface and can expire, become stale, or change.
A reply is not authenticated ownership proof. ARP accepts local address claims without cryptographic verification.
A stale entry is not automatically incorrect. It indicates that recent reachability needs confirmation.
IPv6 uses another mechanism. Neighbor Discovery carries IPv6 neighbor-resolution functions through ICMPv6.
ARP maps a selected IPv4 next-hop address to the MAC address required for local Ethernet delivery. Local traffic resolves the destination host, while remote traffic resolves a local gateway. Requests use Ethernet broadcast, normal replies use unicast, and both travel directly in Ethernet frames with EtherType 0x0806.
An Ethernet/IPv4 ARP message is 28 bytes and records the hardware and protocol types, address lengths, operation, and sender and target addresses. Neighbor caches reduce broadcasts by retaining recent mappings and their reachability state.
ARP probes help detect address conflicts, announcements update mappings, and Proxy ARP allows a device to answer for another destination. Because ARP has no authentication, unprotected local networks are vulnerable to spoofing and cache poisoning. Each routed Ethernet network performs its own resolution; ARP never travels end to end.
ARP turns a known local next-hop IP address into the destination MAC address for the next Ethernet frame.
5 quizzes