Address Resolution Protocol (ARP): How IPv4 Devices Discover Each Other on an Ethernet Network

Every time you open a website, connect to a file server, print a document, or access another computer on your local network, your device performs a series of operations that are almost entirely invisible to the user. While applications typically communicate using IP addresses and domain names, the underlying Ethernet network cannot forward data using those logical identifiers alone. Before any IPv4 packet can be encapsulated into an Ethernet frame and transmitted across a local area network (LAN), the sender must first determine the hardware address of the destination device. This seemingly simple task is performed by the Address Resolution Protocol (ARP).

ARP is one of the most fundamental protocols in IPv4 networking. Defined in RFC 826, it provides the mechanism for translating a known IPv4 address into the corresponding Media Access Control (MAC) address required for communication on an Ethernet network. Without ARP, devices would know the logical destination of their traffic but would have no reliable method of identifying the physical network interface responsible for receiving it. In practical terms, communication between two hosts on the same Ethernet network would be impossible.

Although ARP is conceptually straightforward, its significance extends far beyond basic network communication. Network administrators rely on ARP when troubleshooting connectivity problems, diagnosing duplicate IP address conflicts, and verifying network topology. Security professionals study ARP because its design predates modern security principles and therefore lacks mechanisms to authenticate or validate address mappings. This absence of authentication has made ARP a long-standing target for attackers seeking to perform network reconnaissance, redirect traffic, or establish man-in-the-middle (MITM) positions within a local network.

Understanding ARP requires more than memorizing the exchange of requests and replies. It involves understanding how Ethernet and IP complement one another, how operating systems maintain neighbor tables, why switches never use IP addresses to forward frames, and why a protocol designed in the early 1980s continues to influence the security of modern enterprise networks. By examining ARP from both networking and cybersecurity perspectives, it becomes clear that one of the Internet’s simplest protocols also carries some of its most important operational and security implications.

Why ARP Exists

To appreciate the purpose of ARP, it is first necessary to understand the distinction between logical addressing and physical addressing. These concepts are often introduced together in networking courses, yet they solve entirely different problems.

The Internet Protocol provides logical addressing. An IPv4 address identifies a device within a network and allows routers to determine the path that packets should follow between different networks. Because IP addresses represent a device’s location within a network hierarchy, they may change when a device joins a different subnet, moves to another organization, or receives a new lease from a DHCP server.

Ethernet, however, operates using physical addresses, commonly known as MAC addresses. Every Ethernet frame transmitted across a local network contains both a source and destination MAC address. Switches examine these addresses to determine which physical port should receive each frame. Unlike IP addresses, MAC addresses are associated with network interfaces rather than network locations. Traditionally they are assigned by hardware manufacturers, although modern operating systems can temporarily modify or randomize them for administrative or privacy purposes.

This distinction creates an important challenge. Applications generate data destined for an IPv4 address, but Ethernet hardware requires a MAC address before transmission can occur. If a workstation knows only that it must send a packet to 192.168.10.25, how does it determine the corresponding Ethernet address? The answer is ARP.

Instead of maintaining a permanent database of every device connected to the network, hosts resolve addresses dynamically. Whenever an operating system needs to communicate with another device on the same subnet, it first checks whether the required IP-to-MAC mapping already exists in its local ARP cache. If the mapping is available, communication proceeds immediately. If it is not, the operating system broadcasts an ARP Request asking which device owns the desired IPv4 address. The host configured with that address responds with its MAC address, allowing normal communication to begin.

This approach offers considerable flexibility. Devices can join or leave a network without requiring manual updates on neighboring systems, DHCP servers can reassign IP addresses automatically, and hosts need only maintain mappings for systems with which they actually communicate. The protocol therefore minimizes administrative overhead while enabling dynamic network environments to function efficiently.

The simplicity that makes ARP effective also introduces an important limitation. The protocol assumes that every device connected to the local network behaves honestly. It does not authenticate requests or replies, nor does it verify that the sender is genuinely authorized to claim ownership of a particular IPv4 address. At the time ARP was designed, local Ethernet networks were generally considered trusted environments. Today, that assumption represents one of the protocol’s most significant security weaknesses.

Understanding IP Addresses and MAC Addresses

Although IP addresses and MAC addresses are frequently discussed together, they perform fundamentally different roles within the TCP/IP networking model. Confusing the two often leads to misunderstandings about routing, switching, and address resolution.

An IPv4 address is a Layer 3 logical identifier. It enables routers to forward packets across interconnected networks by examining the destination network portion of the address. Because IPv4 addressing is hierarchical, routers need only understand network prefixes rather than maintaining knowledge of every device on the Internet. This hierarchical design is what allows billions of devices to communicate across global networks.

A MAC address is a Layer 2 hardware identifier used exclusively within the local broadcast domain. Ethernet switches forward frames according to MAC addresses stored in their forwarding tables, not according to IP addresses. Every Ethernet frame therefore contains both a source MAC address and a destination MAC address, regardless of the IP addresses carried inside the frame.

A traditional Ethernet MAC address is 48 bits long and is commonly represented as six hexadecimal octets separated by colons or hyphens.

00:1A:2B:3C:4D:5E

The first 24 bits constitute the Organizationally Unique Identifier (OUI), which is allocated by the IEEE to hardware manufacturers. The remaining 24 bits uniquely identify a specific network interface produced by that manufacturer. Packet analyzers such as Wireshark use publicly available OUI databases to identify the vendor associated with a captured MAC address, providing valuable context during network troubleshooting and security investigations.

Although MAC addresses are often described as permanent hardware identifiers, modern networking has introduced important exceptions. Virtual machines generate virtual MAC addresses, many wireless operating systems implement MAC address randomization to improve user privacy, and administrators can deliberately modify MAC addresses through software. Consequently, a MAC address should be regarded as an identifier rather than proof of a device’s identity.

Understanding this distinction explains why ARP is necessary. Applications and routing decisions depend on IPv4 addresses, whereas Ethernet transmission depends on MAC addresses. ARP provides the translation mechanism that allows these two addressing systems to work together.

When ARP Is Used

A common misconception is that ARP resolves the MAC address of every destination host, regardless of its location. In reality, ARP functions only within the local broadcast domain. It never discovers the MAC address of a remote server located across the Internet.

Suppose a workstation with the address 192.168.10.20 wishes to communicate with another workstation, 192.168.10.35, on the same subnet. Because both devices belong to the same Layer 2 network, the sender performs an ARP lookup to determine the destination MAC address directly.

Now consider a different scenario in which the same workstation accesses a web server located at 203.0.113.15. Since the destination resides on a different network, the operating system recognizes that the packet must first be delivered to the configured default gateway. Instead of attempting to resolve the MAC address of the remote web server, the workstation performs ARP only for the gateway’s IPv4 address.

The resulting communication process is:

Application
      │
      ▼
Destination IP determined
      │
      ▼
Same subnet?
      │
 ┌────┴────┐
 │         │
Yes        No
 │         │
 ▼         ▼
Resolve    Resolve
Target     Default Gateway
MAC        MAC
 │         │
 ▼         ▼
Send Ethernet Frame

This distinction is fundamental to understanding Ethernet networking. ARP resolves only the next-hop MAC address, not necessarily the final destination. Once the packet reaches the router, the Ethernet header is removed, the IP packet is examined, and the router constructs an entirely new Ethernet frame for the next network segment. If necessary, the router performs its own ARP lookup on the outgoing interface before forwarding the packet toward its destination.

This process repeats at every routed hop until the packet finally reaches the destination subnet.

Where ARP Fits Within the TCP/IP Stack

ARP occupies an unusual position within the networking stack because it interacts with both Layer 2 and Layer 3 while belonging entirely to neither. Unlike TCP, UDP, or ICMP, ARP is not encapsulated inside an IP packet. Instead, it is carried directly within an Ethernet frame using the EtherType value 0x0806.

This design avoids a circular dependency. If ARP itself required IP for transport, a host would need a MAC address before it could send the very packet intended to discover that MAC address. By operating directly over Ethernet, ARP can perform address resolution before IP communication begins.

When an Ethernet interface receives a frame with EtherType 0x0806, the operating system immediately interprets the payload as an ARP message. Frames carrying EtherType 0x0800, by contrast, are processed as IPv4 packets. This separation allows ARP to function independently of higher-layer protocols while remaining tightly integrated with Ethernet communication.

Because ARP messages are broadcast only within a single Ethernet segment, routers do not forward them across network boundaries. This behavior confines address resolution to the local subnet, reduces unnecessary broadcast traffic, and reinforces the principle that ARP is strictly a local network protocol.

How ARP Works

Once a host determines that the destination device resides on the same subnet, it must identify the destination’s MAC address before any Ethernet frame can be transmitted. Although this process occurs automatically within a fraction of a second, understanding each stage of the exchange provides valuable insight into how IPv4 communication functions on an Ethernet LAN.

Consider a simple network consisting of two workstations connected to the same switch.

Computer A
IP Address : 192.168.10.15
MAC Address: 00:50:56:11:22:33
Computer B
IP Address : 192.168.10.25
MAC Address: 00:50:56:AA:BB:CC

Suppose a user on Computer A attempts to access a shared folder hosted on Computer B. The application already knows that the destination IP address is 192.168.10.25, but the Ethernet adapter cannot transmit frames addressed only to an IP address. It requires the destination MAC address before constructing the Ethernet header.

Rather than immediately broadcasting an ARP Request, the operating system first examines its ARP cache, also known as the neighbor table. This cache stores recently learned IP-to-MAC mappings so that repeated communications with the same device do not require another network-wide broadcast.

If the cache already contains a valid mapping for 192.168.10.25, the operating system immediately constructs an Ethernet frame using the stored MAC address, and communication proceeds without generating any ARP traffic.

If no suitable entry exists, the address resolution process begins.

The ARP Resolution Workflow

Although operating systems implement ARP slightly differently, the overall workflow remains remarkably consistent across Windows, Linux, macOS, and network appliances.

Application generates data
        │
        ▼
Destination IP determined
        │
        ▼
Same subnet?
        │
 ┌──────┴──────┐
 │             │
Yes            No
 │             │
 ▼             ▼
Check ARP      Resolve default
cache          gateway MAC
 │
 ├─────────────┐
 │             │
Entry exists   Entry missing
 │             │
 ▼             ▼
Send frame     Broadcast ARP Request
               │
               ▼
      Target sends ARP Reply
               │
               ▼
       Update ARP cache
               │
               ▼
      Send original Ethernet frame

This sequence illustrates an important principle: ARP is only invoked when necessary. Once a valid mapping has been learned, future packets are transmitted directly until the cached entry expires or becomes invalid.

Step 1: Checking the ARP Cache

The first operation performed by the networking stack is a lookup in the local ARP cache.

This cache is essentially a small database maintained by the operating system. Each entry associates an IPv4 address with a corresponding MAC address and includes additional metadata that helps the operating system determine whether the information remains valid.

If the operating system discovers an existing mapping for the destination host, it immediately proceeds with transmission. Because no additional network traffic is generated, this lookup is both efficient and transparent to the user.

Only when the cache lacks a valid entry does the operating system generate an ARP Request.

Step 2: Broadcasting an ARP Request

Since the sender does not yet know which device owns the requested IPv4 address, it cannot direct the request toward a specific host. Instead, the operating system constructs an ARP Request and transmits it using the Ethernet broadcast address:

FF:FF:FF:FF:FF:FF

Every network interface within the same broadcast domain receives Ethernet broadcasts. Consequently, every host connected to the local switch processes the incoming ARP Request.

Conceptually, the request asks a single question:

Who has 192.168.10.25? Tell 192.168.10.15.

Although every device receives this request, only the system configured with the queried IPv4 address generates a response.

The ARP Request itself already contains useful information. Along with the target IPv4 address being queried, it also includes the sender’s own IPv4 and MAC addresses. Many operating systems use this information to update their own neighbor tables even before transmitting an ARP Reply.

Step 3: Receiving the ARP Reply

When Computer B receives the broadcast, it compares the requested IPv4 address with the addresses assigned to its network interfaces.

Because 192.168.10.25 belongs to Computer B, it constructs an ARP Reply.

Unlike the original request, the reply is not broadcast. Since Computer B already knows Computer A’s MAC address from the received request, it sends a unicast Ethernet frame directly back to the requesting host.

The reply effectively states:

192.168.10.25 is at 00:50:56:AA:BB:CC

Computer A receives the response, updates its ARP cache, and immediately proceeds to transmit the original IPv4 packet using the newly learned destination MAC address.

The overall exchange appears as follows:

Computer A                              Computer B
Need MAC for 192.168.10.25
        │
        │  ARP Request (Broadcast)
        │───────────────────────────────────────►
        │   Who has 192.168.10.25?
        │
        │◄──────────────────────────────────────
        │  ARP Reply (Unicast)
        │  192.168.10.25 is at
        │  00:50:56:AA:BB:CC
        │
Update ARP Cache
Transmit original packet

From the perspective of the user, this exchange typically completes in only a few milliseconds.

Why Only the Request Is Broadcast

Students often wonder why ARP Requests are broadcast while Replies are usually transmitted using unicast.

The answer lies in what each host knows at the time.

Initially, the sender has no knowledge of the destination MAC address. Broadcasting the request guarantees that every host on the subnet receives it, allowing the correct recipient to identify itself.

Once the destination host receives the request, however, it already knows the sender’s MAC address because that information was included in the ARP packet. There is therefore no need to broadcast the response. Sending a unicast reply minimizes unnecessary traffic and reduces processing overhead on other hosts connected to the same LAN.

This seemingly small design decision helps Ethernet networks remain efficient even as the number of connected devices grows.

Understanding the ARP Cache

Broadcasting every time a packet needs to be transmitted would create unnecessary network traffic and significantly reduce performance. To avoid this overhead, operating systems maintain a temporary database known as the ARP cache, sometimes referred to in modern Linux systems as the neighbor table.

The ARP cache stores recently learned mappings between IPv4 addresses and MAC addresses. Once a mapping has been resolved, subsequent communications with the same host can proceed immediately without requiring another ARP exchange.

Suppose Computer A recently communicated with three neighboring devices. Its ARP cache might conceptually resemble the following:

Whenever the operating system needs to send another packet to 192.168.10.25, it simply consults this cache instead of generating another broadcast.

Contrary to popular belief, ARP entries are not permanent. Network environments change continuously. Devices disconnect from the network, DHCP servers assign new addresses, virtual machines migrate between physical hosts, and administrators replace hardware. If cached mappings were never refreshed, systems would continue sending traffic to obsolete MAC addresses long after the underlying network changed.

To prevent this, operating systems associate each dynamic ARP entry with an aging mechanism. Entries that have not been used for a period of time eventually become candidates for validation or removal.

Windows and Linux implement this process differently, but both seek the same goal: maintaining accurate address mappings while minimizing unnecessary ARP broadcasts.

Modern Linux kernels implement a sophisticated Neighbor Unreachability Detection (NUD) state machine rather than relying solely on simple timeout values. Instead of classifying entries merely as valid or expired, Linux tracks multiple states that reflect the confidence level of each mapping.

A REACHABLE entry has recently been confirmed through successful communication.

A STALE entry remains usable but has not been verified recently.

A DELAY entry is temporarily awaiting confirmation before additional validation occurs.

A PROBE entry indicates that the kernel is actively transmitting ARP Requests to verify whether the neighbor remains reachable.

Finally, a FAILED entry signifies that repeated attempts to contact the neighbor have been unsuccessful.

This state-based approach reduces unnecessary broadcast traffic while allowing Linux to respond intelligently to changing network conditions.

Windows employs different internal algorithms but follows the same overall principle. Recently verified mappings remain available, while unused or outdated entries are refreshed or discarded over time.

Understanding ARP cache behavior is particularly valuable during troubleshooting. Clearing the cache forces the operating system to perform fresh address resolution, making it easier to identify stale entries, duplicate IP addresses, or devices that no longer respond to ARP Requests.

Dynamic and Static ARP Entries

Not every ARP entry is learned automatically.

Most entries are dynamic, meaning they are created when the operating system receives valid ARP traffic and are eventually removed after aging out.

Some entries, however, are configured manually as static ARP entries.

Static entries never change automatically and cannot be overwritten by unsolicited ARP Replies. This characteristic makes them resistant to traditional ARP cache poisoning attacks.

Despite their security benefits, static ARP entries are rarely deployed across large enterprise environments. Maintaining thousands of manually configured mappings quickly becomes impractical whenever hardware is replaced, virtual machines migrate, or IP addressing changes. Consequently, modern organizations generally rely on infrastructure-based protections such as Dynamic ARP Inspection (DAI) instead of static configuration.

Gratuitous ARP

Although ARP is commonly described as a protocol that resolves unknown MAC addresses, not every ARP message is transmitted in response to a request. Operating systems and network devices also generate Gratuitous ARP, an unsolicited ARP announcement that advertises an IP-to-MAC mapping without first being asked for it. Despite the name, Gratuitous ARP serves several important operational purposes and is used extensively in modern enterprise networks.

A typical ARP exchange begins when one device asks, “Who has this IP address?” A Gratuitous ARP, by contrast, is initiated voluntarily by the sender. Rather than resolving another device’s address, the sender announces its own address mapping to every host within the local broadcast domain.

In most operating systems, this announcement is implemented as a broadcast ARP Request in which both the sender and target IPv4 addresses are set to the sender’s own IP address. Although the target IP matches the sender’s address, every device on the network still receives and processes the broadcast. Some operating systems and networking equipment instead transmit an unsolicited ARP Reply, but the purpose remains the same: informing neighboring devices that a particular IPv4 address is now associated with a specific MAC address.

Conceptually, a Gratuitous ARP announcement resembles the following:

Sender IP : 192.168.10.25
Sender MAC: 00:50:56:AA:BB:CC
Target IP : 192.168.10.25
Target MAC: 00:00:00:00:00:00

Unlike a traditional ARP Request, the sender is not expecting another device to provide information. Instead, it is distributing information that neighboring hosts may use to update their ARP caches.

Why Gratuitous ARP Is Used

One of the primary uses of Gratuitous ARP is Duplicate Address Detection (DAD). Before assigning an IPv4 address to a network interface, many operating systems verify that another device is not already using the same address. They accomplish this by broadcasting a Gratuitous ARP message for the intended address. If another host responds, the operating system detects an address conflict and can prevent the duplicate assignment.

Another common application involves high-availability systems. Enterprise networks frequently deploy redundant routers, firewalls, or load balancers using protocols such as the Virtual Router Redundancy Protocol (VRRP), the Hot Standby Router Protocol (HSRP), or the Common Address Redundancy Protocol (CARP). These systems share a virtual IPv4 address that clients use as their default gateway.

Suppose the active router unexpectedly fails. The standby router immediately assumes responsibility for the shared virtual IP address and broadcasts one or more Gratuitous ARP messages announcing that the virtual address is now associated with its own MAC address. Neighboring hosts update their ARP caches almost instantly, allowing traffic to continue flowing without waiting for stale cache entries to expire naturally. This rapid update minimizes service disruption during failover events.

Virtualization platforms also rely heavily on Gratuitous ARP. During live migration, a virtual machine may move from one physical server to another while retaining the same IPv4 and MAC addresses. Although the addresses remain unchanged, the virtual network interface now appears on a different physical switch port. Broadcasting a Gratuitous ARP immediately informs neighboring hosts and Ethernet switches of the VM’s new location, reducing convergence time and avoiding temporary communication failures.

Cloud environments use similar techniques when virtual machines, containers, or virtual network appliances are relocated within the underlying infrastructure.

Security Implications of Gratuitous ARP

While Gratuitous ARP provides important operational benefits, it also illustrates one of ARP’s inherent security challenges. Most operating systems accept unsolicited ARP announcements and update their neighbor tables without authenticating the sender. This behavior is intentional because legitimate scenarios such as router failover and virtual machine migration depend upon it.

Unfortunately, attackers can exploit this same behavior by broadcasting forged Gratuitous ARP messages that falsely associate another device’s IPv4 address with the attacker’s MAC address. Since neighboring systems generally trust these announcements, they may overwrite legitimate ARP cache entries, redirecting traffic toward the attacker’s machine.

The protocol itself cannot distinguish between a legitimate failover event and a malicious spoofing attempt. Consequently, enterprise networks rely on infrastructure-level protections, such as Dynamic ARP Inspection, rather than modifications to the ARP protocol itself.

Proxy ARP

Another specialized capability supported by many routers is Proxy ARP. Unlike Gratuitous ARP, which allows a host to advertise information about itself, Proxy ARP enables a router to answer ARP Requests on behalf of another device.

Suppose a workstation attempts to communicate with an IPv4 address that is not physically located on the same Ethernet segment. Under normal circumstances, the workstation would forward the packet to its configured default gateway. In certain network designs, however, the router itself may respond to the workstation’s ARP Request by providing its own MAC address, even though the requested IPv4 address belongs to a different host.

The workstation therefore believes the destination device is directly reachable on the local network, while in reality the router transparently forwards packets to another subnet.

Conceptually, the communication appears as follows:

Workstation
      │
ARP Request
Who has 192.168.20.50?
      │
      ▼
Router responds
"I do."
(using its own MAC address)
      │
      ▼
Router forwards traffic
to the real destination

Proxy ARP was historically useful when organizations wished to interconnect multiple physical networks without modifying host configurations or introducing explicit gateway settings. In such environments, hosts could continue operating as though every destination resided on the same local network, while routers silently performed Layer 3 forwarding behind the scenes.

Modern enterprise networks, however, rarely depend on Proxy ARP for routine connectivity. Advances in routing protocols, subnetting practices, DHCP, and automated network management have largely eliminated the need for this behavior. Furthermore, excessive reliance on Proxy ARP can obscure network topology, complicate troubleshooting, and increase unnecessary ARP traffic. For these reasons, many organizations disable Proxy ARP unless a specific operational requirement exists.

Nevertheless, understanding Proxy ARP remains valuable because it demonstrates that routers can participate in ARP exchanges under certain conditions and illustrates how Layer 2 and Layer 3 functions sometimes overlap in practical networking.

Real-World Behavior of ARP

Laboratory demonstrations often give the impression that ARP traffic occurs continuously. In production networks, however, ARP typically represents only a very small fraction of overall network traffic. Once devices have populated their neighbor caches, they exchange relatively few ARP messages during normal operation.

Short bursts of ARP traffic are entirely expected in several common situations.

When a workstation first boots, its ARP cache is empty. Before communicating with file servers, domain controllers, printers, or Internet gateways, the operating system must resolve the MAC addresses of these devices. Consequently, the first few seconds after startup often contain multiple ARP Requests.

A similar burst may occur after a network interface reconnects, a DHCP lease is renewed, or an administrator manually clears the ARP cache. Virtual machine migration, gateway failover, and changes in network topology can also generate additional Gratuitous ARP announcements as devices update their neighbor tables.

Observing these temporary increases in ARP traffic should not immediately be interpreted as malicious activity. What typically distinguishes normal behavior from suspicious activity is consistency and volume. Legitimate ARP exchanges usually occur only when address resolution is necessary. By contrast, an attacker performing ARP cache poisoning often transmits forged ARP Replies repeatedly to ensure that victims continue accepting the malicious mapping as legitimate.

Recognizing the difference between expected operational behavior and abnormal ARP traffic is an important skill for network administrators and security analysts alike.

Managing the ARP Cache in Windows and Linux

Although ARP operates automatically, operating systems provide administrative tools for viewing and, when necessary, modifying the contents of the local ARP cache. These utilities are invaluable during network troubleshooting because they reveal exactly how the operating system currently associates IPv4 addresses with Ethernet MAC addresses.

Historically, both Windows and Unix-like operating systems included a utility named arp, and this command remains available today on Windows. Modern Linux distributions, however, have largely transitioned to the iproute2 networking suite, where neighbor management is performed through the ip neigh command. Because older documentation and certification material still reference the legacy utility, understanding both approaches remains useful.

Viewing the ARP Cache in Windows

Windows stores ARP entries in a table that can be displayed using the Command Prompt or PowerShell.

arp -a

A typical output resembles the following:

Interface: 192.168.10.15 --- 0x6
Internet Address      Physical Address      Type
192.168.10.1          3c-52-82-aa-19-10     dynamic
192.168.10.25         00-50-56-aa-bb-cc     dynamic
192.168.10.30         9c-b6-d0-72-1f-84     dynamic

Each row represents a mapping currently maintained by the operating system.

The Internet Address column lists the resolved IPv4 address.

The Physical Address column displays the corresponding Ethernet MAC address.

Finally, the Type column indicates whether the entry was learned dynamically through normal ARP communication or configured manually as a static mapping.

Administrators may also remove cached entries to force Windows to perform fresh address resolution during subsequent communications.

To remove all dynamic entries:

arp -d *

To delete a specific mapping:

arp -d 192.168.10.25

Removing entries does not interrupt network communication permanently. Instead, Windows simply broadcasts a new ARP Request the next time it needs to communicate with the affected destination.

Viewing the Neighbor Table in Linux

While the legacy arp utility remains available on many Linux distributions through the net-tools package, it has largely been superseded by the iproute2 suite. Modern Linux systems recommend using the ip command because it exposes additional information about neighbor states and provides more comprehensive management capabilities.

To display the current neighbor table, use:

ip neigh show

or simply:

ip neigh

A typical output resembles:

192.168.10.1 dev eth0 lladdr 3c:52:82:aa:19:10 REACHABLE
192.168.10.25 dev eth0 lladdr 00:50:56:aa:bb:cc STALE
192.168.10.30 dev eth0 lladdr 9c:b6:d0:72:1f:84 DELAY

Unlike the traditional arp command, this output reflects Linux’s Neighbor Unreachability Detection (NUD) state machine, providing additional insight into how the kernel evaluates each mapping.

The dev field identifies the network interface through which the neighbor is reachable.

The lladdr field specifies the neighbor’s Layer 2 address.

The final field indicates the current state of the neighbor entry.

A REACHABLE entry has recently been validated through successful communication.

A STALE entry has not been used recently but is still considered usable. Rather than immediately discarding it, the kernel verifies the mapping when future traffic requires it.

A DELAY state indicates that the operating system has postponed immediate validation because additional communication may confirm that the mapping remains accurate.

When verification becomes necessary, the kernel transitions the entry to the PROBE state and actively transmits ARP Requests to determine whether the destination still responds.

If repeated attempts fail, the entry ultimately reaches the FAILED state and is removed or refreshed as required.

This intelligent state machine significantly reduces unnecessary broadcast traffic while ensuring that obsolete mappings do not persist indefinitely.

Linux also allows administrators to delete individual entries.

sudo ip neigh del 192.168.10.25 dev eth0

Similarly, permanent entries may be created manually when required.

sudo ip neigh add 192.168.10.25 \
lladdr 00:50:56:aa:bb:cc \
dev eth0 nud permanent

Although static mappings are occasionally useful for specialized systems, they are rarely practical in large enterprise environments because every hardware replacement or addressing change requires manual updates.

Troubleshooting Using the ARP Cache

The ARP cache is often one of the first places administrators examine when diagnosing Layer 2 connectivity problems. Because every IPv4 communication on an Ethernet network depends on successful address resolution, incorrect or missing ARP entries frequently reveal the underlying cause of communication failures.

Suppose a workstation suddenly loses connectivity to its default gateway.

If no ARP entry exists for the gateway, the workstation may be broadcasting ARP Requests without receiving replies. Such behavior could indicate a disconnected cable, an incorrect VLAN assignment, a failed switch port, an offline router, or another Layer 2 communication problem.

Conversely, if the gateway appears in the ARP cache but is associated with an unexpected MAC address, administrators should investigate further. The discrepancy could result from legitimate infrastructure changes, such as a router failover event, but it may also indicate duplicate IP addressing or an ARP cache poisoning attack.

Comparing ARP tables across multiple hosts can further assist troubleshooting. If every workstation associates the gateway with the same MAC address, the network is likely operating normally. If different hosts report conflicting mappings, administrators should investigate the possibility of address conflicts, misconfigured network devices, or malicious activity.

For security analysts, ARP caches also provide valuable contextual information during incident response. Because entries represent recently contacted devices, examining a compromised workstation’s ARP cache can reveal neighboring systems that may warrant additional investigation.

Understanding the ARP Packet Format

Although ARP performs a straightforward function, its packet format is carefully designed to support different networking technologies while remaining compact and efficient. The protocol was standardized in RFC 826, which defines the structure of every ARP Request and ARP Reply transmitted on an Ethernet network.

Unlike protocols such as TCP or UDP, ARP is not encapsulated inside an IP packet. Instead, the ARP message forms the payload of an Ethernet frame whose EtherType field is set to 0x0806. Upon receiving such a frame, the operating system immediately recognizes that the payload contains ARP information rather than IPv4 traffic.

The ARP header begins with several fields that describe the underlying networking technologies involved in the exchange.

The Hardware Type (HTYPE) identifies the Layer 2 technology used by the sender. Ethernet networks use the value 1, although the protocol was originally designed to accommodate multiple hardware technologies.

The Protocol Type (PTYPE) specifies the protocol whose address is being resolved. For IPv4, this value is 0x0800, matching the EtherType assigned to IPv4 traffic.

The Hardware Address Length (HLEN) indicates the size of the hardware address. Because Ethernet MAC addresses occupy six bytes, this field contains the value 6.

The Protocol Address Length (PLEN) identifies the size of the protocol address. IPv4 addresses are four bytes long, so this field contains 4.

The Operation (OPER) field distinguishes between requests and replies. A value of 1 represents an ARP Request, while a value of 2 represents an ARP Reply.

Following these fields are the four address fields that constitute the heart of the protocol.

The Sender Hardware Address (SHA) contains the sender’s MAC address.

The Sender Protocol Address (SPA) contains the sender’s IPv4 address.

The Target Hardware Address (THA) contains the destination MAC address. During an ARP Request, this value is unknown and is therefore filled with zeros.

Finally, the Target Protocol Address (TPA) specifies the IPv4 address being queried.

Conceptually, an ARP Request appears as follows:

Hardware Type           Ethernet (1)
Protocol Type           IPv4 (0x0800)
Hardware Length         6
Protocol Length         4
Operation               Request (1)
Sender MAC              00:50:56:11:22:33
Sender IP               192.168.10.15
Target MAC              00:00:00:00:00:00
Target IP               192.168.10.25

The corresponding reply differs only slightly.

Hardware Type           Ethernet (1)
Protocol Type           IPv4 (0x0800)
Hardware Length         6
Protocol Length         4
Operation               Reply (2)
Sender MAC              00:50:56:AA:BB:CC
Sender IP               192.168.10.25
Target MAC              00:50:56:11:22:33
Target IP               192.168.10.15

Despite its simplicity, this packet format has remained essentially unchanged for decades and continues to support billions of IPv4 communications every day.

An important observation is that both ARP Requests and Replies contain the sender’s IP and MAC addresses. Consequently, operating systems often update their ARP caches whenever they receive valid ARP traffic, even if they did not explicitly request the information. While this behavior improves efficiency by reducing future broadcasts, it also contributes directly to ARP’s susceptibility to spoofing attacks, as malicious hosts can exploit unsolicited ARP messages to distribute false address mappings.

Analyzing ARP Traffic in Wireshark

Wireshark provides one of the clearest ways to understand ARP because every stage of the address resolution process can be observed directly as it occurs on the network. Since ARP exchanges take place before ordinary IPv4 communication begins, they are often among the first packets captured when monitoring an Ethernet interface.

After starting a packet capture, ARP traffic can be isolated using the display filter:

arp

This filter instructs Wireshark to display only ARP frames while temporarily hiding unrelated protocols such as TCP, UDP, DNS, or ICMP.

A typical capture begins with an ARP Request similar to:

Who has 192.168.10.25?
Tell 192.168.10.15

Moments later, assuming the destination exists on the local subnet, Wireshark displays the corresponding reply:

192.168.10.25 is at 00:50:56:AA:BB:CC

Although these summaries provide a convenient overview, expanding the packet reveals considerably more detail.

The Ethernet II section displays the source and destination MAC addresses together with the EtherType value 0x0806, confirming that the frame contains an ARP message.

Expanding the Address Resolution Protocol section exposes every field defined in RFC 826, including the hardware type, protocol type, operation code, sender hardware address, sender protocol address, target hardware address, and target protocol address.

Examining these fields allows analysts to verify exactly how address resolution occurs on the wire. During troubleshooting, repeated ARP Requests without corresponding replies often indicate that the destination host is unreachable, disconnected, assigned an incorrect IP address, or located on a different VLAN. Conversely, an unusually high volume of unsolicited ARP Replies or frequent changes in the MAC address associated with a critical IPv4 address may indicate ARP cache poisoning or another Layer 2 attack.

Because ARP operates beneath higher-layer protocols, understanding its behavior in Wireshark often enables administrators to identify the root cause of connectivity problems before investigating TCP, DNS, HTTP, or application-level traffic.

Real-world observation: In production enterprise networks, ARP traffic typically represents only a very small percentage of overall network traffic. Brief bursts of ARP activity immediately after a host boots, reconnects to the network, renews a DHCP lease, or following a gateway failover are entirely normal. Persistent unsolicited ARP Replies, rapidly changing IP-to-MAC mappings, or repeated broadcasts covering an entire subnet, however, warrant closer investigation because they may indicate reconnaissance or ARP cache poisoning.

How Attackers Use ARP for Network Reconnaissance

Before an attacker attempts to exploit vulnerabilities, escalate privileges, or move laterally through an organization, they first need to understand the environment they have entered. This initial phase, known as reconnaissance, focuses on identifying active systems, understanding network topology, and discovering potential targets. On an Ethernet-based IPv4 network, ARP provides one of the fastest and most reliable mechanisms for accomplishing this objective.

Unlike application-layer protocols, ARP is not an optional service that administrators can simply disable. Every IPv4 host communicating over Ethernet depends on ARP for local address resolution. As a result, even systems that block ICMP Echo Requests (ping), close all TCP ports, or run restrictive host-based firewalls generally continue to participate in ARP because normal network communication would otherwise be impossible.

This characteristic makes ARP-based host discovery considerably more reliable than traditional ICMP ping sweeps within the same broadcast domain. A workstation configured to ignore ping requests must still respond to legitimate ARP Requests directed at its assigned IPv4 address if it is to communicate on the network. Consequently, security professionals often prefer ARP-based discovery when enumerating hosts on a local subnet.

It is important to emphasize that this capability is not unique to attackers. Network administrators rely on the same technique for inventory management, troubleshooting, and verifying network connectivity. Like many networking technologies, ARP itself is neutral; its implications depend entirely on how it is used.

How ARP-Based Host Discovery Works

The process of discovering hosts through ARP is straightforward. The scanning system systematically broadcasts ARP Requests for IPv4 addresses across the target subnet. Every device connected to the local Ethernet segment receives each request, but only the host configured with the queried address responds.

Suppose a security analyst wishes to identify active hosts within the 192.168.10.0/24 subnet.

The scanner begins transmitting ARP Requests sequentially:

Who has 192.168.10.1?
Who has 192.168.10.2?
Who has 192.168.10.3?
...
Who has 192.168.10.254?

Unused addresses generate no reply.

Addresses assigned to active hosts respond with an ARP Reply containing the corresponding MAC address.

As responses are received, the scanner builds an inventory of active systems on the subnet. Since ARP exchanges occur entirely at Layer 2 and require no TCP connections or application-layer communication, discovery is typically very fast and imposes relatively little overhead on the network.

An important advantage of ARP scanning is that every response provides not only confirmation that a host is online but also its Ethernet MAC address. The first three octets of this address constitute the Organizationally Unique Identifier (OUI) assigned by the IEEE, allowing the manufacturer of the network interface to be identified with reasonable accuracy.

For example, a subnet containing numerous VMware OUIs may indicate a virtualized environment, while Cisco, Juniper, HPE, Dell, or Intel prefixes provide clues about the hardware deployed within the network. Although MAC addresses can be spoofed or randomized, OUI information often supplies useful context during security assessments and incident investigations.

Common ARP Discovery Tools

Several widely used networking tools leverage ARP for host discovery. Although their interfaces differ, they all rely on the same fundamental protocol.

arp-scan is one of the best-known utilities designed specifically for ARP-based enumeration. It constructs raw Ethernet frames containing ARP Requests and records every responding host, making it particularly effective for inventorying systems on a local subnet.

Netdiscover provides similar functionality while also supporting passive monitoring. In active mode, it transmits ARP Requests across a specified address range. In passive mode, it simply listens for existing ARP traffic, allowing it to identify active systems without generating additional packets. Passive operation can be valuable during network monitoring or security assessments where minimizing observable activity is desirable.

Modern versions of Nmap also perform ARP-based host discovery automatically when scanning targets located on the same Ethernet segment. Rather than relying solely on ICMP Echo Requests, Nmap intelligently chooses ARP because it provides more accurate host detection within local broadcast domains. This behavior occurs transparently, meaning many users perform ARP scanning without realizing that Nmap has selected the protocol automatically.

Regardless of the specific tool employed, the underlying principle remains identical: every active IPv4 host on an Ethernet LAN must participate in ARP.

Limitations of ARP Reconnaissance

Although ARP is highly effective for local discovery, it has a fundamental limitation: ARP traffic never crosses routers.

An ARP Request is an Ethernet broadcast. Routers deliberately discard Layer 2 broadcasts rather than forwarding them to other networks. Consequently, ARP scanning reveals only devices within the local broadcast domain.

This limitation has important implications for both attackers and defenders.

An attacker who compromises a workstation inside a corporate network may quickly identify every system located within the same VLAN, yet remain completely unaware of devices located on other routed subnets. To continue reconnaissance beyond the local broadcast domain, the attacker must first gain access to another network segment or employ higher-layer discovery techniques.

From a defensive standpoint, this behavior reinforces the value of network segmentation. Properly designed VLANs and routed boundaries not only restrict lateral movement but also significantly reduce the amount of information an attacker can gather after compromising a single endpoint.

ARP’s Trust Model and Its Security Implications

The effectiveness of ARP stems from its simplicity, but that simplicity is also the source of its greatest weakness.

When ARP was standardized in the early 1980s, Ethernet networks were relatively small and operated within trusted organizational environments. The protocol was therefore designed under the assumption that every connected device behaved honestly. Rather than authenticating messages or verifying ownership of IP addresses, ARP simply accepted information provided by neighboring hosts.

When a workstation receives an ARP Reply stating that a particular IPv4 address corresponds to a specific MAC address, the operating system generally updates its ARP cache without attempting to verify the claim. In many implementations, this update occurs even if the host never transmitted the corresponding ARP Request.

From an efficiency standpoint, this behavior is advantageous. Devices can quickly update neighbor information, routers can perform seamless failover using Gratuitous ARP, and virtual machines can migrate between physical hosts without disrupting communication.

From a security perspective, however, this implicit trust presents a serious problem.

Because ARP provides no authentication mechanism, any device connected to the local broadcast domain can claim ownership of almost any IPv4 address. Unless network infrastructure actively validates ARP messages, neighboring systems have little basis for distinguishing legitimate announcements from malicious ones.

This weakness forms the basis of ARP cache poisoning, also known as ARP spoofing.

An attacker connected to the same Ethernet segment can transmit forged ARP Replies claiming that another device’s IPv4 address is associated with the attacker’s MAC address. If neighboring hosts accept the forged mapping, they begin forwarding Ethernet frames to the attacker instead of the legitimate destination.

Depending on the attacker’s objectives, the intercepted traffic may be observed, modified, forwarded, selectively discarded, or redirected toward other systems. The attacker effectively inserts themselves into the communication path without exploiting software vulnerabilities or compromising either endpoint directly.

The attack succeeds not because of a programming error but because the protocol itself was never designed to verify identity.

ARP Spoofing (ARP Cache Poisoning)

ARP spoofing, often referred to as ARP cache poisoning, exploits ARP’s trust model by deliberately distributing false IP-to-MAC mappings throughout the local network. Unlike attacks that target software vulnerabilities or authentication mechanisms, ARP spoofing manipulates the information that hosts use to deliver Ethernet frames.

Consider a workstation communicating with its default gateway.

Initially, the workstation’s ARP cache contains the legitimate mapping:

192.168.10.1
↓
3C:52:82:AA:19:10

where 192.168.10.1 represents the gateway and 3C:52:82:AA:19:10 is its actual MAC address.

Now suppose an attacker joins the same broadcast domain with the MAC address:

00:11:22:33:44:55

The attacker repeatedly broadcasts forged ARP Replies stating:

192.168.10.1 is at 00:11:22:33:44:55

If the workstation accepts this information, its ARP cache changes accordingly.

192.168.10.1
↓
00:11:22:33:44:55

From this point onward, Ethernet frames intended for the gateway are delivered to the attacker’s machine.

If the attacker simply discards these packets, communication fails, resulting in a denial-of-service condition.

More commonly, however, the attacker enables packet forwarding and relays every intercepted packet to the legitimate gateway after examining or modifying its contents. Because communication continues uninterrupted, users often remain unaware that another system has inserted itself into the communication path.

To establish a complete man-in-the-middle position, attackers typically poison both participants.

The victim workstation is informed that the gateway’s IPv4 address belongs to the attacker’s MAC address.

Simultaneously, the gateway receives forged ARP Replies claiming that the victim workstation’s IPv4 address also belongs to the attacker.

The resulting communication path becomes:

Victim
   │
   ▼
Attacker
   │
   ▼
Gateway

Neither endpoint realizes that Ethernet frames are now passing through an intermediate system because the attacker transparently forwards packets after processing them.

This attack demonstrates why ARP’s lack of authentication remains one of the most significant security weaknesses in traditional Ethernet networks. The protocol faithfully performs exactly as designed, yet that design allows malicious hosts to influence how neighboring systems deliver traffic.

What an Attacker Can Do After ARP Poisoning

Successfully poisoning an ARP cache does not immediately compromise a system or decrypt encrypted communications. Instead, it changes the path that Ethernet frames follow within the local network. Rather than communicating directly with the intended destination, the victim unknowingly sends traffic to the attacker’s system, which then decides how that traffic should be handled.

The simplest outcome is a denial-of-service (DoS) attack. If the attacker receives packets but never forwards them to the legitimate destination, communication fails. From the victim’s perspective, the network appears unavailable even though the underlying infrastructure remains operational.

More commonly, attackers configure their systems to forward packets after inspecting them. This creates a transparent man-in-the-middle (MITM) position in which both communicating hosts continue exchanging data while every frame passes through the attacker’s machine.

The impact of such an attack depends largely on the protocols being used.

Applications that transmit information without encryption remain particularly vulnerable. Legacy protocols such as Telnet, FTP, HTTP, POP3, IMAP without TLS, and certain industrial control protocols exchange information in plaintext. An attacker positioned between the communicating hosts may therefore observe usernames, passwords, session identifiers, commands, emails, application data, or other sensitive information directly from captured packets.

Modern enterprise environments increasingly rely on encrypted protocols such as HTTPS, SSH, TLS-secured email, VPN technologies, and secure remote management solutions. Properly implemented encryption prevents an attacker from reading the protected application payload, even if every packet traverses the attacker’s system. This significantly reduces the effectiveness of passive interception.

Nevertheless, ARP poisoning remains a valuable technique because occupying the communication path provides opportunities beyond simple eavesdropping.

An attacker may selectively block packets to disrupt communication, manipulate unprotected traffic, redirect users toward malicious infrastructure by interfering with unsecured DNS traffic, or collect valuable metadata describing communication patterns within the organization. Even when encryption protects the payload itself, information such as source and destination addresses, communication frequency, protocol usage, and timing may still assist subsequent phases of an intrusion.

Consequently, ARP spoofing should not be viewed solely as a credential theft technique. It is better understood as a mechanism for controlling network traffic within a local broadcast domain.

Detecting ARP Spoofing

Because ARP poisoning occurs entirely within the local Ethernet segment, traditional perimeter firewalls are generally unable to detect it. Effective detection instead requires visibility into Layer 2 communication, either through packet analysis, switch monitoring, endpoint telemetry, or network intrusion detection systems capable of inspecting ARP traffic.

One of the clearest indicators of ARP poisoning is an unexpected change in the MAC address associated with a well-known IPv4 address.

For example, a default gateway typically maintains the same MAC address over long periods. If multiple workstations suddenly report different MAC addresses for the gateway without any planned maintenance or failover event, administrators should investigate the possibility of ARP cache poisoning.

Another common indicator is the repeated transmission of unsolicited ARP Replies. Under normal operating conditions, ARP traffic is relatively infrequent. Requests occur when address resolution is required, and replies generally follow immediately. During an ARP poisoning attack, however, the attacker often sends forged ARP Replies at regular intervals to ensure that malicious mappings remain in victims’ ARP caches. This repeated advertising of the same IP-to-MAC association differs noticeably from ordinary network behavior.

Wireshark is particularly useful during such investigations. When capturing traffic on the affected subnet, analysts may observe multiple ARP Replies claiming ownership of the same IPv4 address but advertising different MAC addresses. Such conflicts often indicate either duplicate IP address configuration or deliberate spoofing.

Managed switches and intrusion detection systems may also generate alerts when conflicting ARP mappings are observed. Although these alerts require validation because legitimate events such as router failover can temporarily produce similar behavior, they provide valuable starting points for incident response.

Endpoint monitoring can provide additional evidence. Some operating systems and endpoint security products warn users or administrators when the MAC address associated with a previously trusted gateway changes unexpectedly. While these warnings should not automatically be interpreted as malicious activity, they should always be investigated to determine whether the change resulted from planned infrastructure maintenance or unauthorized network activity.

Mitigating ARP-Based Attacks

Because ARP itself contains no authentication mechanism, securing the protocol requires protections implemented elsewhere in the network. Modern enterprise environments therefore rely on managed switches, access control mechanisms, segmentation, and encryption rather than attempting to modify the protocol itself.

One of the most effective infrastructure-based defenses is Dynamic ARP Inspection (DAI). Available on many enterprise Ethernet switches, DAI validates ARP packets before forwarding them to other devices. Rather than accepting every ARP Reply, the switch compares the advertised IP-to-MAC mapping against a trusted database of known bindings.

This trusted database is commonly created through DHCP Snooping.

DHCP Snooping allows the switch to observe DHCP exchanges and record which MAC address received each IPv4 address from the DHCP server. When an ARP Reply later claims ownership of an IPv4 address, DAI compares the advertised MAC address with the corresponding DHCP binding. If the information does not match, the switch discards the forged packet before it reaches neighboring hosts.

The relationship between these technologies is important. DHCP Snooping establishes trusted IP-to-MAC bindings, while Dynamic ARP Inspection uses those bindings to validate ARP traffic. Together they provide a highly effective defense against traditional ARP cache poisoning attacks in DHCP-managed networks.

Another defensive measure involves the use of static ARP entries for critical infrastructure. Because manually configured mappings cannot be overwritten through unsolicited ARP Replies, they effectively eliminate ARP spoofing for those specific systems. However, maintaining static entries across hundreds or thousands of hosts quickly becomes impractical. Every hardware replacement, virtual machine migration, or network redesign requires manual updates, making static ARP suitable only for a limited number of highly critical devices.

Network segmentation provides another important layer of protection. Since ARP traffic never traverses routers, dividing an organization into multiple VLANs or routed subnets limits the scope of both reconnaissance and ARP spoofing. An attacker who compromises a workstation in one VLAN cannot directly poison ARP caches belonging to systems located in another broadcast domain.

Organizations further strengthen Layer 2 security through technologies such as IEEE 802.1X port-based authentication, Network Access Control (NAC), switch port security, and continuous network monitoring. These controls reduce the likelihood that unauthorized devices can join the network in the first place, thereby limiting opportunities to launch ARP-based attacks.

Finally, widespread adoption of encrypted application protocols provides an important defense in depth. Even if an attacker succeeds in redirecting traffic through their system, properly implemented TLS, SSH, IPsec, and VPN technologies prevent the attacker from reading or modifying protected application data without exploiting additional weaknesses.

No single mitigation completely eliminates the risk posed by ARP. Instead, effective protection results from combining secure network infrastructure, segmentation, authenticated access, encryption, and continuous monitoring.

ARP and IPv6: Why Neighbor Discovery Replaced ARP

Although ARP remains indispensable in IPv4 networking, it is not used by IPv6. Instead, IPv6 employs the Neighbor Discovery Protocol (NDP), defined in RFC 4861, to perform many of the same functions.

Like ARP, Neighbor Discovery resolves Layer 3 addresses into Layer 2 addresses, enabling hosts to communicate across Ethernet networks. However, NDP extends beyond simple address resolution. It also supports router discovery, neighbor reachability detection, duplicate address detection, and prefix discovery, consolidating several IPv4 mechanisms into a single protocol suite.

Another significant difference is that NDP relies primarily on ICMPv6 multicast rather than Ethernet broadcasts. Instead of transmitting requests to every device on the subnet, Neighbor Solicitation messages are delivered only to multicast groups that include potential recipients. This approach reduces unnecessary network traffic, particularly on larger LANs.

From a security perspective, however, IPv6 does not eliminate all Layer 2 concerns. Basic Neighbor Discovery, like ARP, does not authenticate messages by default and is therefore susceptible to spoofing attacks.

To address this limitation, IPv6 defines Secure Neighbor Discovery (SEND) in RFC 3971, which introduces cryptographic protections using Cryptographically Generated Addresses (CGAs) and digital certificates. SEND enables devices to verify the authenticity of Neighbor Discovery messages before accepting them.

Despite its technical advantages, SEND has seen relatively limited deployment. The additional complexity, certificate management requirements, and inconsistent vendor support have limited widespread adoption in enterprise environments. Consequently, organizations continue to rely heavily on infrastructure-based security controls such as switch protections, segmentation, and access control even within IPv6 networks.

Understanding the relationship between ARP and Neighbor Discovery is valuable because it illustrates how networking protocols have evolved. Rather than abandoning address resolution altogether, IPv6 replaces ARP with a more comprehensive mechanism while preserving the fundamental requirement that hosts must still discover one another’s Layer 2 addresses before communication can begin.

Common Misconceptions About ARP

Because ARP is introduced early in networking education, several misconceptions frequently persist even among experienced practitioners.

One common misunderstanding is that ARP resolves the MAC address of any destination host, including Internet servers. In reality, ARP resolves only the MAC address of devices located within the local broadcast domain. When communicating with remote networks, hosts resolve the MAC address of the default gateway rather than the final destination.

Another misconception is that routers forward ARP traffic. They do not. ARP Requests are Ethernet broadcasts, and routers intentionally do not forward Layer 2 broadcast frames between networks. This behavior is precisely why ARP scanning and ARP spoofing are confined to individual broadcast domains.

It is also frequently assumed that MAC addresses cannot be changed because they are assigned by hardware manufacturers. While every network interface is manufactured with a unique hardware address, modern operating systems, hypervisors, and virtual networking platforms routinely support MAC address modification or randomization. Consequently, MAC addresses should never be considered proof of identity.

A further misconception is that ARP poisoning automatically defeats encryption. Redirecting traffic through an attacker’s system does not bypass properly implemented TLS, SSH, IPsec, or VPN encryption. ARP poisoning changes the network path, but encryption continues to protect application-layer data unless additional vulnerabilities are exploited.

Recognizing these distinctions helps prevent incorrect assumptions during both network troubleshooting and security assessments.

Summary

The Address Resolution Protocol is one of the smallest protocols in the TCP/IP suite, yet it performs one of the most important functions in IPv4 networking. Every Ethernet-based IPv4 communication begins with the same fundamental requirement: before a host can transmit an Ethernet frame, it must determine the MAC address associated with the destination IPv4 address. ARP provides this translation, allowing logical network addressing and physical Ethernet communication to operate together seamlessly.

Although the protocol appears simple, its behavior influences nearly every aspect of local network communication. Understanding ARP requires more than memorizing the exchange of requests and replies. It involves recognizing the distinction between logical and physical addressing, understanding why address resolution occurs only within a broadcast domain, appreciating how operating systems maintain neighbor caches, and recognizing the role of Gratuitous ARP and Proxy ARP in modern network operations.

The chapter also highlighted an important historical lesson in protocol design. ARP was created when local networks were generally considered trusted environments. Consequently, it includes no authentication mechanism and assumes that devices honestly advertise their IP-to-MAC mappings. While this assumption simplified implementation and minimized protocol overhead, it also created opportunities for attackers to manipulate address resolution through ARP cache poisoning and man-in-the-middle attacks.

Fortunately, modern enterprise networks provide several layers of defense against these weaknesses. Technologies such as DHCP Snooping, Dynamic ARP Inspection (DAI), IEEE 802.1X, Network Access Control (NAC), VLAN segmentation, and pervasive application-layer encryption significantly reduce the effectiveness of ARP-based attacks. At the same time, packet analyzers such as Wireshark and endpoint monitoring tools enable administrators and incident responders to observe ARP behavior directly, making it easier to identify connectivity issues, duplicate IP address conflicts, and suspicious Layer 2 activity.

Although IPv6 replaces ARP with the Neighbor Discovery Protocol, the underlying principle remains unchanged: communication on a local network still requires a reliable mechanism for mapping logical addresses to physical network interfaces. For this reason, a thorough understanding of ARP provides an excellent foundation for studying Ethernet switching, Layer 2 security, network troubleshooting, IPv6 Neighbor Discovery, and advanced enterprise networking.

Whether you are designing networks, troubleshooting connectivity problems, performing security assessments, or responding to incidents, ARP remains one of the most fundamental protocols you will encounter. Mastering its operation provides valuable insight into how local networks function and why seemingly simple protocols continue to influence both network performance and cybersecurity decades after their introduction.

Key Takeaways

Before moving on to the next protocol, it is worth reinforcing the most important concepts introduced in this chapter:

• ARP maps IPv4 addresses to MAC addresses. It enables Ethernet devices to determine the correct hardware destination for locally delivered packets.
• ARP operates only within the local broadcast domain. Routers do not forward ARP Requests, which is why address resolution is confined to a single Layer 2 network.
• ARP Requests are broadcast, while ARP Replies are typically unicast. This design minimizes unnecessary network traffic once the sender’s MAC address is known.
• Operating systems maintain temporary ARP caches (or neighbor tables) to reduce repeated broadcasts and improve communication efficiency.
• Gratuitous ARP is used for legitimate purposes such as duplicate address detection, high-availability failover, and virtual machine migration, but it can also be abused during ARP spoofing attacks.
• Proxy ARP allows routers to answer ARP Requests on behalf of other devices, although it is less common in modern enterprise networks.
• ARP provides no authentication. This design enables attacks such as ARP cache poisoning and man-in-the-middle interception if additional network protections are absent.
• Enterprise networks mitigate ARP attacks using technologies such as DHCP Snooping, Dynamic ARP Inspection, segmentation, Network Access Control, and encrypted application protocols.
• IPv6 does not use ARP. Instead, it employs the Neighbor Discovery Protocol (NDP), which performs similar functions using ICMPv6.

Together, these concepts form the foundation for understanding local network communication and many of the Layer 2 attacks and defenses encountered in enterprise cybersecurity.

FAQs

Practical Exercises

The following exercises reinforce the concepts presented throughout this chapter. They are designed to encourage observation of normal ARP behavior before exploring its security implications. All practical activities should be performed only on systems and networks that you own or have explicit authorization to test.

Exercise 1: Examine the Local ARP Cache

On a Windows system, display the ARP cache using:

arp -a

On a modern Linux system, display the neighbor table using:

ip neigh

Identify the entry corresponding to your default gateway and compare the reported MAC address with the MAC address shown on the gateway itself, if available. Observe whether the operating system classifies entries as dynamic, reachable, or stale.

Exercise 2: Observe ARP Traffic with Wireshark

Start a packet capture using Wireshark and apply the following display filter:

arp

Next, clear the ARP cache or communicate with a device that has not been contacted recently. Observe the ARP Request followed by the corresponding ARP Reply. Expand the packet fields and identify:

• Sender MAC Address
• Sender IPv4 Address
• Target MAC Address
• Target IPv4 Address
• Operation Code
• Ethernet EtherType (0x0806)

Relating the captured packet to the protocol fields discussed earlier in the chapter provides an excellent understanding of how address resolution occurs on the wire.

Exercise 3: Compare Legacy and Modern Linux Tools

If your Linux distribution includes both utilities, compare the output of:

arp -a

and

ip neigh

Identify the additional information provided by the modern ip neigh command, particularly the Neighbor Unreachability Detection (NUD) states.

Exercise 4: Discover Hosts on a Test Network

Using a lab environment or a network for which you have explicit authorization, perform host discovery with an ARP-based scanning tool such as arp-scan, Netdiscover, or Nmap.

Compare the discovered hosts with your operating system’s ARP cache. Determine whether the MAC address prefixes correspond to the expected hardware vendors by consulting the IEEE Organizationally Unique Identifier (OUI) registry.

Observe how ARP discovery identifies active hosts that may not respond to ICMP Echo Requests.

Exercise 5: Investigate Duplicate Address Detection

Configure a virtual machine or laboratory environment and observe what occurs when two devices attempt to use the same IPv4 address.

Capture the resulting ARP traffic in Wireshark and identify how the operating systems detect the conflict. If your platform supports it, observe the Gratuitous ARP messages generated during interface initialization or address assignment.

Exercise 6: Analyze Enterprise Switch Features

If managed Ethernet switches are available, review the configuration and documentation for DHCP Snooping and Dynamic ARP Inspection (DAI).

Identify:

• How DHCP Snooping builds trusted IP-to-MAC bindings.
• How DAI validates ARP traffic.
• Which switch ports should be configured as trusted.
• What occurs when an invalid ARP Reply is received.

Understanding how these technologies complement one another provides valuable insight into modern Layer 2 security architecture.

Exercise 7: Compare ARP with IPv6 Neighbor Discovery

Review the operation of the Neighbor Discovery Protocol (NDP) defined in RFC 4861.

Identify the similarities and differences between ARP and NDP, paying particular attention to:

• Address resolution
• Router discovery
• Duplicate address detection
• Broadcast versus multicast communication
• Security mechanisms such as Secure Neighbor Discovery (SEND)

Understanding these differences provides a strong foundation for transitioning from IPv4 networking to IPv6.

Looking Ahead

ARP demonstrates that even a relatively simple protocol can have far-reaching implications for network performance, troubleshooting, and cybersecurity. By understanding how devices discover one another at Layer 2, you have established an essential foundation for more advanced topics, including Ethernet switching, VLANs, routing, IPv6 Neighbor Discovery, and Layer 2 attack detection.

The concepts introduced in this chapter also underpin many penetration testing techniques and defensive monitoring strategies. Whether analyzing packet captures, investigating suspicious network behavior, or designing resilient enterprise infrastructures, a solid understanding of ARP remains indispensable for networking and cybersecurity professionals.