Lesson 6 of 12

ARP

22 min read

ARP — Address Resolution Protocol and the MAC Address Layer

When you type a website address into your browser, your computer eventually produces packets of data addressed to an IP (Internet Protocol) address. But those packets do not travel through the physical network by IP address alone. At the local network level — inside your office or your home — a completely different addressing system is at work: MAC (Media Access Control) addresses. ARP (Address Resolution Protocol) is the mechanism that bridges these two worlds. It is also one of the most commonly abused protocols in network attacks.

This lesson explains what MAC addresses are, how ARP works, and how attackers exploit ARP's fundamental design weakness.

Two Kinds of Addresses

To understand ARP, you first need to understand why two different address systems exist.

IP addresses are logical addresses. They are assigned by software — a network administrator, a DHCP (Dynamic Host Configuration Protocol) server, or an operating system — and they can be changed. An IP address tells you where a device is within the hierarchical structure of the internet or a private network. Routers use IP addresses to make forwarding decisions across networks.

MAC addresses are physical addresses. They are assigned during manufacturing and embedded in the firmware of every network interface card (NIC — Network Interface Card). A MAC address identifies a specific piece of hardware, not a location. MAC addresses do not change when you move a device from one network to another (though they can be spoofed in software — more on that shortly).

IP addresses operate at Layer 3 (the Network layer) of the OSI (Open Systems Interconnection) model. MAC addresses operate at Layer 2 (the Data Link layer). When data is sent across a local network — across an Ethernet switch — it is encapsulated in Ethernet frames, and those frames are addressed by MAC address, not IP address.

The problem: when your computer wants to send data to 192.168.1.20 on the same local network, it knows the IP address of the destination — but it does not know what MAC address that device has. Without the MAC address, it cannot construct an Ethernet frame. ARP is the protocol that solves this problem.

MAC Addresses in Depth

A MAC address is 48 bits long — that is 6 bytes, written as six pairs of hexadecimal (base 16) digits.

Common notation styles:

Linux/macOS: 00:1A:2B:3C:4D:5E (colon-separated)
Windows: 00-1A-2B-3C-4D-5E (hyphen-separated)
Cisco equipment: 001A.2B3C.4D5E (dot-separated in groups of four)

Structure of a MAC address:

The first three bytes (24 bits) are the OUI (Organizationally Unique Identifier). The OUI is assigned by the IEEE (Institute of Electrical and Electronics Engineers) to each manufacturer. By looking up the OUI, you can identify who made a network device.

Examples:

00:1A:2B — Apple
00:50:56 — VMware (virtual machine network adapters)
00:0C:29 — VMware (another range used for different VM types)
00:23:AE — Cisco Systems
DC:A6:32 — Raspberry Pi Foundation

The last three bytes (24 bits) are assigned by the manufacturer and uniquely identify that specific device within the manufacturer's product line. In theory, no two network devices in the world share the same MAC address — though in practice, manufacturing errors and deliberate spoofing make this guarantee imperfect.

The broadcast MAC address:

FF:FF:FF:FF:FF:FF is the Ethernet broadcast address. A frame sent to this MAC address is delivered to every device on the local network segment. Every device must receive and process such a frame — at least enough to inspect it and decide whether it is relevant. This is how ARP requests work, as you will see below.

Unicast vs. multicast MAC addresses:

A MAC address whose first bit (the least significant bit of the first byte) is 0 is a unicast address — it identifies a single specific device. A MAC address whose first bit is 1 is a multicast address — it is destined for a group of devices that have registered interest in that group. Broadcast (FF:FF:FF:FF:FF:FF) is a special case of multicast where every device is in the group.

The ARP Process, Step by Step

Here is a complete, detailed walkthrough of what happens when a device needs to find the MAC address of another device on the same local network.

Scenario:

Device A: IP address 192.168.1.10, MAC address AA:AA:AA:AA:AA:AA
Device B: IP address 192.168.1.20, MAC address BB:BB:BB:BB:BB:BB
Both devices are on the same subnet (192.168.1.0/24) connected through an Ethernet switch

Device A wants to send data to Device B. It has Device B's IP address (perhaps retrieved from a DNS lookup, or entered directly), but it does not know Device B's MAC address.

Step 1 — Check the ARP Cache

Before sending any ARP request, Device A checks its local ARP cache — a table it maintains in memory that maps IP addresses to MAC addresses. If Device A recently communicated with Device B, the MAC address may already be cached. If it is found and has not expired, no ARP request is needed.

Assume the cache does not have an entry for 192.168.1.20. Device A must send an ARP request.

Step 2 — ARP Request (Broadcast)

Device A constructs an ARP request packet with the following information:

Sender MAC address: AA:AA:AA:AA:AA:AA (Device A's MAC)
Sender IP address: 192.168.1.10 (Device A's IP)
Target MAC address: 00:00:00:00:00:00 (unknown — this is what we are asking for)
Target IP address: 192.168.1.20 (Device B's IP — what we are asking about)

This ARP request is wrapped in an Ethernet frame with:

Source MAC: AA:AA:AA:AA:AA:AA
Destination MAC: FF:FF:FF:FF:FF:FF (broadcast)

The switch receives this frame and floods it out all ports (because the destination is the broadcast address). Every device on the local segment receives the frame. The message, in plain terms, is: "Who has 192.168.1.20? Tell 192.168.1.10."

Step 3 — ARP Reply (Unicast)

Every device on the segment receives the ARP request. Every device checks whether the target IP address (192.168.1.20) matches its own IP address.

Device B sees that 192.168.1.20 is its IP address. It responds.
All other devices see that 192.168.1.20 is not their IP address. They discard the request.

Device B constructs an ARP reply with:

Sender MAC address: BB:BB:BB:BB:BB:BB (Device B's MAC — this is the answer)
Sender IP address: 192.168.1.20 (Device B's IP)
Target MAC address: AA:AA:AA:AA:AA:AA (Device A's MAC — it already knows this from the request)
Target IP address: 192.168.1.10

This ARP reply is sent as a unicast frame directly to Device A's MAC address (AA:AA:AA:AA:AA:AA). No broadcast is needed — Device B already knows where to send the reply because Device A included its MAC address in the request.

Step 4 — Communication Proceeds

Device A receives the ARP reply. It now knows that 192.168.1.20 is at BB:BB:BB:BB:BB:BB. It stores this mapping in its ARP cache and proceeds to send the Ethernet frame with the actual data.

From this point, every subsequent packet to 192.168.1.20 can be sent directly in a unicast Ethernet frame to BB:BB:BB:BB:BB:BB without any additional ARP requests — until the cache entry expires.

Note that as a side effect, Device B also typically updates its own ARP cache with Device A's IP-to-MAC mapping, since Device A included that information in the request. This means both devices cache each other's information simultaneously.

The ARP Cache

The ARP cache (also called the ARP table) is a short-term in-memory database maintained by every networked device. It stores recent IP-address-to-MAC-address mappings so that ARP requests do not need to be sent for every single packet.

Viewing the ARP cache:

On Windows:

arp -a

On Linux or macOS:

arp -a

(The command is the same across platforms, though the output format differs slightly.)

Example output on Linux:

? (192.168.1.1) at a1:b2:c3:d4:e5:f6 [ether] on eth0
? (192.168.1.20) at bb:bb:bb:bb:bb:bb [ether] on eth0
? (192.168.1.50) at cc:dd:ee:ff:11:22 [ether] on eth0

Example output on Windows:

Interface: 192.168.1.10 --- 0x3
  Internet Address      Physical Address      Type
  192.168.1.1           a1-b2-c3-d4-e5-f6     dynamic
  192.168.1.20          bb-bb-bb-bb-bb-bb     dynamic
  192.168.1.255         ff-ff-ff-ff-ff-ff     static

The "dynamic" entries were learned through ARP requests. The "static" entries were manually configured and do not expire.

Cache expiry:

ARP cache entries have a time limit — they expire and are removed. If the associated device is still on the network and the local machine still needs to communicate with it, a new ARP request will be made and a new entry created.

Typical expiry times:

Linux: approximately 20 minutes (60 seconds for unused entries, renewed by traffic)
Windows: between 15 seconds and 45 seconds for unused entries; up to 10 minutes for active entries
Cisco routers: 4 hours by default

These timers exist because network configurations change: devices get new IP addresses via DHCP, devices move, network interfaces change. The cache must eventually reflect the current state of the network rather than holding stale data indefinitely.

Gratuitous ARP

A gratuitous ARP is an ARP reply that is sent without any preceding ARP request. A device simply announces its own IP-to-MAC mapping to the network, unprompted.

The word "gratuitous" here means "given without being asked for" — not "unnecessary." Gratuitous ARPs serve several legitimate purposes:

IP address conflict detection: When a device comes online and is assigned an IP address (either statically or via DHCP), it sends a gratuitous ARP for its own IP address. If another device is already using that IP address, that device will see the gratuitous ARP and may reply, revealing the conflict. This allows the newly configured device to detect the problem before it causes communication failures.

Updating ARP caches after a change: When a device's MAC address changes — for example, when a failed server's IP address is taken over by a backup server with a different NIC — the new device sends a gratuitous ARP. All other devices on the network update their ARP caches to point the IP address to the new MAC address. This is how high-availability (failover) systems work at Layer 2.

Announcing after DHCP assignment: When a device receives a new IP address from a DHCP server, it may send a gratuitous ARP to inform the network of the new mapping.

The security problem with gratuitous ARP:

Most systems accept gratuitous ARP replies without any verification. They do not check whether the sender actually owns the IP address it is claiming. They simply update their ARP cache. This unconditional acceptance is, as you will see in the next section, the root cause of ARP spoofing attacks.

ARP Spoofing and ARP Poisoning

ARP spoofing (also called ARP poisoning or ARP cache poisoning) is an attack that exploits ARP's lack of authentication to redirect network traffic through an attacker-controlled device.

Because ARP has no authentication mechanism — no cryptographic signature, no verification that the sender actually owns the IP address it is claiming — any device on the local network can send a forged ARP reply claiming to be any IP address. Other devices will believe the forged reply and update their ARP caches accordingly.

The Attack in Detail

Setup:

Device A: 192.168.1.10 (a workstation)
Gateway: 192.168.1.1 (the router that connects the local network to the internet)
Attacker: 192.168.1.99 (a malicious device on the same network segment)
Attacker's MAC: EE:EE:EE:EE:EE:EE

Phase 1 — Poisoning Device A: The attacker sends a forged ARP reply to Device A claiming: "192.168.1.1 is at EE:EE:EE:EE:EE:EE." Device A receives this reply and updates its ARP cache. Now, when Device A wants to send traffic to the gateway (192.168.1.1), it sends it to the attacker's MAC address instead.

Phase 2 — Poisoning the Gateway: The attacker sends a forged ARP reply to the gateway claiming: "192.168.1.10 is at EE:EE:EE:EE:EE:EE." The gateway updates its ARP cache. Now, when the gateway wants to send traffic to Device A, it sends it to the attacker's MAC address.

Phase 3 — Man-in-the-Middle: All traffic from Device A to the internet flows through the attacker. All traffic from the internet to Device A also flows through the attacker (via the gateway). The attacker forwards the traffic in both directions (so that connections continue to work and the victim does not notice the problem), while reading or modifying the data in transit.

This is a man-in-the-middle (MITM) attack at Layer 2. The victim's connection appears normal — web pages load, emails send — but every packet passes through the attacker first.

The attacker can:

Read unencrypted traffic (HTTP, FTP, unencrypted email)
Capture credentials from unencrypted login pages
Inject malicious content into unencrypted web pages
Attempt SSL (Secure Sockets Layer) / TLS (Transport Layer Security) stripping to downgrade encrypted connections to unencrypted ones
Record traffic for later analysis

Continuous Poisoning

ARP cache entries expire. If the attacker sends a forged reply only once, the victim's ARP cache will eventually expire and the correct mapping may be relearned. For this reason, ARP spoofing tools continuously send forged ARP replies (typically every few seconds) to keep the victim's cache poisoned for as long as the attack continues.

Tools That Perform ARP Spoofing

Several well-known tools implement ARP spoofing, all of which are used both by attackers and by security professionals performing authorized penetration tests:

arpspoof (part of the dsniff toolkit): a simple command-line tool for sending forged ARP replies
Ettercap: a comprehensive MITM framework that includes ARP spoofing as one of several attack modes; can also analyze captured traffic and perform credential extraction
Bettercap: a modern, modular network attack and monitoring framework with ARP spoofing modules, commonly used in penetration testing

Understanding these tools exists not to enable attacks but to understand what defenders are protecting against. Knowing how arpspoof works tells you exactly why Dynamic ARP Inspection exists and what it prevents.

Defenses Against ARP Spoofing

Because ARP itself cannot be authenticated without replacing the protocol, defenses operate at other layers.

Dynamic ARP Inspection (DAI)

DAI (Dynamic ARP Inspection) is a feature on managed Ethernet switches. It intercepts all ARP packets on the network and validates them against a trusted database — specifically, the DHCP snooping binding table.

DHCP snooping is a companion feature that watches DHCP traffic and builds a table mapping: IP address → MAC address → switch port → VLAN (Virtual Local Area Network). Because a DHCP server assigned that IP address to that MAC address on that port, the binding table represents the known-good state of the network.

When DAI receives an ARP packet, it checks whether the IP-to-MAC mapping in the ARP packet matches an entry in the DHCP snooping binding table. If the ARP packet claims that 192.168.1.1 is at EE:EE:EE:EE:EE:EE, but the binding table says 192.168.1.1 was never assigned to that MAC address by DHCP, DAI drops the packet.

The attacker's forged ARP replies are silently discarded before they reach any victim. The poisoning cannot succeed.

DAI is the most effective and scalable defense against ARP spoofing. It requires managed switches (not the inexpensive unmanaged switches used in small offices) and requires DHCP snooping to be configured first.

Static ARP Entries

A static ARP entry is a manually configured entry in the ARP cache that does not expire and cannot be overwritten by received ARP replies. If you configure Device A with a permanent static ARP entry mapping the gateway's IP address (192.168.1.1) to the gateway's true MAC address, a forged ARP reply claiming a different MAC for that IP will be ignored.

This is effective in principle but impractical at scale. Every device on the network would need to be manually configured with static entries for every other device it communicates with — and those entries would need to be updated every time any device's MAC address changes. In a network of any significant size, this is unmanageable.

Static ARP entries are sometimes used for a small number of critical systems — such as the default gateway — where the manual overhead is acceptable and the security benefit is high.

Network Segmentation

ARP operates within broadcast domains. A broadcast domain is the set of devices that receive a broadcast frame — typically all devices on the same subnet connected through Layer 2 switches. Routers do not forward broadcast frames; they separate broadcast domains.

An attacker performing ARP spoofing can only poison ARP caches of devices in the same broadcast domain. An attacker on the guest wireless network cannot poison the ARP caches of devices on the corporate wired network, because those are on separate subnets separated by a router.

Smaller subnets mean smaller broadcast domains. Smaller broadcast domains limit the scope of ARP spoofing attacks. This is one of the concrete, technical reasons that network segmentation improves security — it is not just a conceptual separation; it physically limits the reach of Layer 2 attacks.

Encryption (TLS)

Even if an attacker successfully performs ARP spoofing and captures all traffic, encryption renders the captured data unreadable. HTTPS (Hypertext Transfer Protocol Secure) connections — which use TLS — are encrypted end-to-end between the client and the server. An attacker who intercepts the encrypted traffic cannot read the contents without the session keys, which are established using asymmetric cryptography during the TLS handshake.

This is not a defense against ARP spoofing itself — the attack still succeeds, and the attacker still intercepts traffic. But it is a critical compensating control. A network where all sensitive communication uses TLS is much less vulnerable to the consequences of a successful ARP MITM attack.

Note that attackers may attempt TLS stripping — downgrading a connection from HTTPS to HTTP if the browser allows it. HSTS (HTTP Strict Transport Security) is a web server header that tells browsers to always use HTTPS for a given domain and reject any attempt to downgrade to HTTP, which mitigates TLS stripping attacks.

Port Security

Port security is a switch feature that limits the MAC addresses allowed on a given switch port. If a switch port is configured to allow only one specific MAC address, any frame arriving on that port from a different MAC address is dropped (or the port is shut down). This prevents attackers from connecting unauthorized devices to the network and limits the ability of software-based MAC spoofing to introduce rogue devices.

Proxy ARP

Proxy ARP is a behavior in which a router responds to ARP requests on behalf of devices on a different network. When a device sends an ARP request for an IP address that is not on the local subnet, a router with proxy ARP enabled will respond with its own MAC address — in effect saying "send traffic for that address to me, and I'll route it."

Legitimate uses of proxy ARP include:

Connecting two networks that are in the same IP subnet but physically separated (so devices in each half think they are on the same flat network)
Some DSL (Digital Subscriber Line) and cable internet architectures
Certain VPN (Virtual Private Network) configurations

Proxy ARP can also be used by attackers. A device that answers ARP requests for addresses it does not own — whether it is a router or a rogue device — can redirect traffic intended for systems on other subnets. Understanding proxy ARP helps you recognize when traffic is being intercepted at Layer 3 boundaries rather than just within a flat subnet.

Most network engineers consider enabling proxy ARP unnecessarily risky in modern networks, and it is disabled by default on many router platforms.

IPv6 and NDP — The Successor to ARP

IPv6 (Internet Protocol version 6) does not use ARP. IPv4's ARP is replaced in IPv6 by NDP (Neighbor Discovery Protocol), which is defined in RFC 4861.

NDP uses ICMPv6 (Internet Control Message Protocol version 6) messages rather than a standalone protocol:

NS (Neighbor Solicitation): The IPv6 equivalent of an ARP request. A device sends a Neighbor Solicitation to a specific multicast address asking "who has this IPv6 address?"
NA (Neighbor Advertisement): The IPv6 equivalent of an ARP reply. The device that owns the IPv6 address responds with its MAC address.

NDP also handles router discovery (finding the default gateway), prefix discovery (learning which subnets are local), and address autoconfiguration (SLAAC — Stateless Address Autoconfiguration).

Is NDP more secure than ARP?

In some respects, yes. NDP uses multicast instead of broadcast, which reduces the scope of solicitations (not every device on the segment receives them). NDP also has a security extension called SEND (Secure Neighbor Discovery), defined in RFC 3971, which uses cryptographic signatures to authenticate NDP messages and prevent spoofing.

However, SEND is rarely deployed in practice due to implementation complexity and performance overhead. Most IPv6 networks use NDP without SEND, which means they remain vulnerable to Neighbor Advertisement spoofing — the IPv6 equivalent of ARP spoofing. DAI has an IPv6 equivalent called RA Guard (Router Advertisement Guard) and ND Inspection, which some managed switches support.

The practical takeaway: switching to IPv6 does not eliminate Layer 2 spoofing attacks. The attack surface changes shape, but the fundamental problem — that local network address resolution is unauthenticated in most deployments — persists.

What ARP Reveals in a Security Context

Understanding ARP is useful for more than preventing attacks. ARP information can reveal a great deal about a network during both legitimate security assessments and adversarial reconnaissance.

Passive ARP monitoring: By capturing ARP traffic on a network segment, you can identify every active IP-to-MAC mapping on that segment. This reveals the number of active hosts, their IP addresses, and through OUI lookup, the manufacturer of each device — which often reveals the type of device (server, workstation, printer, IP camera, network appliance).

ARP scanning: Tools like arp-scan and Nmap (Network Mapper) can send ARP requests to an entire subnet and collect replies. ARP scanning at Layer 2 is faster and more reliable than IP-level scanning (ping sweeping) because ARP responses bypass host-based firewalls that might block ICMP (Internet Control Message Protocol) ping packets. ARP scanning is a standard step in network reconnaissance and penetration testing.

Detecting ARP spoofing: Security monitoring tools and IDS (Intrusion Detection System) software can detect ARP spoofing by watching for anomalies: a MAC address that was previously associated with one IP address suddenly claiming a different IP, or an IP address claiming multiple different MAC addresses in quick succession. XArp and Arpwatch are tools specifically designed for ARP monitoring and anomaly detection.

MAC address spoofing: While MAC addresses are embedded in hardware, they can be overridden in software. Most modern operating systems allow a user to set a custom MAC address on a network interface. Attackers use MAC spoofing to impersonate legitimate devices (bypassing MAC-based access controls), to appear to be a different manufacturer (to evade detection), or in conjunction with ARP spoofing attacks. Defenders cannot assume that a MAC address represents a genuine, unalterable identity.

The Bottom Line

ARP (Address Resolution Protocol) solves the problem of mapping logical IP addresses to physical MAC addresses so that data can be delivered within a local network segment via Ethernet. When a device needs to send data to an IP address on the same subnet, it broadcasts an ARP request asking for the corresponding MAC address; the owner of that IP replies with its MAC address; both sides cache the mapping. Because ARP has no authentication, any device can send forged ARP replies claiming to be any IP address — this is ARP spoofing, the basis for Layer 2 man-in-the-middle attacks. The most effective defense is DAI (Dynamic ARP Inspection) on managed switches, which validates ARP packets against a DHCP snooping binding table and drops forged replies. Network segmentation limits the scope of ARP attacks by reducing broadcast domain size. Encryption (TLS) ensures that even successfully intercepted traffic cannot be read. IPv6 replaces ARP with NDP (Neighbor Discovery Protocol) using ICMPv6, but without SEND (Secure Neighbor Discovery), IPv6 networks remain vulnerable to analogous spoofing attacks.

Check Your Understanding

Device A has IP address 10.10.1.5. Device B has IP address 10.10.1.8. Device A wants to send data to Device B. Describe, step by step, what happens in the ARP process before the first data packet is actually delivered. What does the ARP request contain, how is it delivered, and what does the ARP reply contain?
An attacker on the same /24 network as a victim workstation (10.10.1.20) and the victim's default gateway (10.10.1.1) wants to perform a man-in-the-middle attack using ARP poisoning. What forged ARP replies does the attacker need to send, to whom, and what effect does each have? What does the attacker need to do to ensure the victim does not notice the attack?

Something to Think About

DAI (Dynamic ARP Inspection) works by comparing ARP packets against the DHCP snooping binding table. What happens if a device has a statically configured IP address (not assigned by DHCP)? It would not appear in the DHCP snooping table, so DAI would drop its ARP packets as if they were forged. How would you handle this situation in a real network, and what does this tell you about the trade-offs between security controls and operational complexity?
ARP spoofing attacks are generally limited to devices in the same broadcast domain (the same subnet). Given that, what does the fact that a successful ARP poisoning attack occurred tell you about the attacker's position in the network? How might an attacker have gotten onto the same subnet as their target in the first place, and what does this say about the relationship between physical security, wireless security, and network segmentation?

References

Official Specification. RFC 826 — "An Ethernet Address Resolution Protocol". Internet Engineering Task Force, 1982. — The original ARP specification; remarkably short and readable, defining the core protocol still in use today.
Official Specification. RFC 5227 — "IPv4 Address Conflict Detection". Internet Engineering Task Force. — Documents gratuitous ARP behavior in detail and specifies how IP address conflict detection using ARP is expected to work.
Official Guidance. NIST SP 800-153 — "Guidelines for Securing Wireless Local Area Networks (WLANs)". National Institute of Standards and Technology. — Covers Layer 2 attacks including ARP spoofing in wireless environments, where the attacker's separation from the wired network makes ARP attacks particularly relevant.
Real-World Incident. CISA — "Advisory AA22-011A: Understanding and Mitigating Russian State-Sponsored Cyber Threats". Cybersecurity and Infrastructure Security Agency. — Documents MITM techniques used by state-sponsored actors consistent with ARP-layer interception combined with credential harvesting from intercepted traffic.