Address Resolution Protocol (ARP) is a network protocol used to map a known IPv4 address to a MAC (hardware) address on a local Ethernet or Wi-Fi segment. It is not a standard OSI protocol but is commonly described as sitting between the data-link and network layers (Layers 2 and 3), and is defined in RFC 826.
In practice
In embedded systems with Ethernet or Wi-Fi connectivity, ARP is a required component of any IPv4 network stack that operates over Ethernet-like LANs. When a device needs to send an IP packet to another host on the same subnet, it must first resolve that host's MAC address. If the address is not already cached, the sender broadcasts an ARP Request frame to the local segment; the target host replies with a unicast ARP Reply containing its MAC address. The sender stores this mapping in an ARP cache for a period of time to avoid repeated lookups. Note that point-to-point links and certain non-Ethernet encapsulations do not use ARP even when running IPv4.
Embedded TCP/IP stacks such as lwIP, uIP, and FreeRTOS+TCP all include ARP implementations. The ARP cache in these stacks is typically small, often holding only 4 to 16 entries, which is usually sufficient for constrained devices that communicate with a gateway and a handful of peers. Cache size is often a configurable parameter; on memory-limited targets, setting it too small can cause frequent re-resolution and added latency, though the right size is highly stack- and traffic-pattern-dependent and any specific numbers should be treated as illustrative examples.
A common pitfall on embedded targets is ARP cache timeout mismanagement. If a peer's IP address is reassigned (for example, by a DHCP server) while a stale ARP entry remains in cache, packets will be sent to the wrong MAC address until the entry expires or is evicted. Another issue arises during bring-up: a device that sends IP traffic before completing ARP resolution will silently drop packets, which can look like an IP-layer or routing problem rather than a Layer 2 issue.
Gratuitous ARP is a special case where a device announces its own IP-to-MAC mapping without being asked, typically sent at boot to update other hosts' caches and detect IP address conflicts. Some embedded stacks support this; others do not, so address-conflict detection may require explicit application-level handling or reliance on DHCP conflict detection instead.
Frequently asked
Does ARP work with IPv6?
No. IPv6 uses Neighbor Discovery Protocol (NDP) instead of ARP for address resolution. NDP is carried over ICMPv6 and also covers additional functions such as router discovery and prefix discovery. If your embedded
stack supports IPv6, it must implement NDP rather than ARP for neighbor address resolution.
Why does my embedded device stop communicating after a network change even though its IP is correct?
A stale ARP
cache entry is a common cause. If a gateway or peer has changed its
MAC address (for example, after hardware replacement or a
DHCP lease reassignment), the cached mapping becomes invalid. Forcing an ARP cache flush or waiting for the entry to expire typically restores communication.
How large should the ARP cache be on a constrained microcontroller?
It depends on the number of peers the device communicates with simultaneously. Many lwIP-based designs default to 10 entries (ARP_TABLE_SIZE in lwipopts.h). For a device that only talks to a single gateway and one or two servers, 4 to 8 entries is generally sufficient. Setting it too small increases ARP traffic and
latency; setting it too large wastes
RAM.
What is a gratuitous ARP and when should an embedded device send one?
A gratuitous ARP is an unsolicited ARP Reply (or Request with sender IP equal to target IP) that a host sends to announce its own IP-to-MAC mapping. Embedded devices commonly send one at network bring-up to update peers' caches and to detect IP address conflicts. Not all lightweight stacks send gratuitous ARPs by default, so check your
stack's documentation.
Can ARP be a security concern on embedded devices?
Yes. ARP has no authentication, making it vulnerable to ARP spoofing, where a malicious host sends forged ARP Replies to redirect traffic. On isolated industrial or sensor networks this is often an acceptable risk, but devices deployed on shared or untrusted networks should consider using static ARP entries for critical peers or operating behind a gateway that enforces isolation.
Differentiators vs similar concepts
ARP is sometimes confused with DNS: DNS resolves human-readable hostnames to IP addresses (Layer 3), while ARP resolves IP addresses to
MAC addresses (Layer 2). They solve different problems at different layers and are both typically needed for a device to reach an internet host by name. ARP is also distinct from RARP (Reverse ARP) and its modern successor
DHCP, which go in the opposite direction and assign IP addresses to devices based on their MAC addresses.
