In standard networking scenarios, Address Resolution Protocol (ARP) requests are typically broadcast to all devices on the local network segment. This broadcast behavior (destination MAC FF:FF:FF:FF:FF:FF) is fundamental to ARP's operation, as the requesting host doesn't know which specific device holds the IP-to-MAC mapping it needs.
While uncommon, unicast ARP requests do occur in specific situations:
// Example Wireshark filter to catch unicast ARP:
arp.opcode == 1 && !(eth.dst == ff:ff:ff:ff:ff:ff)
1. Proxy ARP Implementations: Some routers or gateway devices may send unicast ARP requests when implementing proxy ARP functionality.
2. ARP Cache Validation: Modern operating systems may use unicast ARP to verify existing cache entries before they expire.
// Linux kernel ARP behavior (arp.c):
if (arp->op == ARPOP_REQUEST && skb->pkt_type == PACKET_HOST) {
// This handles unicast ARP requests
arp_process(skb);
}
In your Wireshark capture, you might notice these characteristics of unicast ARP requests:
- Destination MAC is specific (not broadcast)
- Operation code still shows as request (ARPOP_REQUEST)
- Often appears in rapid succession after a broadcast ARP
When analyzing network issues, unicast ARP requests can indicate:
- Possible ARP cache poisoning attempts
- Network stack optimizations in newer OS versions
- Specialized network appliance behavior
# tcpdump filter for unicast ARP:
tcpdump -i eth0 'arp and not ether dst ff:ff:ff:ff:ff:ff'
Modern Windows versions implement an ARP optimization where they first send a unicast ARP to the cached MAC address before resorting to broadcast, reducing network noise.
While ARP (Address Resolution Protocol) requests are typically sent as broadcast frames (destination MAC FF:FF:FF:FF:FF:FF), there are specific scenarios where unicast ARP requests occur. The standard ARP process uses broadcast to discover the MAC address associated with an IP when no prior communication exists.
Here are the primary cases where you might observe unicast ARP requests:
- ARP Refresh Mechanism: When a host needs to verify an existing ARP cache entry before expiration
- Probe Requests: For duplicate address detection (DAD) in IPv4 implementations
- Targeted Verification: When a system specifically needs to confirm another host's MAC address
- ARP Cache Update: Some operating systems send unicast ARP to update stale entries
Here's how a unicast ARP request might appear in Wireshark:
Ethernet II, Src: 00:1a:2b:3c:4d:5e, Dst: 00:1e:4f:5a:6b:7c
Address Resolution Protocol (request)
Hardware type: Ethernet (1)
Protocol type: IPv4 (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: request (1)
Sender MAC address: 00:1a:2b:3c:4d:5e
Sender IP address: 192.168.1.100
Target MAC address: 00:1e:4f:5a:6b:7c
Target IP address: 192.168.1.101
Here's a Python example demonstrating how to send both broadcast and unicast ARP requests:
import socket
import struct
def send_arp_request(dest_ip, dest_mac=None):
# Create raw socket
s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW)
s.bind(("eth0", 0))
# Build Ethernet frame
if dest_mac: # Unicast
dest = dest_mac.replace(':', '').decode('hex')
else: # Broadcast
dest = '\xff\xff\xff\xff\xff\xff'
src_mac = '00:1a:2b:3c:4d:5e' # Replace with your MAC
src = src_mac.replace(':', '').decode('hex')
eth_type = '\x08\x06' # ARP
# Build ARP packet
arp = struct.pack('!HHBBH6s4s6s4s',
0x0001, # Hardware type (Ethernet)
0x0800, # Protocol type (IPv4)
6, # Hardware size
4, # Protocol size
0x0001, # Operation (request)
src, # Sender MAC
socket.inet_aton('192.168.1.100'), # Sender IP
dest if dest_mac else '\x00\x00\x00\x00\x00\x00', # Target MAC
socket.inet_aton(dest_ip)) # Target IP
packet = dest + src + eth_type + arp
s.send(packet)
The technical rationale behind unicast ARP includes:
- Network Efficiency: Reduces unnecessary broadcast traffic
- Targeted Validation: Verifies specific entries without disturbing other hosts
- Cache Optimization: Helps maintain accurate ARP cache with minimal overhead
When analyzing network traffic:
- Check for operating system-specific implementations (Windows, Linux, macOS handle ARP differently)
- Examine the ARP cache (arp -a on Windows, ip neigh on Linux) before packet capture
- Consider network topology - some devices may convert broadcast to unicast