ARP

Knowing a destination's IP address does not mean you can send data to it immediately. Within the same network, Ethernet -- which actually delivers frames -- uses MAC (Media Access Control) addresses, not IP. The IP layer says 'send it to 10.0.0.5,' but the Ethernet layer below asks 'so what is that device's physical address?' This problem recurs every time a device is added to or replaced on the same subnet. Maintaining an IP-to-MAC mapping table manually is impractical, and in environments where DHCP assigns addresses dynamically it is nearly impossible. ARP is the protocol that automatically bridges this gap, allowing you to discover a peer's MAC address within the same network given only its IP.

When Ethernet became the dominant local network standard, sending a frame within a network required the destination's MAC address. Simultaneously, as the internet spread and IP addressing became the standard identifier, applications and routing operated entirely on IP. The problem was that the IP layer and the Ethernet layer used different address systems. With only a few devices, static mapping could survive, but as networks grew and DHCP began assigning addresses dynamically, manual management became impossible. ARP emerged to bridge these two address systems automatically. Despite being a simple protocol, ARP has endured because the gap between IP and Ethernet -- the two layers that need to cooperate -- does not disappear as long as networks exist.

ARP works with a simple request-response mechanism. When the sending device does not know the destination IP's MAC address, it sends an ARP Request as an Ethernet broadcast. This request reaches every device on the same LAN segment, and only the device holding that IP sends back an ARP Reply as a unicast. The sender then stores the IP-MAC mapping in its ARP cache for a period of time. While the cache entry is valid, there is no need to broadcast again for the same destination. If the destination is in a different subnet, ARP resolves the MAC address of the default gateway (router), not the final destination. After the router receives the frame, it uses IP routing to determine the next hop, and ARP runs again on that hop's network. In this way, ARP acts as the glue between IP routing and Ethernet delivery.

ARP and DNS both follow the pattern of 'using a known identifier to find an unknown one.' The difference lies in the scope and the type of address being resolved. DNS translates domain names to IP addresses and operates hierarchically across the entire internet. ARP translates IP addresses to MAC addresses and operates only within the same local network (LAN segment). So DNS problems manifest as name resolution failures, while ARP problems show up as inability to communicate with a device even within the same subnet. In network diagnostics, if a ping works to a different subnet but fails to a specific device in the same subnet, checking the ARP cache and broadcast path is a good first step.

In most cases, ARP is handled automatically by the operating system, so application developers rarely interact with it directly. But checking the ARP cache (arp -a) when network problems arise is a fundamental diagnostic habit. When you cannot communicate with a device on the same subnet, simply checking whether the ARP table has a correct mapping or whether stale entries remain can quickly narrow down the cause. From a security perspective, ARP spoofing is an important threat. Because ARP has no authentication mechanism, an attacker on the same network can send false replies to intercept traffic. In security-sensitive environments, defenses like static ARP entries and Dynamic ARP Inspection (DAI) should be considered. ARP itself is simple, but that simplicity is also its security weakness, making it an item that should not be overlooked in LAN security design.