What is an ARP request and an ARP reply, and how is each one addressed (broadcast vs unicast)?
An ARP request is broadcast to the whole local network asking "who has this IPv4 address?"; only the owner answers with a unicast ARP reply containing its MAC, which the sender then caches.
* The request is broadcast so every host sees it; only the IP's owner replies by unicast, and the sender caches the mapping before sending the frame. *
ARP request → ARP reply mechanics:
| Message | Sent as | Contents |
|---|---|---|
| ARP Request | Broadcast (dest MAC ff-ff-ff-ff-ff-ff) |
"Who has target IPv4 X? Tell me your MAC." Every device on the local network receives and processes it. |
| ARP Reply | Unicast (back to the requester) | Only the device that owns IPv4 X answers: "X is at my MAC." |
After the reply: The requester adds the IPv4-to-MAC mapping to its ARP table, then uses that MAC as the destination MAC in the frame. Subsequent frames to that IP skip the ARP exchange (the entry is cached).
Why it matters: The request must be a broadcast because the sender does not yet know the target's MAC, so it cannot address the frame to anyone specific. This broadcast-then-cache pattern is also why a single ARP request can briefly burden every host on the segment.
Go deeper:
-
Traditional ARP — PracticalNetworking walks the two-step request/reply, the broadcast destination MAC ffff.ffff.ffff, and how the opcode flips from 1 to 2. -
RFC 826 — An Ethernet Address Resolution Protocol — the authoritative definition of the request/reply packet format and the broadcast-then-cache behaviour.