ARP的正常使用是通过广播帧，因为 ARP 旨在允许机器发现其他主机的 MAC 地址：这只有在 MAC 地址确实事先不知道的情况下才有意义。通常，一台机器负责响应关于自己的请求：如果有人询问当前拥有 IP 地址 10.0.17.42 的机器的 MAC 地址，则该机器应该响应；而且，更重要的是，网络上的其他主机将不会响应，即使它们知道 10.0.17.42 地址的当前所有者的 MAC 地址。

只有地址所有者实际响应避免淹没网络。如果任何机器都在响应它看到的所有请求，那么繁忙网络上的广播 ARP 请求可能会触发数百个响应。

为了使单播 ARP 请求有意义，它应该被发送到已知 MAC 地址的主机，而不是 IP 地址所有者本身（否则，请求的意义何在？）；但默认情况下，该主机不会响应。因此，合法的单播 ARP 请求只会发生在存在已知 ARP 响应器的上下文中，该响应器已被配置为响应分配给其他机器的 IP 地址的 ARP 请求。这是一个相当不寻常的设置。

Linux 系统可以配置为响应其他机器地址的 ARP 请求；这称为代理 ARP。然而，主要的用例是一些透明的防火墙：局域网被分成几个不同的局域网，而本地机器不知道分裂。将子 LAN 连接在一起的机器运行代理 ARP，以保持单个 LAN 的假象，同时仍然过滤通信。但在这种情况下，机器不知道设置；单播 ARP 请求只会发生在其中一台机器上，该机器会以某种方式知道 LAN 拆分已完成。

因此，在实践中，单播 ARP 请求通常是恶意行为的标志。普通机器不会这样做。

可能是由于MAC 泛洪攻击- 一种单播泛洪攻击攻击者将耗尽交换机 MAC 分配表中的空间，因此无法在地址缓存中找到正确的地址（所有地址均由攻击者提供），它将数据包洪流到所有端口（如果交换机接收到一个目标地址未知的单播数据包，该数据包被视为广播数据包，并被发送到网络上的所有主机）。在大多数/所有/目标合法 MAC 被强制退出表后，现在是启动数据包嗅探器的好时机，因为据称交换机吐出的先前不可用的数据包可用于捕获。即使没有意图捕获数据包，这已经是一种 DoS 攻击，尤其是。在大型网络中（由于与交换机通信的客户端数量），这肯定会降低网络性能。

顺便说一句，根据RFC1122，单播 ARP 请求在第 23 页上是合法的：

(2) 单播轮询——通过周期性地向远程主机发送一个点对点的 ARP 请求来主动轮询远程主机，如果连续 N 次轮询都没有收到 ARP 应答，则删除该条目。同样，超时时间应该在一分钟左右，通常 N 为 2。

我不知道单播 ARP 请求有任何合法用途。您提到这是某些实现的功能；你有什么进一步的细节吗？

我怀疑恶意使用单播 ARP 请求是为了规避反欺骗功能。例如，Linux 内核不会侦听未经请求的 ARP 响应，但您可以使用欺骗性 ARP 请求来欺骗它，使其认为响应是请求的。与广播请求相比，单播请求影响其他设备或引起注意的可能性更小。

鉴于 snort 有这么多规则，我建议您专注于获得一系列问题的经验，而不是非常详细地关注这一问题。

在Snort 邮件列表上反复讨论之后（并且未能就这条规则联系作者），我决定接受

这不是已定义的行为，尽管 ARP 轮询可能是某些特定系统上的事情，但规则仍然需要存在，因为我们先验地不知道它是否被某些特定于上下文的机制证明是合理的。即使我们看不到它们有多危险，合法主机也没有理由发送单播请求，因此它应该像任何非正统行为一样触发警报。

寻求答案。你们提出了有趣的观点，但它们更像是有根据的猜测，而不是我寻求的“明确”答案，我想只有 Jeff Nathan 可以提供。

不过感谢您的回答，我确实向他们学习。

注意：在我编辑这个答案之前，这可能是因为主机添加了一个 MAC<->IP 配对到他的表中，无论传入的 ARP 数据包是请求还是回复（因此您可以通过发送来淹没主机的表请求），但后来我意识到 RFC 826 中的接收算法使主机更新他的表，只要协议目标字段对应于他的 IP，因此请求不必是单播的，这种攻击就可以起作用 - 回到正题一。

NB2：我和一位在这个问题上比我更有经验的同事进行了一次有趣的谈话。我向他询问了规则，当我告诉他有关 ARP 轮询的事情时，他的第一反应是完全翻转并跑回他的机器以确保它没有发送此类请求。因为当他不打算与网络通信时，他的计算机没有理由与网络通信:)（也因为他认为对于您不经常联系的主机，此轮询功能会导致无用的流量）。