这意味着任何主机 A 都可以代表主机 B 执行 ARP 请求。
这意味着对于某个 MAC 地址的任何 ARP 请求，不是 ARP 请求 TPA 中的 IP 所有者，而是由其他人代替他回答。这对我来说也意味着，我可以为单个 ARP 请求获得多个答案。
编辑：澄清：
SHA := source hardware address
SPA := source protocol address
THA := target hardware address
TPA := target protocol address
以太网源、ARP 请求 SHA、ARP 回复 THA 可以不同吗？我认为这是理所当然的，ARP 请求 SHA 和 ARP 回复 THA 总是相同的。但我不确定ARP请求的以太网源地址（以及ARP回复中的以太网目的地址）是否也必须与该地址相同。
如果我理解您的问题，您会问这三个字段是否始终相同：ARP Request Ethernet Source ARP Request Source Hardware Address和ARP Reply Target Hardware Address。
我们可以比较传统“正常”ARP 会话和代理 ARP 的值。
SHA 和 THA 在 Wireshark 中显示为“源 MAC 地址”和“目标 MAC 地址”，查看上面的图像，似乎所有三个字段都匹配（当然是跨两个帧）——它们都是00:53:ff:ff:aa:aa. 这也与原始请求中的以太网源匹配。因此，对于常规 ARP 而言，所有三个值似乎都匹配。
接下来我们将看看代理 ARP：
同样，ARP 回复的以太网报头中的源 MAC 似乎与 ARP 回复中的发送方 MAC 地址以及 ARP 请求中的目标 MAC 地址相匹配。
但是我们还没有研究过一种“其他”类型的 ARP 对话......
不过我确实发现有一个地方不同……那就是在 ARP 探测和公告序列中。具体在ARP公告
这是 ARP 公告，注意 THA 是00:00:00:00:00:00. 该公告并不是真正“回答”问题，因此 THA/TPA 字段被忽略。事实上，ARP 公告仍然有一个 OPcode1，从技术上讲，它是一个 ARP 请求。
所以在某种程度上，ARP 探测/公告序列没有 ARP 回复——只有 ARP 请求。在这种情况下，以太网 SRC 和 SHA 总是相互匹配——但在回复中没有 THA 来匹配。
另外，ARP请求TPA和ARP回复SPA可以不同吗？
TPA := target protocol address
SPA := source protocol address
查看上面的捕获，似乎在所有情况下请求 TPA 和回复 SPA 都是相同的。
我无法想象他们会有所不同的情况。但我承认我没有明确研究过这一点。
不过，我倾向于相信，如果他们是不同的，原始发件人会简单地看进来的答复为ARP欺骗，而不是作为一个答案原始发件人的原题。
关于 1.，我从RFC 826 中找到了这段摘录：
然后地址解析模块将 ar$hrd 字段设置为 ares_hrd$Ethernet，将 ar$pro 设置为正在解析的协议类型，将 ar$hln 设置为 6（48 位以太网地址中的字节数），ar$pln到那个协议中地址的长度，ar$op 到 ares_op$REQUEST，ar$sha 是它自己的 48 位以太网地址，ar$spa 是它自己的协议地址，ar$tpa 是它的协议地址试图访问的机器
这意味着，至少根据原始规范，这不是要完成的。
查看RFC 826，您可以轻松发现请求 SHA/SPA 应始终与回复 THA/TPA 匹配：
Swap hardware and protocol fields, putting the local
hardware and protocol addresses in the sender fields.
这来自详细说明如何处理接收到的 ARP 数据包的部分。由于请求的 SHA/SPA 现在交换到回复的 THA/TPA，它们应该匹配。
那么这与以太网源匹配吗？再次回到RFC 826：
The Address
Resolution module then sets the ar$hrd field to
ares_hrd$Ethernet, ar$pro to the protocol type that is being
resolved, ar$hln to 6 (the number of bytes in a 48.bit Ethernet
address), ar$pln to the length of an address in that protocol,
ar$op to ares_op$REQUEST, ar$sha with the 48.bit ethernet address
of itself, ar$spa with the protocol address of itself, and ar$tpa
with the protocol address of the machine that is trying to be
accessed. 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.
由于这是所有驱动程序级别的实现，因此这应该是发送 ARP 请求的接口的驱动程序。因此，该接口的以太网源应该是 SHA。所以是的，所有三个（以太网源地址、请求 SHA 和回复 THA）都应该匹配。
至于请求 TPA 与 SPA 相同，我们可以稍微扩展一下之前引用的RFC 826部分：
When an address resolution packet is received, the receiving
Ethernet module gives the packet to the Address Resolution module
which goes through an algorithm similar to the following.
Negative conditionals indicate an end of processing and a
discarding of the packet.
?Do I have the hardware type in ar$hrd?
Yes: (almost definitely)
[optionally check the hardware length ar$hln]
?Do I speak the protocol in ar$pro?
Yes:
[optionally check the protocol length ar$pln]
Merge_flag := false
If the pair <protocol type, sender protocol address> is
already in my translation table, update the sender
hardware address field of the entry with the new
information in the packet and set Merge_flag to true.
?Am I the target protocol address?
Yes:
If Merge_flag is false, add the triplet <protocol type,
sender protocol address, sender hardware address> to
the translation table.
?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
Yes:
Swap hardware and protocol fields, putting the local
hardware and protocol addresses in the sender fields.
Set the ar$op field to ares_op$REPLY
Send the packet to the (new) target hardware address on
the same hardware on which the request was received.
所以，如果一个接口不是 TPA，它应该响应一个否定条件?Am I the target protocol address?并结束处理。如果它与 TPA 匹配，那么我们再次交换 TPA 和 SPA。所以他们应该是一样的。
此外，如果请求中的 TPA 使用不同的 SPA 进行回复，请注意原始请求者在收到回复后会将回复 SPA 放入其 ARP 表中。它仍然没有原始请求的 TPA 条目，因此会再次启动 ARP 过程。
现在，说了这么多，这就是应该发生的事情。RFC 826没有指定任何类型的检查来验证 ARP 帧的以太网地址是否与 SHA 的以太网地址匹配。这并不意味着这样的检查不存在，它可能被添加到驱动程序中或在网络上实现，以帮助防止您在提问时提到的 ARP 滥用。
另外，我应该指出，如果您从以太网跳到 FDDI，FDDI 源地址将与 SHA 不匹配。当以太网桥接到令牌环网时，由于用于寻址的位顺序不同，需要桥接器修改 ARP 数据包的有效载荷，因此存在一些 ARP“丑陋”。后来 FDDI 出现时，虽然它使用与令牌环相同的位顺序，但对于 ARP 有效载荷，他们使用以太网位的顺序来避免这种“丑陋”。