ARP and MAC Address
ARP and MAC Address
Definition: A MAC address is a permanent 48-bit hardware identifier assigned to a network interface; the Address Resolution Protocol (ARP) resolves Layer 3 IP addresses to Layer 2 MAC addresses so frames can be delivered on a local network.
How It Works
A MAC address is burned into the network interface card (NIC) at manufacture, though most OSes let you override it in software (MAC spoofing/randomization, now common on phones and laptops for Wi-Fi privacy). It’s written as six hex octets separated by colons or dashes, e.g. AA:BB:CC:DD:EE:FF. The first three octets are the Organizationally Unique Identifier (OUI), assigned by the IEEE to the manufacturer (Apple, Intel, Cisco, etc.); the last three are a serial number the vendor assigns, together guaranteeing (in theory) global uniqueness.
ARP solves a specific handoff problem: IP routing decides where a packet needs to go logically, but Ethernet switches only understand MAC addresses, they have no concept of an IP address at all. Before a host can put a packet on the wire, it needs the destination’s (or the next-hop router’s) MAC address.
The resolution sequence:
- Host A wants to send to IP
192.168.1.5, which its subnet mask tells it is on the same local segment. - Host A checks its local ARP cache. If there’s no entry, it broadcasts an ARP Request frame (destination MAC
FF:FF:FF:FF:FF:FF, so every NIC on the segment receives and processes it): “Who has 192.168.1.5? Tell 192.168.1.10.” - Every host on the local segment receives the broadcast and inspects it, but only the owner of
192.168.1.5replies, unicast, with an ARP Reply containing its MAC address. - Host A caches the mapping (IP -> MAC) in its ARP table for a limited time (commonly 60 seconds to a few minutes, OS-dependent) so it doesn’t have to broadcast again for every packet.
- If the destination is on a different subnet, the host ARPs for its default gateway’s MAC address instead, sends the frame to the gateway’s MAC (but keeps the original destination IP inside), and the gateway handles routing from there, rewriting the Layer 2 addressing at each hop while the Layer 3 addressing stays constant end-to-end.
Hosts also send gratuitous ARP, an unsolicited announcement of their own IP-to-MAC mapping, typically right after boot or an IP change, so neighbors update their caches proactively and to detect IP address conflicts (if another host replies claiming the same IP, that’s a collision).
Under the Hood
The ARP packet format (RFC 826), when carried in an Ethernet frame with EtherType 0x0806:
| Field | Size | Purpose |
|---|---|---|
| Hardware type | 2 bytes | 1 = Ethernet |
| Protocol type | 2 bytes | 0x0800 = IPv4 |
| Hardware address length | 1 byte | 6 (MAC) |
| Protocol address length | 1 byte | 4 (IPv4) |
| Opcode | 2 bytes | 1 = request, 2 = reply |
| Sender MAC | 6 bytes | |
| Sender IP | 4 bytes | |
| Target MAC | 6 bytes | all zero in a request |
| Target IP | 4 bytes |
A MAC address’s first byte encodes two flags in its low-order bits: the I/G bit (individual vs group/multicast address) and the U/L bit (universally administered vs locally administered, i.e. vendor-burned vs software-set). Broadcast (FF:FF:FF:FF:FF:FF) and multicast frames (e.g. 01:00:5E:xx:xx:xx for IPv4 multicast, derived directly from the target multicast IP) rely on this bit being set, letting a NIC’s hardware filter recognize “this frame is addressed to a group I should still process” without CPU involvement.
IPv6 doesn’t use ARP at all. It replaces it with Neighbor Discovery Protocol (NDP), which runs over ICMPv6 and uses multicast Neighbor Solicitation/Neighbor Advertisement messages (sent to a solicited-node multicast address derived from the target’s IPv6 address) instead of a broadcast to every host. This is more efficient on switched networks, avoids waking every device on the segment for every resolution, and NDP additionally folds in router discovery and duplicate address detection, jobs IPv4 split across ARP, ICMP router discovery, and DHCP.
Switches build their own mapping, the MAC address (forwarding/CAM) table, by inspecting the source MAC of every frame they see on each port, a process called MAC learning, entirely separate from ARP. ARP resolves IP-to-MAC at the host; the switch’s table resolves MAC-to-port for frame forwarding. A frame for an unknown destination MAC gets flooded out every port (except the one it arrived on) until the switch learns where that MAC actually lives.
ARP has no authentication, no sequence numbers, and no way to verify a reply actually came from the IP owner it claims to represent, a deliberate simplicity trade-off from an era (1982) when local networks were assumed trustworthy.
Why It Matters
ARP is the glue between the logical addressing IP routing depends on and the physical addressing Ethernet switching depends on. Without it, a host would have no way to translate “send to this IP” into “send to this physical interface.” Every LAN packet, even ones ultimately destined for the internet, starts with an ARP resolution to find the next hop’s MAC address, whether that’s the final destination or the default gateway.
MAC addresses also matter beyond ARP: switches use them for VLAN and port security policies, DHCP servers commonly use them to hand out consistent (sticky) IP leases, and wireless networks use randomized MAC addresses specifically to prevent third parties from tracking a device’s movement across different Wi-Fi networks by its fixed hardware identifier.
Common Pitfalls
- ARP spoofing (ARP cache poisoning): an attacker sends unsolicited, forged ARP replies claiming to own the gateway’s IP, redirecting local traffic through the attacker’s machine for a man-in-the-middle attack. Because ARP trusts any reply, this works against any host that doesn’t have static ARP entries or ARP inspection enabled.
- Assuming ARP works across subnets. It’s strictly a local-link protocol; it never crosses a router, which is exactly why routers exist as the boundary where Layer 2 broadcast domains end.
- Stale ARP cache entries after a NIC replacement or a failover event (e.g. VRRP/HSRP virtual-router failover), causing traffic to keep going to a dead MAC address until the cache entry expires or is manually flushed.
- Confusing “MAC address” with “device identity” or “location.” A MAC address identifies a physical interface on a segment, not a device or a person, and it can be spoofed trivially in software, it’s not a security boundary on its own.
- IP address conflicts producing ARP flux: two hosts claiming the same IP cause other hosts’ ARP tables to flap between two different MAC addresses, manifesting as intermittent connectivity that’s hard to diagnose without a packet capture.
- Overlooking gratuitous ARP’s dual use, legitimate for failover announcements, but also exactly what an ARP-spoofing tool sends, so network monitoring tools flag unexpected gratuitous ARP as a potential attack indicator.
Defenses Against ARP Spoofing
Because ARP trusts any reply by default, mitigating spoofing has to happen outside the protocol itself:
- Dynamic ARP Inspection (DAI): a switch feature that validates ARP replies against a trusted binding table (usually built from DHCP snooping records) before forwarding them, dropping anything that doesn’t match a known IP-to-MAC-to-port binding.
- Static ARP entries: manually pinning critical hosts (like a default gateway) so the OS never trusts a dynamic reply for that IP, effective but doesn’t scale past a handful of hosts.
- Port security: limiting how many, or which, MAC addresses a switch port will accept, blocking an attacker from flooding a segment with forged source addresses.
- VLAN segmentation: shrinking the broadcast domain limits how many hosts a spoofed ARP reply can actually reach.
- Monitoring tools:
arpwatchand similar utilities alert on new or changed IP-to-MAC mappings, catching spoofing attempts and legitimate hardware changes alike.
History
- ARP was defined in RFC 826 (1982), designed for early Ethernet networks where every host on a segment was assumed trustworthy, hence no authentication in the protocol.
- MAC address OUIs have been assigned by the IEEE since Ethernet’s standardization, the 48-bit space was considered generous at the time; IEEE later introduced a 64-bit EUI-64 identifier format for other addressing needs, though standard Ethernet NICs still use 48-bit MACs.
- IPv6’s Neighbor Discovery Protocol (RFC 4861, 2007) replaced ARP outright for IPv6 networks, folding in jobs ARP never handled itself, like router discovery and duplicate address detection, which IPv4 split across ARP, ICMP router discovery, and DHCP.
- Dynamic ARP Inspection and similar switch-level defenses became standard features through the 2000s, largely in response to widely available ARP-spoofing tools (dsniff, ettercap) that made local-network man-in-the-middle attacks trivial to execute.
Debugging an ARP Issue
A host that can’t reach its default gateway despite a correct IP configuration is a classic symptom to trace at the ARP layer:
ping <gateway-ip>fails or times out.arp -a(Windows/macOS) orip neigh(Linux) shows the gateway’s entry asincomplete,FAILED, or missing entirely, meaning no ARP reply was ever received for that IP.tcpdump -i eth0 arpwhile re-pinging shows whether the ARP request actually goes out on the wire, and whether any reply comes back at all, or from an unexpected MAC address.- A reply arriving from the correct IP but a MAC that doesn’t match the gateway’s known hardware address is a strong signal of ARP spoofing, not a simple connectivity failure, worth escalating rather than just clearing the cache.
ip neigh flush all(Linux) orarp -d *(Windows) clears the stale cache and forces a fresh resolution, which alone resolves cases where the gateway’s MAC legitimately changed (e.g. after a hardware swap or VRRP failover) but the old mapping was still cached.
Comparison
| ARP (IPv4) | NDP (IPv6) | RARP (legacy) | |
|---|---|---|---|
| Transport | Raw Ethernet broadcast | ICMPv6 multicast | Raw Ethernet broadcast |
| Direction | IP -> MAC | IP -> MAC (+ router discovery, duplicate detection) | MAC -> IP |
| Security | None (spoofable) | Optional SEND (cryptographically signed) | None |
| Scope | Local link only | Local link only | Local link only |
| Cache behavior | Timed expiry, per-OS default | Timed expiry, reachability confirmation built in | Timed expiry |
| Status | Standard for IPv4 LANs | Standard for IPv6 LANs | Obsolete, replaced by DHCP/BOOTP |
Example
On Windows or Linux, arp -a lists the current ARP cache: IP addresses mapped to MAC addresses for hosts you’ve recently communicated with on the local network. Running ping to a new local IP for the first time triggers an ARP request/reply pair before the ICMP echo can actually be sent, visible in a packet capture (tcpdump -i eth0 arp) as two ARP frames immediately preceding the first ICMP packet.
On a managed switch, show mac address-table shows the learned MAC-to-port mappings that let the switch avoid flooding frames to every port. Clearing a host’s ARP cache manually (arp -d * on Windows, ip neigh flush all on Linux) is a common first troubleshooting step when a host seems to be sending traffic to a MAC address that no longer answers, forcing a fresh resolution instead of waiting for the cache entry to time out naturally.
FAQ
Can two devices on the internet have the same MAC address? Yes, in theory, MAC uniqueness is only guaranteed within the same broadcast domain (local segment), not globally. Vendors sometimes reuse OUI ranges or ship duplicate addresses by mistake, it just never matters unless both devices end up on the same LAN.
Does ARP work over Wi-Fi the same way as Ethernet? Yes, ARP is link-layer-agnostic in principle, it just needs a broadcast-capable Layer 2 medium. Wi-Fi access points forward ARP broadcasts to associated clients the same way a switch forwards them to connected ports.
Why does arp -a sometimes show incomplete entries? That means an ARP request was sent but no reply came back yet, usually because the target host is offline, or a firewall is dropping the broadcast/reply.
Is a MAC address enough to identify a specific physical device? Not reliably. Software MAC randomization, virtual machines and containers generating their own MACs, and NIC replacement all break the “one device, one permanent MAC” assumption.