What's special about the Target MAC address 00:00:00:00:00:00 (or the broadcast ff:ff:ff:ff:ff:ff) in an ARP Request?
ARP Request can't fill in the target MAC because finding it is the whole point — so the Ethernet frame is broadcast (ff:ff:...), and the ARP-internal target MAC is set to all zeros.
The two MAC fields:
ARP Requests have two MAC slots, in different headers:
| Header | Source MAC | Destination MAC |
|---|---|---|
| Ethernet (outer) | Sender's MAC | ff:ff:ff:ff:ff:ff (broadcast) |
| ARP (inner) | Sender's MAC | 00:00:00:00:00:00 (unknown) |
Why the Ethernet broadcast:
The sender doesn't know who has the IP. The only way to ask "everyone, which of you is 192.168.1.5?" is to broadcast — every device on the LAN segment receives it.
Why the ARP target field is zeros:
It's a placeholder. The whole protocol exists to discover that field. The replier fills in the answer in their ARP Reply.
The reply packet is unicast:
The ARP Reply goes back as a regular unicast frame, addressed directly to the requester. The replier uses the requester's source MAC (which was in the request).
EtherType for ARP:
0x0806 — distinguishes ARP from IPv4 (0x0800) and IPv6 (0x86DD) at the Ethernet layer. This 2-byte field tells the receiver "this frame's payload is ARP, not IP."
Tip: ARP-spoofing attacks abuse this trust — anyone on the LAN can answer with a forged MAC and redirect traffic. Defense: dynamic ARP inspection (DAI) on switches or static ARP entries for critical hosts.
Go deeper:
Address Resolution Protocol (Wikipedia) — why the request's target-hardware-address field starts empty and the frame is broadcast.- RFC 826 — Ethernet ARP — the original spec showing the request/reply field layout end to end.