Strange: why does linux respond to ping with ARP request after last ping reply?

Question

I (and a colleague) have just noticed, and tested, that when a Linux machine is pinged, after the last ping it initiates a unicast ARP request to the machine that initiated the ICMP ping. When pinging to a Windows machine, the Windows machine does not issue an ARP request at the end.

Does anybody know what the purpose is of this unicast ARP request, and why it occurs on Linux and not on Windows?

The Wireshark trace (with 10.20.30.45 being a Linux box):

No.Time        Source           Destination      Prot  Info
19 10.905277   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
20 10.905339   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
21 11.904141   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
22 11.904173   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
23 12.904104   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
24 12.904137   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
25 13.904078   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
26 13.904111   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
27 15.901799   D-Link_c5:e7:ea  D-Link_33:cb:92  ARP   Who has 10.20.30.14?  Tell 10.20.30.45
28 15.901855   D-Link_33:cb:92  D-Link_c5:e7:ea  ARP   10.20.30.14 is at 00:05:5d:33:cb:92

Update: I've just googled some more for unicast ARP requests, and the only useful reference I've found is in RFC 4436 which is about "Detecting Network Attachment" (from 2006). This technique uses unicast ARPs to allow a host to determine whether it is reconnected to a previously known network. But I don't see how this applies to an ARP request as a result of doing a ping. So the mystery remains...

Solution 1

Linux sends various unicast ARP requests to update it's ARP cache. This is to prevent stale (and potentially malicious) ARP cache entries.

There are a few situations where unicast ARP is used, basically to validate the ARP cache. If the entry is stale, then the fallback is to broadcast ARP.

This is discussed in RFC1122 2.3.2.1

I think that is what it is doing, as to why, my first guess would be some sort of anti-spoofing measure. ARP packets are always never routed, so I'm presuming you're doing this on your local LAN? Does this situation happen consistently every time you ping the host or have you just traced one time? In which case, the ARP cache for that host may have been timing out coincidentally.

What OS is running on the host you are pinging the machine from?

Solution 2

I think it's a bug. The following trace is from a ping to an address that is in the ARP cache but stale. I can't think of any good reason to unicast ARP twice in such a short time. This is with 4.14.15 but I've seen the behaviour over many kernel versions.

root@observer:~# tcpdump -nevi eth0 arp
device eth0 entered promiscuous mode
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

13:11:57.362910 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.1 tell 10.1.2.2, length 28
13:11:57.363018 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.1 is-at 42:5f:03:40:00:22, length 28
13:11:57.392890 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.2 tell 10.1.2.1, length 28
13:11:57.393049 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.2 is-at 42:5f:03:40:00:43, length 28

Comments

[Rabarberski]

But this 'feature' wouldn't require sending out an ARP request, since the spammed machine could have already extracted the MAC address from the ICMP ping request.

[Rabarberski]

Thanks for the RFC link. I thought time-outs were the default way to get rid of old arp entries and keep the arp cache size limited. The latter doesn't seem to be done by performing unicast ARPs (but maybe there is a timeout as well). We've tested this on a local testbed LAN 3 times (twice from a Linux machine and once from a WinXP machine). I've also tested this on the 'real' LAN by pinging from my PC (WinXP) to a VMWare Ubuntu 9.04 running on my PC. Same result, same timing (2 seconds).

[Rabarberski]

Do you have any link to the 'Linux sends various unicast ARP requests ...' claim?

[Hubert Kario]

I'm not sure, but it does look like arp spoofing countermeasure. I wonder though how effective is this, I mean, the MAC addresses are used for switching ethernet frames, using unicast message will make it go straight to the last machine from with the destination mac came from...

[stolenmoment]

Looks to me like it's both sides checking the validity of their ARP caches; those two interchanges went in opposite directions, and their entries would be essentially the same age, and so time out and get checked at the same time.