ARP Request and Reply Process

Step 1: The ARP Request (a Broadcast)

Device A (192.168.1.10) broadcasts to EVERYONE on the local network:

"Who has 192.168.1.20? Tell 192.168.1.10 (MAC AA:BB:CC:11:22:33)"

Since Device A doesn't yet know which specific device has that IP address, it broadcasts the request to every device on the local network at once - the only device that actually owns that IP address is expected to respond.

Step 2: The ARP Reply (a Direct, Unicast Response)

Device B (192.168.1.20), recognizing its own IP address, replies directly (not broadcast):

"192.168.1.20 is at MAC AA:BB:CC:44:55:66"

Unlike the initial request, the reply is sent directly (unicast) back to the specific device that asked, since Device B now knows exactly who to reply to.

Why the Request Is Broadcast but the Reply Isn't

The requester genuinely doesn't yet know which specific device to ask, so broadcasting is the only option available at that point. But once the correct device responds, there's no longer any reason to involve every other device on the network in the reply - a direct, private response is more efficient.

Caching the Result for Future Use

Once Device A receives the reply, it stores this mapping in its ARP cache (covered in the previous note), so future packets to that same IP address can skip the entire request-reply exchange, at least until that cache entry eventually expires.

A Related Case: Gratuitous ARP

Sometimes a device broadcasts an ARP message about its own address without being asked at all - commonly done right after obtaining a new IP address, both to detect if another device is mistakenly using the exact same address, and to proactively update everyone else's ARP caches with its correct mapping.