Loading content...
IP addresses identify where devices are in the network topology. MAC addresses identify the physical hardware on the local network. But here's the fundamental challenge: IP packets must ultimately be delivered in frames, and frames require MAC addresses.
When your laptop wants to send a packet to 192.168.1.1, it knows the destination IP—but the network interface card needs to know the destination MAC address to construct the Ethernet frame. How does the system bridge this gap?
This is the address resolution problem: translating between layer 3 (logical) addresses and layer 2 (physical) addresses. The protocols that solve this problem—ARP for IPv4 and Neighbor Discovery for IPv6—are among the most fundamental in networking, operating silently behind every packet delivery.
By the end of this page, you will understand: (1) Why address resolution is necessary for packet delivery, (2) ARP protocol operation and message format, (3) ARP caching and its role in efficiency, (4) ARP security vulnerabilities and mitigations, and (5) IPv6 Neighbor Discovery Protocol as ARP's successor.
Consider what happens when Host A wants to send an IP packet to Host B on the same local network:
What Host A knows:
192.168.1.10000:11:22:33:44:55192.168.1.50What Host A needs to know:
??:??:??:??:??:??Why IP alone isn't sufficient:
IP addresses have no physical meaning—they're assigned by software and can change. Ethernet switches don't understand IP; they forward frames based on MAC addresses. The network interface card transmits frames, not packets directly.
To deliver the packet, Host A must:
192.168.1.100Step 3 is impossible without knowing Host B's MAC address.
When Resolution is Needed:
Address resolution occurs in two scenarios:
1. Direct Delivery (Same Network) When the destination IP is on the same network (determined by subnet mask), the sender resolves the destination IP directly to a MAC address.
2. Indirect Delivery (Different Network) When the destination IP is on a different network, the sender must send the packet to its default gateway (router). It resolves the router's IP to a MAC address—not the final destination's.
In both cases, the process is the same: IP address → MAC address mapping via resolution protocol.
Address resolution only happens on the local network segment. You never resolve MAC addresses for hosts on remote networks—you can't, because remote MACs are meaningless locally. You only resolve the next hop's MAC: either the destination (if local) or the router (if remote). The router then performs its own resolution for the next segment.
The Address Resolution Protocol (ARP), defined in RFC 826, resolves IPv4 addresses to MAC addresses through a simple request-reply mechanism.
ARP Request (Broadcast):
When a host needs to resolve an IP address:
FF:FF:FF:FF:FF:FF)ARP Reply (Unicast):
The device with the requested IP address responds:
123456789101112131415161718192021222324252627282930313233343536
# Scenario: Host A (192.168.1.50) wants to reach Host B (192.168.1.100) # Step 1: ARP Request (broadcast)┌────────────────────────────────────────────────────────┐│ Ethernet Header ││ Destination MAC: FF:FF:FF:FF:FF:FF (broadcast) ││ Source MAC: 00:11:22:33:44:55 (Host A) ││ EtherType: 0x0806 (ARP) │├────────────────────────────────────────────────────────┤│ ARP Message ││ Operation: 1 (Request) ││ Sender MAC: 00:11:22:33:44:55 ││ Sender IP: 192.168.1.50 ││ Target MAC: 00:00:00:00:00:00 (unknown) ││ Target IP: 192.168.1.100 │└────────────────────────────────────────────────────────┘ # All hosts on the network receive this broadcast.# Only Host B (192.168.1.100) responds. # Step 2: ARP Reply (unicast)┌────────────────────────────────────────────────────────┐│ Ethernet Header ││ Destination MAC: 00:11:22:33:44:55 (Host A) ││ Source MAC: AA:BB:CC:DD:EE:FF (Host B) ││ EtherType: 0x0806 (ARP) │├────────────────────────────────────────────────────────┤│ ARP Message ││ Operation: 2 (Reply) ││ Sender MAC: AA:BB:CC:DD:EE:FF (Host B) ││ Sender IP: 192.168.1.100 ││ Target MAC: 00:11:22:33:44:55 ││ Target IP: 192.168.1.50 │└────────────────────────────────────────────────────────┘ # Host A now knows: 192.168.1.100 → AA:BB:CC:DD:EE:FF| Field | Size | Description |
|---|---|---|
| Hardware Type | 2 bytes | Network type (1 = Ethernet) |
| Protocol Type | 2 bytes | Protocol being resolved (0x0800 = IPv4) |
| Hardware Size | 1 byte | MAC address length (6 for Ethernet) |
| Protocol Size | 1 byte | IP address length (4 for IPv4) |
| Operation | 2 bytes | 1 = Request, 2 = Reply |
| Sender Hardware Address | 6 bytes | Sender's MAC address |
| Sender Protocol Address | 4 bytes | Sender's IP address |
| Target Hardware Address | 6 bytes | Target's MAC (0 in request) |
| Target Protocol Address | 4 bytes | Target's IP address |
ARP has no connection state, acknowledgments, or retransmission logic. If a request goes unanswered, the sender simply tries again. If a reply is lost, the next attempt to communicate triggers a new request. This simplicity keeps ARP lightweight but makes it vulnerable to various attacks.
Broadcasting ARP requests for every packet would be incredibly inefficient—broadcasts consume bandwidth on every device, and the latency would be intolerable. The solution is the ARP cache: a local table storing recent IP-to-MAC mappings.
ARP Cache Behavior:
1234567891011121314151617181920212223242526272829
# Windows: View ARP cacheC:\> arp -a Interface: 192.168.1.50 --- 0x4 Internet Address Physical Address Type 192.168.1.1 d4-6d-50-a1-b2-c3 dynamic 192.168.1.100 aa-bb-cc-dd-ee-ff dynamic 192.168.1.255 ff-ff-ff-ff-ff-ff static # Linux/macOS: View ARP cache $ arp -nAddress HWtype HWaddress Flags Mask Iface192.168.1.1 ether d4:6d:50:a1:b2:c3 C eth0192.168.1.100 ether aa:bb:cc:dd:ee:ff C eth0 # Linux: Modern 'ip' command$ ip neigh show192.168.1.1 dev eth0 lladdr d4:6d:50:a1:b2:c3 REACHABLE192.168.1.100 dev eth0 lladdr aa:bb:cc:dd:ee:ff STALE # Clear specific entry (Windows)C:\> arp -d 192.168.1.100 # Clear entire cache (Linux - requires root)$ ip neigh flush all # Add static entry (persists until reboot)C:\> arp -s 192.168.1.200 00-50-56-c0-00-01$ arp -s 192.168.1.200 00:50:56:c0:00:01| State | Meaning | Next Action |
|---|---|---|
| REACHABLE | Entry valid; recent successful communication | Use directly |
| STALE | Entry aged; no recent confirmation | Use but may re-verify on next use |
| DELAY | Packet sent; waiting briefly for verification | Probe if no traffic confirms |
| PROBE | Actively verifying with unsolicited ARP | Re-resolve if no response |
| FAILED | Resolution failed; no response to probes | Report error to higher layers |
| INCOMPLETE | Resolution in progress; waiting for reply | Queue packets; timeout if no response |
Cache Timeout Tradeoffs:
Most operating systems use 2-20 minute dynamic timeouts, with revalidation through normal traffic patterns.
Gratuitous ARP:
A device may broadcast its own IP-MAC mapping unsolicited—this is Gratuitous ARP:
Stale ARP entries are a common troubleshooting headache. If a server's NIC is replaced (new MAC) or an IP is reassigned, other devices may still cache the old mapping. Symptoms: intermittent connectivity, connection resets, or complete unreachability. Solution: Clear ARP caches on affected devices or wait for natural expiration.
ARP was designed in an era of trusted networks and has no built-in security. This makes it vulnerable to several attacks that exploit its trusting nature.
ARP Spoofing / Poisoning:
An attacker sends forged ARP replies, associating their MAC address with another device's IP (typically the gateway):
This enables Man-in-the-Middle (MITM) attacks, where the attacker intercepts and forwards traffic between victim and gateway—reading passwords, modifying responses, or injecting malicious content.
Defense Mechanisms:
1. Dynamic ARP Inspection (DAI)
2. Static ARP Entries
3. Private VLANs
4. Port Security
5. 802.1X Authentication
The ultimate defense against ARP-based MITM is encryption at higher layers. HTTPS, SSH, and VPNs render intercepted traffic unreadable. Even if an attacker captures packets, they can't decrypt the contents. Always assume the local network is hostile and encrypt sensitive traffic.
Several variations and special cases of ARP behavior exist to handle unusual network configurations.
Proxy ARP:
A router can answer ARP requests on behalf of devices on other networks—this is Proxy ARP (RFC 1027).
Scenario: Host A (192.168.1.50/24) wants to reach Host B (192.168.2.100/24). Without proper routing configuration, Host A might try to ARP directly for 192.168.2.100, not realizing it's on a different network.
Proxy ARP Solution:
Proxy ARP makes routing transparent to hosts with misconfigured subnet masks, but is generally considered a legacy workaround rather than a best practice.
| Case | Description | Use |
|---|---|---|
| Gratuitous ARP | Device announces its own IP-MAC mapping | Detect conflicts, update caches, failover |
| Proxy ARP | Router answers for hosts on other networks | Transparent routing for misconfigured hosts |
| Reverse ARP (RARP) | Request IP based on known MAC | Obsolete; replaced by DHCP/BOOTP |
| Inverse ARP (InARP) | Request IP of known MAC on Frame Relay | Frame Relay DLCI resolution |
| ARP Probe | ARP for own IP with sender IP = 0 | DAD before using DHCP address |
| ARP Announcement | Gratuitous ARP after passing DAD | Inform network of new binding |
ARP for Non-Ethernet Networks:
ARP is hardware-agnostic—its format includes hardware type fields that specify the link layer technology. While Ethernet is most common, ARP works on:
Virtual Environment Considerations:
Virtual machines, containers, and cloud instances present unique ARP scenarios:
While Proxy ARP can solve immediate problems, it creates security and manageability issues: it hides routing failures (things seem to work when they shouldn't), expands broadcast domains artificially, and can enable attacks from misconfigured hosts. Modern best practice is to configure hosts correctly rather than rely on Proxy ARP.
IPv6 replaces ARP with the Neighbor Discovery Protocol (NDP), defined in RFC 4861. NDP uses ICMPv6 messages rather than a separate protocol and provides significantly enhanced functionality.
NDP Message Types:
| Message | Type | Purpose |
|---|---|---|
| Router Solicitation (RS) | 133 | Host requests router presence/configuration |
| Router Advertisement (RA) | 134 | Router announces itself, prefix, configuration options |
| Neighbor Solicitation (NS) | 135 | Resolve IPv6 to MAC (like ARP Request) |
| Neighbor Advertisement (NA) | 136 | Response with MAC address (like ARP Reply) |
| Redirect | 137 | Router informs host of better first hop |
Address Resolution with NS/NA:
NDP address resolution is similar to ARP but uses multicast instead of broadcast:
2001:db8::100ff02::1:ff00:0100 (derived from target's last 24 bits)...00:0100 listen12345678910111213141516171819202122232425262728293031
# IPv6 Address Resolution Example # Host A wants to reach Host B at 2001:db8::100# Host B's MAC: aa:bb:cc:dd:ee:ff # Step 1: Neighbor SolicitationSource IP: 2001:db8::50 (Host A)Destination IP: ff02::1:ff00:0100 (solicited-node multicast)ICMPv6 Type: 135 (Neighbor Solicitation)Target Address: 2001:db8::100Options: Source Link-Layer Address = 00:11:22:33:44:55 # Only hosts with addresses ending in ...00:0100 receive this# Much more efficient than broadcast! # Step 2: Neighbor AdvertisementSource IP: 2001:db8::100 (Host B)Destination IP: 2001:db8::50 (Host A - unicast)ICMPv6 Type: 136 (Neighbor Advertisement)Target Address: 2001:db8::100Flags: Solicited=1, Override=1Options: Target Link-Layer Address = aa:bb:cc:dd:ee:ff # Host A now knows: 2001:db8::100 → aa:bb:cc:dd:ee:ff # View IPv6 Neighbor Cache (Linux)$ ip -6 neigh show2001:db8::1 dev eth0 lladdr d4:6d:50:a1:b2:c3 router REACHABLE2001:db8::100 dev eth0 lladdr aa:bb:cc:dd:ee:ff STALEfe80::1 dev eth0 lladdr d4:6d:50:a1:b2:c3 router REACHABLENDP Improvements Over ARP:
The solicited-node multicast address is derived from the target's last 24 bits. In a /64 network with 1,000 hosts, a Neighbor Solicitation reaches only ~1 host (statistically), not all 1,000 as ARP broadcast would. This dramatic efficiency gain scales better for large networks.
Let's trace address resolution through a complete packet delivery scenario to see how all the pieces fit together.
Scenario: Host A (192.168.1.50) connects to web server (10.0.0.100) on another network.
Network Configuration:
12345678910111213141516171819202122232425262728293031323334353637383940414243444546
# Phase 1: Host A determines routing decisionHost A destination: 10.0.0.100Host A network: 192.168.1.0/24Is 10.0.0.100 in 192.168.1.0/24? → NODecision: Send to default gateway (192.168.1.1) # Phase 2: Host A resolves gateway MACHost A checks ARP cache for 192.168.1.1├─ Cache HIT: Use cached MAC (e.g., D4:6D:50:A1:B2:C3)└─ Cache MISS: Send ARP Request ARP Request: "Who has 192.168.1.1?" → Router responds: "192.168.1.1 is at D4:6D:50:A1:B2:C3" → Host A caches: 192.168.1.1 → D4:6D:50:A1:B2:C3 # Phase 3: Host A constructs and sends frameIP Packet: Source IP: 192.168.1.50 Destination IP: 10.0.0.100 ← Final destination Payload: [HTTP Request] Ethernet Frame: Source MAC: 00:11:22:33:44:55 (Host A) Destination MAC: D4:6D:50:A1:B2:C3 (Router!) ← Next hop only Payload: [IP Packet] → Frame transmitted on wire # Phase 4: Router receives and processesRouter receives frame on interface 192.168.1.1Router decapsulates: extracts IP packetRouter checks: Is 10.0.0.100 directly connected? Interface 10.0.0.1 connects to 10.0.0.0/24 → YES # Phase 5: Router resolves server MACRouter checks ARP cache for 10.0.0.100├─ Cache HIT: Use cached MAC (e.g., AA:BB:CC:DD:EE:FF)└─ Cache MISS: Send ARP on 10.0.0.0/24 interface → Server responds with its MAC # Phase 6: Router forwards to serverNew Ethernet Frame: Source MAC: [Router's 10.0.0.1 interface MAC] Destination MAC: AA:BB:CC:DD:EE:FF (Server) Payload: [Same IP Packet - unchanged!] → Server receives and processesCritical Observations:
This pattern repeats for every hop in a multi-router path. The IP layer provides end-to-end addressing; the data link layer and ARP provide point-to-point delivery between each pair of adjacent devices.
From the application's perspective, it communicates directly with the server using IP addresses. The complex dance of ARP requests, MAC address lookups, frame encapsulation, and multi-hop forwarding is completely invisible. This abstraction is the power of layered networking—each layer hides complexity from those above it.
Address resolution is the essential glue between logical and physical networking. Let's consolidate the key concepts:
Module Complete:
With this page, you've completed the Addressing module of Network Layer Concepts. You now understand:
These concepts form the foundation for understanding IP routing, subnetting, NAT, and all higher-level network protocols.
Congratulations! You've mastered network layer addressing—from the theoretical foundations of logical vs. physical addresses to the practical mechanisms of DHCP and ARP. This knowledge is essential for network administration, troubleshooting, security, and understanding how the Internet actually delivers billions of packets every second.