RFC5227：IPv4 Address Conflict Detection，July 2008
本备忘录的状态
本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。
梗概
当同一链路上的两台主机尝试同时使用相同的 IPv4 地址时（除非在少数特殊情况下已事先协调好），一台或两台主机都会出现问题。本文档描述了 (i) 主机可以提前采取的简单预防措施，以帮助防止发生这种错误配置，以及 (ii) 如果确实发生这种错误配置，主机可以在事后被动检测到的简单机制它已经发生，以便主机或管理员可以响应以纠正问题。
1、 简介
从历史上看，意外地将两台 Internet 主机配置为相同的 IP 地址通常是一个令人讨厌且难以诊断的问题。
这是不幸的，因为现有的地址解析协议 (Address Resolution Protocol，ARP) 为主机提供了一种简单的方法来检测这种错误配置并将其报告给用户。DHCP 规范 [RFC2131] 简要提到了 ARP 在检测错误配置中的作用，如以下 RFC 2131 的三个节选所示：
* 客户端应该探测新收到的地址，例如，使用 ARP
* 客户端应该对参数进行最终检查（例如，分配网络地址的 ARP）
* 如果客户端检测到地址已被使用（例如，通过使用 ARP），客户端必须向服务器发送 DHCPDECLINE 消息
不幸的是，DHCP 规范没有为实现者提供关于要发送的 ARP 数据包的数量、数据包之间的间隔、在断定可以安全使用地址之前等待的总时间，或者甚至是主机的数据包类型的任何指导。应该倾听，才能做出这个决定。如果在断定一个地址可以安全使用之后，它没有指定主机应该采取的行动，它随后发现它是错误的。它也未能指定 DHCP 客户端应采取哪些预防措施来防范病理性故障情况，例如重复提供相同地址的 DHCP 服务器，即使它已被拒绝多次。
DHCP 规范的作者当时可能有理由认为这些问题的答案似乎过于简单、明显和直截了当，不值得一提，但不幸的是，这给每个单独的实现者留下了协议设计的一些负担。本文件旨在通过明确规定以下方面所需的行动来弥补这一遗漏：
1. 确定地址的使用是否可能导致寻址冲突。这包括 (a) 地址已被同一链路上的另一台主机主动使用的情况，以及 (b) 两台主机无意中开始使用同一地址的情况，并且两者同时处于探查以确定地址是否可以安全使用（第 2.1 节）。
2. 后续被动检测网络上的另一台主机无意中使用了相同的地址。即使所有主机都采取了预防措施以避免使用已在使用的地址，但如果在初始接口配置时两台主机无法通信，仍然会发生冲突。如果主机暂时超出范围，则无线网络接口可能会发生这种情况，或者如果两个以太网集线器之间的链路在地址配置时不起作用，则可能会发生以太网接口。精心设计的主机不仅会处理在接口配置期间检测到的冲突，还会在主机使用地址的整个持续时间内处理以后检测到的冲突（第 2.4 节）。
3. 在重复冲突次数过多的情况下，地址获取尝试的速率限制（第 2.1 节）。
IPv4 地址冲突检测 (Address Conflict Detection，ACD) 的实用程序不仅限于 DHCP 客户端。无论地址是如何配置的，无论是通过人类用户手动输入、通过从 DHCP 服务器接收的信息，还是通过任何其他配置信息源，检测冲突都是有用的。在检测到冲突时，配置代理应该被通知错误。在配置代理是人类用户的情况下，该通知可以采用屏幕上的错误消息、简单网络管理协议 (Simple Network Management Protocol，SNMP) 通知或通过文本消息发送到移动电话的错误消息的形式。对于 DHCP 服务器，该通知采用发送到服务器的 DHCP DECLINE 消息的形式。在由某种其他类型的软件进行配置的情况下，该通知采用向所讨论的软件发出错误指示的形式，通知它它选择的地址与网络上的某个其他主机冲突。配置软件可以选择停止网络操作，也可以自动选择一个新地址，以便主机尽快重新建立IP连接。
IPv4 链路本地地址的分配 [RFC3927] 可以被认为是这种机制的一个特例，其中配置代理是一个伪随机数生成器，它在收到冲突通知时采取的行动是选择一个不同的随机数，然后重试。事实上，这正是 1998 年在 Mac OS 9 中实现 IPv4 Link-Local Addressing 的方式。如果 DHCP 客户端未能从任何 DHCP 服务器获得响应，它将简单地组成一个包含随机 169.254.x.x 的虚假响应地址。如果 ARP 模块报告了该地址的冲突，则 DHCP 客户端将再次尝试，根据需要多次组成一个新的随机 169.254.x.x 地址，直到成功。将 ACD 实现为网络堆栈的标准功能有一个副作用，即它意味着 IPv4 链路本地寻址的一半工作已经完成。
1.1、 本文档中使用的约定和术语
本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“可以”和“可选”是被解释为“在 RFC 中使用的关键字以指示需求级别”[RFC2119] 中的描述。
本文档在 ARP 数据包上下文中使用术语“发送方 IP 地址”或“目标 IP 地址”时，指的是 ARP 规范 [RFC826] 中标识为“ar$spa”的 ARP 数据包字段（发送者协议地址）和'ar$tpa'（目标协议地址）。对于本文档中描述的 ARP 用法，这些字段中的每一个都始终包含一个 IPv4 地址。
在本文档中，“ARP 探测”一词用于指在本地链路上广播的 ARP 请求数据包，其“发送方 IP 地址”为全零。“发送方硬件地址”必须包含发送数据包的接口的硬件地址。“发送方 IP 地址”字段必须设置为全零，以避免在地址已被另一台主机使用的情况下污染同一链路上其他主机中的 ARP 缓存。“目标硬件地址”字段被忽略，应该设置为全零。“目标 IP 地址”字段必须设置为被探测的地址。ARP 探测既传达了一个问题（“有人在使用这个地址吗？”），也传达了一个隐含的陈述（“这是我希望使用的地址。”）。
在本文档中，术语“ARP 公告”用于指在本地链路上广播的 ARP 请求数据包，与上述 ARP 探测相同，除了发送方和目标 IP 地址字段都包含被宣布的 IP 地址.它传达了比 ARP Probe 更强的声明，即“这是我现在使用的地址”。
本协议中使用的以下时序常数在第 2 节中引用，该节详细描述了协议的操作。（请注意，此处列出的值是固定常量；它们不打算由实施者、操作员或最终用户修改。这些常量在此处被赋予符号名称，以便于编写可能希望以不同方式引用本文档的未来标准这些命名常量的值；但是，目前不存在这样的未来标准。）
PROBE_WAIT ：1 秒（初始随机延迟） PROBE_NUM ：3（探测包数） PROBE_MIN ：1 秒（重复探测前的最小延迟） PROBE_MAX ：2 秒（重复探测前的最大延迟） ANNOUNCE_WAIT ：2 秒（宣布前延迟） ANNOUNCE_NUM ：2（公告包数） ANNOUNCE_INTERVAL ：2 秒（公告包之间的时间） MAX_CONFLICTS ：10（限速前的最大冲突） RATE_LIMIT_INTERVAL ：60 秒（连续尝试之间的延迟） DEFEND_INTERVAL ：10 秒（防御性 ARP 之间的最小间隔）
1.2、 与 RFC 826 的关系
本文档不修改 RFC 826 中的任何协议规则。它不修改数据包格式或任何字段的含义。“数据包生成”和“数据包接收”的现有规则仍然完全按照 RFC 826 中的规定适用。
本文档通过指定以下内容扩展了 RFC 826：
(1) 配置接口时应生成特定的 ARP 请求，以发现该地址是否已在使用中，以及
(2) 应该对每个接收到的 ARP 数据包执行额外的简单测试，以促进被动的持续冲突检测。这个额外的测试不会在网络上产生额外的数据包开销（不发送额外的数据包）并且对主机的额外 CPU 负担可以忽略不计，因为每个实现 ARP 的主机*已经*需要根据数据包接收规则中指定的处理每个接收到的 ARP 数据包RFC 826。这些规则已经包括检查 ARP 数据包的“发送者 IP 地址”是否出现在主机 ARP 缓存的任何条目中；附加测试只是检查“发送方 IP 地址”是否是主机的*自己的* IP 地址，在许多架构上可能只需一条附加机器指令。
正如 RFC 826 中已经规定的那样，一个 ARP 请求数据包有两个功能，一个Assertion断言和一个question问题：
* 断言：
字段“ar$sha”（发送者硬件地址）和“ar$spa”（发送者协议地址）一起用作对事实的断言：所述协议地址映射到所述硬件地址。
* 问题：
字段“ar$tha”（目标硬件地址，零）和“ar$tpa”（目标协议地址）作为一个问题，询问所声明的协议地址，它映射到哪个硬件地址。
本文件阐明了有一个没有另一个意味着什么。
一些读者指出，要问任何真正纯粹的问题可能是不可能的；问任何问题必然会引发关于审讯者为什么想知道答案的猜测。就像有人指着一个空座位问：“有人坐吗？”暗示了一个不言而喻的“......因为如果不是那么我会”，这里也是如此。带有全零“发送方 IP 地址”的 ARP 探测可能表面上只是在问一个无辜的问题（“有人在使用这个地址吗？”），但一个知道 IPv4 地址冲突检测如何工作的智能实现应该能够识别这一点问题作为声明地址的前兆。
因此，如果该实施也在那个确切的时刻，在问同一个问题的过程中，它应该认识到他们不能都坐在同一个座位上，所以询问其他座位是谨慎的。
1.2.1、 广播 ARP 回复
在 IPv4 地址冲突检测 (ACD) 的某些应用中，使用广播而不是单播来传递 ARP 回复可能是有利的，因为这样可以比其他方式更快地检测到地址冲突。例如，“IPv4 链路本地地址的动态配置”[RFC3927] 完全按照此处指定的方式使用 ACD，但另外指定应使用广播发送 ARP 回复，因为在这种情况下，增加广播流量以换取改进的可靠性和容错性被认为是适当的。可能还有其他适合相同权衡的未来规范。更多细节在第 2.6 节“广播 ARP 回复”中给出。
RFC 826 暗示对 ARP 请求的回复通常使用单播传递，但也可以使用广播传递 ARP 回复。RFC 826 中的数据包接收规则指定应在检查“ar$op”字段之前*处理“ar$spa”字段的内容，因此任何正确实现 RFC 826 中指定的数据包接收算法的主机都将正确处理通过链路层广播传递的 ARP 回复。
1.3、 适用性
本规范适用于所有 IEEE 802 局域网 (Local Area Networks，LAN) [802]，包括以太网 [802.3]、令牌环 [802.5] 和 IEEE 802.11 无线 LAN [802.11]，以及其他运行的链路层技术数据速率至少为 1 Mb/s，往返延迟最多为一秒，并使用 ARP [RFC826] 从 IP 地址映射到链路层硬件地址。无论本文档在何处使用术语“IEEE 802”，该文本同样适用于任何这些网络技术。
支持 ARP 但以低于 1 Mb/s 的速率或高于 1 秒的延迟运行的链路层技术仍可在此协议下正常工作，但更多情况下可能需要处理在探测阶段完成后检测到的后期冲突。在这些类型的链路上，可能需要为以下参数指定不同的值：
(a) PROBE_NUM、PROBE_MIN 和 PROBE_MAX，ARP 探测的数量和间隔，在第 2.1 节中解释。
(b) ANNOUNCE_NUM 和 ANNOUNCE_INTERVAL，ARP 公告的数量和间隔，在第 2.3 节中解释。
(c) RATE_LIMIT_INTERVAL 和 MAX_CONFLICTS，控制可以尝试地址声明的最大速率，在第 2.1 节中解释。
(d) DEFEND_INTERVAL，冲突 ARP 之间的时间间隔，低于该时间间隔主机不得试图保护其地址，在第 2.4 节中解释。
不支持 ARP 的链路层技术可能能够使用其他技术来确定当前是否正在使用特定的 IP 地址。但是，为此类网络实施地址冲突检测超出了本文档的范围。
为了使本文档中指定的协议有效，链路上的所有主机都不需要实现它。对于实现此规范的给定主机以防止意外地址冲突，所需要的只是同一链路上的对等方正确实施 RFC 826 中给出的 ARP 协议。具体而言，当对等主机收到 ARP 请求时如果 ARP 请求的目标协议地址与该接口上配置的主机 IP 地址（其中之一）匹配，那么只要它正确响应格式正确的 ARP 应答，查询主机就能够检测到该地址已被使用。
本文档中的规范允许主机检测在同一物理链路上使用同一地址的两台主机之间的冲突。ACD 不会检测在不同物理链路上使用相同地址的两台主机之间的冲突，实际上它不应该检测。例如，地址 10.0.0.1 [RFC1918] 被全世界无数专用网络上的无数设备使用，这不是冲突，因为它们位于不同的链路上。只有当两个这样的设备连接到同一个链路时才会发生冲突，并且当这种情况发生时（有时会发生），这是 ACD 对检测和报告非常有用的情况的完美示例（和/或自动更正）此错误。
就本文档而言，如果满足以下条件，则认为一组主机“位于同一链路上”：
- 当该集合中的任何主机 A 使用单播、多播或广播向该集合中的任何其他主机 B 发送数据包时，整个链路层数据包有效负载未经修改地到达，并且
- 由该组主机中的任何主机通过该链路发送的广播可以被该组中的所有其他主机接收。
可以修改链路层 *header*，例如在令牌环源路由 [802.5] 中，但不能修改链路层 *payload*。特别是，如果任何转发数据包的设备修改了 IP 报文头或 IP 有效负载的任何部分，则不再认为该数据包位于同一链路上。这意味着数据包可以通过中继器、网桥、集线器或交换机等设备，并且仍被视为在本文档中位于同一链路上，但不能通过减少 TTL 的 IP 路由器等设备或以其他方式修改 IP 报文头。
本文档使用术语“主机”的地方，它同样适用于路由器或其他多宿主主机上的接口，无论主机/路由器当前是否正在转发数据包。在许多情况下，路由器将是关键的网络基础设施，其 IP 地址在当地广为人知，并且被认为是相对恒定的。例如，默认路由器的地址是 DHCP 服务器通常与其客户端通信的参数之一，并且（至少在 DHCP Reconfigure [RFC3203] 等机制得到广泛实施之前）DHCP 没有任何实用的方法如果地址发生变化，服务器会通知客户端。因此，对于此类设备，通过选择新的 IP 地址来处理冲突并不是一个好的选择。在这些情况下，第 2.4 节（“正在进行的地址冲突检测和地址防御”）中的选项 (c) 适用。
但是，即使手动为设备配置了固定地址，网络上的其他设备声称拥有相同的 IP 地址也会污染对等 ARP 缓存并阻止可靠通信，因此通知操作员仍然有帮助。如果在操作员设置固定手动地址时检测到冲突，则立即通知操作员是有帮助的；如果随后检测到冲突，通过一些适当的异步通信渠道通知操作员是有帮助的。即使无法通过冲突地址进行可靠通信，仍然可以通过其他仍在运行的通信通道通知操作员，例如通过路由器上的其他接口，通过动态 IPv4 链路本地地址，通过有效的 IPv6 地址，甚至通过一些完全不同的非 IP 技术，例如本地连接的屏幕或串行控制台。
2、 地址探测、宣布、冲突检测和防御
本节介绍了安全确定地址是否已在使用中的初始探测、宣布所选地址、正在进行的冲突检查以及可选使用广播 ARP 回复以提供更快的冲突检测。
2.1、 探测地址
在开始使用 IPv4 地址（无论是从手动配置、DHCP 还是其他方式接收）之前，实现此规范的主机必须通过广播 ARP Probe 数据包来测试该地址是否已在使用中。这也适用于以下情况：网络接口从非活动状态转换为活动状态、计算机从睡眠中唤醒、链路状态更改发出以太网电缆已连接的信号时、802.11 无线接口与新基站相关联时，或者当主机主动连接到逻辑链路时发生任何其他连接变化。
当然，主机不得定期执行此检查。如第 2.4 节所述，这将浪费网络带宽，并且由于主机能够被动地发现冲突而没有必要。
2.1.1、 探测详细信息
主机通过广播针对所需地址的 ARP 请求来探测地址是否已被使用。客户端必须用发送数据包的接口的硬件地址填写 ARP 请求的“发送者硬件地址”字段。“发送者 IP 地址”字段必须设置为全零；这是为了避免在地址已被另一台主机使用的情况下污染同一链路上其他主机中的 ARP 缓存。“目标硬件地址”字段被忽略，应该设置为全零。“目标 IP 地址”字段必须设置为被探测的地址。以这种方式构造的具有全零“发送方 IP 地址”的 ARP 请求称为“ARP 探测”。
当准备好开始探测时，主机应等待在 0 到 PROBE_WAIT 秒范围内统一选择的随机时间间隔，然后发送 PROBE_NUM 个探测包，这些探测包中的每一个随机且均匀地间隔，PROBE_MIN 到 PROBE_MAX 秒。这种初始随机延迟有助于确保同时启动的大量主机不会同时发送它们的初始探测数据包。
如果在此期间，从探测过程开始到发送最后一个探测包后的 ANNOUNCE_WAIT 秒，主机在执行探测的接口上接收到任何 ARP 包（请求*或*回复），其中包的 ' sender IP address' 是被探测的地址，那么主机必须将此地址视为正在被其他主机使用，并且应该向配置代理（人工操作员、DHCP 服务器等）指示建议的地址不是可以接受。
此外，如果在此期间主机收到任何 ARP 探测，其中数据包的“目标 IP 地址”是被探测的地址，并且数据包的“发送方硬件地址”不是任何主机接口的硬件地址，那么主机应该类似地将其视为地址冲突，并向配置代理发出错误信号，如上所述。如果两个（或更多）主机出于某种原因无意中配置了相同的地址，并且两者都同时在探测该地址以查看它是否可以安全使用，则可能会发生这种情况。
注意：检查数据包的“发送者硬件地址”不是任何主机接口的硬件地址很重要。某些类型的以太网集线器（通常称为“缓冲中继器”）和许多无线接入点可能会将任何接收到的广播数据包“重新广播”给所有接收者，包括原始发送者本身。因此，上述预防措施对于确保主机在看到自己的 ARP 数据包回显时不会感到困惑是必要的。
实现本规范的主机必须采取预防措施来限制它探测新候选地址的速率：如果主机在给定接口上遇到 MAX_CONFLICTS 或更多地址冲突，则主机必须限制它在其上探测新地址的速率此接口对每个 RATE_LIMIT_INTERVAL 的尝试新地址不超过一个。这是为了防止在病理性故障情况下发生灾难性的 ARP 风暴，例如有缺陷的 DHCP 服务器重复为每台请求的主机分配相同的地址。此限速规则不仅适用于在初始探测阶段经历的冲突，也适用于后来经历的冲突，如第 2.4 节“正在进行的地址冲突检测和地址防御”中所述。
如果在最后一个 ARP 探测传输后的 ANNOUNCE_WAIT 秒内没有收到冲突的 ARP 应答或 ARP 探测，则主机已成功确定可以安全使用所需的地址。
2.2、 在适当的网络技术上更短的超时
可能会出现比本文档要求的延迟更短的网络技术。随后的 IETF 出版物可能会为这些技术的 PROBE_WAIT、PROBE_NUM、PROBE_MIN 和 PROBE_MAX 的不同值提供指导。
如果出现链路上不同主机使用不同时序参数的情况，这不会导致任何问题。该协议不依赖于实现相同版本协议的链路上的所有主机；实际上，该协议根本不依赖于实现该协议的链路上的所有主机。所需要的只是所有主机都按照 RFC 826 中的规定实现 ARP，并正确回答它们收到的 ARP 请求。在不同的主机使用不同的时序参数的情况下，将会发生的只是一些主机将比其他主机更快地配置它们的接口。万一在地址探测阶段未检测到地址冲突，冲突仍将通过下面第 2.4 节中描述的持续地址冲突检测来检测。
2.3、 宣布地址
在探查确定可以安全使用所需地址后，实现此规范的主机必须随后通过广播 ANNOUNCE_NUM ARP 公告（间隔为 ANNOUNCE_INTERVAL 秒）来宣布它开始使用此地址。ARP 公告与上述 ARP 探测相同，只是现在发送方和目标 IP 地址都设置为主机新选择的 IPv4 地址。这些 ARP 公告的目的是确保链路上的其他主机没有旧的 ARP 缓存条目，这些条目是以前可能使用相同地址的其他主机留下的。主机可以在发送两个 ARP 公告中的第一个后立即开始合法地使用 IP 地址；第二个 ARP 公告的发送可以异步完成，与主机可能希望执行的其他网络操作并发。
2.4、 持续的地址冲突检测和地址防御
地址冲突检测不仅限于初始接口配置时间，当主机发送 ARP 探测时。地址冲突检测是一个持续的过程，只要主机正在使用地址，它就会一直有效。在任何时候，如果主机收到一个 ARP 数据包（请求*或*回复），其中“发送方 IP 地址”是在该接口上配置的主机自己的 IP 地址（其中之一），但“发送方硬件地址”不匹配任何主机自己的接口地址，则这是一个冲突的 ARP 数据包，表明其他主机也认为它正在有效地使用该地址。为了解决地址冲突，主机必须响应以下 (a)、(b) 或 (c) 中描述的冲突 ARP 数据包：
(a) 在接收到一个冲突的 ARP 数据包时，主机可以选择立即停止使用该地址，并向配置代理发出错误信号，如上所述。
(b) 如果主机当前有活动的 TCP 连接或其他原因更喜欢保持相同的 IPv4 地址，并且在最后的 DEFEND_INTERVAL 秒内没有看到任何其他冲突的 ARP 数据包，那么它可以选择尝试通过以下方式保护其地址记录收到冲突 ARP 数据包的时间，然后广播一个 ARP 公告，将自己的 IP 和硬件地址作为 ARP 的发送者地址，“目标 IP 地址”设置为自己的 IP 地址，然后“目标硬件地址”设置为全零。完成此操作后，主机可以继续正常使用该地址，而无需任何进一步的特殊操作。但是，如果这不是主机看到的第一个冲突 ARP 包，并且为前一个冲突 ARP 包记录的时间是最近的，在 DEFEND_INTERVAL 秒内，那么主机必须立即停止使用该地址并向配置代理发出错误信号如上所述。这是必要的，以确保两台主机不会陷入无限循环，两台主机都试图保护同一个地址。
(c) 如果主机已配置为在任何情况下都不应放弃其地址（可能是因为它是需要具有众所周知的稳定 IP 地址的设备，例如链路的默认路由器或DNS 服务器）然后它可以选择无限期地保护它的地址。如果这样的主机收到一个冲突的 ARP 数据包，那么它应该采取适当的步骤从 ARP 数据包中记录有用的信息，例如源以太网地址，并将问题通知管理员。应适当控制此类通知的数量，以防止生成过多的错误报告。如果主机最近没有看到任何其他冲突的 ARP 数据包，在最后的 DEFEND_INTERVAL 秒内，那么它必须记录收到冲突的 ARP 数据包的时间，然后广播一个单一的 ARP 公告，给出它自己的 IP 和硬件地址。完成此操作后，主机可以继续正常使用该地址，而无需任何进一步的特殊操作。然而，如果这不是主机看到的第一个冲突的 ARP 包，并且为前一个冲突的 ARP 包记录的时间在 DEFEND_INTERVAL 秒内，那么主机不得发送另一个防御性 ARP 公告。这是必要的，以确保两个配置错误的主机不会陷入无限循环，在它们都试图保护同一个地址时，用广播流量淹没网络。
希望提供可靠网络操作的主机必须响应上述 (a)、(b) 或 (c) 中所述的冲突 ARP 数据包。忽略冲突的 ARP 数据包会导致看似随机的网络故障，这些故障可能难以诊断，并且对人类用户来说非常令人沮丧。
强制地址重新配置可能具有破坏性，导致 TCP（和其他传输层）连接中断。然而，这种中断应该是非常罕见的，如果发生无意的地址重复，那么通信中断是不可避免的。同一网络上使用相同 IP 地址的两台不同主机不可能可靠运行。
在由于冲突而放弃地址之前，主机应该积极尝试使用该地址重置任何现有连接。如第 5 节所述，这减轻了地址重新配置带来的一些安全威胁。
对于大多数不需要固定 IP 地址的客户端机器，一旦检测到冲突，立即请求配置代理（人类用户、DHCP 客户端等）配置新地址是尽快恢复有用通信的最佳方法尽可能。上述广播单个 ARP 公告以保护地址的机制通过帮助提高两个冲突主机之一可能能够保留其地址的机会，在一定程度上缓解了该问题。
2.5、 持续检测
从主机发送它的第一个 ARP 公告开始，直到它停止使用该 IP 地址，主机必须以 ARP 规范 [RFC826] 要求的通常方式回答 ARP 请求。具体来说，这意味着每当主机接收到 ARP 请求时，这不是上文第 2.4 节所述的冲突 ARP 数据包，其中 ARP 请求的“目标 IP 地址”是主机自己的 IP 地址（之一）在该接口上配置，主机必须以 RFC 826 中所述的 ARP 回复进行响应。这同样适用于具有非零发送方 IP 地址的标准 ARP 请求和具有全零发送方 IP 地址的探测请求。
2.6、 广播 ARP 回复
在手动分配地址的精心运行的网络中，或者具有可靠 DHCP 服务器和可靠 DHCP 客户端的网络中，地址冲突只应在极少数故障情况下发生，因此上文第 2.4 节中描述的被动监控就足够了。如果两台主机使用相同的 IP 地址，那么迟早一台主机或另一台将广播一个 ARP 请求，另一台将看到该请求，从而检测到并解决冲突。
但是，冲突配置可能会在检测到之前持续一小段时间。假设两台主机 A 和 B 无意中因为某种原因被分配了同一个 IP 地址 X，所以在接口配置时都没有检测到冲突。假设现在通信链路已恢复，第三台主机 C 广播地址 X 的 ARP 请求。主机 A 和 B 都没有意识到任何冲突，都将向主机 C 发送单播 ARP 回复。主机 C 将看到这两个回复，并且可能有点困惑，但是主机 A 和 B 都不会看到对方的回复，也不会立即检测到有冲突需要解决。主机 A 和 B 将继续不知道冲突，直到其中一个或其他广播自己的 ARP 请求。
如果需要更快的冲突检测，这可以通过让主机使用链路级广播发送 ARP 回复来实现，而不是仅通过广播发送 ARP 请求，并通过单播发送回复。不建议将其用于一般用途，但在 IPv4 ACD 上构建的其他规范可能会选择指定广播 ARP 回复（如果合适）。例如，“IPv4 链路本地地址的动态配置”[RFC3927] 指定广播 ARP 回复，因为在这种情况下，使用 IPv4 ACD 检测地址冲突不仅仅是检测其他配置机制故障的备用预防措施；使用 IPv4 ACD 检测地址冲突是唯一的配置机制。
使用广播发送 ARP 回复确实会增加广播流量，但在最坏的情况下不会超过两倍。在 ARP 的传统用法中，单播 ARP 回复仅在响应广播 ARP 请求时发生，因此通过广播发送这些消息意味着我们最多生成一个广播回复以响应每个现有的广播请求。在许多网络上，ARP 流量在总流量中所占的比例微不足道，将其翻倍并没有实际意义。然而，这可能并非适用于所有网络，因此不应普遍使用广播 ARP 回复。如果更快的冲突检测的好处超过了增加广播流量和增加参与网络主机上的数据包处理负载的成本，则应使用广播 ARP 回复。
3、 为什么使用ARP请求报文而不是ARP应答报文进行ARP通告？
在 IETF 从 2000 年到 2008 年审议 IPv4 地址冲突检测期间，一个反复被问到的问题是，“难道 ARP 公告不应该使用免费的 ARP 应答数据包来执行吗？”
从表面上看，这似乎是合理的。传统的 ARP 回复是对问题的回答。如果事实上没有提出任何问题，那么将这样的答复描述为免费是合理的。
“免费回复”一词似乎完全适用于 ARP 公告：对实际上没有人提出的隐含问题的回答。
不管这在原则上看起来多么合理，实际上有两个原因使争论倾向于使用 ARP 请求数据包。一是历史先例，二是实用主义。
历史先例是（如上文第 4 节所述）免费 ARP 在 Stevens Networking [Ste94] 中记录为使用 ARP 请求数据包。BSD Unix、Microsoft Windows、Mac OS 9、Mac OS X 等都使用 Stevens 中描述的 ARP 请求数据包。在这个阶段，试图强制他们都切换到使用 ARP 回复数据包将是徒劳的。
实际原因是 ARP 请求数据包更有可能与更多现有的 ARP 实现一起正常工作，其中一些可能无法完全正确地实现 RFC 826。RFC 826 中的数据包接收规则指出，操作码是在数据包处理中检查的最后一件事，所以这真的无关紧要，但可能会有“创造性”实现根据“ar$op”具有不同的数据包处理字段，并且有几个原因导致它们比免费 ARP 回复更有可能接受免费 ARP 请求：
* 不正确的 ARP 实现可能会认为 ARP 回复仅通过单播发送。RFC 826 没有说明这一点，但不正确的实现可能会假设它；“最不意外原则”规定，如果有两种或多种方法可以解决网络问题，而这些方法在其他方面同样好，那么具有最少异常属性的一种方法可能与现有实现的互操作性问题最少。ARP Announcement 需要向链路上的所有主机广播信息。由于 ARP 请求数据包始终是广播的，而 ARP 应答数据包不是，因此通过广播接收 ARP 请求数据包比通过广播接收 ARP 应答数据包更令人惊讶。
* 不正确的 ARP 实现可能会期望仅接收 ARP 回复以响应该实现最近发出的 ARP 请求。意外的主动回复可能会被忽略。
* 不正确的 ARP 实现可能会忽略 'ar$tha' 与其硬件地址不匹配的 ARP 回复。
* 不正确的 ARP 实现可能会忽略 'ar$tpa' 与其 IP 地址不匹配的 ARP 回复。
总之，不正确的 ARP 实现可能会拒绝 ARP 回复（通常是由于客户端请求而发生），而不是 ARP 请求（已经预期会主动发生）。
4、 历史笔记
一些读者声称，如 Stevens [Ste94] 中所述，“免费 ARP”提供重复地址检测，从而不需要 ACD。这是不正确的。Stevens 所描述的免费 ARP 与本文档中使用更具描述性的术语“ARP 公告”所指的数据包完全相同。这种传统的免费 ARP 实现在首次配置接口时仅发送一个 ARP 公告。结果是受害者（现有地址持有者）记录了一个错误，而攻击者继续操作，通常甚至没有发现任何问题。然后两台机器通常会继续尝试使用相同的 IP 地址，但由于它们都在不断地重置对方的 TCP 连接而无法正常运行。预计人类管理员会注意到受害者机器上的日志消息并在事后修复损坏。通常，这必须通过物理访问相关机器来完成，因为在这种状态下，两者都无法保持 TCP 连接打开足够长的时间来通过网络执行任何有用的操作。
Gratuitous ARP 实际上并没有提供有效的重复地址检测功能，并且（截至 2008 年 1 月）Google 搜索短语“Gratuitous ARP”的许多热门结果都是描述如何禁用它的文章。
但是，IPv4 地址冲突检测的实施者应该意识到，在撰写本文时，免费 ARP 仍在广泛部署。本文档第 2.1 节和第 2.4 节中描述的步骤有助于使主机能够抵御错误配置和地址冲突，即使其他主机*不*按照相同的规则运行。
5、 安全考虑
IPv4 地址冲突检测 (ACD) 基于 ARP [RFC826]，它继承了该协议的安全漏洞。恶意主机可能会在网络上发送欺骗性的 ARP 包，干扰其他主机的正常运行。例如，主机很容易通过提供自己硬件地址的回复来回答所有 ARP 请求，从而声称拥有网络上每个地址的所有权。
该规范使现有的 ARP 漏洞不会变得更糟，并且在某些方面使其变得更好：实现该规范的主机不会尝试自动重新配置，或者至少通知人类用户正在发生的事情，而不是默默地失败而没有说明原因。
如果主机愿意选择一个新地址来响应 ARP 冲突，如第 2.4 节 (a) 小节所述，这可能会使同一链路上的恶意攻击者更容易劫持 TCP 连接。让主机在放弃地址之前主动重置任何现有连接有助于降低这种风险。
6、 致谢
本文档是 Zeroconf 工作组关于 IPv4 链路本地寻址 [RFC3927] 讨论的结果，其中许多参与者不清楚链路本地地址管理的哪些元素是特定于该特定问题空间的（例如，随机选择地址），以及哪些元素是通用的并且适用于所有 IPv4 地址配置机制（例如，地址冲突的检测）。以下人员在该工作和/或本文档的后续编辑过程中提出了宝贵意见：Bernard Aboba、Randy Bush、Jim Busse、James Carlson、Alan Cox、Spencer Dawkins、Pavani Diwanji、Ralph Droms、Donald Eastlake III、亚历克斯·埃尔德、斯蒂芬·法瑞尔、彼得·福特、斯宾塞·贾卡隆、乔什·格雷斯利、埃里克·格特曼、迈伦·哈蒂格、迈克·赫德、休·霍尔布鲁克、理查德·约翰逊、金容云、马克·克罗奇马尔、罗德·洛佩兹、罗里·麦奎尔、萨蒂什·蒙德拉、托马斯·纳滕Erik Nordmark、Randy Presuhn、Howard Ridenour、Pekka Savola、Daniel Senie、Dieter Siegmund、Valery Smyslov、Mark Townsley、Oleg Tychev 和 Ryan Troll。
7、 参考文献
7.1、 规范性参考
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2、 参考资料
[802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [802.3] ISO/IEC 8802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3-1996), 1996. [802.5] ISO/IEC 8802-5 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 5: Token ring access method and physical layer specifications, (also ANSI/IEEE Std 802.5-1998), 1998. [802.11] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1999, 1999. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001. [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [Ste94] W. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.
完整的版权声明
版权所有 (C) IETF 信托 (2008)。
本文档受 BCP 78 中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
本文档和此处包含的信息按“原样”提供，贡献者、他/她代表或由（如果有）赞助的组织、互联网协会、IETF 信托和互联网工程任务组否认所有明示或暗示的保证，包括但不限于使用此处信息不会侵犯任何权利或任何暗示的适销性或特定用途适用性的保证。
知识产权
IETF 对可能声称与本文档中描述的技术的实施或使用有关的任何知识产权或其他权利的有效性或范围或根据此类权利可能或可能不会获得任何许可的程度不持任何立场能得到的;它也不表示它已做出任何独立努力来确定任何此类权利。有关 RFC 文档中权利的程序信息，请参见 BCP 78 和 BCP 79。
向 IETF 秘书处披露的 IPR 副本，以及任何保证可用的许可，或试图获得本规范的实施者或用户使用此类专有权利的一般许可或许可的结果来自位于 http://www.ietf.org/ipr 的 IETF 在线 IPR 存储库。
IETF 邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施该标准可能需要的技术的其他专有权利。请将信息发送至 IETF，地址为 ietf-ipr@ietf.org。
