ARP - Address Resolution Protocol. How the network maps IP to MAC and how this mechanism is attacked (RFC 826)

The Address Resolution Protocol (ARP) is one of the oldest Internet protocols. The specification was written by David C. Plummer at MIT and published in November 1982 as RFC 826. Since then the protocol itself has barely evolved - its deep simplicity is both a strength (universality) and a weakness (no security mechanisms).

ARP bridges two layers of the OSI model: when an IPv4 host wants to send a packet to an IP address on its local network, it must first determine the MAC address corresponding to that IP. Without it the Ethernet switch would not know which port to forward the frame to.

ARP frame structure

ARP is encapsulated directly in an Ethernet frame with EtherType 0x0806. Packet format:

Field	Length	Purpose
Hardware Type	2 bytes	Network type (1 = Ethernet)
Protocol Type	2 bytes	L3 protocol type (0x0800 = IPv4)
Hardware Length	1 byte	MAC address length (6 for Ethernet)
Protocol Length	1 byte	L3 address length (4 for IPv4)
Operation	2 bytes	Operation code (1 = Request, 2 = Reply, 3/4 = RARP)
Sender Hardware Address	6 bytes	Sender MAC
Sender Protocol Address	4 bytes	Sender IP
Target Hardware Address	6 bytes	Target MAC (zeros in Request)
Target Protocol Address	4 bytes	Target IP

The packet is 28 bytes; including the Ethernet header - 42 bytes. The minimum Ethernet frame is 64 bytes, so ARP is padded with zeros up to that size.

The exchange

Typical scenario: host 192.168.1.10 wants to send a packet to 192.168.1.20.

The host checks its ARP table. If there is no entry for 192.168.1.20, it sends an ARP Request as a broadcast (destination MAC = FF:FF:FF:FF:FF:FF): “Who has 192.168.1.20? Tell 192.168.1.10”.
All hosts in the segment receive the request. The host with IP 192.168.1.20 answers with a unicast ARP Reply: “192.168.1.20 is at MAC AA:BB:CC:DD:EE:FF”.
The originating host stores the mapping in its ARP table (typically for 20-300 seconds) and sends the packet.

ARP variants

Gratuitous ARP (GARP) - a host sends an ARP Request or Reply with its own IP as the target. Uses: duplicate address detection, announcing takeover of a virtual address (VRRP, HSRP, cluster failover), refreshing neighbours’ ARP tables.

Proxy ARP (RFC 1027) - a router answers ARP Requests for IP addresses located on another network, impersonating the end host. Historically used for bridging between segments without routing configuration. Today considered bad practice - it complicates topology and hinders diagnostics.

Reverse ARP (RARP, RFC 903) - the reverse operation: the host knows its MAC and asks for its IP. Superseded by BOOTP and DHCP.

Inverse ARP (InARP, RFC 2390) - used in Frame Relay and ATM to map a layer 2 DLCI to a neighbour’s IP address. Irrelevant in Ethernet networks.

ARP for IPv6? NDP

There is no ARP in IPv6. Its role is taken over by the Neighbor Discovery Protocol (NDP, RFC 4861) based on ICMPv6. NDP inherits almost all of ARP’s security problems in a new form - details in the article IPv6 (RFC 8200).

ARP poisoning - the fundamental attack

WARNING

ARP does not verify whether the responding host is actually the owner of the requested IP address. Any host in the segment can send an ARP Reply with arbitrary content. This property has been known for decades but will never be fixed at the protocol level - ARP will remain the way it is.

ARP poisoning (ARP spoofing) consists of sending forged ARP replies that mislead the victims’ ARP tables:

The attacker sends to victim A: “Gateway 192.168.1.1 is at the attacker’s MAC”
The attacker sends to the gateway: “Victim 192.168.1.X is at the attacker’s MAC”
All traffic between A and the gateway flows through the attacker

Consequences:

Man-in-the-middle - the attacker sees all traffic and can modify it
SSL stripping - combined with tools such as mitmproxy, it can decrypt HTTPS when clients are misconfigured
Session hijacking - hijacking unencrypted sessions (Telnet, FTP, HTTP)
DoS - cutting off communication by directing traffic into the void

Tools: Ettercap, arpspoof (dsniff), Cain & Abel (historical), bettercap, Responder (combined with other techniques).

Defence against ARP poisoning

Mechanism	Effect
Dynamic ARP Inspection (DAI)	The switch verifies every ARP against the DHCP Snooping table - blocks forged IP/MAC pairs
DHCP Snooping	The switch tracks legitimate DHCP leases, building a table of trusted IP/MAC pairs
Port Security	Limits the number of MACs per port, blocks floods
Static ARP entries	Permanent ARP entries on critical devices (router, server) - immune to poisoning
ARP Monitoring	Tools such as arpwatch, XArp detect changes in IP/MAC mapping and raise alerts
802.1X + MACsec	Port authentication and encryption eliminate the vector - the attacker can neither eavesdrop nor send on the network

TIP

In OT environments, static ARP entries on PLCs and HMI stations are a realistic defence. Devices do not change their IP during operation and the ARP table does not age out. This is more reliable than DAI in networks without DHCP.

ARP in operational practice

# Linux - show ARP table
ip neighbor show
arp -a                        # classic

# Windows - show ARP table
arp -a

# Clear the table
sudo ip -s -s neigh flush all  # Linux
netsh interface ip delete arpcache  # Windows

# Wireshark filter
arp
arp.opcode == 2               # Reply only
arp.duplicate-address-detected

Wireshark automatically flags suspicious patterns - duplicates, conflicting entries, rapid-fire replies - with a red frame and the label “duplicate IP address”.

ARP traffic and attack samples:

automayt/ICS-pcap - includes ARP samples in ICS network context
Orange-Cyberdefense/awesome-industrial-protocols - references to L2 tools

ARP in OT networks

OT networks, particularly in older substations and production lines, often run with a flat L2 topology - many PLCs, HMI panels and engineering workstations in a single segment. In such an architecture ARP poisoning is trivial and the consequences catastrophic - MITM between an HMI and a PLC enables unauthorised modification of controller code.

Recommendations for OT architects:

Microsegmentation - groups of 5-10 devices in a single VLAN, routing between them through a firewall
Static ARP entries on PLCs and HMIs for critical addresses (engineering workstation, historian server)
DAI on industrial switches supporting the feature (Hirschmann, Moxa, Cisco IE)
ARP monitoring - arpwatch or dedicated systems (Claroty, Nozomi) detect unusual IP/MAC pairs
No DHCP in OT segments - static addressing eliminates the DHCP attack surface and enables DAI

Summary

ARP is an intrinsically insecure protocol. Fixing it at the specification level is impractical - it would require replacing every IPv4 host in every network. Instead, defence relies on supplementing the protocol with infrastructure layer mechanisms (DAI, DHCP Snooping, 802.1X) and with network architecture (segmentation). In OT environments, static ARP entries remain the most reliable defence available even on the oldest equipment.

Sources

RFC 826 - An Ethernet Address Resolution Protocol - original specification (1982)
RFC 1027 - Using ARP to Implement Transparent Subnet Gateways - Proxy ARP
RFC 5227 - IPv4 Address Conflict Detection - duplicate IP detection
Cisco - Dynamic ARP Inspection Configuration - DAI implementation
arpwatch - classic ARP monitoring tool