ARP Explained: How Your Network Finds MAC Addresses from IPs

Every time you load a webpage, send a Slack message, or ping a server, your operating system has to solve a puzzle before a single byte leaves your machine: it knows the destination's IP address, but your network hardware — your Ethernet card, your Wi-Fi adapter — doesn't understand IP addresses. It only speaks in MAC addresses, those 48-bit hardware identifiers burned into every network interface at the factory. Without a way to bridge that gap, your packets go nowhere.

This is the exact problem ARP was designed to solve back in 1982 (RFC 826), and it's still doing that job on virtually every LAN on the planet. It sits at the boundary between Layer 2 (Data Link) and Layer 3 (Network) of the OSI model, acting as a live translation service that maps 'logical' IP addresses to 'physical' MAC addresses. When it works, it's invisible. When it breaks — or gets exploited — things get interesting fast.

By the end of this article you'll understand exactly how ARP request and reply packets are constructed, why the ARP cache exists and what happens when it goes stale, how ARP spoofing works at a packet level so you can reason about network security, and how to inspect and manipulate ARP behavior on a real Linux or macOS machine. This is the kind of depth that separates engineers who just use networks from engineers who actually understand them.

What is ARP — Address Resolution Protocol?

ARP — Address Resolution Protocol is a core concept in CS Fundamentals. Rather than starting with a dry definition, let's see it in action and understand why it exists.

// TheCodeForge — ARP — Address Resolution Protocol example
// Always use meaningful names, not x or n
public class ForgeExample {
    public static void main(String[] args) {
        String topic = "ARP — Address Resolution Protocol";
        System.out.println("Learning: " + topic + " 🔥");
    }
}

Frequently Asked Questions