在ARP协议分析实验中，发现Windows7操作系统在清除ARP缓存后，即便目标机器已更新缓存，仍会发送ARP请求进行可达性验证，这一行为遵循RFC4861标准。实验显示，即使存在ARP表项，其状态可能是STALE，需要通过ARP请求确认REACHABLE状态，以保证数据包发送的准确性。
在做计算机网络协议分析实验中，需要清除本机的ARP缓存之后，在控制台ping另一台机器，然后查看抓包的ARP数据包，观察ARP协议的使用方式。
实验现象
网络结构：
+----------------+ 路由器 +----------------+
| | | | |
| A(172.16.2.35) +----------+---------+ B(172.16.2.33) |
| | | |
+----------------+ +----------------+
在抓包结果中，发现不仅本机（172.16.2.35）发送了ARP请求，目标机（172.16.2.33）也发送了ARP请求。对比时间戳，可以确认确实是在ping的回应之前发送的请求。
| 序号 | A(172.16.2.35) | B(172.16.2.33) |
|---|---|---|
| 1 | ARP Request (who is 172.16.2.33) (src: A mac) | |
| 2 | ARP Response (MAC of 172.16.2.33 is xxx) | |
| 3 | ICMP Echo Request (ping) | |
| 4 | ARP Request (who is 172.16.2.35) (src: B mac) | |
| 5 | ARP Response (MAC of 172.16.2.35 is xxx) | |
| 6 | ICMP Echo Response (ping) |
这里就有一个奇怪的地方：
根据课堂上学的ARP流程，当A向B发送1号ARP请求时，携带了源MAC地址，那么B应该更新了自己的ARP缓存，能够将 172.16.2.35 和对应的MAC地址对应起来。如果B的ARP缓存中已经有了A的表项，那么在发送ICMP回应的时候，应该是不需要再发送ARP请求来获取地址的。
但实际上，确实捕获到了4号和5号数据包，表明B还是做了ARP请求。
原因
实验中使用的机器是 windows 7 的操作系统，因此我找到了这份微软文档：
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/address-resolution-protocol-arp-caching-behavior
其中写到：
ARP caching behavior has been changed in Windows Vista. The TCP/IP stack implementations in Windows Vista comply with RFC4861 (Neighbor Discovery protocol for IP version 6 [Ipv6]) for both the IPv4 and the IPv6 Neighbor Discovery process.
ARP 缓存行为已在 Windows Vista 中更改。 Windows Vista 中的 TCP/IP 堆栈实现符合 RFC4861（IP 版本 6 [Ipv6] 的邻居发现协议），适用于 IPv4 和 IPv6 邻居发现过程。
因此 windows 7 的ARP实现应该是符合RFC4861标准的，那么在RFC4861标准中我们可以找到：
https://www.ietf.org/rfc/rfc4861.txt
7.3.2. Neighbor Cache Entry States
A Neighbor Cache entry can be in one of five states:
Neighbor Cache 条目可以处于以下五种状态之一：
INCOMPLETE ...
REACHABLE Positive confirmation was received within the last
ReachableTime milliseconds that the forward path to
the neighbor was functioning properly. While
REACHABLE, no special action takes place as packets
are sent.
在最后 ReachableTime 毫秒内收到肯定确认，表明到邻居的转发
路径正常运行。当 REACHABLE 时，发送数据包时不会发生任何特殊操作。
STALE More than ReachableTime milliseconds have elapsed
since the last positive confirmation was received that
the forward path was functioning properly. While
stale, no action takes place until a packet is sent.
自上次收到前向路径正常运行的肯定确认以来，已超过 ReachableTime 毫秒。
虽然陈旧，但在发送数据包之前不会发生任何操作。
The STALE state is entered upon receiving an
unsolicited Neighbor Discovery message that updates
the cached link-layer address. Receipt of such a
message does not confirm reachability, and entering
the STALE state ensures reachability is verified
quickly if the entry is actually being used. However,
reachability is not actually verified until the entry
is actually used.
在收到更新缓存链路层地址的未经请求的 Neighbor Discovery 消息后进入
STALE 状态。收到此类消息并不能确认可达性，进入 STALE 状态可确保
在条目实际被使用时快速验证可达性。然而，直到条目被实际使用时，
可达性才真正得到验证。
DELAY ...
PROB ...
这里我们关注 REACHABLE 和 STALE 这两种状态。这说明即使ARP表项被更新，也不一定能直接使用。
接下来解释为什么实验现象中，会发送4号包和5号包。
https://www.ietf.org/rfc/rfc4861.txt
7.2.3. Receipt of Neighbor Solicitations
7.2.3. 接收到邻居请求
... Otherwise, the following
description applies. If the Source Address is not the unspecified
address and, on link layers that have addresses, the solicitation
includes a Source Link-Layer Address option, then the recipient
SHOULD create or update the Neighbor Cache entry for the IP Source
Address of the solicitation. If an entry does not already exist, the
node SHOULD create a new one and set its reachability state to STALE
as specified in Section 7.3.3. ...
……否则，以下描述适用。如果源地址不是未指定的地址，并且在有地址的链路层上，请求包括
源链路层地址选项，那么接收者应该为请求的 IP 源地址创建或更新邻居缓存条目。如果条目
不存在，节点应该创建一个新的条目并将其可达性状态设置为 STALE，如第 7.3.3 节中所述。……
正如这里所写的，当实验中，A向B发送ARP请求之后，B的ARP缓存中，A的表项是 STALE 状态。这说明当B需要A的MAC地址时，这个表项是未经验证的。所以，B发送了4号包来验证这个表项的可达性。
当B接收到回应的5号包时，A对应的表项被修改为 REACHABLE ，这时B才确认了表项的可达性，从而发送 ping 的回复包。
2037
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
