ARP doesn’t just "map" IP to MAC; it actively discovers MAC addresses by broadcasting requests and learning from replies.
Let’s watch ARP in action. Imagine Host A (192.168.1.10) needs to send a packet to Host B (192.168.1.20) on the same local network. Host A knows Host B’s IP address, but to actually send the Ethernet frame, it needs Host B’s MAC address.
Host A checks its ARP cache (ip neigh show on Linux, arp -a on Windows/macOS). If Host B’s MAC isn’t there, Host A crafts an ARP request. This request is a broadcast message, meaning it goes to everyone on the local network segment. The request essentially says, "I’m 192.168.1.10, and I need the MAC address for 192.168.1.20. Who has that IP?"
Every device on the network receives this broadcast. Host B (192.168.1.20) recognizes its own IP address in the request. It then sends back an ARP reply, directly to Host A’s MAC address (which the ARP request also contained). This reply says, "I am 192.168.1.20, and my MAC address is 00:1A:2B:3C:4D:5E." Host A receives this reply, adds the IP-to-MAC mapping to its ARP cache, and can now send the Ethernet frame containing the IP packet to Host B’s MAC address.
The problem ARP solves is fundamental to how IP packets traverse local network segments. IP addresses are logical and routable across different networks, but Ethernet frames, the actual carriers of data on a local link, require physical (MAC) addresses. ARP bridges this gap. Without ARP, a host wouldn’t know the destination MAC address to put in the Ethernet header, and the packet would never leave its originating machine on the local network. It’s the translator between the network layer (IP) and the data link layer (Ethernet/MAC).
Internally, the ARP process involves a cache, typically managed by the operating system’s network stack. When a host needs to send data to an IP address on its local subnet, it first consults this cache. If the corresponding MAC address is found, the packet is encapsulated in an Ethernet frame and sent directly. If not, an ARP request is generated. This request is sent as a broadcast frame (destination MAC FF:FF:FF:FF:FF:FF) containing the target IP address. All devices on the local network receive this broadcast. The device whose IP address matches the request then sends an ARP reply directly to the requesting host’s MAC address. This reply contains the target IP address and the sender’s MAC address. Upon receiving the reply, the requesting host updates its ARP cache with the new mapping and proceeds to send the original packet. ARP entries in the cache have a Time To Live (TTL), usually a few minutes, after which they expire and must be re-resolved, ensuring the cache remains relatively fresh.
The ARP cache is a critical performance optimization. Imagine if every single IP packet transmission required an ARP broadcast and reply. The network would be flooded with ARP traffic, and there would be significant latency as hosts waited for replies. By caching the mappings, subsequent communication with the same IP address can be much faster, as the MAC address is readily available. The cache also helps reduce the load on network devices, as not every ARP request needs to be processed by every host.
When a host receives an ARP request, it checks if the requested IP address is its own. If it is, it sends an ARP reply. Crucially, even if the requested IP is not its own, the host still learns about the sender of the ARP request. The ARP packet itself contains the sender’s IP and MAC address. So, when Host A sends an ARP request for Host B, Host C (another device on the network) receives that broadcast. Host C sees that 192.168.1.10 has the MAC address of Host A. Host C will add this mapping to its own ARP cache. This is a form of gratuitous ARP, where a device proactively announces its IP-to-MAC mapping without being asked. This helps keep ARP caches updated across the network.
The most surprising part of ARP’s operation is how it handles IP address conflicts. If two devices on the same network segment are configured with the same IP address, the behavior can be chaotic. However, ARP has a built-in mechanism to detect this. When a device is configured with an IP address, it can send an ARP request for its own IP address. If another device on the network already has that IP address, it will respond with an ARP reply, indicating that the IP is already in use. This allows the operating system to detect the conflict and alert the user or take corrective action. This proactive check, happening before significant traffic is exchanged, is a silent guardian against IP duplication on a local network.
The next concept you’ll encounter is how ARP operates across different network segments, which it doesn’t do directly.