After analyzing some Wireshark traffic captures, I noticed that some ARP requests were broadcast frames, as expected, but I randomly found some ARP requests that were unicast frames. I thought ARP requests were always broadcast frames, but I was wrong.
Let’s do a quick review of the ARP protocol using a simple topology in Packet Tracer:
Imagine that PC1 (10.10.10.1) wants to access the Web Server (10.10.10.3). PC1 will generate an IP packet that needs to be encapsulated inside an Ethernet frame. To create the Ethernet frame, PC1 needs to know the MAC address of the Web Server. Now is when the ARP process come into play. PC1 will send an ARP request asking for the MAC address of 10.10.10.3. Since the destination MAC address is unknown, this frame must be a broadcast frame and it will be received by all the devices in the LAN. Only the device with IP 10.10.10.3 (the Web Server) will reply with its MAC address.
The Wireshark capture shown below corresponds to an ARP request. In the Ethernet section of the capture, we can see that it is a broadcast frame (the destination MAC address is FF:FF:FF:FF:FF:FF).
The next Wireshark capture is also an ARP request, but the destination address is a unicast MAC address instead of a broadcast address.
What is, then, the purpose of a unicast ARP request if the destination MAC address is already known? I found the answer of this question in the RFC 1122 – “Requirements for Internet Hosts – Communication Layers”. Section 22.214.171.124 describe four mechanisms for flushing out-of-date ARP entries. One of the mechanisms is called “unicast poll” and is described as: “Actively poll the remote host by periodically sending a point-to-point ARP Request to it, and delete the entry if no ARP Reply is received from N successive polls“.
Following the example shown in the previous capture, the sending host has an entry in its ARP table that matches the IP 192.168.18.31 with the MAC address 60:f2:62:0f:50:a5. In order to verify if the MAC address is still valid, a unicast ARP request is sent using the MAC address recorded in the ARP table. If the destination host is still using that MAC address, it will reply with an ARP reply message. If no reply is received, it means that the MAC address is no longer in use and the sending host will delete the corresponding ARP table entry.
One final observation. In this particular capture of a unicast ARP request, the “Target MAC address” field is filled with a MAC address of all zeros (00:00:00:00:00:00). However, it is possible to find ARP requests that also use the MAC address of the destination host in this field. For example, the capture shown below:
Does it depend on the particular implementation of the ARP protocol running on the sending host? Or maybe another protocol feature? I’ll keep digging into it.