Arp - Learning Module | OneNoughtOne

Loading content...

0/228

ARP Request/Reply

The Heart of ARP

At its core, ARP is a simple question-and-answer protocol. The ARP Request asks: "Who has this IP address?" The ARP Reply answers: "I have that IP, and here's my MAC address." This elegant simplicity enables all IP over Ethernet communication.

Yet this simplicity conceals important details. How are these messages formatted? What fields are included and why? How does broadcast vs. unicast transmission affect network behavior? What happens when multiple hosts respond? Understanding the precise mechanics of ARP request/reply is essential for network analysis, security assessment, and protocol implementation.

What You Will Learn

By the end of this page, you will understand the exact structure of ARP request and reply messages, how they're encapsulated in Ethernet frames, the semantics of each field, how to capture and analyze them with packet sniffers, and edge cases like duplicate responses and timing considerations.

ARP Message Format Deep Dive

The ARP message format (defined in RFC 826) is compact and purpose-built. For IPv4 over Ethernet—the most common case—the message is exactly 28 bytes.

Complete ARP Message Structure:

ARP Message Fields (IPv4 over Ethernet)
Offset	Field	Size	Value/Description
0	Hardware Type (HTYPE)	2 bytes	1 = Ethernet (most common)
2	Protocol Type (PTYPE)	2 bytes	0x0800 = IPv4
4	Hardware Address Length (HLEN)	1 byte	6 = MAC address length
5	Protocol Address Length (PLEN)	1 byte	4 = IPv4 address length
6	Operation (OPER)	2 bytes	1 = Request, 2 = Reply
8	Sender Hardware Address (SHA)	6 bytes	MAC address of sender
14	Sender Protocol Address (SPA)	4 bytes	IP address of sender
18	Target Hardware Address (THA)	6 bytes	MAC of target (0s in request)
24	Target Protocol Address (TPA)	4 bytes	IP address being resolved

Field Details:

Hardware Type (HTYPE) Identifies the link-layer protocol. Value 1 signifies Ethernet. Other values exist for legacy technologies:

1 = Ethernet
6 = IEEE 802 Networks
15 = Frame Relay
20 = Serial Line

In practice, value 1 is almost universal today.

Protocol Type (PTYPE) Uses the same values as EtherType. For IPv4, this is 0x0800. The fact that this matches the IP EtherType is intentional—it allows consistent protocol identification across the stack.

Hardware/Protocol Address Lengths (HLEN/PLEN) These fields allow ARP to work with various address sizes. For Ethernet (6-byte MAC) and IPv4 (4-byte IP), these are always 6 and 4 respectively. IPv6 does not use ARP—it uses NDP—but if it did, PLEN would be 16.

Operation Code (OPER) Distinguishes request from reply:

1 = ARP Request
2 = ARP Reply
3 = RARP Request (Reverse ARP)
4 = RARP Reply

Address Fields (SHA, SPA, THA, TPA) The four address fields contain the actual resolution data. Their interpretation differs between requests and replies.

Variable Length Design

ARP's HLEN and PLEN fields make the protocol theoretically extensible to any hardware/protocol combination. A hypothetical implementation could map 20-byte addresses to 8-byte hardware addresses. This flexibility was important during networking's early years when multiple competing standards existed.

ARP Request Construction

When a host needs to resolve an IP address to a MAC address, it constructs an ARP Request. Let's trace through the exact construction process.

Scenario: Host A (192.168.1.100, MAC AA:AA:AA:AA:AA:AA) needs to resolve Host B (192.168.1.200).

Step 1: Build the ARP Packet

ARP Request Packet Construction
ARP Request Packet (28 bytes):
┌────────────────────────────────────────────────────────┐
│ Hardware Type    │ 0x0001              │ Ethernet      │
│ Protocol Type    │ 0x0800              │ IPv4          │
│ HLEN             │ 0x06                │ 6 bytes       │
│ PLEN             │ 0x04                │ 4 bytes       │
│ Operation        │ 0x0001              │ REQUEST       │
├────────────────────────────────────────────────────────┤
│ Sender MAC (SHA) │ AA:AA:AA:AA:AA:AA   │ Host A's MAC  │
│ Sender IP  (SPA) │ 192.168.1.100       │ Host A's IP   │
│ Target MAC (THA) │ 00:00:00:00:00:00   │ UNKNOWN ←     │
│ Target IP  (TPA) │ 192.168.1.200       │ We want this  │
└────────────────────────────────────────────────────────┘
 
Key Insight: Target MAC is set to zeros because that's what
we're asking for. We know the Target IP; we need the Target MAC.

Step 2: Build the Ethernet Frame

The ARP packet must be encapsulated in an Ethernet frame for transmission:

Ethernet Frame for ARP Request
Ethernet Frame:
┌─────────────────────────────────────────────────────────┐
│ Destination MAC │ FF:FF:FF:FF:FF:FF    │ BROADCAST     │
│ Source MAC      │ AA:AA:AA:AA:AA:AA    │ Host A's MAC  │
│ EtherType       │ 0x0806               │ ARP           │
├─────────────────────────────────────────────────────────┤
│                                                         │
│                    ARP Packet (28 bytes)                │
│                    (as constructed above)               │
│                                                         │
├─────────────────────────────────────────────────────────┤
│ Padding          │ 18 bytes of zeros   │ Min 46 payload│
│ FCS              │ 4 bytes             │ CRC-32        │
└─────────────────────────────────────────────────────────┘
 
Total frame size: 14 (header) + 28 (ARP) + 18 (padding) + 4 (FCS) = 64 bytes

Why Broadcast?

The destination MAC is broadcast (FF:FF:FF:FF:FF:FF) because the sender doesn't know which host has the target IP. Every host on the broadcast domain receives the frame and checks if the target IP matches their own. Only the owner responds.

ARP Reply Construction

When Host B (192.168.1.200, MAC BB:BB:BB:BB:BB:BB) receives the ARP request and recognizes its own IP in the Target IP field, it constructs an ARP Reply.

Step 1: Build the ARP Reply Packet

ARP Reply Packet Construction
ARP Reply Packet (28 bytes):
┌────────────────────────────────────────────────────────┐
│ Hardware Type    │ 0x0001              │ Ethernet      │
│ Protocol Type    │ 0x0800              │ IPv4          │
│ HLEN             │ 0x06                │ 6 bytes       │
│ PLEN             │ 0x04                │ 4 bytes       │
│ Operation        │ 0x0002              │ REPLY ←       │
├────────────────────────────────────────────────────────┤
│ Sender MAC (SHA) │ BB:BB:BB:BB:BB:BB   │ Host B's MAC  │ ← The answer!
│ Sender IP  (SPA) │ 192.168.1.200       │ Host B's IP   │
│ Target MAC (THA) │ AA:AA:AA:AA:AA:AA   │ Host A's MAC  │ ← From request
│ Target IP  (TPA) │ 192.168.1.100       │ Host A's IP   │ ← From request
└────────────────────────────────────────────────────────┘
 
Key Changes from Request:
1. Operation changed from 1 to 2 (REPLY)
2. Sender/Target addresses SWAPPED
3. Sender MAC now contains the resolved address

Step 2: Build the Ethernet Frame (Unicast)

Ethernet Frame for ARP Reply
Ethernet Frame:
┌─────────────────────────────────────────────────────────┐
│ Destination MAC │ AA:AA:AA:AA:AA:AA    │ UNICAST ←     │
│ Source MAC      │ BB:BB:BB:BB:BB:BB    │ Host B's MAC  │
│ EtherType       │ 0x0806               │ ARP           │
├─────────────────────────────────────────────────────────┤
│                                                         │
│                    ARP Reply (28 bytes)                 │
│                                                         │
├─────────────────────────────────────────────────────────┤
│ Padding + FCS                                           │
└─────────────────────────────────────────────────────────┘
 
Unlike the request's broadcast, the reply is UNICAST directly
to the original requester. No other hosts see this frame.

Efficiency Through Unicast

The unicast reply is crucial for network efficiency. If replies were also broadcast, every host would process every ARP transaction, wasting CPU cycles. By unicasting replies, only the interested party (the original requester) processes the response.

Complete Byte-Level Example

Let's examine the complete hex representation of an ARP request and reply as they would appear in a packet capture.

ARP Request (Raw Hex):

ARP Request Hexdump
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Ethernet Header (14 bytes)
FF FF FF FF FF FF    # Destination MAC: Broadcast
AA AA AA AA AA AA    # Source MAC: Host A (sender)
08 06                # EtherType: ARP (0x0806)
 
# ARP Payload (28 bytes)
00 01                # Hardware Type: Ethernet (1)
08 00                # Protocol Type: IPv4 (0x0800)
06                   # Hardware Address Length: 6
04                   # Protocol Address Length: 4
00 01                # Operation: Request (1)
AA AA AA AA AA AA    # Sender MAC: AA:AA:AA:AA:AA:AA
C0 A8 01 64          # Sender IP: 192.168.1.100 (C0=192, A8=168, 01=1, 64=100)
00 00 00 00 00 00    # Target MAC: Unknown (zeros)
C0 A8 01 C8          # Target IP: 192.168.1.200 (C8=200)
 
# Padding (18 bytes for minimum 64-byte frame)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ARP Reply (Raw Hex):

ARP Reply Hexdump
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Ethernet Header (14 bytes)
AA AA AA AA AA AA    # Destination MAC: Host A (unicast)
BB BB BB BB BB BB    # Source MAC: Host B (responder)
08 06                # EtherType: ARP (0x0806)
 
# ARP Payload (28 bytes)
00 01                # Hardware Type: Ethernet (1)
08 00                # Protocol Type: IPv4 (0x0800)
06                   # Hardware Address Length: 6
04                   # Protocol Address Length: 4
00 02                # Operation: Reply (2) ← Key difference
BB BB BB BB BB BB    # Sender MAC: BB:BB:BB:BB:BB:BB (the answer!)
C0 A8 01 C8          # Sender IP: 192.168.1.200
AA AA AA AA AA AA    # Target MAC: AA:AA:AA:AA:AA:AA (copied from request)
C0 A8 01 64          # Target IP: 192.168.1.100 (copied from request)
 
# Padding (18 bytes)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Wireshark Analysis

In Wireshark, this hex would display with helpful color-coding: Ethernet header in one color, ARP fields in another. The display filters 'arp.opcode == 1' (requests) and 'arp.opcode == 2' (replies) help isolate specific message types during troubleshooting.

Request-Reply Matching

Unlike protocols such as DNS or HTTP, ARP has no transaction ID or sequence number. So how does the requester know that a reply corresponds to its request?

Matching Mechanism:

The requester matches replies based on:

Reply's Sender IP: Must match the Target IP from the original request
Interface: Reply must arrive on the same interface where the request was sent
Timing: Reply arrives within the expected timeout window

ARP Reply Processing Algorithm (on the requester):

ARP Reply Matching Logic
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
function processARPReply(reply):
    # Step 1: Check if we're waiting for this resolution
    pendingEntry = arpCache.findIncomplete(reply.senderIP)
    if pendingEntry is None:
        # We weren't waiting for this - unsolicited reply
        # Still may update cache if entry exists (RFC 826 merge rule)
        existingEntry = arpCache.find(reply.senderIP)
        if existingEntry:
            existingEntry.updateMAC(reply.senderMAC)
        return
    
    # Step 2: Complete the pending entry
    pendingEntry.setMAC(reply.senderMAC)
    pendingEntry.setState(REACHABLE)
    
    # Step 3: Transmit queued packets
    while pendingEntry.hasQueuedPackets():
        packet = pendingEntry.dequeue()
        transmitWithMAC(packet, reply.senderMAC)

Why No Transaction IDs?

ARP was designed for simplicity on local networks where:

Collision is rare: In a typical network, you only resolve one IP at a time per host
Replies are distinct: Each reply carries the resolved IP, making matching unambiguous
Timing bounds matching: Replies arriving outside the timeout are ignored
Best-effort is sufficient: If matching occasionally fails, the protocol retries

The absence of transaction IDs does have security implications—it makes ARP spoofing easier since attackers don't need to guess IDs.

Race Condition Risk

If you send ARP requests for two different IPs simultaneously, and replies arrive, matching works correctly because each reply's Sender IP differs. However, if an attacker races to respond before the legitimate host, their (fake) reply may be accepted. This is the basis for ARP spoofing attacks.

Edge Cases and Anomalies

Real networks present various edge cases that ARP implementations must handle. Understanding these prepares you for troubleshooting unusual scenarios.

Duplicate ARP Responses

If two hosts have the same IP (misconfiguration or attack), both may respond to ARP requests. The requester typically uses the last reply received, but behavior varies by implementation.

No Response (Timeout)

If no reply arrives within the timeout (typically 1 second per retry, 3 retries):

The incomplete cache entry is marked FAILED
Queued packets for that destination are dropped
The application receives an error (e.g., 'No route to host' or 'Destination unreachable')

Common Edge Cases

•IP Conflict Detection: Host boots, sends GARP for its own IP, receives reply. Another host already has this IP! Configuration conflict detected.
•Asymmetric Routing: Host A can reach Host B via a gateway, but B's reply comes directly (bypassing gateway). B still learns A's MAC from the request, but reply routing differs from request.
•VLAN Mismatch: Request sent on VLAN 10, but target is on VLAN 20. Broadcast doesn't cross VLAN boundary. No reply ever comes—hosts are in different broadcast domains.
•Firewall Blocking ARP: Some misconfigured firewalls block ARP (though this is rare—ARP is usually below firewall inspection). Results in complete connectivity failure.
•MAC Address Not Found: Switch has no MAC table entry for reply destination. Reply is flooded (like a broadcast). Usually benign but indicates switch learning issues.

Debugging No-Reply Scenarios

When ARP requests get no reply: (1) Verify target IP is on the same subnet as source, (2) Check if target host is powered on and connected, (3) Verify no VLAN mismatch, (4) Check for broadcast storm/rate limiting, (5) Capture with Wireshark on both sides to see if request arrives and reply is sent.

Capturing ARP with Packet Sniffers

Packet capture tools are invaluable for analyzing ARP traffic. Here's how to use common tools effectively.

Wireshark Filters for ARP:

Wireshark Display Filters for ARP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# Show all ARP traffic
arp
 
# Show only ARP requests
arp.opcode == 1
 
# Show only ARP replies
arp.opcode == 2
 
# Show ARP for specific IP
arp.dst.proto_ipv4 == 192.168.1.200 or arp.src.proto_ipv4 == 192.168.1.200
 
# Show ARP from specific MAC
arp.src.hw_mac == aa:aa:aa:aa:aa:aa
 
# Show gratuitous ARP (sender IP = target IP)
arp.src.proto_ipv4 == arp.dst.proto_ipv4
 
# Show potential ARP spoofing (multiple MACs for same IP)
# Requires statistics analysis - can't be done with single filter

tcpdump for Command-Line Capture:

tcpdump ARP Capture Commands
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Capture all ARP traffic on eth0
sudo tcpdump -i eth0 arp -n
 
# Capture ARP with full packet hex dump
sudo tcpdump -i eth0 arp -XX -n
 
# Capture ARP for specific host
sudo tcpdump -i eth0 arp and host 192.168.1.200 -n
 
# Save to file for later analysis
sudo tcpdump -i eth0 arp -w arp_capture.pcap
 
# Live decode with verbose output
sudo tcpdump -i eth0 arp -v -n
 
# Example output:
# 10:30:45.123456 ARP, Request who-has 192.168.1.200 tell 192.168.1.100, length 28
# 10:30:45.123789 ARP, Reply 192.168.1.200 is-at bb:bb:bb:bb:bb:bb, length 28

ARP Traffic Characteristics

Normal ARP traffic is bursty—requests appear when hosts start communicating, then cease for cache timeout periods. Continuous high-rate ARP traffic suggests: (1) network scanning, (2) ARP spoofing attack, (3) IP conflict, or (4) very short cache timeouts. Baseline your network's normal ARP rate to detect anomalies.

ARP Request/Reply Timing Analysis

Understanding ARP timing helps diagnose network latency and performance issues.

Normal Timing Expectations:

Expected ARP Timing
Metric	Typical Value	Concerning If
Request → Reply latency	< 1ms (same switch)	10ms indicates congestion
Request → Reply latency	< 5ms (same LAN)	50ms indicates problems
Retry interval	1 second	N/A (OS configured)
Maximum retries	3 attempts	N/A (OS configured)
Total timeout	~3 seconds	Failures appear here

Timing Analysis with tcpdump:

# Capture with microsecond timestamps
sudo tcpdump -i eth0 arp -ttt -n

# Example output showing inter-packet timing:
# 00:00:00.000000 ARP, Request who-has 192.168.1.200...
# 00:00:00.000423 ARP, Reply 192.168.1.200 is-at...  ← 423 μs latency

What Timing Tells You:

Sub-millisecond replies: Target is directly connected, healthy network
1-5ms replies: Normal for multi-switch networks
10-50ms replies: Network congestion, overloaded target, or long path
100ms+ replies: Serious issues—CPU overload, packet loss/retries
Replies after 1+ seconds: Initial request was lost, this is a retry/reply pair

Retry Pattern Detection:

If you see the same ARP request repeated at 1-second intervals, followed by no reply, the target is unreachable:

10:30:45.000 ARP, Request who-has 192.168.1.200...
10:30:46.001 ARP, Request who-has 192.168.1.200...  ← 1 sec retry
10:30:47.002 ARP, Request who-has 192.168.1.200...  ← 2nd retry
10:30:48.003 ARP, Request who-has 192.168.1.200...  ← 3rd retry (final)
# After this, ARP gives up and marks entry FAILED

Application Impact

ARP timeout directly impacts application latency. If ARP takes 3 seconds to fail, that's 3 seconds of connection delay before the application even sees an error. In high-availability systems, this can cause cascading timeouts. Short retry intervals with graceful degradation strategies are essential.

Summary: ARP Request/Reply

We've examined the ARP request/reply mechanism at every level—from conceptual overview to raw hex bytes. This knowledge is foundational for network troubleshooting and security analysis. Let's consolidate the key takeaways:

Key Takeaways

•Fixed 28-byte format — ARP packets are compact with clearly defined fields for hardware/protocol types, lengths, operation, and four addresses.
•Request broadcasts, reply unicasts — Requests reach everyone in the broadcast domain; replies go directly to the requester.
•Target MAC is zeros in requests — That's the question being asked; it gets filled in the reply's Sender MAC field.
•No transaction IDs — Matching relies on Sender IP in reply matching Target IP in request, plus timing.
•Minimum frame size requires padding — 28-byte ARP payload needs 18 bytes of padding to reach Ethernet's 64-byte minimum.
•Edge cases require handling — Duplicates, timeouts, IP conflicts, and VLAN issues all manifest as ARP anomalies.
•Packet capture is essential — Wireshark and tcpdump are invaluable for ARP analysis and troubleshooting.
•Timing reveals network health — Sub-millisecond replies indicate healthy networks; multi-second delays indicate problems.

What's Next:

With request/reply mechanics fully understood, we'll examine the ARP table management in depth—how operating systems organize, store, and maintain their collections of ARP bindings across interfaces and network changes.

Page Complete

You now have complete knowledge of ARP request and reply message formats, construction, transmission, and matching. You can decode ARP packets from raw hex, understand timing implications, and use packet capture tools for analysis. Next, we'll explore ARP table structure and management in comprehensive detail.