diagram.mmd — sequence
ARP Resolution sequence diagram

ARP (Address Resolution Protocol, RFC 826) is the protocol used to map a known IPv4 address to an unknown MAC (Media Access Control) address on a local network segment, enabling link-layer frame delivery.

IP routing gets a packet to the correct subnet, but Ethernet (and most link-layer technologies) uses MAC addresses for actual frame delivery between devices on the same network segment. ARP bridges this gap.

When ARP is needed: When device A wants to send an IP packet to device B on the same subnet, it needs B's MAC address to construct the Ethernet frame. If A doesn't have B's MAC in its ARP cache, it must perform ARP resolution.

ARP Request (Broadcast): A sends an ARP request frame to the broadcast MAC address (FF:FF:FF:FF:FF:FF). The frame says: "Who has IP 192.168.1.10? Tell 192.168.1.1." Every device on the segment receives this frame.

ARP Reply (Unicast): Only the device with the matching IP responds. It sends a unicast ARP reply directly to A: "I have 192.168.1.10; my MAC is aa:bb:cc:dd:ee:ff."

ARP Cache: Both the requester and responder cache each other's IP-to-MAC mapping in their ARP tables (typically for 20 seconds to a few minutes). Subsequent packets skip the broadcast round-trip.

ARP Spoofing: Because ARP has no authentication, a malicious device can send gratuitous ARP replies associating its own MAC with another device's IP, enabling man-in-the-middle attacks. This is why ARP is restricted at the switch level in managed networks (Dynamic ARP Inspection).

IPv6 replaces ARP with NDP (Neighbor Discovery Protocol), which uses ICMPv6 multicast rather than broadcast. ARP feeds into DHCP IP Assignment and IP Packet Routing.

Free online editor
Edit this diagram in Graphlet
Fork, modify, and export to SVG or PNG. No sign-up required.
Open in Graphlet →

Frequently asked questions

ARP is the protocol that maps a known IPv4 address to an unknown MAC address on a local network segment. IP routing delivers packets to the correct subnet, but Ethernet uses MAC addresses for actual frame delivery. ARP bridges this gap by broadcasting a query and receiving a unicast reply from the matching device.
When device A needs to send a packet to device B on the same subnet, it broadcasts an ARP request to `FF:FF:FF:FF:FF:FF` asking "who has IP X?" Only the device with that IP replies with its MAC address directly to A. Both devices then cache the IP-to-MAC mapping in their ARP tables to avoid repeating the broadcast for subsequent packets.
ARP runs whenever a device needs to send a packet to a local IP address that is not in its ARP cache. Cache entries are typically held for 20 seconds to a few minutes depending on the OS. After expiry, the device will re-broadcast if it needs to communicate again.
mermaid
sequenceDiagram participant HostA as Host A (192.168.1.1) participant Broadcast as LAN Broadcast (FF:FF:FF:FF:FF:FF) participant HostB as Host B (192.168.1.10) participant HostC as Host C (192.168.1.20) note">Note over HostA: Want to send to 192.168.1.10\nCheck ARP cache — miss HostA->>Broadcast: ARP Request\nWho has 192.168.1.10?\nTell 192.168.1.1\n(src MAC: aa:bb:cc:11:22:33) note">Note over HostB: Received broadcast\nIP matches — reply note">Note over HostC: Received broadcast\nIP does not match — ignore HostB-->>HostA: ARP Reply (unicast)\n192.168.1.10 is at dd:ee:ff:44:55:66 note">Note over HostA: Update ARP cache:\n192.168.1.10 -> dd:ee:ff:44:55:66\n(TTL ~20 min) HostA->>HostB: Ethernet frame\nDst MAC: dd:ee:ff:44:55:66\nIP payload to 192.168.1.10 note">Note over HostA: Subsequent packets use\ncached MAC — no broadcast
Copied to clipboard