2

Why does an ARP request from my Router have a Target MAC Address: Broadcast enter image description here

While Host issued ARP requests always have Target MAC Address: 00:00:00:00:00:00? enter image description here

Also, I periodically see ARP requests generated by a host going to the router, but it already includes the correct Target MAC address. What is that all about? enter image description here

  • You need to edit your question to give some examples. – Ron Maupin Jan 11 '18 at 16:07
  • And specific devices. – Ron Trunk Jan 11 '18 at 16:08
4

Because RFC 826 doesn't specify what address to use, but indeed explicitly allow any address:

(ar$tha) Hardware address of target of this packet (if known).
[...]
It does not set ar$tha to anything in particular, because it is this value that it is trying to determine. It could set ar$tha to the broadcast address for the hardware (all ones in the case of the 10Mbit Ethernet) if that makes it convenient for some aspect of the implementation.

So each implementation is free to use the broadcast address or not.

RFC826 is updated by RFC 5227, but it doesn't change this:

This document does not modify any of the protocol rules in RFC 826.
It does not modify the packet format, or the meaning of any of the
fields. The existing rules for "Packet Generation" and "Packet
Reception" still apply exactly as specified in RFC 826.

Nor does RFC5494, the other RFC that update RFC826

Regarding the request that already include the MAC addresses see RFC5227 section 2.3:

2.3. Announcing an Address

Having probed to determine that a desired address may be used safely, a host implementing this specification MUST then announce that it is commencing to use this address by broadcasting ANNOUNCE_NUM ARP Announcements, spaced ANNOUNCE_INTERVAL seconds apart. An ARP Announcement is identical to the ARP Probe described above, except that now the sender and target IP addresses are both set to the host's newly selected IPv4 address. The purpose of these ARP Announcements is to make sure that other hosts on the link do not have stale ARP cache entries left over from some other host that may previously have been using the same address. The host may begin legitimately using the IP address immediately after sending the first of the two ARP Announcements; the sending of the second ARP Announcement may be completed asynchronously, concurrent with other networking operations the host may wish to perform.

  • 1
    @Lijok Yep forgot this point of your question, I added the answer to this also. – JFL Jan 11 '18 at 16:35
  • 2
    ARP entries typically need to be refreshed periodically, which is likely what you're seeing in the 3rd example. In order to reduce resource utilization of all of the hosts in the broadcast domain, a unicast ARP request can be sent directly to the router to confirm if it is still alive. I would expect that if the router didn't respond to the unicast ARP request then the host would probably try again with a broadcast ARP request to see if gets an answer. I have seen this behavior many times myself, but my reasoning is technically speculation. – halfmetaljacket Jan 12 '18 at 7:58
0

Your third question was answered in this thread: https://networkengineering.stackexchange.com/a/28807

A client may refresh its ARP entries by using unicast polling of the already known peer. I know my home router does this a lot. Every 30 seconds or so, it sends a unicast ARP request to my computer.

User halfmetaljacket above was correct in his assumptions.

According to RFC1222 :

Unicast Poll -- 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. Again, the timeout should be on the order of a minute, and typically N is 2.

That's a great find by user Eddie

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy