Address Resolution Protocol and Reverse Address Resolution Protocol

Ethernet hardware forwards traffic using MAC addresses. Suppose a machine on an Ethernet network wants to send an IPv4 packet to another machine on the same LAN. The sender knows the target IPv4 address, but it must learn the target MAC address. ARP provides a simple request/reply exchange:

1. ARP Request (broadcast): “Who has IPv4 address 192.0.2.8? Tell 192.0.2.2.”
2. ARP Reply (unicast): “192.0.2.8 is at aa:bb:cc:dd:ee:ff.”

The sender stores the result in the ARP cache (Linux: the neighbor table) for a short time so it does not need to broadcast again for every packet.

View and troubleshoot ARP on Linux

• Preferred (modern): inspect the neighbor/ARP table with ip neigh show, flush entries with ip neigh flush all, and watch changes with ip monitor neigh.
• Legacy: arp -a still exists on some systems, but many distros prefer iproute2 tooling.
• Probing: arping <ipv4-address> can validate that a host responds on the LAN and that resolution is working.

ARP Advice: Sometimes ARP/neighbor output is the fastest way to confirm a device’s L2 identity on a LAN. For example, some older UNIX workflows relied on ifconfig (legacy) for interface settings but used the ARP cache to confirm discovered MAC addresses. On modern Linux, prefer ip link / ip addr for interface details.

ARP spoofing and practical defenses

• What it is: In ARP spoofing/poisoning, an attacker sends forged ARP replies so victims map a legitimate IPv4 address to the attacker’s MAC address, enabling interception (MITM) or disruption (DoS).
• What to look for: frequent ARP table changes, duplicate IPs mapping to different MACs, or a “gateway IP” suddenly resolving to an unexpected MAC.
• Mitigations (real-world):
  • Switch controls: Dynamic ARP Inspection (DAI), DHCP snooping, port security (enterprise networks).
  • Host-side: static neighbor/ARP entries for critical systems (carefully managed), monitoring tools such as arpwatch, and tighter L2 segmentation.
  • Design: reduce broadcast domains (VLANs), enforce least-privilege access, and prefer encrypted app protocols so sniffed traffic is less useful.

ARP is also a standard feature across IP-capable network stacks and devices, often including options such as static entries, cache timeouts, cache clearing, and (in some environments) proxy ARP.

RARP was designed for the reverse problem: given a machine’s Ethernet (MAC) address, discover its IP address at boot. Historically, this was used by diskless workstations that needed an IP configuration before higher-level services could load.

Modern status: RARP is obsolete. In practical modern networks, the same outcome is achieved with DHCP (or historically BOOTP), often combined with PXE/iPXE for network boot.

A classic RARP “question” looks like: “My Ethernet address is aa:bb:cc:dd:ee:ff; what is my IP address?” The reply would come from an RARP server that maintained MAC-to-IP mappings.

Legacy implementations stored mappings in files such as /etc/ethers (platform-dependent). In modern environments, the authoritative mapping is typically held by the DHCP server (and optionally documented in IPAM).

Legacy example output (for illustration only):

3ffe:1900:4545:3:200:f8ff:fe21:67cf

Note: the address above is IPv6-formatted. RARP itself is an older, Ethernet-era mechanism associated with early IP boot workflows. For IPv6 bootstrapping and neighbor resolution, modern networks use DHCPv6/SLAAC and Neighbor Discovery (NDP).

Conclusion: ARP is a core IPv4 LAN mechanism that maps IPv4 addresses to MAC addresses so frames can be delivered locally. RARP is largely historical and has been replaced by DHCP-based provisioning and network boot tooling. As a Linux network administrator, your day-to-day workflow is usually: verify local addressing, inspect ip neigh, validate ARP/NDP behavior, and apply controls that reduce spoofing risk.