How ARP Resolves IP Addresses to MAC Addresses: From the Basics to ARP Spoofing

Imagine you're on a simple home network. Your laptop is connected to Wi-Fi, your phone is on the same network, and a Raspberry Pi in the corner of your room is happily running a handful of Docker services.

Now you open a terminal on your laptop and try to ping another device on the same network:

ping 192.168.1.20

At first glance, everything seems straightforward. You already know the destination IP address. The operating system should simply send the packet, right?

This is exactly where networking smiles and says:

"Not quite. There's still one more layer below."

The real question is:

How does your network card know which physical device owns 192.168.1.20?

An IP address makes perfect sense to us—and to the network layer. But a network interface card ultimately communicates using something called a MAC Address. On an Ethernet network, what actually travels across the wire isn't just an abstract concept like an IP address. Ethernet carries frames, and every frame must contain a destination MAC address.

So your operating system faces one very simple—but absolutely essential—question:

I know the destination IP address, but where do I find its MAC address?

And that's exactly where ARP enters the picture.

ARP is one of those protocols that nobody thinks about as long as everything works. But the moment your network starts behaving strangely, connections begin failing, your gateway stops responding correctly, or topics like security and Man-in-the-Middle attacks come into play, this seemingly simple protocol suddenly becomes one of the most important pieces of the puzzle.

Before ARP: Why Isn't an IP Address Enough?

To understand ARP, we first need to clarify one important fact:

IP addresses and MAC addresses exist for completely different purposes.

An IP address is a logical identifier used by the network layer. For example, when you see:

192.168.1.20

you're looking at a logical address. It can change over time. DHCP might assign one address today and a different one tomorrow.

IP addresses are primarily used for routing. When a packet needs to travel from one network to another, routers examine the destination IP address and decide where the packet should go next.

A MAC address, on the other hand, is different.

A MAC address is the hardware (or more accurately, Layer 2) address of a network interface, something like:

a4:bb:6d:12:34:56

Inside a Local Area Network (LAN), Ethernet delivers frames using MAC addresses. Your network card doesn't say:

"Send this frame to IP X."

Instead, it says:

"Send this frame to MAC Address Y."

That means before your computer can send data to another IP address on the local network, it first has to discover the MAC address associated with that IP.

That's exactly what ARP does.

What Is ARP?

ARP stands for Address Resolution Protocol.

Its primary job in IPv4 networks is very simple:

Find the MAC address associated with an IP address on the local network.

For example, your computer already knows the destination IP:

192.168.1.20

But to build an Ethernet frame, it also needs something like:

11:22:33:44:55:66

ARP bridges that gap.

One important thing to understand is that ARP only works inside a local network.

If the destination device is on the same LAN, your computer will try to discover that device's MAC address.

However, if the destination is somewhere on the Internet—for example:

8.8.8.8

your computer does not try to discover Google's MAC address.

Instead, it only needs the MAC address of your Default Gateway (your router), because that's the next device on the local network.

This distinction is extremely important:

ARP does not discover the MAC address of the final destination on the Internet. It discovers the MAC address of the next hop on the local network.

Sometimes that next hop is the destination itself.

Sometimes it's your router.

Which Layer Does ARP Belong To?

Technically speaking, ARP sits somewhere between Layer 2 and Layer 3.

On one hand, it works with IP addresses (Layer 3).

On the other, its result is a MAC address (Layer 2).

In practice, ARP is generally considered a Layer 2 protocol because ARP packets are carried inside Ethernet frames and exist primarily to enable Layer 2 communication.

Here's a simplified view:

flowchart TB
    A["🖥️ Application Layer
Browser, SSH, Ping, DNS"] -->
    B["🚚 Transport Layer
TCP / UDP"]

    B -->
    C["🌐 Network Layer
IP Address & Routing"]

    C -->
    D["🔍 ARP
Resolve IP to MAC Address
'Who owns this IP?'"]

    D -->
    E["📦 Data Link Layer
Ethernet Frame + MAC Address"]

    E -->
    F["📡 Physical Layer
Cable, Wi-Fi, Radio Signals"]

ARP is neither TCP nor UDP.

It doesn't even use ports.

So if someone asks:

"Which port does ARP use?"

The answer is simple:

None.

Instead, Ethernet identifies ARP using its own EtherType.

For ARP:

0x0806

For IPv4:

0x0800

A Simple Scenario

Suppose we have two computers:

PC-A wants to communicate with PC-B.

The first thing PC-A does is check whether it already knows the MAC address for 192.168.1.20.

This information is stored inside the ARP Cache (or Neighbor Table).

If the answer is already cached, communication begins immediately.

Otherwise, PC-A needs to ask.

Its question looks like this:

Who has 192.168.1.20?
Tell 192.168.1.10

In other words:

"Whoever owns 192.168.1.20, please tell 192.168.1.10 what your MAC address is."

But since PC-A doesn't yet know who owns that IP address, it asks everyone.

That's where broadcasting comes in.

ARP Request: Asking the Entire LAN

An ARP Request is usually sent as a broadcast.

The Ethernet destination address is:

ff:ff:ff:ff:ff:ff

Which essentially means:

"Everyone on this LAN should receive this message."

PC-A sends the request, and the switch floods it to every device within that broadcast domain.

sequenceDiagram
    participant PCA as PC-A
    Note over PCA: 192.168.1.10
    participant SW as Switch
    participant PCB as PC-B
    Note over PCB: 192.168.1.20
    participant PCC as PC-C
    Note over PCC: 192.168.1.30

    PCA->>SW: ARP Request: Who has 192.168.1.20?
    SW->>PCB: Broadcast ARP Request
    SW->>PCC: Broadcast ARP Request
    PCB-->>SW: ARP Reply: 192.168.1.20 is at BB:BB:BB:BB:BB:BB
    SW-->>PCA: ARP Reply

Every device receives the request.

Only one responds.

If PC-B owns that IP address, it replies:

192.168.1.20 is at BB:BB:BB:BB:BB:BB

This is called an ARP Reply.

ARP Reply: A More Private Conversation

Unlike an ARP Request, which is broadcast, an ARP Reply is typically unicast.

It is sent directly back to the computer that originally asked.

PC-A now learns:

192.168.1.20 -> BB:BB:BB:BB:BB:BB

It stores this mapping inside its ARP Cache.

From that point onward, any Ethernet frame destined for PC-B is built using that MAC address.

Only now does the actual data transfer begin.

An interesting observation:

Before the very first packet ever reaches its destination, a tiny invisible conversation usually takes place behind the scenes.

Think of ARP as the person who quietly asks:

"Excuse me, where is Alex sitting?"

before the meeting even starts.

What Is the ARP Cache?

If every single packet required an ARP Request, the network would be flooded with broadcasts.

To avoid this, operating systems temporarily store resolved IP-to-MAC mappings inside the ARP Cache.

On Linux:

ip neigh

Example output:

192.168.1.1 dev wlan0 lladdr 58:ef:68:12:34:56 REACHABLE
192.168.1.20 dev wlan0 lladdr b8:27:eb:aa:bb:cc STALE

On Windows:

arp -a

Modern Linux systems generally prefer ip neigh over the older arp -a command.

What If the Destination Is Outside the LAN?

This is probably the biggest misconception about ARP.

Suppose your machine has:

192.168.1.10/24

and your default gateway is:

192.168.1.1

Now you want to connect to:

8.8.8.8

Does your computer send an ARP request asking for Google's MAC address?

Absolutely not.

Instead, it realizes that 8.8.8.8 is outside the local subnet.

The packet must therefore be delivered to the router.

So ARP asks:

Who has 192.168.1.1?

—not—

Who has 8.8.8.8?

Once it learns the router's MAC address, it places the IP packet (whose destination is still 8.8.8.8) inside an Ethernet frame addressed to the router.

This is worth remembering:

The destination IP may belong to a server anywhere on the Internet, but the destination MAC address always belongs to the next hop on the local link.

flowchart LR
    A["Laptop
192.168.1.10"]
    R["Router (Default Gateway)
192.168.1.1"]
    I["Internet Host
8.8.8.8"]

    A -->|ARP: Find Router's MAC| R
    R -->|Forward IP Packet| I
    A -.->|No ARP for Internet Hosts| I

Watching ARP with Wireshark and tcpdump

Theory becomes much easier to understand once you actually observe ARP packets.

In Wireshark, simply apply this filter:

arp

Then clear your ARP cache or ping a new device.

You'll likely see both ARP Requests and ARP Replies.

On Linux:

sudo tcpdump -i wlan0 arp

or

sudo tcpdump -i eth0 arp

Example output:

ARP, Request who-has 192.168.1.20 tell 192.168.1.10
ARP, Reply 192.168.1.20 is-at b8:27:eb:aa:bb:cc

You're literally watching the hidden conversation happen in real time.

Why Does ARP Only Work on the Local Network?

Because ARP relies on broadcasts.

Routers do not forward broadcast traffic.

Imagine if every device on Earth could broadcast:

Who has 8.8.8.8?

The Internet would collapse under the noise.

That's why every router defines the boundary of a broadcast domain.

ARP never crosses that boundary.

Gratuitous ARP

Sometimes a device announces its own IP-to-MAC mapping without anyone asking.

That's called Gratuitous ARP.

Example:

192.168.1.20 is at BB:BB:BB:BB:BB:BB

This helps detect duplicate IP addresses and is commonly used in High Availability environments where virtual IP addresses move between servers.

Like many networking features, it can also be abused under certain attack scenarios.

Proxy ARP

With Proxy ARP, another device—usually a router—answers ARP Requests on behalf of someone else.

For example:

Who has 192.168.2.50?

Router:

192.168.2.50 is at Router-MAC

The router is essentially saying:

"Send the traffic to me, and I'll take care of the rest."

Proxy ARP has legitimate use cases but can also complicate troubleshooting if used carelessly.

Where Does ARP Become a Security Problem?

ARP has no built-in authentication.

If a device announces:

192.168.1.1 is at AA:BB:CC:DD:EE:FF

there's no reliable way for another device to verify whether that statement is true.

That's exactly why attacks like ARP Spoofing and ARP Poisoning are possible.

An attacker may tell the victim:

192.168.1.1 is at Attacker-MAC

while simultaneously telling the router:

192.168.1.10 is at Attacker-MAC

The result?

Traffic now flows through the attacker before reaching its destination.

If packet forwarding is enabled, neither side may notice anything unusual.

This is one form of a Man-in-the-Middle (MITM) attack.

flowchart LR
    V["Victim
192.168.1.10"]

    A["Attacker
Sends Fake ARP Replies"]

    R["Router (Gateway)
192.168.1.1"]

    I["Internet"]

    V -->|"Traffic sent to attacker's MAC"| A
    A -->|"Relays packets"| R
    R --> I

    A -.->|"Tells victim:
'I am the Router'"| V
    A -.->|"Tells router:
'I am the Victim'"| R

This article focuses on understanding the mechanism—not demonstrating attacks.

Defending Against ARP Spoofing

Enterprise networks commonly rely on technologies like:

• Dynamic ARP Inspection (DAI)
• DHCP Snooping
• Static ARP Entries (where appropriate)
• VLAN segmentation
• Client Isolation
• Proper encryption using HTTPS, SSH, and VPNs

ARP itself is not secure.

Modern security relies on additional protections layered above it.

Does IPv6 Use ARP?

No.

IPv6 replaces ARP with the Neighbor Discovery Protocol (NDP), which operates over ICMPv6.

Although the implementation changes, the underlying problem remains the same:

A device still needs to discover which Layer 2 address corresponds to the next hop.

Common Misconceptions About ARP

One common misconception is that ARP resolves MAC addresses across the Internet.

It doesn't.

Another is that ARP is only used when communicating directly with another computer.

In reality, it's also used every time your computer needs to discover the MAC address of its default gateway before reaching the Internet.

Another misconception is that MAC addresses travel across the Internet with packets.

They don't.

Every router strips the old Ethernet frame and creates a brand-new one for the next hop.

The IP address usually stays the same.

The MAC addresses change at every link.

Finally, many people assume ARP isn't important because it's simple.

The opposite is true.

ARP is like the hinges on a door.

Nobody notices them while they work.

But once they fail, the entire door stops being useful.

Conclusion

ARP bridges the gap between IP addresses and MAC addresses in IPv4 networks.

Whenever a computer needs to communicate on a local network—or simply send traffic to its default gateway—it first needs to know which MAC address should receive the Ethernet frame.

If the mapping already exists in the ARP Cache, communication begins immediately.

Otherwise, the system broadcasts an ARP Request, receives an ARP Reply, stores the result, and only then starts sending real traffic.

On the surface, ARP is nothing more than a simple question and answer:

Who has this IP?
This IP is at this MAC.

Yet behind that tiny exchange lies the foundation of nearly every communication that happens on an IPv4 local network.

Without ARP, your computer might know where a destination exists logically, but it would have no idea who to hand the Ethernet frame to physically.

And despite its simplicity, ARP also reminds us of an important lesson in network security:

The protocols that work quietly in the background are often the ones worth understanding the most.