奇妙な：なぜLinuxは最後のping応答の後にARPリクエストでpingに応答するのですか？

私（および同僚）は、Linuxマシンがpingされると、最後のping がICMP pingを開始したマシンへのユニキャスト ARP要求を開始することに気づき、テストしました。Windowsマシンにpingを実行すると、Windowsマシンは最後にARP要求を発行しません。

このユニキャストARPリクエストの目的は何か、そしてWindowsではなくLinuxで発生する理由を誰もが知っていますか？

Wiresharkトレース（Linuxボックスは10.20.30.45）：

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

更新：私はいくつかのより多くのためにGoogleで検索しましたARP要求のユニキャストの、そして私が見つけた唯一の便利な参照がであるRFC 4436（2006年）、「ネットワーク接続検出」についてです。この手法では、ユニキャストARPを使用して、ホストが以前に既知のネットワークに再接続されているかどうかを判断できます。しかし、pingを実行した結果、これがARP要求にどのように適用されるかわかりません。だから謎は残っています...

Linuxは、さまざまなユニキャストARP要求を送信して、ARPキャッシュを更新します。これは、古い（および潜在的に悪意のある）ARPキャッシュエントリを防ぐためです。

基本的にARPキャッシュを検証するために、ユニキャストARPが使用される状況がいくつかあります。エントリが古い場合、フォールバックはARPをブロードキャストすることです。

これはRFC1122 2.3.2.1で説明されています

私はそれが何をしているのか、なぜそうなのか、私の最初の推測はある種のスプーフィング対策だと思う。ARPパケットは常にルーティングされないので、ローカルLANでこれを行っていると思いますか？この状況は、ホストにpingを実行するたびに一貫して発生しますか、それとも1回トレースしただけですか？その場合、そのホストのARPキャッシュが偶然タイムアウトした可能性があります。

マシンにpingを送信するホストで実行されているOSは何ですか？

バグだと思います。次のトレースは、pingからARPキャッシュ内にあるが古いアドレスへのトレースです。このような短い時間にARPを2回ユニキャストする正当な理由は考えられません。これは4.14.15でのことですが、多くのカーネルバージョンでの動作を見てきました。

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

推測に過ぎませんが、これは、マシンがpingシリーズまたは特定の数のpingに応答するたびにクライアントのMACアドレスを記録する「機能」になります。pingスパムの追跡に役立つ情報になる可能性があります。