Every device on a network has both an IP address and a MAC address, and something has to bridge the two. That’s the job of the Address Resolution Protocol (ARP): mapping a known IP address to the MAC address a device actually needs to build an Ethernet frame. This guide covers exactly how that resolution process works, how ARP tables behave, and the security implications of a protocol that was designed decades before network security was a primary concern.
Why Address Resolution Protocol (ARP) Exists
When a device sends an Ethernet frame, that frame needs both a destination and source MAC address in its header, regardless of what IP address the packet inside it is addressed to. The destination MAC address can be unicast, broadcast, or multicast depending on the situation, but the source MAC address is always unicast, since a frame only ever originates from one specific device. ARP exists specifically to resolve the destination MAC address a device needs before it can build that frame in the first place.
How ARP Resolves IPv4 Addresses to MAC Addresses
Every device maintains an ARP table, also called the ARP cache, stored in RAM. Before sending a frame, a device checks this table for an existing mapping between the relevant IPv4 address and its corresponding MAC address:
- If the destination IPv4 address is on the same local network as the source, the device looks up the destination’s own IPv4 address in its ARP table.
- If the destination IPv4 address is on a different network, the device looks up its default gateway’s IPv4 address instead, since the frame needs to go to the router first regardless of the packet’s ultimate destination.
Each ARP table entry binds one MAC address to one IPv4 address, a mapping the table stores only temporarily, not permanently.
When There’s No Existing Entry
If a device needs to send a frame and finds no matching entry in its ARP table, it sends an ARP request to discover the missing MAC address. This request is encapsulated directly in an Ethernet frame, with no IPv4 header involved at all, which is worth noting since ARP is often mistakenly assumed to be an IP-layer protocol. It isn’t; it operates directly at the Ethernet level.
The ARP request includes:
- Target IPv4 address: The IP address the sender is trying to resolve.
- Target MAC address: Unknown at this point, so this field is set to all zeros (00:00:00:00:00:00) rather than left genuinely blank, since ARP packet fields have a fixed length.
The Ethernet frame carrying the request includes:
- Destination MAC address: The broadcast address, FF:FF:FF:FF:FF:FF, so every NIC on the local segment receives and processes the request.
- Source MAC address: The MAC address of the device sending the request.
- Type: 0x0806, the EtherType value that tells a receiving NIC to hand this frame’s payload to the ARP process rather than treating it as ordinary IP traffic.
Because the request is a broadcast, a switch floods it out every port except the one it arrived on. Every device on the segment receives it, but only the device whose IPv4 address matches the target address actually responds; every other device silently discards it.
The ARP Reply
This is a detail that’s easy to overlook: unlike the request, the ARP reply is sent as unicast, not broadcast. By the time the target device responds, it already knows the requester’s MAC address, since that address was included as the source MAC in the original request frame. There’s no need to broadcast the reply to the entire segment when the responder can address it directly to the one device that actually needs it.
Reaching a Remote Network
If the destination IPv4 address isn’t on the local network, the source device needs to send the frame to its default gateway instead of directly to the final destination. The default gateway’s IPv4 address is stored in the host’s own IP configuration. When building a packet, a device compares the destination IPv4 address against its own to determine whether they’re on the same network. If they’re not, the device checks its ARP table for an entry matching the default gateway’s IPv4 address, and runs the ARP process to resolve it if no entry exists yet. The resulting frame then goes to the router’s MAC address, even though the packet inside it is ultimately headed somewhere else entirely.
Removing and Managing ARP Table Entries
ARP cache entries expire automatically after a period defined by the device’s operating system, typically ranging from a couple of minutes to a few hours depending on the platform. Entries can also be removed manually. Once an entry is cleared, the device has to repeat the full ARP request and reply process before it can populate that mapping again.
Viewing the ARP Table
- Cisco routers and switches:
show ip arp - Windows:
arp -a - Linux/macOS:
arp -aorip neighon newer Linux systems
Gratuitous ARP
A gratuitous ARP is a special case: a device sends an ARP request or reply for its own IPv4 address, without anyone having asked for it. This serves a few genuine purposes. It lets a device announce its presence and MAC address to the rest of the segment proactively, commonly done right after a device boots or changes its IP address. It also helps detect IP address conflicts, since if another device on the segment already claims that IP, it will typically respond, revealing the conflict immediately.
Gratuitous ARP is also used during failover events in high-availability setups, where a backup device takes over an IP address and needs every other device on the segment to update their ARP tables to point to its own MAC address instead of the failed device’s.
Security Considerations: ARP Spoofing
ARP was designed in an era with far less concern for network security, and it shows: there’s no built-in authentication mechanism verifying that an ARP reply actually came from the device it claims to represent. This creates a real, well-known vulnerability called ARP spoofing (or ARP poisoning), where an attacker sends forged ARP replies claiming to own an IP address that actually belongs to another device, commonly the default gateway. Devices on the segment update their ARP tables based on this forged information, and traffic that should have gone to the legitimate gateway gets sent to the attacker’s device instead, enabling a man-in-the-middle position over that traffic.
A few practical defenses exist. Dynamic ARP Inspection (DAI), available on many managed switches, validates ARP packets against a trusted binding table before allowing them onto the network, dropping forged replies before they can poison a legitimate device’s ARP cache. Static ARP entries can be manually configured for particularly sensitive devices, like a default gateway, though this doesn’t scale well across a large network. Port security features that limit which MAC addresses are permitted on a given switch port add another layer of defense against the kind of unauthorized device presence ARP spoofing relies on.
Why IPv6 Doesn’t Use ARP
IPv6 replaces ARP entirely with Neighbor Discovery Protocol (NDP), which performs the equivalent address resolution function using ICMPv6 multicast rather than Ethernet broadcast. This is a deliberate design improvement: multicast reaches only devices that need to process the request, rather than every device on the segment the way ARP’s broadcast approach does.
Troubleshooting ARP Issues
A device can’t reach anything on its local network. Check its ARP table for a valid entry for the destination or default gateway. An incomplete or missing ARP entry, sometimes shown as “incomplete” in the table output, points to an ARP resolution failure rather than a routing problem.
Intermittent connectivity that seems to affect traffic to a specific device. This can be a sign of a duplicate IP address on the segment, where two devices are both replying to ARP requests for the same IPv4 address, causing traffic to bounce unpredictably between them. Checking whether the MAC address associated with that IP keeps changing in captured traffic is a reliable way to confirm this specific cause.
Suspected ARP spoofing on a network. Comparing the MAC address currently associated with the default gateway’s IP in a device’s ARP table against the gateway’s actually known, correct MAC address is a quick manual check. A mismatch is a strong indicator of ARP poisoning in progress.
A Worked Example: Resolving a Local Address
Say a laptop at 192.168.1.10 needs to send data to a printer at 192.168.1.20, both on the same local network. The laptop checks its ARP table and finds no entry for 192.168.1.20. It broadcasts an ARP request: “Who has 192.168.1.20? Tell 192.168.1.10.”
Every device on the segment receives this broadcast, but only the printer, recognizing its own IP address as the target, responds. The printer sends a unicast ARP reply directly back to the laptop’s MAC address, including its own MAC address in the reply. The laptop stores this new mapping in its ARP table and can now build a properly addressed Ethernet frame to reach the printer directly, without needing to repeat this resolution process again until the entry eventually expires.
ARP Tables and Switch MAC Address Tables Aren’t the Same Thing
It’s worth clearing up a point of confusion for anyone newer to this material: an ARP table and a switch’s MAC address table sound similar but serve different purposes. A device’s ARP table maps IP addresses to MAC addresses, letting that device build correctly addressed frames. A switch’s MAC address table maps MAC addresses to physical switch ports, letting the switch forward frames out the correct port rather than flooding every port.
The two tables are maintained independently, by different devices, for different reasons, even though both ultimately rely on the same underlying MAC addresses to do their jobs. Confusing the two is a common early mistake, but keeping them conceptually separate makes troubleshooting significantly easier once a real connectivity problem needs diagnosing.
Frequently Asked Questions
What is the Address Resolution Protocol used for?
ARP resolves a known IPv4 address into the MAC address a device needs to build an Ethernet frame, since Ethernet frames require MAC addressing regardless of what IP address the payload is headed to. It operates directly at the Ethernet level, with no IP header involved in the ARP messages themselves.
Is an ARP reply broadcast or unicast?
An ARP reply is always unicast, sent directly to the device that made the original request. This is possible because the responding device already knows the requester’s MAC address from the source MAC field in the original broadcast request.
What is ARP spoofing and why is it dangerous?
ARP spoofing is an attack where a device sends forged ARP replies claiming to own an IP address it doesn’t actually control, commonly impersonating the default gateway. Since ARP has no built-in authentication, other devices update their ARP tables based on this false information, potentially redirecting their traffic through the attacker’s device for interception.
What is gratuitous ARP used for?
Gratuitous ARP lets a device announce its own IP-to-MAC mapping without being asked, commonly used to detect IP address conflicts on a segment or to update other devices’ ARP tables after a failover event in a high-availability setup. It’s a legitimate, useful mechanism, distinct from the malicious forged replies used in ARP spoofing.
Why doesn’t IPv6 use ARP?
IPv6 replaces ARP with Neighbor Discovery Protocol, which uses ICMPv6 multicast instead of Ethernet broadcast to resolve addresses. This is more efficient, since multicast only reaches devices that actually need to process the request, rather than flooding every device on the segment the way ARP’s broadcast-based approach does.
How long does an ARP table entry last before expiring?
This depends on the operating system, but entries are always temporary, typically expiring somewhere between a couple of minutes and a few hours if unused. Once an entry expires or is manually cleared, the full ARP request and reply process has to repeat before that mapping is available again.
