Networking · 28.05.2025

ARP for Humans

What's the Deal with ARP?

Alright, let's talk about something that happens every single time you connect to a network, but most people never think about: the Address Resolution Protocol, or ARP. If the internet was a city, IP addresses would be the street addresses, and MAC addresses would be the specific apartment numbers. You need both to get a package delivered. ARP is the friendly neighborhood postman who figures out the apartment number (MAC address) for a given street address (IP address).

I've been documenting the details of ARP for the academy course, and most explanations I found were either too academic or too surface-level. This is my take on explaining ARP in a practical way. We'll look at how it works on the wire, some interesting tricks, and how it can be exploited.

This isn't a step-by-step tutorial - it's about understanding the core concepts. Grab a coffee.

The Two-Address Problem (Or: Why ARP Even Exists)

Here's something that confused the hell out of me when I was learning networking: why do we need two addresses? We have IP addresses for talking to computers on the internet, right? Why do we also need MAC addresses?

The answer is about layers of abstraction. Your network card (the actual physical hardware) only understands MAC addresses. It's like the physical mailbox on your apartment building—it doesn't care about your name or your apartment number, it just knows its own unique serial number. MAC addresses are burned into the hardware at the factory. They're supposed to be globally unique (though they're not always in practice).

IP addresses, on the other hand, are logical addresses. They can change. You can move your laptop from one network to another, and it gets a new IP. But the MAC address? That stays the same. IP addresses exist at Layer 3 (the Network layer), and they're used for routing packets across different networks—across the entire internet, potentially.

But when your packet finally arrives at the local network (your home Wi-Fi, your office LAN, whatever), the routers and switches at that level don't care about IP addresses anymore. They work with MAC addresses. They operate at Layer 2 (the Data Link layer). So there needs to be a way to translate "I want to talk to IP 192.168.1.10" into "I need to send this frame to MAC address 00:1A:2B:3C:4D:5E."

That translation? That's ARP. It's the glue between Layer 2 and Layer 3.

Where Does ARP Live? (Layer 2.5, Kinda)

People sometimes call ARP a "Layer 2.5" protocol, and I think that's a perfect way to describe it. It's not quite Layer 2, because it deals with IP addresses (which are Layer 3). But it's not Layer 3 either, because it operates directly on top of Ethernet frames (which are Layer 2).

Think of it like this: ARP is the bouncer standing between the IP world and the Ethernet world, making introductions.

The Basic Handshake: Who has this IP?

Imagine you're at a party (your local network). You know your friend "Bob" (IP address 192.168.1.10) is here, but you don't know what he looks like (his MAC address). What do you do? You shout, "Hey, who is Bob?!".

That's exactly what an ARP request is. Your computer screams into the void (a broadcast message to every device on the local network):

"WHO-HAS 192.168.1.10? TELL 192.168.1.5"

Every device on the network hears this. Most of them will just ignore it, thinking "Nope, not me." But Bob's computer, 192.168.1.10, will hear it and reply directly to you (a unicast message):

"192.168.1.10 IS-AT 00:1A:2B:3C:4D:5E"

Now your computer knows the MAC address for that IP. It stores this in its ARP cache (short-term memory) so it doesn't have to ask again for a while.

Let's Look at the Wires: The ARP Frame

What does that "shout" actually look like as data? It's not just text. It's a structured message, an ARP packet. If you look at it in a tool like Wireshark, you'll see it's quite simple.

But first, let's talk about where ARP lives in a frame. When you send an ARP message, it travels inside an Ethernet frame. The Ethernet frame is the Layer 2 envelope that carries data on your local network.

Here's the full picture of what goes on the wire:

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ ETHERNET FRAME ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ ┌────────────────────────────────────────────────────┐ │
│ │ Destination MAC: FF:FF:FF:FF:FF:FF (Broadcast) │ │ ← Layer 2 Header
│ │ Source MAC: AA:BB:CC:DD:EE:FF │ │
│ │ EtherType: 0x0806 (ARP) │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ ARP HEADER/DATA │ │ ← Layer 2.5 "Payload"
│ │ Hardware Type: 0x0001 (Ethernet) │ │
│ │ Protocol Type: 0x0800 (IPv4) │ │
│ │ Hardware Addr Len: 6 bytes │ │
│ │ Protocol Addr Len: 4 bytes │ │
│ │ Opcode: 1 (Request) or 2 (Reply) │ │
│ │ Sender MAC: AA:BB:CC:DD:EE:FF │ │
│ │ Sender IP: 192.168.1.5 │ │
│ │ Target MAC: 00:00:00:00:00:00 (Unknown) │ │
│ │ Target IP: 192.168.1.10 │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ [Frame Check Sequence - 4 bytes CRC] │ ← Error detection
└────────────────────────────────────────────────────────────┘

Breaking It Down: The Ethernet Header

The Ethernet header comes first. This is the Layer 2 part:

  • Destination MAC: For ARP requests, this is set to FF:FF:FF:FF:FF:FF, which is the broadcast address. This means "hey, everyone on this network segment, look at this!"
  • Source MAC: This is your computer's MAC address. Everyone needs to know who's asking.
  • EtherType: This is a 2-byte field that tells the receiving computer what kind of data is in the payload. 0x0806 means "this is ARP." (For comparison, 0x0800 means "this is IPv4," and 0x86DD means "this is IPv6.")

The EtherType field is crucial. When your network card receives a frame, it looks at this field to decide what to do with the payload. If it sees 0x0806, it hands the payload to the ARP handler in the operating system.

The ARP Payload: Where the Magic Happens

After the Ethernet header, we have the ARP message itself. This is the "data" part of the Ethernet frame, but it's really an ARP header with its own structure:

  • Hardware Type: Almost always 1, which means Ethernet. (There are other types like Token Ring, but you won't see them anymore.)
  • Protocol Type: Almost always 0x0800, which means IPv4. This tells ARP we're mapping IPv4 addresses to hardware addresses.
  • Hardware Address Length: 6 bytes for MAC addresses.
  • Protocol Address Length: 4 bytes for IPv4 addresses. (If this were IPv6, it'd be 16.)
  • Opcode: This is the key field. 1 = Request ("who has this IP?"), 2 = Reply ("I have it!").
  • Sender MAC & Sender IP: The MAC and IP address of the device sending this ARP message.
  • Target MAC & Target IP: For a request, the Target MAC is set to all zeros (00:00:00:00:00:00) because we don't know it yet—that's what we're trying to find out! The Target IP is the IP address we're looking for. For a reply, both fields are filled in with the correct values.

Why Is It Structured This Way?

You might be wondering: why does ARP include both "Hardware Type" and "Protocol Type" fields? Isn't it always Ethernet and IPv4?

Well, ARP was designed to be generic. The idea was that it could map any network-layer protocol to any hardware address. In practice, 99.9% of the time it's Ethernet ↔ IPv4. But the designers thought ahead, and that's why the structure is so flexible.

The beauty of this design is that the ARP message is self-describing. Any computer that receives it can parse it without needing prior knowledge, just by reading the "length" fields.

The "Look at Me!" Signal: Gratuitous ARP

Now for a neat trick. What if a device wants to announce itself to the network without being asked? This is called a Gratuitous ARP (sometimes abbreviated as GARP, which I find hilarious for some reason).

It's like walking into the party and shouting, "Hey everyone, I'm Alex, and I'm at 192.168.1.20!"

A gratuitous ARP is an ARP request (not a reply!) where the sender is asking "who has my own IP address?" It's broadcasting a question about itself. The Target IP is set to the same IP as the Sender IP. Sounds weird, right?

Why Would Anyone Do This?

Gratuitous ARPs serve several clever purposes:

1. Announcing Presence and Updating Caches

When a device first joins a network or changes its IP address, it can send a gratuitous ARP to let everyone know "Hey, I exist, and this is my IP-to-MAC mapping!" Other devices on the network will receive this and update their ARP caches accordingly. This is especially useful when an IP address moves from one device to another.

2. IP Conflict Detection

This is the clever part. When your computer gets a new IP address (via DHCP or manual configuration), it often sends a gratuitous ARP for that IP before it actually configures the interface. It's asking: "Does anyone else think they have this IP?"

If another device on the network replies "Yes, I have that IP!", your computer knows there's a duplicate IP address and can refuse to use it (or alert you). You've probably seen those "IP address conflict" error messages on Windows—this is how that detection works.

The trick is that the sender sets the Target MAC to all zeros and asks about its own IP. If someone replies, that's a problem.

3. High-Availability and Failover

This is where it gets really cool in production environments. Imagine you have two servers in a cluster: a primary and a backup. They're both connected to the network, but only the primary is actively serving traffic at IP 10.0.0.100.

If the primary server fails, the backup server needs to take over instantly. So what does it do? It sends a gratuitous ARP saying:

"10.0.0.100 IS NOW AT [backup server's MAC address]"

Every device on the network that had the old MAC address cached will immediately update to the new one. Within milliseconds, all traffic destined for 10.0.0.100 is now flowing to the backup server. No manual intervention needed. This is how many load balancers and virtual IP systems work under the hood (like Linux's VRRP or Keepalived).

The Security Implications

Gratuitous ARPs are unsolicited. Nobody asked for them. And most operating systems, by default, will accept them and update their ARP caches. Do you see the problem yet? We'll get to that in the poisoning section.

The Dark Side: ARP Cache Poisoning

Because ARP is so trusting, it has a dark side. ARP was designed in the 1980s, in a simpler time, assuming everyone on the local network was friendly and had good intentions. It has no authentication, no encryption, and no validation. Anyone can send an ARP reply at any time, and by default, most systems will believe it.

This is the basis for an ARP Cache Poisoning (or ARP Spoofing) attack, and it's one of the most fundamental attacks in network security.

How the Attack Works

Let's set the stage. You're on a coffee shop Wi-Fi network. There are three devices:

  • Your laptop (192.168.1.100, MAC: AA:BB:CC:DD:EE:FF)
  • The router/gateway (192.168.1.1, MAC: 11:22:33:44:55:66)
  • Attacker's laptop (Eve, 192.168.1.50, MAC: EE:EE:EE:EE:EE:EE)

You want to browse the web, so your laptop needs to send packets to the router. First, it does an ARP request:

"WHO-HAS 192.168.1.1? TELL 192.168.1.100"

The router replies:

"192.168.1.1 IS-AT 11:22:33:44:55:66"

Your laptop updates its ARP cache and is happy. But Eve is listening. She's running a tool like arpspoof or ettercap. She continuously sends fake ARP replies to your laptop, claiming:

"192.168.1.1 IS-AT EE:EE:EE:EE:EE:EE" (her MAC address)

Your laptop receives this unsolicited ARP reply. Most operating systems will accept it and update their ARP cache, even though nobody asked for it. This is the "trusting" nature of ARP.

Now, your laptop's ARP cache looks like this:

192.168.1.1 → EE:EE:EE:EE:EE:EE (Eve's MAC, not the router's!)

From this point forward, every packet you think you're sending to the router is actually being sent to Eve's machine. She can:

  1. Read all your traffic (see every website you visit, every password you type if it's not HTTPS)
  2. Modify your traffic (inject malicious content, redirect you to phishing sites)
  3. Forward it to the real router so you don't even notice anything is wrong (this is a true Man-in-the-Middle attack)

Eve typically also poisons the router's ARP cache, telling the router:

"192.168.1.100 IS-AT EE:EE:EE:EE:EE:EE"

Now she's in the middle of the conversation in both directions. All your traffic flows through her machine. This is why it's called a Man-in-the-Middle (MITM) attack.

Why Is This Still a Problem in 2025?

You might be thinking: "This is an old attack. Surely we've fixed it by now?" Well... not really.

The fundamental issue is that ARP can't be "fixed" without breaking backward compatibility. There are mitigations (which we'll discuss), but the protocol itself is inherently insecure by design. As long as we're using Ethernet and IPv4 on local networks, ARP will exist, and ARP poisoning will be possible.

That said, modern defenses have made it harder (but not impossible) to pull off:

  • HTTPS Everywhere: Even if an attacker is in the middle, they can't read or modify HTTPS traffic without the user seeing certificate warnings.
  • Dynamic ARP Inspection (DAI): Some enterprise switches can validate ARP packets against a trusted database of IP-to-MAC bindings (usually from DHCP snooping). Invalid ARP replies get dropped.
  • Static ARP Entries: You can manually configure static ARP entries on critical systems, but this doesn't scale and is a pain to manage.
  • ARP Monitoring Tools: Tools like arpwatch can alert administrators when ARP mappings change unexpectedly.

But on most home and public Wi-Fi networks? ARP poisoning is still trivially easy to pull off.

Spotting the Foul Play in Wireshark

So how do you spot this in the wild? It's surprisingly easy if you know what to look for. Fire up Wireshark and use the display filter arp.

Here's what to watch for:

1. Multiple, Rapid ARP Replies for the Same IP

If you see a flood of ARP replies for a single IP address, especially if they contain different MAC addresses, that's a huge red flag. This is often a sign of an attacker trying to poison the cache of many devices at once.

Example in a capture:

No. Time Source Destination Protocol Info
450 10.2345 Router_Real Broadcast ARP 192.168.1.1 is at 11:22:33:44:55:66
451 10.2347 Attacker_Eve Broadcast ARP 192.168.1.1 is at EE:EE:EE:EE:EE:EE
452 10.4347 Attacker_Eve Broadcast ARP 192.168.1.1 is at EE:EE:EE:EE:EE:EE
453 10.6347 Attacker_Eve Broadcast ARP 192.168.1.1 is at EE:EE:EE:EE:EE:EE

Notice the attacker is sending repeated gratuitous ARPs to keep the poisoning active. If the attacker stops, the victim's cache might eventually get the correct entry back (from a legitimate ARP reply or cache timeout).

2. ARP Replies Without a Request

Legitimate gratuitous ARPs happen, but they are usually infrequent (e.g., when a device joins the network or during a failover event). If you see a device constantly spamming unsolicited ARP replies for IPs that aren't its own, it's highly suspicious.

In Wireshark, you can filter for this with:

arp.opcode == 2 and arp.src.proto_ipv4 != arp.dst.proto_ipv4

This shows ARP replies where the sender's IP doesn't match the IP being advertised—a telltale sign of spoofing.

3. Duplicate IP Announcements

Look for the "Duplicate IP address detected" message in Wireshark's expert information panel (the colored circle at the bottom left). Wireshark is smart enough to track IP-to-MAC bindings and will flag when it sees the same IP claiming different MAC addresses.

You can also use this display filter:

arp.duplicate-address-detected

4. Look at the Timing

Real ARP traffic has a natural pattern: request → reply, with a small delay. If you see ARP replies coming in at perfectly regular intervals (like every 2 seconds), and they're all gratuitous, that's usually automated tooling at work.

A Real Example of a Poisoning Attempt

Here's what a typical attack might look like in your capture:

No. Time Source Destination Protocol Info
101 1.2345 Victim Broadcast ARP Who has 192.168.1.1? Tell 192.168.1.100
102 1.2348 Router_Real Victim ARP 192.168.1.1 is at 11:22:33:44:55:66
103 1.2349 Attacker_Eve Victim ARP 192.168.1.1 is at EE:EE:EE:EE:EE:EE <-- POISONED!
...
150 3.2345 Attacker_Eve Broadcast ARP 192.168.1.1 is at EE:EE:EE:EE:EE:EE <-- Gratuitous
...
200 5.2345 Attacker_Eve Broadcast ARP 192.168.1.1 is at EE:EE:EE:EE:EE:EE <-- Again!

In packet 103, Eve sends a fake reply immediately after the legitimate one. If her packet arrives at the victim's network card after the legitimate one, it will overwrite the correct entry because ARP caches typically accept the most recent reply.

Then, packets 150 and 200 show Eve sending gratuitous ARPs every few seconds to maintain the poisoned state. This is necessary because ARP cache entries have a timeout (typically 1-5 minutes), after which they expire and the victim might send a fresh ARP request.

What to Look for in the Frame Details

When you click on an ARP packet in Wireshark, expand the "Address Resolution Protocol" section in the packet details pane. Look for:

  • Is gratuitous: Wireshark will explicitly label gratuitous ARPs. If you see a lot of these from one device, investigate further.
  • Sender MAC address vs. Ethernet source: These should always match. If they don't, someone is trying to be sneaky (though this is rare).
  • Opcode: Make sure requests (1) and replies (2) make sense in context. Random unsolicited replies are suspicious.

Bonus: Check Your Own ARP Cache

On Linux or macOS, run:

arp -a

On Windows:

arp -a

You'll see a list of IP-to-MAC mappings your system currently knows. If you're being poisoned, you might see a MAC address for your gateway that doesn't match what your router actually has. (You can usually find your router's real MAC address on a sticker on the device itself, or in its web interface.)

If you suspect poisoning, you can flush your ARP cache:

  • Linux: sudo ip -s -s neigh flush all
  • macOS: sudo arp -d -a
  • Windows: arp -d (run as administrator)

This clears all entries, forcing your system to send fresh ARP requests. But if the attacker is still active, your cache will just get poisoned again.

Modern Defenses and Best Practices

So, what can you actually do about ARP's security problems? Here are some practical defenses that are used in the real world:

1. Dynamic ARP Inspection (DAI)

This is the big one for enterprise networks. Modern managed switches (like Cisco Catalyst or Aruba switches) support Dynamic ARP Inspection. Here's how it works:

The switch maintains a trusted database of IP-to-MAC bindings, usually derived from DHCP Snooping (where the switch monitors DHCP traffic to learn which devices legitimately have which IPs). When an ARP packet arrives, the switch checks it against this database:

  • Trusted ARP packet: Forwarded normally
  • Untrusted ARP packet: Dropped, and an alert is logged

This is incredibly effective, but it requires:

  • Managed switches (not your $20 home router)
  • Proper configuration
  • DHCP to be used (static IPs are harder to validate)

2. Static ARP Entries

You can manually configure static ARP entries for critical systems. On Linux:

sudo arp -s 192.168.1.1 11:22:33:44:55:66

This tells your system "the router is always at this MAC address, don't accept any other claims." The problem? It doesn't scale, and if the MAC address ever legitimately changes (hardware replacement, virtual IP failover), your connectivity breaks until you manually update it.

3. IPsec or MACsec

If you need bulletproof security on a local network, you can encrypt and authenticate all traffic at Layer 2 (MACsec) or Layer 3 (IPsec). This makes MITM attacks useless because the attacker can't read or modify the encrypted traffic.

MACsec is particularly elegant because it operates at Layer 2, providing hop-by-hop encryption between switches. But again, this requires hardware support and careful configuration.

4. Network Segmentation and VLANs

Limiting the broadcast domain size reduces the attack surface. If you segment your network into multiple VLANs, an attacker on one VLAN can't poison ARP caches on another VLAN. They'd have to compromise a router or Layer 3 switch to jump VLANs.

5. ARP Monitoring (arpwatch, XArp)

Tools like arpwatch on Linux can monitor your network and alert you when ARP mappings change. It keeps a database of known IP-to-MAC pairings and sends an email or syslog message when something changes unexpectedly.

This doesn't prevent attacks, but it gives you visibility. If you're a network admin and you get an alert that your gateway's MAC address suddenly changed, you know something is wrong.

6. Switch Port Security

You can configure switches to limit which MAC addresses are allowed on each physical port. If a port suddenly starts sending traffic with a MAC address that wasn't learned during the initial connection phase, the switch can shut down the port.

This is more about preventing unauthorized devices from connecting than preventing ARP poisoning specifically, but it helps.

Some Things Tutorials Don't Tell You

Here are a few "gotchas" and interesting facts about ARP that I wish I'd known earlier:

ARP Works Across VLANs... Sort of

ARP is a Layer 2 broadcast protocol, so it only works within a single broadcast domain (usually one VLAN). You can't ARP for a device on a different subnet or VLAN. Instead, you ARP for your default gateway, and the gateway handles routing between subnets.

This is why, when you ping a device on a different network, your computer sends an ARP request for the router's MAC address, not the destination's MAC address.

IPv6 Doesn't Use ARP (Thank God)

IPv6 uses a protocol called Neighbor Discovery Protocol (NDP), which is part of ICMPv6. It's functionally similar to ARP but includes built-in security features like Secure Neighbor Discovery (SEND), which uses cryptographic signatures to authenticate messages.

That said, NDP has its own vulnerabilities (like RA flooding attacks), so it's not a magic bullet.

Proxy ARP Is a Thing

A router can respond to ARP requests on behalf of another device. This is called Proxy ARP. It's used when you have multiple subnets on the same physical network (don't ask why, it's usually a misconfiguration or legacy setup).

If you see a router responding to ARP requests for IPs that aren't its own, that's probably Proxy ARP. It looks suspicious in a packet capture but is actually legitimate (though not recommended for modern networks).

The ARP Cache Timeout Is Short for a Reason

Most systems expire ARP entries after 1-5 minutes of inactivity. This seems annoyingly short, but it's by design. Networks change constantly: devices disconnect, new devices join, IPs get reassigned. A short timeout ensures that stale entries don't persist and break connectivity.

Of course, this also means attackers need to send poisoning packets regularly to maintain their attack, which makes them easier to detect if you're watching.

ARP Packets Are Tiny

An ARP packet is only 28 bytes (plus the Ethernet header). It's one of the smallest protocols you'll find. This is part of why it's so fast—there's barely any data to process.

Stay Curious

ARP is one of those fundamental building blocks of networking that's simple in design, but has complex implications. It's a protocol that works on the honor system, which is both its strength and its weakness.

Understanding ARP at this level—really understanding where it sits in the stack, how the frames are structured, and why it's vulnerable—is what separates someone who can Google error messages from someone who can actually troubleshoot and secure networks.

The next time you're waiting for a webpage to load, just think about the little ARP conversation that probably just happened under the hood, making it all possible. Your computer shouted into the void, "Who has this IP?", and somewhere on your network, a device whispered back, "I do." That handshake, that trust, is what makes local networking work.

And if you're feeling adventurous, fire up Wireshark on your home network and just watch the ARP traffic for a few minutes. You'll see devices announcing themselves, routers responding to queries, and the beautiful chaos of a living, breathing network. You might even spot something suspicious. (But please don't poison your roommate's ARP cache. They'll know it was you.)

If you want to dig deeper, I've covered the implementation details of ARP in my TCP/IP stack course. We actually build an ARP resolver from scratch in C, watching the raw bytes come in and parsing them field-by-field. There's nothing quite like the satisfaction of seeing your own code craft an ARP request, send it out on the wire, and receive a real reply from a real device.

Happy hacking, and remember: question everything, especially protocols that trust everyone.

P.S.: If you're interested in testing ARP attacks in a safe, controlled environment, check out tools like arpspoof (part of dsniff), ettercap, or bettercap. Spin up a VM lab or use Docker containers, never on a network you don't own. Understanding attacks is the first step to defending against them.

← All notes