Network Working Group S. Cheshire
Request for Comments: 5227 Apple Inc.
Updates: 826 July 2008
Category: Standards Track
Network Working Group S. Cheshire
Request for Comments: 5227 Apple Inc.
Updates: 826 July 2008
Category: Standards Track
IPv4 Address Conflict Detection
IPv4地址冲突检测
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination), problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect, after the fact, that it has happened, so that the host or administrator may respond to rectify the problem.
当同一链路上的两台主机试图同时使用相同的IPv4地址时（除非在极少数特殊情况下通过事先协调安排），一台或两台主机就会出现问题。本文档描述了（i）主机可以提前采取的一种简单预防措施，以帮助防止这种错误配置的发生，以及（ii）如果这种错误配置确实发生，主机可以通过一种简单的机制，在发生错误后被动地检测到它已经发生，以便主机或管理员可以响应纠正问题。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions and Terminology Used in This Document ..........4
1.2. Relationship to RFC 826 ....................................5
1.2.1. Broadcast ARP Replies ...............................7
1.3. Applicability ..............................................7
2. Address Probing, Announcing, Conflict Detection, and Defense ....9
2.1. Probing an Address ........................................10
2.1.1. Probe Details ......................................10
2.2. Shorter Timeouts on Appropriate Network Technologies ......11
2.3. Announcing an Address .....................................12
2.4. Ongoing Address Conflict Detection and Address Defense ....12
2.5. Continuing Operation ......................................14
2.6. Broadcast ARP Replies .....................................14
3. Why Are ARP Announcements Performed Using ARP Request
Packets and Not ARP Reply Packets? .............................15
4. Historical Note ................................................17
5. Security Considerations ........................................17
6. Acknowledgments ................................................18
7. References .....................................................18
7.1. Normative References ......................................18
7.2. Informative References ....................................19
1. Introduction ....................................................2
1.1. Conventions and Terminology Used in This Document ..........4
1.2. Relationship to RFC 826 ....................................5
1.2.1. Broadcast ARP Replies ...............................7
1.3. Applicability ..............................................7
2. Address Probing, Announcing, Conflict Detection, and Defense ....9
2.1. Probing an Address ........................................10
2.1.1. Probe Details ......................................10
2.2. Shorter Timeouts on Appropriate Network Technologies ......11
2.3. Announcing an Address .....................................12
2.4. Ongoing Address Conflict Detection and Address Defense ....12
2.5. Continuing Operation ......................................14
2.6. Broadcast ARP Replies .....................................14
3. Why Are ARP Announcements Performed Using ARP Request
Packets and Not ARP Reply Packets? .............................15
4. Historical Note ................................................17
5. Security Considerations ........................................17
6. Acknowledgments ................................................18
7. References .....................................................18
7.1. Normative References ......................................18
7.2. Informative References ....................................19
Historically, accidentally configuring two Internet hosts with the same IP address has often been an annoying and hard-to-diagnose problem.
从历史上看，意外地将两个Internet主机配置为相同的IP地址通常是一个恼人且难以诊断的问题。
This is unfortunate, because the existing Address Resolution Protocol (ARP) provides an easy way for a host to detect this kind of misconfiguration and report it to the user. The DHCP specification [RFC2131] briefly mentions the role of ARP in detecting misconfiguration, as illustrated in the following three excerpts from RFC 2131:
这是不幸的，因为现有的地址解析协议（ARP）为主机提供了一种简单的方法来检测这种错误配置并向用户报告。DHCP规范[RFC2131]简要地提到了ARP在检测错误配置中的作用，如RFC2131的以下三个摘录所示：
o the client SHOULD probe the newly received address, e.g., with ARP
o 客户端应探测新收到的地址，例如，使用ARP
o The client SHOULD perform a final check on the parameters (e.g., ARP for allocated network address)
o 客户端应对参数进行最终检查（例如，分配网络地址的ARP）
o If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server
o 如果客户端检测到地址已在使用中（例如，通过使用ARP），则客户端必须向服务器发送DHCPDecend消息
Unfortunately, the DHCP specification does not give any guidance to implementers concerning the number of ARP packets to send, the interval between packets, the total time to wait before concluding that an address may safely be used, or indeed even which kinds of packets a host should be listening for, in order to make this determination. It leaves unspecified the action a host should take if, after concluding that an address may safely be used, it subsequently discovers that it was wrong. It also fails to specify what precautions a DHCP client should take to guard against pathological failure cases, such as a DHCP server that repeatedly OFFERs the same address, even though it has been DECLINEd multiple times.
不幸的是，DHCP规范没有就要发送的ARP数据包的数量、数据包之间的间隔、在得出可以安全使用地址之前等待的总时间，或者甚至主机应该监听哪种数据包来进行此确定向实现者提供任何指导。如果在断定某个地址可以安全使用后，主机随后发现该地址是错误的，那么该主机应该采取什么行动，这一点未予明确。它也没有指定DHCP客户端应该采取什么预防措施来防止病理性故障，例如DHCP服务器重复提供相同的地址，即使它已被拒绝多次。
The authors of the DHCP specification may have been justified in thinking at the time that the answers to these questions seemed too simple, obvious, and straightforward to be worth mentioning, but unfortunately this left some of the burden of protocol design to each individual implementer. This document seeks to remedy this omission by clearly specifying the required actions for:
DHCP规范的作者当时可能认为，这些问题的答案似乎过于简单、明显和直截了当，不值得一提，但不幸的是，这将协议设计的一些负担留给了每个实现者。本文件旨在通过明确规定以下方面所需的措施来弥补这一遗漏：
1. Determining whether use of an address is likely to lead to an addressing conflict. This includes (a) the case where the address is already actively in use by another host on the same link, and (b) the case where two hosts are inadvertently about to begin using the same address, and both are simultaneously in the process of probing to determine whether the address may safely be used (Section 2.1.).
1. 确定地址的使用是否可能导致地址冲突。这包括（a）地址已被同一链路上的另一主机积极使用的情况，以及（b）两台主机无意中即将开始使用同一地址的情况，并且两台主机同时处于探测过程中，以确定地址是否可以安全使用（第2.1节）。
2. Subsequent passive detection that another host on the network is inadvertently using the same address. Even if all hosts observe precautions to avoid using an address that is already in use, conflicts can still occur if two hosts are out of communication at the time of initial interface configuration. This could occur with wireless network interfaces if the hosts are temporarily out of range, or with Ethernet interfaces if the link between two Ethernet hubs is not functioning at the time of address configuration. A well-designed host will handle not only conflicts detected during interface configuration, but also conflicts detected later, for the entire duration of the time that the host is using the address (Section 2.4.).
2. 网络上的另一台主机无意中使用相同地址的后续被动检测。即使所有主机都遵守预防措施以避免使用已在使用的地址，如果在初始接口配置时两台主机失去通信，仍可能发生冲突。如果主机暂时超出范围，则无线网络接口可能会出现这种情况；如果两个以太网集线器之间的链路在地址配置时不起作用，则以太网接口可能会出现这种情况。设计良好的主机不仅可以处理在接口配置期间检测到的冲突，还可以在主机使用该地址的整个过程中处理以后检测到的冲突（第2.4节）。
3. Rate-limiting of address acquisition attempts in the case of an excessive number of repeated conflicts (Section 2.1.).
3. 在重复冲突次数过多的情况下，地址获取尝试的速率限制（第2.1节）。
The utility of IPv4 Address Conflict Detection (ACD) is not limited to DHCP clients. No matter how an address was configured, whether via manual entry by a human user, via information received from a DHCP server, or via any other source of configuration information,
IPv4地址冲突检测（ACD）的实用程序不限于DHCP客户端。无论地址是如何配置的，无论是通过人工输入、通过从DHCP服务器接收的信息还是通过任何其他配置信息源，
detecting conflicts is useful. Upon detecting a conflict, the configuring agent should be notified of the error. In the case where the configuring agent is a human user, that notification may take the form of an error message on a screen, a Simple Network Management Protocol (SNMP) notification, or an error message sent via text message to a mobile phone. In the case of a DHCP server, that notification takes the form of a DHCP DECLINE message sent to the server. In the case of configuration by some other kind of software, that notification takes the form of an error indication to the software in question, to inform it that the address it selected is in conflict with some other host on the network. The configuring software may choose to cease network operation, or it may automatically select a new address so that the host may re-establish IP connectivity as soon as possible.
检测冲突非常有用。在检测到冲突时，应将错误通知配置代理。在配置代理是人类用户的情况下，该通知可以采取屏幕上的错误消息、简单网络管理协议（SNMP）通知或通过文本消息发送到移动电话的错误消息的形式。对于DHCP服务器，该通知采用发送到服务器的DHCP拒绝消息的形式。在由某种其他类型的软件进行配置的情况下，该通知以错误指示的形式发送给相关软件，通知其所选地址与网络上的某个其他主机冲突。配置软件可以选择停止网络操作，也可以自动选择新地址，以便主机尽快重新建立IP连接。
Allocation of IPv4 Link-Local Addresses [RFC3927] can be thought of as a special case of this mechanism, where the configuring agent is a pseudo-random number generator, and the action it takes upon being notified of a conflict is to pick a different random number and try again. In fact, this is exactly how IPv4 Link-Local Addressing was implemented in Mac OS 9 back in 1998. If the DHCP client failed to get a response from any DHCP server, it would simply make up a fake response containing a random 169.254.x.x address. If the ARP module reported a conflict for that address, then the DHCP client would try again, making up a new random 169.254.x.x address as many times as was necessary until it succeeded. Implementing ACD as a standard feature of the networking stack has the side effect that it means that half the work for IPv4 Link-Local Addressing is already done.
IPv4链路本地地址分配[RFC3927]可视为该机制的一种特殊情况，其中配置代理是一个伪随机数生成器，在收到冲突通知时，它采取的行动是选择一个不同的随机数并重试。事实上，这正是1998年Mac OS 9中IPv4链路本地寻址的实现方式。如果DHCP客户端无法从任何DHCP服务器获得响应，它只会生成一个包含随机169.254.x.x地址的假响应。如果ARP模块报告该地址存在冲突，则DHCP客户端将重试，根据需要多次创建新的随机169.254.x.x地址，直到成功。将ACD实现为网络堆栈的标准功能会产生副作用，这意味着IPv4链路本地寻址的一半工作已经完成。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照“RFC中用于指示需求水平的关键词”[RFC2119]中的描述进行解释。
Wherever this document uses the term 'sender IP address' or 'target IP address' in the context of an ARP packet, it is referring to the fields of the ARP packet identified in the ARP specification [RFC826] as 'ar$spa' (Sender Protocol Address) and 'ar$tpa' (Target Protocol Address), respectively. For the usage of ARP described in this document, each of these fields always contains an IPv4 address.
当本文件在ARP数据包的上下文中使用术语“发送方IP地址”或“目标IP地址”时，它指的是ARP规范[RFC826]中标识为“ar$spa”（发送方协议地址）和“ar$tpa”（目标协议地址）的ARP数据包字段。对于本文档中描述的ARP使用，每个字段始终包含一个IPv4地址。
In this document, the term 'ARP Probe' is used to refer to an ARP Request packet, broadcast on the local link, with an all-zero 'sender IP address'. The 'sender hardware address' MUST contain the hardware address of the interface sending the packet. The 'sender IP address' field MUST be set to all zeroes, to avoid polluting ARP caches in
在本文档中，术语“ARP Probe”用于指在本地链路上广播的ARP请求数据包，其“发送方IP地址”为零。“发送方硬件地址”必须包含发送数据包的接口的硬件地址。“发送方IP地址”字段必须设置为全零，以避免污染中的ARP缓存
other hosts on the same link in the case where the address turns out to be already in use by another host. The 'target hardware address' field is ignored and SHOULD be set to all zeroes. The 'target IP address' field MUST be set to the address being probed. An ARP Probe conveys both a question ("Is anyone using this address?") and an implied statement ("This is the address I hope to use.").
同一链路上的其他主机，如果该地址已被其他主机使用。“目标硬件地址”字段被忽略，应设置为全零。“目标IP地址”字段必须设置为要探测的地址。ARP探测同时传递一个问题（“有人使用这个地址吗？”）和一个隐含的语句（“这是我希望使用的地址”）。
In this document, the term 'ARP Announcement' is used to refer to an ARP Request packet, broadcast on the local link, identical to the ARP Probe described above, except that both the sender and target IP address fields contain the IP address being announced. It conveys a stronger statement than an ARP Probe, namely, "This is the address I am now using."
在本文档中，术语“ARP公告”用于指在本地链路上广播的ARP请求包，与上述ARP探测相同，但发送方和目标IP地址字段均包含被公告的IP地址。它传达了一个比ARP探测器更强的声明，即“这是我现在使用的地址。”
The following timing constants used in this protocol are referenced in Section 2, which describes the operation of the protocol in detail. (Note that the values listed here are fixed constants; they are not intended to be modifiable by implementers, operators, or end users. These constants are given symbolic names here to facilitate the writing of future standards that may want to reference this document with different values for these named constants; however, at the present time no such future standards exist.)
本协议中使用的以下定时常数在第2节中引用，该节详细描述了协议的操作。（请注意，此处列出的值是固定常数；实施者、操作员或最终用户不可修改这些常数。此处给出这些常数的符号名称，以便于编写未来的标准，这些标准可能希望使用这些命名常数的不同值引用本文档；但是，目前没有这种未来的标准是存在的。）
PROBE_WAIT 1 second (initial random delay) PROBE_NUM 3 (number of probe packets) PROBE_MIN 1 second (minimum delay until repeated probe) PROBE_MAX 2 seconds (maximum delay until repeated probe) ANNOUNCE_WAIT 2 seconds (delay before announcing) ANNOUNCE_NUM 2 (number of Announcement packets) ANNOUNCE_INTERVAL 2 seconds (time between Announcement packets) MAX_CONFLICTS 10 (max conflicts before rate-limiting) RATE_LIMIT_INTERVAL 60 seconds (delay between successive attempts) DEFEND_INTERVAL 10 seconds (minimum interval between defensive ARPs) 1.2. Relationship to RFC 826
探测等待1秒（初始随机延迟）探测数量3（探测数据包数量）探测最少1秒（重复探测之前的最小延迟）探测最多2秒（重复探测之前的最大延迟）宣布等待2秒（宣布之前的延迟）宣布数量2（宣布数据包数量）宣布间隔2秒（公告数据包之间的时间）最大冲突10（速率限制前的最大冲突）速率限制间隔60秒（连续尝试之间的延迟）防御间隔10秒（防御ARP之间的最小间隔）1.2.与RFC 826的关系
This document does not modify any of the protocol rules in RFC 826. It does not modify the packet format, or the meaning of any of the fields. The existing rules for "Packet Generation" and "Packet Reception" still apply exactly as specified in RFC 826.
本文档不修改RFC 826中的任何协议规则。它不会修改数据包格式或任何字段的含义。“包生成”和“包接收”的现有规则仍然完全适用于RFC 826中指定的规则。
This document expands on RFC 826 by specifying:
本文件在RFC 826的基础上进行了扩展，具体说明如下：
(1) that a specific ARP Request should be generated when an interface is configured, to discover if the address is already in use, and
(1) 配置接口时应生成特定的ARP请求，以发现地址是否已在使用，以及
(2) an additional trivial test that should be performed on each received ARP packet, to facilitate passive ongoing conflict detection. This additional test creates no additional packet overhead on the network (no additional packets are sent) and negligible additional CPU burden on hosts, since every host implementing ARP is *already* required to process every received ARP packet according to the Packet Reception rules specified in RFC 826. These rules already include checking to see if the 'sender IP address' of the ARP packet appears in any of the entries in the host's ARP cache; the additional test is simply to check to see if the 'sender IP address' is the host's *own* IP address, potentially as little as a single additional machine instruction on many architectures.
(2) 对每个接收到的ARP数据包进行额外的简单测试，以便于进行被动冲突检测。由于每个实现ARP的主机*已经*需要根据RFC 826中规定的数据包接收规则处理每个接收到的ARP数据包，因此该附加测试不会在网络上产生额外的数据包开销（不会发送额外的数据包），主机上的CPU负担可以忽略不计。这些规则已经包括检查ARP数据包的“发送方IP地址”是否出现在主机ARP缓存中的任何条目中；额外的测试只是检查“发送方IP地址”是否是主机的*自己的*IP地址，在许多体系结构上可能只有一条额外的机器指令。
As already specified in RFC 826, an ARP Request packet serves two functions, an assertion and a question:
如RFC 826中所述，ARP请求包提供两个功能，一个断言和一个问题：
* Assertion: The fields 'ar$sha' (Sender Hardware Address) and 'ar$spa' (Sender Protocol Address) together serve as an assertion of a fact: that the stated Protocol Address is mapped to the stated Hardware Address.
* 断言：字段“ar$sha”（发送方硬件地址）和“ar$spa”（发送方协议地址）一起作为一个事实的断言：声明的协议地址映射到声明的硬件地址。
* Question: The fields 'ar$tha' (Target Hardware Address, zero) and 'ar$tpa' (Target Protocol Address) serve as a question, asking, for the stated Protocol Address, to which Hardware Address it is mapped.
* 问题：“ar$tha”（目标硬件地址，零）和“ar$tpa”（目标协议地址）字段用作问题，询问所述协议地址，它映射到哪个硬件地址。
This document clarifies what it means to have one without the other.
本文件阐明了一个没有另一个的含义。
Some readers pointed out that it is probably impossible to ask any truly pure question; asking any question necessarily invites speculation about why the interrogator wants to know the answer. Just as someone pointing to an empty seat and asking, "Is anyone sitting here?" implies an unspoken "... because if not then I will," the same is true here. An ARP Probe with an all-zero 'sender IP address' may ostensibly be merely asking an innocent question ("Is anyone using this address?"), but an intelligent implementation that knows how IPv4 Address Conflict Detection works should be able to recognize this question as the precursor to claiming the address.
一些读者指出，可能不可能提出任何真正纯粹的问题；问任何问题都必然会引起猜测，询问者为什么想知道答案。正如有人指着一个空座位问：“有人坐在这里吗？”这意味着一个潜台词“……如果没有，我会的”，这里也是如此。具有全零“发送方IP地址”的ARP探测器表面上可能只是在问一个无辜的问题（“有人使用此地址吗？”），但了解IPv4地址冲突检测工作原理的智能实现应该能够将此问题视为声明该地址的前提。
Consequently, if that implementation is also, at that exact moment, in the process of asking the very same question, it should recognize that they can't both sit in the same seat, so it would be prudent to ask about some other seat.
因此，如果该实施也在同一时刻，在提出同一个问题的过程中，它应该认识到他们不能坐在同一个座位上，因此谨慎的做法是询问其他座位。
In some applications of IPv4 Address Conflict Detection (ACD), it may be advantageous to deliver ARP Replies using broadcast instead of unicast because this allows address conflicts to be detected sooner than might otherwise happen. For example, "Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927] uses ACD exactly as specified here, but additionally specifies that ARP Replies should be sent using broadcast, because in that context the trade-off of increased broadcast traffic in exchange for improved reliability and fault-tolerance was deemed to be an appropriate one. There may be other future specifications where the same trade-off is appropriate. Additional details are given in Section 2.6, "Broadcast ARP Replies".
在IPv4地址冲突检测（ACD）的某些应用程序中，使用广播而不是单播来传递ARP应答可能是有利的，因为这样可以比其他方式更快地检测到地址冲突。例如，“IPv4链路本地地址的动态配置”[RFC3927]完全按照此处的规定使用ACD，但另外指定应使用广播发送ARP回复，因为在这种情况下，增加广播流量以换取提高可靠性和容错性被认为是适当的。将来可能会有其他规范，在这些规范中，同样的权衡是合适的。第2.6节“广播ARP回复”中给出了其他详细信息。
RFC 826 implies that replies to ARP Requests are usually delivered using unicast, but it is also acceptable to deliver ARP Replies using broadcast. The Packet Reception rules in RFC 826 specify that the content of the 'ar$spa' field should be processed *before* examining the 'ar$op' field, so any host that correctly implements the Packet Reception algorithm specified in RFC 826 will correctly handle ARP Replies delivered via link-layer broadcast.
RFC 826意味着对ARP请求的回复通常使用单播发送，但也可以使用广播发送ARP回复。RFC 826中的数据包接收规则规定，在*检查“ar$op”字段之前，*应处理“ar$spa”字段的内容，因此任何正确实现RFC 826中指定的数据包接收算法的主机都将正确处理通过链路层广播发送的ARP回复。
This specification applies to all IEEE 802 Local Area Networks (LANs) [802], including Ethernet [802.3], Token-Ring [802.5], and IEEE 802.11 wireless LANs [802.11], as well as to other link-layer technologies that operate at data rates of at least 1 Mb/s, have a round-trip latency of at most one second, and use ARP [RFC826] to map from IP addresses to link-layer hardware addresses. Wherever this document uses the term "IEEE 802", the text applies equally to any of these network technologies.
本规范适用于所有IEEE 802局域网（LAN）[802]，包括以太网[802.3]、令牌环[802.5]和IEEE 802.11无线局域网[802.11]，以及以至少1 Mb/s的数据速率运行、具有最多1秒的往返延迟且使用ARP[RFC826]的其他链路层技术从IP地址映射到链路层硬件地址。本文件使用术语“IEEE 802”时，本文本同样适用于任何此类网络技术。
Link-layer technologies that support ARP but operate at rates below 1 Mb/s or latencies above one second will still work correctly with this protocol, but more often may have to handle late conflicts detected after the Probing phase has completed. On these kinds of links, it may be desirable to specify different values for the following parameters:
支持ARP但以低于1 Mb/s的速率运行或延迟超过1秒的链路层技术仍能正确使用此协议，但更多情况下可能需要处理探测阶段完成后检测到的延迟冲突。在这些类型的链路上，可能需要为以下参数指定不同的值：
(a) PROBE_NUM, PROBE_MIN, and PROBE_MAX, the number of, and interval between, ARP Probes, explained in Section 2.1.
(a) PROBE_NUM、PROBE_MIN和PROBE_MAX，ARP探测的数量和间隔，如第2.1节所述。
(b) ANNOUNCE_NUM and ANNOUNCE_INTERVAL, the number of, and interval between, ARP Announcements, explained in Section 2.3.
(b) 通告数量和通告间隔，ARP通告的数量和间隔，如第2.3节所述。
(c) RATE_LIMIT_INTERVAL and MAX_CONFLICTS, controlling the maximum rate at which address claiming may be attempted, explained in Section 2.1.
(c) RATE_LIMIT_INTERVAL和MAX_冲突，控制可能尝试地址声明的最大速率，如第2.1节所述。
(d) DEFEND_INTERVAL, the time interval between conflicting ARPs below which a host MUST NOT attempt to defend its address, explained in Section 2.4.
(d) Defense_INTERVAL，冲突ARP之间的时间间隔，低于此时间间隔主机不得尝试保护其地址，如第2.4节所述。
Link-layer technologies that do not support ARP may be able to use other techniques for determining whether a particular IP address is currently in use. However, implementing Address Conflict Detection for such networks is outside the scope of this document.
不支持ARP的链路层技术可以使用其他技术来确定特定IP地址当前是否正在使用。但是，为此类网络实施地址冲突检测不在本文档的范围之内。
For the protocol specified in this document to be effective, it is not necessary that all hosts on the link implement it. For a given host implementing this specification to be protected against accidental address conflicts, all that is required is that the peers on the same link correctly implement the ARP protocol as given in RFC 826. To be specific, when a peer host receives an ARP Request where the Target Protocol Address of the ARP Request matches (one of) that host's IP address(es) configured on that interface, then as long as it properly responds with a correctly-formatted ARP Reply, the querying host will be able to detect that the address is already in use.
为了使本文档中指定的协议生效，链路上的所有主机都不必实现该协议。对于实现本规范的给定主机，要防止意外地址冲突，所需的只是同一链路上的对等方正确实现RFC 826中给出的ARP协议。具体来说，当对等主机接收到ARP请求时，如果ARP请求的目标协议地址与该接口上配置的主机IP地址（其中一个）匹配，则只要该主机以正确格式的ARP应答正确响应，查询主机将能够检测到该地址已在使用中。
The specifications in this document allow hosts to detect conflicts between two hosts using the same address on the same physical link. ACD does not detect conflicts between two hosts using the same address on different physical links, and indeed it should not. For example, the address 10.0.0.1 [RFC1918] is in use by countless devices on countless private networks throughout the world, and this is not a conflict, because they are on different links. It would only be a conflict if two such devices were to be connected to the same link, and when this happens (as it sometimes does), this is a perfect example of a situation where ACD is extremely useful to detect and report (and/or automatically correct) this error.
本文档中的规范允许主机检测在同一物理链路上使用相同地址的两台主机之间的冲突。ACD不会检测在不同物理链路上使用相同地址的两台主机之间的冲突，事实上，它不应该检测冲突。例如，地址10.0.0.1[RFC1918]被世界各地无数专用网络上的无数设备使用，这不是冲突，因为它们位于不同的链路上。只有当两个这样的设备连接到同一条链路时，才会发生冲突，当这种情况发生时（有时会发生），这是一个完美的例子，说明ACD对于检测和报告（和/或自动纠正）此错误非常有用。
For the purposes of this document, a set of hosts is considered to be "on the same link" if:
在本文件中，一组主机被视为“在同一链路上”，如果：
- when any host, A, from that set, sends a packet to any other host, B, in that set, using unicast, multicast, or broadcast, the entire link-layer packet payload arrives unmodified, and
- 当来自该集合的任何主机A使用单播、多播或广播向该集合中的任何其他主机B发送分组时，整个链路层分组有效载荷未经修改地到达，并且
- a broadcast sent over that link by any host from that set of hosts can be received by every other host in that set.
- 任何主机通过该链路从该主机集中发送的广播都可以被该主机集中的所有其他主机接收。
The link-layer *header* may be modified, such as in Token Ring Source Routing [802.5], but not the link-layer *payload*. In particular, if any device forwarding a packet modifies any part of the IP header or IP payload, then the packet is no longer considered to be on the same link. This means that the packet may pass through devices such as repeaters, bridges, hubs, or switches and still be considered to be on the same link for the purpose of this document, but not through a device such as an IP router that decrements the TTL or otherwise modifies the IP header.
可以修改链路层*报头*，例如在令牌环源路由[802.5]中，但不能修改链路层*有效负载*。特别地，如果转发分组的任何设备修改了IP报头或IP有效载荷的任何部分，则分组不再被认为在同一链路上。这意味着数据包可以通过诸如中继器、网桥、集线器或交换机之类的设备，并且在本文档中仍然被视为处于同一链路上，但不能通过诸如减少TTL或以其他方式修改IP报头的IP路由器之类的设备。
Where this document uses the term "host", it applies equally to interfaces on routers or other multi-homed hosts, regardless of whether the host/router is currently forwarding packets. In many cases a router will be critical network infrastructure with an IP address that is locally well known and assumed to be relatively constant. For example, the address of the default router is one of the parameters that a DHCP server typically communicates to its clients, and (at least until mechanisms like DHCP Reconfigure [RFC3203] become widely implemented) there isn't any practical way for the DHCP server to inform clients if that address changes. Consequently, for such devices, handling conflicts by picking a new IP address is not a good option. In those cases, option (c) in Section 2.4 ("Ongoing Address Conflict Detection and Address Defense") applies.
当本文件使用术语“主机”时，它同样适用于路由器或其他多主机上的接口，无论主机/路由器当前是否正在转发数据包。在许多情况下，路由器将是一个关键的网络基础设施，其IP地址在本地是众所周知的，并且假定是相对恒定的。例如，默认路由器的地址是DHCP服务器通常与其客户机通信的参数之一，并且（至少在DHCP重新配置[RFC3203]等机制广泛实施之前）DHCP服务器没有任何实际的方法通知客户机地址是否发生变化。因此，对于此类设备，通过选择新的IP地址来处理冲突不是一个好的选择。在这些情况下，第2.4节（“持续解决冲突检测和解决防御”）中的选项（c）适用。
However, even when a device is manually configured with a fixed address, having some other device on the network claiming to have the same IP address will pollute peer ARP caches and prevent reliable communication, so it is still helpful to inform the operator. If a conflict is detected at the time the operator sets the fixed manual address, then it is helpful to inform the operator immediately; if a conflict is detected subsequently, it is helpful to inform the operator via some appropriate asynchronous communication channel. Even though reliable communication via the conflicted address is not possible, it may still be possible to inform the operator via some other communication channel that is still operating, such as via some other interface on the router, via a dynamic IPv4 link-local address, via a working IPv6 address, or even via some completely different non-IP technology such as a locally-attached screen or serial console.
然而，即使手动为设备配置了固定地址，网络上的其他设备声称拥有相同的IP地址也会污染对等ARP缓存并阻止可靠通信，因此通知运营商仍然很有帮助。如果在操作员设置固定手动地址时检测到冲突，则应立即通知操作员；如果随后检测到冲突，则通过适当的异步通信通道通知操作员是有帮助的。即使不可能通过冲突地址进行可靠通信，也可以通过一些仍在运行的其他通信信道通知运营商，例如通过路由器上的一些其他接口，通过动态IPv4链路本地地址，通过工作IPv6地址，甚至通过一些完全不同的非IP技术，如本地连接的屏幕或串行控制台。
This section describes initial probing to safely determine whether an address is already in use, announcing the chosen address, ongoing conflict checking, and optional use of broadcast ARP Replies to provide faster conflict detection.
本节介绍安全确定地址是否已在使用的初始探测、宣布所选地址、进行冲突检查以及可选使用广播ARP回复以提供更快的冲突检测。
Before beginning to use an IPv4 address (whether received from manual configuration, DHCP, or some other means), a host implementing this specification MUST test to see if the address is already in use, by broadcasting ARP Probe packets. This also applies when a network interface transitions from an inactive to an active state, when a computer awakes from sleep, when a link-state change signals that an Ethernet cable has been connected, when an 802.11 wireless interface associates with a new base station, or when any other change in connectivity occurs where a host becomes actively connected to a logical link.
在开始使用IPv4地址（无论是通过手动配置、DHCP还是其他方式接收）之前，实现此规范的主机必须通过广播ARP探测数据包来测试该地址是否已在使用中。当网络接口从非活动状态过渡到活动状态时，当计算机从睡眠中醒来时，当链路状态改变信号表明已连接以太网电缆时，当802.11无线接口与新基站关联时，这也适用，或者当主机主动连接到逻辑链路时，连接发生任何其他变化。
A host MUST NOT perform this check periodically as a matter of course. This would be a waste of network bandwidth, and is unnecessary due to the ability of hosts to passively discover conflicts, as described in Section 2.4.
当然，主机不得定期执行此检查。如第2.4节所述，这将浪费网络带宽，而且由于主机能够被动地发现冲突，因此没有必要这样做。
A host probes to see if an address is already in use by broadcasting an ARP Request for the desired address. The client MUST fill in the 'sender hardware address' field of the ARP Request with the hardware address of the interface through which it is sending the packet. The 'sender IP address' field MUST be set to all zeroes; this is to avoid polluting ARP caches in other hosts on the same link in the case where the address turns out to be already in use by another host. The 'target hardware address' field is ignored and SHOULD be set to all zeroes. The 'target IP address' field MUST be set to the address being probed. An ARP Request constructed this way, with an all-zero 'sender IP address', is referred to as an 'ARP Probe'.
主机通过广播所需地址的ARP请求来探测地址是否已经在使用中。客户端必须在ARP请求的“发送方硬件地址”字段中填写发送数据包的接口的硬件地址。“发件人IP地址”字段必须设置为全零；这是为了避免在同一链路上的其他主机中的ARP缓存被另一个主机使用时受到污染。“目标硬件地址”字段被忽略，应设置为全零。“目标IP地址”字段必须设置为要探测的地址。以这种方式构造的ARP请求，其“发送方IP地址”为零，称为“ARP探测”。
When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range zero to PROBE_WAIT seconds, and should then send PROBE_NUM probe packets, each of these probe packets spaced randomly and uniformly, PROBE_MIN to PROBE_MAX seconds apart. This initial random delay helps ensure that a large number of hosts powered on at the same time do not all send their initial probe packets simultaneously.
当准备好开始探测时，主机应等待在0到PROBE_wait秒范围内均匀选择的随机时间间隔，然后发送PROBE_NUM PROBE数据包，这些数据包中的每个数据包随机均匀地间隔，PROBE_MIN到PROBE_MAX秒间隔。此初始随机延迟有助于确保同时通电的大量主机不会同时发送其初始探测数据包。
If during this period, from the beginning of the probing process until ANNOUNCE_WAIT seconds after the last probe packet is sent, the host receives any ARP packet (Request *or* Reply) on the interface where the probe is being performed, where the packet's 'sender IP address' is the address being probed for, then the host MUST treat this address as being in use by some other host, and should indicate to the configuring agent (human operator, DHCP server, etc.) that the proposed address is not acceptable.
如果在此期间，从探测过程开始到最后一个探测数据包发送后的通告等待秒，主机在执行探测的接口上接收到任何ARP数据包（请求*或*回复），其中数据包的“发送方IP地址”是被探测的地址，然后，主机必须将此地址视为其他主机正在使用，并应向配置代理（人工操作员、DHCP服务器等）指示建议的地址不可接受。
In addition, if during this period the host receives any ARP Probe where the packet's 'target IP address' is the address being probed for, and the packet's 'sender hardware address' is not the hardware address of any of the host's interfaces, then the host SHOULD similarly treat this as an address conflict and signal an error to the configuring agent as above. This can occur if two (or more) hosts have, for whatever reason, been inadvertently configured with the same address, and both are simultaneously in the process of probing that address to see if it can safely be used.
此外，如果在此期间主机接收到任何ARP探测，其中数据包的“目标IP地址”是被探测的地址，而数据包的“发送方硬件地址”不是任何主机接口的硬件地址，然后，主机应类似地将此视为地址冲突，并如上所述向配置代理发出错误信号。如果出于任何原因，两台（或多台）主机无意中配置了相同的地址，并且两台主机同时在探测该地址以查看是否可以安全使用，则可能会发生这种情况。
NOTE: The check that the packet's 'sender hardware address' is not the hardware address of any of the host's interfaces is important. Some kinds of Ethernet hub (often called a "buffered repeater") and many wireless access points may "rebroadcast" any received broadcast packets to all recipients, including the original sender itself. For this reason, the precaution described above is necessary to ensure that a host is not confused when it sees its own ARP packets echoed back.
注意：检查数据包的“发送方硬件地址”是否不是任何主机接口的硬件地址非常重要。某些类型的以太网集线器（通常称为“缓冲中继器”）和许多无线接入点可以将任何接收到的广播数据包“重播”给所有接收者，包括原始发送者本身。因此，有必要采取上述预防措施，以确保主机在看到自己的ARP数据包回显时不会混淆。
A host implementing this specification MUST take precautions to limit the rate at which it probes for new candidate addresses: if the host experiences MAX_CONFLICTS or more address conflicts on a given interface, then the host MUST limit the rate at which it probes for new addresses on this interface to no more than one attempted new address per RATE_LIMIT_INTERVAL. This is to prevent catastrophic ARP storms in pathological failure cases, such as a defective DHCP server that repeatedly assigns the same address to every host that asks for one. This rate-limiting rule applies not only to conflicts experienced during the initial probing phase, but also to conflicts experienced later, as described in Section 2.4 "Ongoing Address Conflict Detection and Address Defense".
实现此规范的主机必须采取预防措施，以限制其探测新候选地址的速率：如果主机在给定接口上遇到MAX_冲突或更多地址冲突，然后，主机必须将其在此接口上探测新地址的速率限制为每个速率限制间隔内不超过一个尝试的新地址。这是为了防止在病理性故障情况下发生灾难性的ARP风暴，例如，有缺陷的DHCP服务器会重复为每个请求相同地址的主机分配相同的地址。如第2.4节“持续地址冲突检测和地址防御”所述，此速率限制规则不仅适用于初始探测阶段遇到的冲突，也适用于以后遇到的冲突。
If, by ANNOUNCE_WAIT seconds after the transmission of the last ARP Probe no conflicting ARP Reply or ARP Probe has been received, then the host has successfully determined that the desired address may be used safely.
如果在传输最后一个ARP探测后的几秒钟内未收到冲突的ARP应答或ARP探测，则主机已成功确定所需地址可以安全使用。
Network technologies may emerge for which shorter delays are appropriate than those required by this document. A subsequent IETF publication may be produced providing guidelines for different values for PROBE_WAIT, PROBE_NUM, PROBE_MIN, and PROBE_MAX on those technologies.
可能出现比本文件要求的延迟更短的网络技术。随后可能会产生IETF出版物，为这些技术上的探测等待、探测数量、探测最小值和探测最大值的不同值提供指南。
If the situation arises where different hosts on a link are using different timing parameters, this does not cause any problems. This protocol is not dependent on all hosts on a link implementing the
如果出现链路上的不同主机使用不同定时参数的情况，这不会导致任何问题。此协议不依赖于实现
same version of the protocol; indeed, this protocol is not dependent on all hosts on a link implementing the protocol at all. All that is required is that all hosts implement ARP as specified in RFC 826, and correctly answer ARP Requests they receive. In the situation where different hosts are using different timing parameters, all that will happen is that some hosts will configure their interfaces more quickly than others. In the unlikely event that an address conflict is not detected during the address probing phase, the conflict will still be detected by the Ongoing Address Conflict Detection described below in Section 2.4.
议定书的同一版本；实际上，该协议根本不依赖于实现该协议的链路上的所有主机。所需要的只是所有主机按照RFC 826中的规定实现ARP，并正确地响应它们接收到的ARP请求。在不同主机使用不同定时参数的情况下，只会出现一些主机比其他主机更快地配置其接口的情况。在地址探测阶段未检测到地址冲突的不太可能的情况下，仍将通过下面第2.4节中描述的持续地址冲突检测来检测冲突。
Having probed to determine that a desired address may be used safely, a host implementing this specification MUST then announce that it is commencing to use this address by broadcasting ANNOUNCE_NUM ARP Announcements, spaced ANNOUNCE_INTERVAL seconds apart. An ARP Announcement is identical to the ARP Probe described above, except that now the sender and target IP addresses are both set to the host's newly selected IPv4 address. The purpose of these ARP Announcements is to make sure that other hosts on the link do not have stale ARP cache entries left over from some other host that may previously have been using the same address. The host may begin legitimately using the IP address immediately after sending the first of the two ARP Announcements; the sending of the second ARP Announcement may be completed asynchronously, concurrent with other networking operations the host may wish to perform.
在探测以确定所需地址是否可以安全使用后，实施本规范的主机必须通过广播annound_NUM ARP announces来宣布其开始使用该地址，广播间隔为秒。ARP公告与上述ARP探测相同，只是现在发送方和目标IP地址都设置为主机新选择的IPv4地址。这些ARP公告的目的是确保链路上的其他主机没有从以前可能使用相同地址的其他主机遗留的过时ARP缓存项。在发送两个ARP公告中的第一个之后，主机可以立即开始合法使用IP地址；第二个ARP公告的发送可以异步完成，与主机可能希望执行的其他联网操作同时完成。
Address Conflict Detection is not limited to only the time of initial interface configuration, when a host is sending ARP Probes. Address Conflict Detection is an ongoing process that is in effect for as long as a host is using an address. At any time, if a host receives an ARP packet (Request *or* Reply) where the 'sender IP address' is (one of) the host's own IP address(es) configured on that interface, but the 'sender hardware address' does not match any of the host's own interface addresses, then this is a conflicting ARP packet, indicating some other host also thinks it is validly using this address. To resolve the address conflict, a host MUST respond to a conflicting ARP packet as described in either (a), (b), or (c) below:
当主机发送ARP探测时，地址冲突检测不仅限于初始接口配置的时间。地址冲突检测是一个持续的过程，只要主机使用地址，该过程就会生效。在任何时候，如果主机接收到一个ARP数据包（请求*或*回复），其中“发送方IP地址”是该接口上配置的主机自己的IP地址之一，但“发送方硬件地址”与主机自己的任何接口地址都不匹配，则这是一个冲突的ARP数据包，表示其他主机也认为它正在有效地使用此地址。要解决地址冲突，主机必须响应以下（a）、（b）或（c）中所述的冲突ARP数据包：
(a) Upon receiving a conflicting ARP packet, a host MAY elect to immediately cease using the address, and signal an error to the configuring agent as described above.
(a) 在接收到冲突的ARP分组时，主机可以选择立即停止使用该地址，并如上所述向配置代理发送错误信号。
(b) If a host currently has active TCP connections or other reasons to prefer to keep the same IPv4 address, and it has not seen any other conflicting ARP packets within the last DEFEND_INTERVAL seconds, then it MAY elect to attempt to defend its address by recording the time that the conflicting ARP packet was received, and then broadcasting one single ARP Announcement, giving its own IP and hardware addresses as the sender addresses of the ARP, with the 'target IP address' set to its own IP address, and the 'target hardware address' set to all zeroes. Having done this, the host can then continue to use the address normally without any further special action. However, if this is not the first conflicting ARP packet the host has seen, and the time recorded for the previous conflicting ARP packet is recent, within DEFEND_INTERVAL seconds, then the host MUST immediately cease using this address and signal an error to the configuring agent as described above. This is necessary to ensure that two hosts do not get stuck in an endless loop with both hosts trying to defend the same address.
(b) 如果主机当前有活动的TCP连接或出于其他原因希望保留相同的IPv4地址，并且在最后的保护间隔秒内没有看到任何其他冲突的ARP数据包，那么它可以选择通过记录接收冲突的ARP数据包的时间来尝试保护其地址，然后广播一个ARP公告，给出自己的IP和硬件地址作为ARP的发送方地址，“目标IP地址”设置为自己的IP地址，“目标硬件地址”设置为全零。完成此操作后，主机可以继续正常使用该地址，而无需任何进一步的特殊操作。但是，如果这不是主机看到的第一个冲突ARP数据包，并且前一个冲突ARP数据包记录的时间是最近的，在保护间隔秒内，则主机必须立即停止使用此地址，并如上所述向配置代理发送错误信号。这是必要的，以确保两台主机不会陷入一个无休止的循环，因为两台主机都试图保护相同的地址。
(c) If a host has been configured such that it should not give up its address under any circumstances (perhaps because it is the kind of device that needs to have a well-known stable IP address, such as a link's default router or a DNS server) then it MAY elect to defend its address indefinitely. If such a host receives a conflicting ARP packet, then it should take appropriate steps to log useful information such as source Ethernet address from the ARP packet, and inform an administrator of the problem. The number of such notifications should be appropriately controlled to prevent an excessive number of error reports being generated. If the host has not seen any other conflicting ARP packets recently, within the last DEFEND_INTERVAL seconds, then it MUST record the time that the conflicting ARP packet was received, and then broadcast one single ARP Announcement, giving its own IP and hardware addresses. Having done this, the host can then continue to use the address normally without any further special action. However, if this is not the first conflicting ARP packet the host has seen, and the time recorded for the previous conflicting ARP packet is within DEFEND_INTERVAL seconds, then the host MUST NOT send another defensive ARP Announcement. This is necessary to ensure that two misconfigured hosts do not get stuck in an endless loop flooding the network with broadcast traffic while they both try to defend the same address.
(c) 如果主机已配置为在任何情况下都不应放弃其地址（可能是因为它是一种需要具有众所周知的稳定IP地址的设备，如链路的默认路由器或DNS服务器），那么它可能会选择无限期地保护其地址。如果这样的主机接收到冲突的ARP数据包，那么它应该采取适当的步骤记录有用的信息，例如来自ARP数据包的源以太网地址，并将问题通知管理员。应适当控制此类通知的数量，以防止生成过多的错误报告。如果主机最近在最近的保护间隔秒内没有看到任何其他冲突的ARP数据包，则必须记录接收冲突ARP数据包的时间，然后广播一个ARP公告，给出其自己的IP和硬件地址。完成此操作后，主机可以继续正常使用该地址，而无需任何进一步的特殊操作。但是，如果这不是主机看到的第一个冲突ARP数据包，并且前一个冲突ARP数据包记录的时间在防御间隔秒内，则主机不得发送另一个防御ARP公告。这是必要的，以确保两个配置错误的主机不会陷入一个无限循环中，当它们都试图保护同一地址时，网络中充斥着广播流量。
A host wishing to provide reliable network operation MUST respond to conflicting ARP packets as described in (a), (b), or (c) above. Ignoring conflicting ARP packets results in seemingly random network failures that can be hard to diagnose and very frustrating for human users.
如上文（A）、（b）或（c）所述，希望提供可靠网络操作的主机必须响应冲突的ARP数据包。忽略冲突的ARP数据包会导致看似随机的网络故障，很难诊断，对人类用户来说非常令人沮丧。
Forced address reconfiguration may be disruptive, causing TCP (and other transport-layer) connections to be broken. However, such disruptions should be exceedingly rare, and if inadvertent address duplication happens, then disruption of communication is inevitable. It is not possible for two different hosts using the same IP address on the same network to operate reliably.
强制地址重新配置可能会造成中断，导致TCP（和其他传输层）连接中断。然而，这样的中断应该是非常罕见的，如果无意中发生地址重复，那么通信中断是不可避免的。在同一网络上使用相同IP地址的两台不同主机不可能可靠运行。
Before abandoning an address due to a conflict, hosts SHOULD actively attempt to reset any existing connections using that address. This mitigates some security threats posed by address reconfiguration, as discussed in Section 5.
在由于冲突而放弃某个地址之前，主机应主动尝试使用该地址重置任何现有连接。如第5节所述，这缓解了地址重新配置带来的一些安全威胁。
For most client machines that do not need a fixed IP address, immediately requesting the configuring agent (human user, DHCP client, etc.) to configure a new address as soon as the conflict is detected is the best way to restore useful communication as quickly as possible. The mechanism described above of broadcasting a single ARP Announcement to defend the address mitigates the problem somewhat, by helping to improve the chance that one of the two conflicting hosts may be able to retain its address.
对于大多数不需要固定IP地址的客户端计算机，一旦检测到冲突，立即请求配置代理（人类用户、DHCP客户端等）配置新地址是尽快恢复有用通信的最佳方式。上述广播单个ARP公告以保护地址的机制通过帮助提高两个冲突主机中的一个能够保留其地址的机会，在一定程度上缓解了问题。
From the time a host sends its first ARP Announcement, until the time it ceases using that IP address, the host MUST answer ARP Requests in the usual way required by the ARP specification [RFC826]. Specifically, this means that whenever a host receives an ARP Request, that's not a conflicting ARP packet as described above in Section 2.4, where the 'target IP address' of the ARP Request is (one of) the host's own IP address(es) configured on that interface, the host MUST respond with an ARP Reply as described in RFC 826. This applies equally for both standard ARP Requests with non-zero sender IP addresses and Probe Requests with all-zero sender IP addresses.
从主机发送其第一个ARP公告开始，直到停止使用该IP地址为止，主机必须按照ARP规范[RFC826]要求的常规方式响应ARP请求。具体而言，这意味着每当主机接收到ARP请求时，该请求不是上文第2.4节所述的冲突ARP数据包，其中ARP请求的“目标IP地址”是在该接口上配置的主机自己的IP地址之一，主机必须按照RFC 826中所述的ARP回复进行响应。这同样适用于具有非零发送方IP地址的标准ARP请求和具有所有零发送方IP地址的探测请求。
In a carefully-run network with manually-assigned addresses, or a network with a reliable DHCP server and reliable DHCP clients, address conflicts should occur only in rare failure scenarios, so the passive monitoring described above in Section 2.4 is adequate. If two hosts are using the same IP address, then sooner or later one host or the other will broadcast an ARP Request, which the other will see, allowing the conflict to be detected and consequently resolved.
在具有手动分配地址的精心运行的网络中，或具有可靠的DHCP服务器和可靠的DHCP客户端的网络中，地址冲突只应在极少的故障情况下发生，因此上文第2.4节所述的被动监控就足够了。如果两台主机使用相同的IP地址，那么早晚一台主机或另一台主机将广播一个ARP请求，另一台主机将看到该请求，从而允许检测冲突并最终解决。
It is possible, however, that a conflicting configuration may persist for a short time before it is detected. Suppose that two hosts, A and B, have been inadvertently assigned the same IP address, X. Suppose further that at the time they were both probing to determine
然而，冲突配置可能会在检测到之前持续很短时间。假设两台主机A和B无意中被分配了相同的IP地址X。进一步假设当时它们都在探测以确定
whether the address could safely be used, the communication link between them was non-functional for some reason, so neither detected the conflict at interface-configuration time. Suppose now that the communication link is restored, and a third host, C, broadcasts an ARP Request for address X. Unaware of any conflict, both hosts A and B will send unicast ARP Replies to host C. Host C will see both Replies, and may be a little confused, but neither host A nor B will see the other's Reply, and neither will immediately detect that there is a conflict to be resolved. Hosts A and B will continue to be unaware of the conflict until one or other broadcasts an ARP Request of their own.
无论地址能否安全使用，由于某种原因，它们之间的通信链路不起作用，因此在接口配置时都没有检测到冲突。假设现在通信链路已恢复，第三台主机C广播地址X的ARP请求。在不知道任何冲突的情况下，主机a和B都将向主机C发送单播ARP回复。主机C将看到这两个回复，可能有点混乱，但主机a和B都看不到对方的回复，两人都不会立即发现有冲突需要解决。主机A和B将继续不知道冲突，直到一个或另一个广播自己的ARP请求。
If quicker conflict detection is desired, this may be achieved by having hosts send ARP Replies using link-level broadcast, instead of sending only ARP Requests via broadcast, and Replies via unicast. This is NOT RECOMMENDED for general use, but other specifications building on IPv4 ACD may choose to specify broadcast ARP Replies if appropriate. For example, "Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927] specifies broadcast ARP Replies because in that context, detection of address conflicts using IPv4 ACD is not merely a backup precaution to detect failures of some other configuration mechanism; detection of address conflicts using IPv4 ACD is the sole configuration mechanism.
如果需要更快的冲突检测，这可以通过让主机使用链路级广播发送ARP应答来实现，而不是仅通过广播发送ARP请求，通过单播发送应答。这不建议用于一般用途，但基于IPv4 ACD的其他规范可能会选择指定广播ARP应答（如果适用）。例如，“IPv4链路本地地址的动态配置”[RFC3927]指定广播ARP应答，因为在该上下文中，使用IPv4 ACD检测地址冲突不仅仅是检测某些其他配置机制故障的备份预防措施；使用IPv4 ACD检测地址冲突是唯一的配置机制。
Sending ARP Replies using broadcast does increase broadcast traffic, but in the worst case by no more than a factor of two. In the traditional usage of ARP, a unicast ARP Reply only occurs in response to a broadcast ARP Request, so sending these via broadcast instead means that we generate at most one broadcast Reply in response to each existing broadcast Request. On many networks, ARP traffic is such an insignificant proportion of the total traffic that doubling it makes no practical difference. However, this may not be true of all networks, so broadcast ARP Replies SHOULD NOT be used universally. Broadcast ARP Replies should be used where the benefit of faster conflict detection outweighs the cost of increased broadcast traffic and increased packet processing load on the participant network hosts.
使用广播发送ARP回复确实会增加广播流量，但在最坏的情况下不会超过两倍。在ARP的传统用法中，单播ARP应答仅在响应广播ARP请求时发生，因此通过广播发送这些应答意味着我们最多生成一个广播应答来响应每个现有广播请求。在许多网络上，ARP流量在总流量中所占的比例很小，因此将其增加一倍并没有实际意义。然而，并非所有网络都是如此，因此广播ARP回复不应普遍使用。如果更快的冲突检测的好处超过了增加的广播流量和参与者网络主机上增加的数据包处理负载的成本，则应使用广播ARP应答。
3. Why Are ARP Announcements Performed Using ARP Request Packets and Not ARP Reply Packets?
3. 为什么使用ARP请求数据包而不是ARP回复数据包来执行ARP公告？
During IETF deliberation of IPv4 Address Conflict Detection from 2000 to 2008, a question that was asked repeatedly was, "Shouldn't ARP Announcements be performed using gratuitous ARP Reply packets?"
在2000年至2008年IETF审议IPv4地址冲突检测时，反复提出的一个问题是，“ARP公告不应该使用免费的ARP回复包吗？”
On the face of it, this seems reasonable. A conventional ARP Reply is an answer to a question. If in fact no question had been asked, then it would be reasonable to describe such a reply as gratuitous.
从表面上看，这似乎是合理的。传统的ARP回复是对问题的回答。如果事实上没有人提出任何问题，那么将这种答复描述为无缘无故是合理的。
The term "gratuitous reply" would seem to apply perfectly to an ARP Announcement: an answer to an implied question that in fact no one asked.
“无缘无故的回答”一词似乎完全适用于ARP公告：对一个实际上没有人问的隐含问题的回答。
However reasonable this may seem in principle, in practice there are two reasons that swing the argument in favor of using ARP Request packets. One is historical precedent, and the other is pragmatism.
无论这在原则上看起来多么合理，实际上有两个理由支持使用ARP请求数据包。一个是历史先例，另一个是实用主义。
The historical precedent is that (as described above in Section 4) Gratuitous ARP is documented in Stevens Networking [Ste94] as using ARP Request packets. BSD Unix, Microsoft Windows, Mac OS 9, Mac OS X, etc., all use ARP Request packets as described in Stevens. At this stage, trying to mandate that they all switch to using ARP Reply packets would be futile.
历史先例是（如上文第4节所述），Stevens Networking[Ste94]将无偿ARP记录为使用ARP请求数据包。BSD Unix、Microsoft Windows、Mac OS 9、Mac OS X等都使用Stevens中描述的ARP请求包。在这个阶段，试图强制要求他们全部改用ARP应答包将是徒劳的。
The practical reason is that ARP Request packets are more likely to work correctly with more existing ARP implementations, some of which may not implement RFC 826 entirely correctly. The Packet Reception rules in RFC 826 state that the opcode is the last thing to check in packet processing, so it really shouldn't matter, but there may be "creative" implementations that have different packet processing depending on the 'ar$op' field, and there are several reasons why these are more likely to accept gratuitous ARP Requests than gratuitous ARP Replies:
实际原因是，ARP请求包更有可能在更多现有ARP实现中正常工作，其中一些可能无法完全正确地实现RFC 826。RFC 826中的数据包接收规则规定，操作码是数据包处理中最后一个要检查的内容，因此这并不重要，但根据“ar$op”字段的不同，可能存在具有不同数据包处理的“创造性”实现，与免费ARP回复相比，他们更愿意接受免费ARP请求的原因有几个：
* An incorrect ARP implementation may expect that ARP Replies are only sent via unicast. RFC 826 does not say this, but an incorrect implementation may assume it; the "principle of least surprise" dictates that where there are two or more ways to solve a networking problem that are otherwise equally good, the one with the fewest unusual properties is the one likely to have the fewest interoperability problems with existing implementations. An ARP Announcement needs to broadcast information to all hosts on the link. Since ARP Request packets are always broadcast, and ARP Reply packets are not, receiving an ARP Request packet via broadcast is less surprising than receiving an ARP Reply packet via broadcast.
* 不正确的ARP实现可能期望ARP回复仅通过单播发送。RFC 826没有这样说，但是一个不正确的实现可能会假定它；“最少意外原则”规定，如果有两种或两种以上的方法可以解决同样好的网络问题，那么具有最少不寻常属性的方法可能是与现有实现具有最少互操作性问题的方法。ARP公告需要向链路上的所有主机广播信息。由于ARP请求数据包始终是广播的，而ARP应答数据包则不是广播的，因此通过广播接收ARP请求数据包比通过广播接收ARP应答数据包更令人惊讶。
* An incorrect ARP implementation may expect that ARP Replies are only received in response to ARP Requests that have been issued recently by that implementation. Unexpected unsolicited Replies may be ignored.
* 不正确的ARP实现可能期望仅在响应该实现最近发出的ARP请求时接收ARP回复。意外的主动回复可能会被忽略。
* An incorrect ARP implementation may ignore ARP Replies where 'ar$tha' doesn't match its hardware address.
* 如果“ar$tha”与其硬件地址不匹配，则错误的ARP实现可能会忽略ARP回复。
* An incorrect ARP implementation may ignore ARP Replies where 'ar$tpa' doesn't match its IP address.
* 如果“ar$tpa”与其IP地址不匹配，则错误的ARP实现可能会忽略ARP回复。
In summary, there are more ways that an incorrect ARP implementation might plausibly reject an ARP Reply (which usually occurs as a result of being solicited by the client) than an ARP Request (which is already expected to occur unsolicited).
总之，错误的ARP实现可能会以更多的方式拒绝ARP回复（通常是客户请求的结果），而不是ARP请求（预计会在未经请求的情况下发生）。
Some readers have claimed that "Gratuitous ARP", as described in Stevens [Ste94], provides duplicate address detection, making ACD unnecessary. This is incorrect. What Stevens describes as Gratuitous ARP is the exact same packet that this document refers to by the more descriptive term 'ARP Announcement'. This traditional Gratuitous ARP implementation sends only a single ARP Announcement when an interface is first configured. The result is that the victim (the existing address holder) logs an error, and the offender continues operation, often without even detecting any problem. Both machines then typically proceed to try to use the same IP address, and fail to operate properly because they are each constantly resetting the other's TCP connections. The human administrator is expected to notice the log message on the victim machine and repair the damage after the fact. Typically this has to be done by physically going to the machines in question, since in this state neither is able to keep a TCP connection open for long enough to do anything useful over the network.
一些读者声称，史蒂文斯[Ste94]中描述的“免费ARP”提供了重复地址检测，使ACD变得不必要。这是不正确的。史蒂文斯所描述的免费ARP与本文件中更具描述性的术语“ARP公告”所指的完全相同。这种传统的免费ARP实现在第一次配置接口时只发送一个ARP通知。结果是受害者（现有的地址持有者）记录了一个错误，罪犯继续操作，通常甚至没有发现任何问题。然后，两台机器通常会继续尝试使用相同的IP地址，但无法正常运行，因为它们都在不断重置另一台机器的TCP连接。人工管理员应注意到受害者机器上的日志消息，并在事后修复损坏。通常，这必须通过物理访问相关机器来完成，因为在这种状态下，双方都无法保持TCP连接打开足够长的时间，以便在网络上执行任何有用的操作。
Gratuitous ARP does not in fact provide effective duplicate address detection and (as of January 2008) many of the top results for a Google search for the phrase "Gratuitous ARP" are articles describing how to disable it.
免费ARP实际上并没有提供有效的重复地址检测，而且（截至2008年1月）谷歌搜索短语“免费ARP”的许多顶级结果都是描述如何禁用它的文章。
However, implementers of IPv4 Address Conflict Detection should be aware that, as of this writing, Gratuitous ARP is still widely deployed. The steps described in Sections 2.1 and 2.4 of this document help make a host robust against misconfiguration and address conflicts, even when the other host is *not* playing by the same rules.
然而，IPv4地址冲突检测的实现者应该意识到，在撰写本文时，免费ARP仍然被广泛部署。本文档第2.1节和第2.4节中所述的步骤有助于使主机能够抵御错误配置和解决冲突，即使另一主机*不*遵守相同的规则。
IPv4 Address Conflict Detection (ACD) is based on ARP [RFC826] and it inherits the security vulnerabilities of that protocol. A malicious host may send fraudulent ARP packets on the network, interfering with the correct operation of other hosts. For example, it is easy for a host to answer all ARP Requests with Replies giving its own hardware address, thereby claiming ownership of every address on the network.
IPv4地址冲突检测（ACD）基于ARP[RFC826]，它继承了该协议的安全漏洞。恶意主机可能在网络上发送欺诈性ARP数据包，干扰其他主机的正确操作。例如，主机很容易回答所有ARP请求，并给出自己的硬件地址，从而声称拥有网络上的每个地址。
This specification makes this existing ARP vulnerability no worse, and in some ways makes it better: instead of failing silently with no indication why, hosts implementing this specification either attempt to reconfigure automatically, or at least inform the human user of what is happening.
该规范使现有的ARP漏洞不再恶化，并在某些方面使其变得更好：实现该规范的主机不是在没有指示原因的情况下默默失败，而是尝试自动重新配置，或者至少将发生的情况通知人类用户。
If a host willingly selects a new address in response to an ARP conflict, as described in Section 2.4, subsection (a), this potentially makes it easier for malicious attackers on the same link to hijack TCP connections. Having a host actively reset any existing connections before abandoning an address helps mitigate this risk.
如第2.4节（a）小节所述，如果主机自愿选择一个新地址来响应ARP冲突，这可能会使同一链路上的恶意攻击者更容易劫持TCP连接。让主机在放弃地址之前主动重置任何现有连接有助于降低此风险。
This document arose as a result of Zeroconf Working Group discussions on IPv4 Link-Local Addressing [RFC3927], where it was not clear to many participants which elements of link-local address management were specific to that particular problem space (e.g., random selection of an address), and which elements were generic and applicable to all IPv4 address configuration mechanisms (e.g., the detection of address conflicts). The following people made valuable comments in the course of that work and/or the subsequent editing of this document: Bernard Aboba, Randy Bush, Jim Busse, James Carlson, Alan Cox, Spencer Dawkins, Pavani Diwanji, Ralph Droms, Donald Eastlake III, Alex Elder, Stephen Farrell, Peter Ford, Spencer Giacalone, Josh Graessley, Erik Guttman, Myron Hattig, Mike Heard, Hugh Holbrook, Richard Johnson, Kim Yong-Woon, Marc Krochmal, Rod Lopez, Rory McGuire, Satish Mundra, Thomas Narten, Erik Nordmark, Randy Presuhn, Howard Ridenour, Pekka Savola, Daniel Senie, Dieter Siegmund, Valery Smyslov, Mark Townsley, Oleg Tychev, and Ryan Troll.
本文件是Zeroconf工作组讨论IPv4链路本地寻址[RFC3927]的结果，许多参与者不清楚链路本地地址管理的哪些元素特定于该特定问题空间（例如，地址的随机选择），以及哪些元素是通用的，并且适用于所有IPv4地址配置机制（例如，地址冲突的检测）。以下人士在这项工作和/或本文件后续编辑过程中发表了宝贵意见：伯纳德·阿博巴、兰迪·布什、吉姆·巴斯、詹姆斯·卡尔森、艾伦·考克斯、斯宾塞·道金斯、帕瓦尼·迪万吉、拉尔夫·德罗姆斯、唐纳德·伊斯特莱克三世、亚历克斯·埃尔德、斯蒂芬·法雷尔、彼得·福特、斯宾塞·贾卡隆、乔什·格拉斯利、埃里克·古特曼、，迈伦·哈蒂格、迈克·赫德、休·霍尔布鲁克、理查德·约翰逊、金永焕、马克·克罗奇马尔、罗德·洛佩兹、罗里·麦奎尔、萨蒂什·蒙德拉、托马斯·纳滕、埃里克·诺德马克、兰迪·普雷森、霍华德·里德努尔、佩卡·萨沃拉、丹尼尔·塞尼、迪特尔·西格蒙德、瓦莱里·斯洛夫、马克·汤斯利、奥列格·泰切夫和瑞安·特罗尔。
[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.
[RFC826]Plummer，D.“以太网地址解析协议——或——将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.
[802]局域网和城域网的IEEE标准：概述和体系结构，ANSI/IEEE标准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.3]ISO/IEC 8802-3信息技术-系统间远程通信和信息交换-局域网和城域网-通用规范-第3部分：带冲突检测的载波侦听多址（CSMA/CD）访问方法和物理层规范（也可称为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.5]ISO/IEC 8802-5信息技术-系统间远程通信和信息交换-局域网和城域网-通用规范-第5部分：令牌环访问方法和物理层规范（也叫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.
[802.11]信息技术.系统间电信和信息交换.局域网和城域网.特殊要求.第11部分：无线局域网介质访问控制（MAC）和物理层（PHY）规范，IEEE标准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.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001.
[RFC3203]T'Joens，Y.，Hublet，C.，和P.De Schrijver，“DHCP重新配置扩展”，RFC32032001年12月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]Cheshire，S.，Aboba，B.和E.Guttman，“IPv4链路本地地址的动态配置”，RFC 3927，2005年5月。
[Ste94] W. Stevens, "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.
[Ste94]W.Stevens，“TCP/IP图解，第1卷：协议”，Addison-Wesley，1994年。
Author's Address
作者地址
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino California 95014 USA
Stuart Cheshire Apple Inc.美国加利福尼亚州库珀蒂诺无限环路1号95014
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.