Network Working Group B. Aboba
Request for Comments: 4436 Microsoft Corporation
Category: Standards Track J. Carlson
Sun Microsystems
S. Cheshire
Apple Computer
March 2006
Network Working Group B. Aboba
Request for Comments: 4436 Microsoft Corporation
Category: Standards Track J. Carlson
Sun Microsystems
S. Cheshire
Apple Computer
March 2006
Detecting Network Attachment in IPv4 (DNAv4)
检测IPv4（DNAv4）中的网络连接
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The time required to detect movement between networks and to obtain (or to continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes, from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses, a set of steps known as Detecting Network Attachment for IPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment.
检测网络之间的移动和获取（或继续使用）IPv4配置所需的时间可能占连接点之间移动的总切换延迟的一小部分。本文档根据部署支持ARP、DHCP和IPv4链路本地地址的主机的经验，综合了一组称为检测IPv4网络连接（DNAv4）的步骤，以减少连接点之间移动的切换延迟。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Applicability ..............................................2
1.2. Requirements ...............................................5
1.3. Terminology ................................................5
2. Overview ........................................................6
2.1. Reachability Test ..........................................8
2.1.1. Packet Format .......................................9
2.2. IPv4 Address Acquisition ..................................10
2.3. IPv4 Link-Local Addresses .................................11
2.4. Manually Assigned Addresses ...............................12
3. Security Considerations ........................................12
4. References .....................................................13
4.1. Normative References ......................................13
4.2. Informative References ....................................13
5. Acknowledgements ...............................................14
1. Introduction ....................................................2
1.1. Applicability ..............................................2
1.2. Requirements ...............................................5
1.3. Terminology ................................................5
2. Overview ........................................................6
2.1. Reachability Test ..........................................8
2.1.1. Packet Format .......................................9
2.2. IPv4 Address Acquisition ..................................10
2.3. IPv4 Link-Local Addresses .................................11
2.4. Manually Assigned Addresses ...............................12
3. Security Considerations ........................................12
4. References .....................................................13
4.1. Normative References ......................................13
4.2. Informative References ....................................13
5. Acknowledgements ...............................................14
The time required to detect movement between networks and to obtain (or to continue to use) an operable IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment.
检测网络之间的移动和获得（或继续使用）可操作的IPv4配置所需的时间可能是连接点之间移动总切换延迟的一小部分。
This document synthesizes, from experience in the deployment of hosts supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local addresses [RFC3927], a set of steps known as Detecting Network Attachment for IPv4 (DNAv4). DNAv4 optimizes the (common) case of re-attachment to a network that one has been connected to previously by attempting to re-use a previous (but still valid) configuration, reducing the re-attachment time on LANs to a few milliseconds. Since this procedure is dependent on the ARP protocol, it is not suitable for use on media that do not support ARP.
本文档根据部署支持ARP[RFC826]、DHCP[RFC2131]和IPv4链路本地地址[RFC3927]的主机的经验，综合了一组称为检测IPv4网络连接（DNAv4）的步骤。DNAv4通过尝试重新使用以前（但仍然有效）的配置来优化重新连接到以前连接的网络的（常见）情况，将LAN上的重新连接时间减少到几毫秒。由于此过程依赖于ARP协议，因此不适合在不支持ARP的介质上使用。
DHCP is an effective and widely adopted mechanism for a host to obtain an IP address for use on a particular network link, or to re-validate a previously obtained address via DHCP's INIT-REBOOT mechanism [RFC2131].
DHCP是一种有效且广泛采用的机制，用于主机获取IP地址以在特定网络链路上使用，或通过DHCP的INIT-REBOOT机制重新验证先前获取的地址[RFC2131]。
When obtaining a new address, DHCP specifies that the client SHOULD use ARP to verify that the offered address is not already in use. The process of address conflict detection [ACD] can take as much as seven seconds. In principle, this time interval could be shortened,
当获取新地址时，DHCP指定客户端应使用ARP来验证提供的地址是否尚未被使用。地址冲突检测[ACD]的过程可能需要长达7秒的时间。原则上这个时间间隔可以缩短,，
with the obvious trade-off: the less time a host spends waiting to see if another host is already using its intended address, the greater the risk of inadvertent address conflicts.
有一个明显的权衡：主机等待另一个主机是否已经在使用其预期地址的时间越短，发生意外地址冲突的风险就越大。
Where the client successfully re-validates a previously obtained address using the INIT-REBOOT mechanism, the DHCP specification does not require the client to perform address conflict detection, so this seven-second delay does not apply. However, the DHCP server may be slow to respond or may be down and not responding at all, so hosts could benefit from having an alternative way to quickly determine that a previously obtained address is valid for use on this particular link.
当客户端使用INIT-REBOOT机制成功地重新验证以前获得的地址时，DHCP规范不要求客户端执行地址冲突检测，因此7秒延迟不适用。但是，DHCP服务器的响应速度可能较慢，或者可能已停机且根本没有响应，因此主机可以通过另一种方式快速确定先前获取的地址是否可用于此特定链路，从而从中受益。
When the client moves between networks, the address re-validation attempt may be unsuccessful; a DHCPNAK may be received in response to a DHCPREQUEST, causing the client to restart the configuration process by moving to the INIT state. If an address previously obtained on the new network is still operable, DNAv4 enables the host to confirm the new configuration quickly, bypassing restart of the configuration process and conflict detection.
当客户端在网络之间移动时，地址重新验证尝试可能不成功；可以接收DHCPNAK以响应DHCPREQUEST，从而使客户端通过移动到INIT状态来重新启动配置过程。如果先前在新网络上获得的地址仍然可用，DNAv4使主机能够快速确认新配置，从而绕过重新启动配置过程和冲突检测。
The alternative mechanism specified by this document applies when a host has a previously allocated DHCP address, which was not returned to the DHCP server via a DHCPRELEASE message, and which still has time remaining on its lease. In this case, the host may determine whether it has re-attached to the logical link where this address is valid for use, by sending a unicast ARP Request packet to a router previously known for that link (or, in the case of a link with more than one router, by sending one or more unicast ARP Request packets to one or more of those routers).
当主机具有先前分配的DHCP地址时，本文档指定的替代机制适用，该地址未通过DHCPRELEASE消息返回到DHCP服务器，并且仍有剩余的租用时间。在这种情况下，主机可以通过将单播ARP请求分组发送到先前已知用于该链路的路由器（或者，在具有多个路由器的链路的情况下，通过将一个或多个单播ARP请求分组发送到这些路由器中的一个或多个）来确定其是否已重新连接到该地址可供使用的逻辑链路。
The use of unicast ARP has a number of benefits. One benefit is that unicast packets impose less burden on the network than broadcast packets, particularly on 802.11 networks where broadcast packets may be sent at rates as low as 1 Mb/sec. Another benefit is that if the host is not on the link it hoped to find itself on, a broadcast ARP Request could pollute the ARP caches of peers on that link. When using private addresses [RFC1918], another device could be legitimately using the same address, and a broadcast ARP Request could disrupt its communications, causing TCP connections to be broken, and similar problems. Also, using a unicast ARP packet addressed to the MAC address of the router the host is expecting to find means that if the host is not on the expected link there will be no device with that MAC address, and the ARP packet will harmlessly disappear into the void without doing any damage.
使用单播ARP有许多好处。一个好处是单播分组比广播分组对网络施加的负担更小，特别是在802.11网络上，其中广播分组可以以低至1 Mb/秒的速率发送。另一个好处是，如果主机不在它希望自己所在的链路上，广播ARP请求可能会污染该链路上对等方的ARP缓存。当使用专用地址[RFC1918]时，另一个设备可以合法地使用相同的地址，广播ARP请求可能会中断其通信，导致TCP连接中断，以及类似的问题。此外，使用寻址到路由器MAC地址的单播ARP分组，主机期望找到的意思是，如果主机不在预期链路上，将不会有具有该MAC地址的设备，并且ARP分组将无害地消失在空隙中而不会造成任何损坏。
These issues that define the applicability of DNAv4 lead us to a number of conclusions:
定义DNAv4适用性的这些问题使我们得出了一些结论：
o DNAv4 is a performance optimization. Its purpose is to speed up a process that may require as much as a few hundred milliseconds (DHCP INIT-REBOOT), as well as to reduce multi-second conflict detection delays when a host changes networks.
o DNAv4是一种性能优化。它的目的是加速可能需要几百毫秒（DHCP初始化-重新启动）的进程，以及减少主机更改网络时的多秒冲突检测延迟。
o As a performance optimization, it must not sacrifice correctness. In other words, false positives are not acceptable. DNAv4 must not conclude that a host has returned to a previously visited link where it has an operable IP address if this is not in fact the case.
o 作为一种性能优化，它不能牺牲正确性。换句话说，误报是不可接受的。如果事实并非如此，DNAv4不得断定主机已返回到其具有可操作IP地址的先前访问的链路。
o As a performance optimization, false negatives are acceptable. It is not an absolute requirement that this optimization correctly recognize a previously visited link in all possible cases. For example, if a router ignores unicast ARP Requests, then DNAv4 will not be able to detect that it has returned to the same link in the future. This is acceptable because the host still operates correctly as it did without DNAv4, just without the performance benefit. Users and network operators who desire the performance improvement offered by DNAv4 can upgrade their routers to support DNAv4.
o 作为性能优化，可以接受漏报。在所有可能的情况下，此优化正确识别以前访问过的链接不是绝对要求。例如，如果路由器忽略单播ARP请求，则DNAv4将无法检测到它在将来已返回到同一链路。这是可以接受的，因为主机仍然可以像没有DNAv4时一样正常运行，只是没有性能优势。DN4的网络运营商可以为其提供支持，以提高其网络性能。
o As a performance optimization, where DNAv4 fails to provide a benefit, it should add little or no delay compared to today's DHCP processing. In practice, this implies that DHCP processing needs to proceed in parallel. Waiting for DNAv4 to fail before beginning DHCP processing can greatly increase total processing time, the opposite of the desired effect.
o 作为一种性能优化，如果DNAv4不能提供好处，那么与今天的DHCP处理相比，它应该增加很少或没有延迟。实际上，这意味着DHCP处理需要并行进行。在开始DHCP处理之前等待DNAv4失败会大大增加总处理时间，这与预期效果相反。
o Trials are inexpensive. DNAv4 performs its checks using small unicast packets. An IPv4 ARP packet on Ethernet is just 42 octets, including the Ethernet header. This means that the cost of an unsuccessful attempt is small, whereas the cost of a missed opportunity (having the right address available as a candidate and choosing not to try it for some reason) is large. As a result, the best strategy is often to try all available candidate configurations, rather than try to determine which candidates, if any, may be correct for this link, based on heuristics or hints. For a heuristic to offer the prospect of being a potentially useful way to eliminate inappropriate configurations from the candidate list, that heuristic has to (a) be fast and inexpensive to compute, as compared to sending a 42-octet unicast packet, and (b) have high probability of not falsely eliminating a candidate configuration that could be found to be the correct one.
o 试验费用低廉。DNAv4使用小型单播数据包执行其检查。以太网上的IPv4 ARP数据包只有42个八位字节，包括以太网报头。这意味着尝试失败的成本很小，而错过机会的成本（拥有合适的地址作为候选地址，并出于某种原因选择不尝试）很大。因此，最好的策略通常是尝试所有可用的候选配置，而不是根据启发式或提示确定哪些候选配置（如果有）可能适合此链接。为了使启发式算法成为从候选列表中消除不适当配置的潜在有用方法，该启发式算法必须（a）与发送42个八位组的单播数据包相比，计算速度快且成本低，以及（b）很有可能不会错误地删除可能是正确配置的候选配置。
o Time is limited. If DNAv4 is to be effective in enabling low latency handoffs, it needs to complete in less than 10 ms. This implies that any heuristic used to eliminate candidate configurations needs to take at most a few milliseconds to compute. This does not leave much room for heuristics based on observation of link-layer or Internet-layer traffic.
o 时间有限。如果DNAv4要有效实现低延迟切换，则需要在不到10毫秒的时间内完成。这意味着用于消除候选配置的任何启发式算法最多需要几毫秒的计算时间。这并没有给基于链路层或互联网层流量观察的启发式方法留下太多空间。
In this document, several words are used to signify the requirements of the specification. 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]中的描述进行解释。
This document uses the following terms:
本文件使用以下术语：
ar$sha ARP packet field: Sender Hardware Address [RFC826]. The hardware (MAC) address of the originator of an ARP packet.
ar$sha ARP数据包字段：发送方硬件地址[RFC826]。ARP数据包发起者的硬件（MAC）地址。
ar$spa ARP packet field: Sender Protocol Address [RFC826]. For IP Address Resolution, this is the IPv4 address of the sender of the ARP packet.
ar$spa ARP数据包字段：发送方协议地址[RFC826]。对于IP地址解析，这是ARP数据包发送方的IPv4地址。
ar$tha ARP packet field: Target Hardware Address [RFC826]. The hardware (MAC) address of the target of an ARP packet.
ar$tha ARP数据包字段：目标硬件地址[RFC826]。ARP数据包目标的硬件（MAC）地址。
ar$tpa ARP packet field: Target Protocol Address [RFC826]. For IPv4 Address Resolution, the IPv4 address for which one desires to know the hardware address.
ar$tpa ARP数据包字段：目标协议地址[RFC826]。对于IPv4地址解析，需要知道其硬件地址的IPv4地址。
DHCP client A DHCP client or "client" is an Internet host using the Dynamic Host Configuration Protocol (DHCP) [RFC2131] to obtain configuration parameters, such as a network address.
DHCP客户端DHCP客户端或“客户端”是使用动态主机配置协议（DHCP）[RFC2131]获取配置参数（如网络地址）的Internet主机。
DHCP server A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients.
DHCP服务器DHCP服务器或“服务器”是向DHCP客户端返回配置参数的Internet主机。
Link A communication facility or medium over which network nodes can communicate. Each link is associated with a minimum of two endpoints. Each link endpoint has a unique link-layer identifier.
链路网络节点可通过其进行通信的通信设施或介质。每个链接至少与两个端点关联。每个链接端点都有一个唯一的链接层标识符。
Link Down An event provided by the link layer that signifies a state change associated with the interface's no longer being capable of communicating data frames; transient periods of high frame loss are not sufficient. DNAv4 does not utilize "Link Down" indications.
链路断开由链路层提供的事件，该事件表示与接口不再能够通信数据帧相关联的状态改变；高帧丢失的瞬态周期是不够的。DNAv4不使用“链路断开”指示。
Link Layer Conceptual layer of control or processing logic that is responsible for maintaining control of the data link. The data link layer functions provide an interface between the higher-layer logic and the data link. The link layer is the layer immediately below IP.
链路层控制或处理逻辑的概念层，负责维护数据链路的控制。数据链路层功能提供高层逻辑和数据链路之间的接口。链路层是IP下的一层。
Link Up An event provided by the link layer that signifies a state change associated with the interface's becoming capable of communicating data frames.
链接由链接层提供的事件，表示与接口能够通信数据帧相关的状态更改。
Point of Attachment The link endpoint on the link to which the host is currently connected.
连接点主机当前连接到的链接上的链接端点。
Routable address In this specification, the term "routable address" refers to any unicast IPv4 address other than an IPv4 Link-Local address. This includes private addresses as specified in "Address Allocation for Private Internets" [RFC1918].
可路由地址在本规范中，术语“可路由地址”指除IPv4链路本地地址以外的任何单播IPv4地址。这包括“专用互联网地址分配”[RFC1918]中规定的专用地址。
Operable address In this specification, the term "operable address" refers either to a static IPv4 address, or an address assigned via DHCPv4 that has not been returned to the DHCP server via a DHCP RELEASE message, and whose lease has not yet expired.
可操作地址在本规范中，术语“可操作地址”是指静态IPv4地址或通过DHCPv4分配的地址，该地址尚未通过DHCP释放消息返回DHCP服务器，且其租约尚未到期。
On connecting to a new point of attachment, the host responds to a "Link Up" indication from the link layer by carrying out the DNAv4 procedure.
在连接到新的连接点时，主机通过执行DNAv4程序来响应链路层的“连接”指示。
For each network that it connects to, it is assumed that the host saves the following parameters to stable storage:
对于所连接的每个网络，假定主机将以下参数保存到稳定存储器中：
[1] The IPv4 and MAC address of one or more test nodes on the network.
[1] 网络上一个或多个测试节点的IPv4和MAC地址。
[2] The IPv4 configuration parameters, including the DHCP client identifier, assigned address, and lease expiration time.
[2] IPv4配置参数，包括DHCP客户端标识符、分配的地址和租约到期时间。
From the set of networks that have operable IPv4 addresses associated with them, the host selects a subset and attempts to confirm the configuration for each network, using the reachability test described in Section 2.1.
从具有与之相关联的可操作IPv4地址的网络集合中，主机选择一个子集，并尝试使用第2.1节中描述的可达性测试来确认每个网络的配置。
For a particular network, the host SHOULD use the addresses of local routers (preferably default gateways) as its test nodes. If more than one address is known, those addresses may be tested in parallel. In order to ensure configuration validity, the host SHOULD only configure routes for which the next hop address passes the reachability test. Other routes SHOULD be re-learned.
对于特定网络，主机应使用本地路由器（最好是默认网关）的地址作为其测试节点。如果已知多个地址，则可并行测试这些地址。为了确保配置有效性，主机应该只配置下一跳地址通过可达性测试的路由。应重新学习其他路线。
DNAv4 does not significantly increase the likelihood of an address conflict. The reachability test is only carried out for a network when the host has previously completed conflict detection as recommended in Section 2.2 of the DHCP specification [RFC2131] and obtained an operable IPv4 configuration on that network. Restrictions on sending ARP Requests and Responses are described in Section 2.1.1.
DNAv4不会显著增加地址冲突的可能性。仅当主机先前已按照DHCP规范[RFC2131]第2.2节的建议完成冲突检测并在该网络上获得可操作的IPv4配置时，才对网络执行可达性测试。第2.1.1节描述了发送ARP请求和响应的限制。
One case where DNAv4 does increase the likelihood of an address conflict is when:
DNAv4确实会增加地址冲突的可能性的一种情况是：
o a DHCP server hands out an address lease,
o DHCP服务器发出地址租约，
o the host with that lease leaves the network,
o 拥有该租约的主机离开网络，
o the DHCP server is power-cycled or crashes and is rebooted,
o DHCP服务器已断电或崩溃并重新启动，
o the DHCP server, having failed to save leases to stable storage, assigns that same address to another host, and
o DHCP服务器无法将租约保存到稳定存储，将该地址分配给另一台主机，然后
o the first host returns and, having a still-valid lease with time remaining, proceeds to use its assigned address, conflicting with the new host that is now using that same address.
o 第一台主机返回，并且在剩余时间内仍具有有效租约，继续使用其分配的地址，与当前使用相同地址的新主机冲突。
While Section 4 of the DHCP specification [RFC2131] assumes that DHCP servers save their leases in persistent storage, almost no consumer-grade NAT gateway does so. Short DHCP lease lifetimes can mitigate this risk, though this also limits the operable candidate configurations available for DNAv4 to try.
虽然DHCP规范[RFC2131]的第4节假定DHCP服务器将其租约保存在持久存储中，但几乎没有消费者级NAT网关这样做。较短的DHCP租用生命周期可以降低此风险，但这也限制了DNAv4可以尝试的可操作候选配置。
The host skips the reachability test for a network if any of the following conditions are true:
如果以下任一条件为真，主机将跳过网络的可达性测试：
[a] The host does not have an operable routable IPv4 address on that network. In this case, the reachability test cannot confirm that the host has an operable routable IPv4 address, so completing the reachability test would serve no purpose.
[a] 主机在该网络上没有可操作的可路由IPv4地址。在这种情况下，可达性测试无法确认主机是否具有可操作的可路由IPv4地址，因此完成可达性测试没有任何意义。
[b] The host does not know the addresses of any test nodes on that network. In this case, insufficient information is available to carry out the reachability test.
[b] 主机不知道该网络上任何测试节点的地址。在这种情况下，没有足够的信息来执行可达性测试。
[c] If DHCP authentication [RFC3118] is configured. The reachability test utilizes ARP, which is insecure. Hosts that have been configured to attempt DHCP authentication SHOULD NOT utilize the reachability test. Security issues are discussed in Section 4.
[c] 如果配置了DHCP身份验证[RFC3118]。可达性测试使用ARP，这是不安全的。已配置为尝试DHCP身份验证的主机不应使用可达性测试。第4节讨论了安全问题。
[d] The contents of the DHCP Client Identifier option that the client used to obtain the candidate configuration is different from the DHCP Client Identifier option the client intends to present on the interface in question. In this case, it is anticipated that a DHCP server would NAK any request made by the client to acquire or extend the candidate configuration, since the two interfaces are presenting differing identities.
[d] 客户端用于获取候选配置的DHCP客户端标识符选项的内容不同于客户端打算在相关接口上显示的DHCP客户端标识符选项。在这种情况下，由于两个接口呈现不同的身份，因此预期DHCP服务器将拒绝客户机发出的获取或扩展候选配置的任何请求。
If the reachability test is successful, the host SHOULD continue to use the operable routable IPv4 address associated with the confirmed network, without needing to re-acquire it. Once a valid reachability test response is received, validation is complete, and additional responses should be discarded.
如果可达性测试成功，主机应继续使用与确认网络相关联的可操作路由IPv4地址，而无需重新获取该地址。一旦收到有效的可达性测试响应，验证就完成了，应该放弃其他响应。
If a DHCPv4 client is operational, it is RECOMMENDED that the host attempt to obtain IPv4 configuration via DHCPv4 in parallel with the reachability tests, with the host using the first answer returned. This ensures that the DNAv4 procedure will not result in additional delay in the case where reachability tests fail, or where sending a DHCPREQUEST from the INIT-REBOOT state, as described in Section 3.2 and 4.3.2 of the DHCP specification [RFC2131], completes more quickly than the reachability tests.
如果DHCPv4客户端可运行，建议主机在进行可达性测试的同时，尝试通过DHCPv4获取IPv4配置，主机使用返回的第一个答案。这确保了在可达性测试失败的情况下，或在DHCP规范[RFC2131]第3.2节和第4.3.2节所述的从初始重新启动状态发送DHCPREQUEST的情况下，DNAv4过程不会导致额外的延迟，完成速度比可达性测试快。
In situations where both DNAv4 and DHCP are used on the same link, it is possible that the reachability test will complete successfully, and then DHCP will complete later with a different result. If this happens, the implementation SHOULD abandon the reachability test
在同一链路上同时使用DNAv4和DHCP的情况下，可能会成功完成可达性测试，然后DHCP将在稍后完成，并产生不同的结果。如果发生这种情况，实现应该放弃可达性测试
results and use the DHCP result instead, unless the address confirmed via the reachability test has been manually assigned (see Section 2.4).
结果并改用DHCP结果，除非已手动分配通过可达性测试确认的地址（见第2.4节）。
Where the reachability test does not return an answer, this is typically because the host is not attached to the network whose configuration is being tested. In such circumstances, there is typically little value in aggressively retransmitting reachability tests that do not elicit a response.
如果可达性测试没有返回答案，这通常是因为主机未连接到正在测试其配置的网络。在这种情况下，积极地重新传输不引起响应的可达性测试通常没有什么价值。
Where DNAv4 and DHCP are tried in parallel, one strategy is to forsake reachability test retransmissions and to allow only the DHCP client to retransmit. In order to reduce competition between DNAv4 and DHCP retransmissions, a DNAv4 implementation that retransmits may utilize the retransmission strategy described in Section 4.1 of the DHCP specification [RFC2131], scheduling DNAv4 retransmissions between DHCP retransmissions.
在并行尝试DNAv4和DHCP的情况下，一种策略是放弃可达性测试重传，只允许DHCP客户端重传。为了减少DNAv4和DHCP重传之间的竞争，重传的DNAv4实现可以利用DHCP规范[RFC2131]第4.1节中描述的重传策略，在DHCP重传之间调度DNAv4重传。
If a response is received to any reachability test or DHCP message, pending retransmissions are canceled. It is RECOMMENDED that a DNAv4 implementation retransmit no more than twice. To provide damping in the case of spurious "Link Up" indications, it is RECOMMENDED that the DNAv4 procedure be carried out no more than once a second.
如果收到对任何可达性测试或DHCP消息的响应，则取消挂起的重新传输。建议DNAv4实现的重新传输不超过两次。为了在出现虚假“连接”指示的情况下提供阻尼，建议DNAv4程序每秒执行不超过一次。
The reachability test is performed by sending a unicast ARP Request. The host MUST set the target protocol address (ar$tpa) to the IPv4 address of the node being tested, and the sender protocol address field (ar$spa) to its own candidate IPv4 address. The ARP Request MUST use the host MAC address as the source, and the test node MAC address as the destination. The host includes its MAC address in the sender hardware address field (ar$sha) and sets the target hardware address field (ar$tha) to 0.
通过发送单播ARP请求来执行可达性测试。主机必须将目标协议地址（ar$tpa）设置为被测试节点的IPv4地址，将发送方协议地址字段（ar$spa）设置为其自己的候选IPv4地址。ARP请求必须使用主机MAC地址作为源，使用测试节点MAC地址作为目标。主机将其MAC地址包含在发送方硬件地址字段（ar$sha）中，并将目标硬件地址字段（ar$tha）设置为0。
If a valid ARP Reply is received, the MAC address in the sender hardware address field (ar$sha) in the ARP Reply is matched against the target hardware address field (ar$tpa) in the ARP Request, and the IPv4 address in the sender protocol address field (ar$spa) of the ARP Reply is matched against the target protocol address field (ar$tpa) in the ARP Request. If a match is found, then the host continues to use that IPv4 address, subject to the lease re-acquisition and expiration behavior described in Section 4.4.5 of the DHCP specification [RFC2131].
如果收到有效的ARP回复，ARP回复中发送方硬件地址字段（ar$sha）中的MAC地址与ARP请求中的目标硬件地址字段（ar$tpa）匹配，ARP回复的发送方协议地址字段（ar$spa）中的IPv4地址与目标协议地址字段（ar$tpa）匹配在ARP请求中。如果找到匹配项，则主机将继续使用该IPv4地址，遵守DHCP规范[RFC2131]第4.4.5节中描述的租约重新获取和到期行为。
The risk of an address conflict is greatest when the host moves between private networks, since in this case the completion of conflict detection on the former network does not provide assurance
当主机在专用网络之间移动时，地址冲突的风险最大，因为在这种情况下，在前一个网络上完成冲突检测并不能提供保证
against an address conflict on the new network. Until a host has confirmed the operability of its IPv4 configuration by receipt of a response to the reachability test, it SHOULD NOT respond to ARP Requests and SHOULD NOT broadcast ARP Requests containing its address within the sender protocol address field (ar$spa).
针对新网络上的地址冲突。在主机通过接收到对可达性测试的响应来确认其IPv4配置的可操作性之前，它不应响应ARP请求，也不应在发送方协议地址字段（ar$spa）内广播包含其地址的ARP请求。
Sending an ICMP Echo Request [RFC792] would not be an acceptable way of testing a candidate configuration, since sending any IP packet generally requires an ARP Request/Reply exchange and, as explained above, ARP packets may not be broadcast safely until after the candidate configuration has been confirmed. Also, where a host moves from one private network to another, an ICMP Echo Request can result in an ICMP Echo Response even when the MAC address has changed, as long as the IPv4 address remains the same. This can occur, for example, where a host moves from one home network using prefix 192.168/16 to another one. In addition, if the ping is sent with TTL > 1, then an ICMP Echo Response can be received from an off-link router. As a result, if the MAC address of the test node is not checked, the host can mistakenly confirm attachment, potentially resulting in an address conflict. As a result, sending an ICMP Echo Request SHOULD NOT be used as a substitute for the reachability test.
发送ICMP回显请求[RFC792]不是测试候选配置的可接受方式，因为发送任何IP数据包通常需要ARP请求/应答交换，并且如上所述，ARP数据包可能在候选配置得到确认后才能安全广播。此外，当主机从一个专用网络移动到另一个专用网络时，即使MAC地址已更改，只要IPv4地址保持不变，ICMP回显请求也可能导致ICMP回显响应。例如，当主机使用前缀192.168/16从一个家庭网络移动到另一个家庭网络时，可能会发生这种情况。此外，如果发送ping时TTL>1，则可以从断开链路的路由器接收ICMP回显响应。因此，如果未检查测试节点的MAC地址，主机可能会错误地确认连接，从而可能导致地址冲突。因此，发送ICMP回显请求不应被用作可达性测试的替代。
If the host has an operable routable IPv4 address on one or more networks, and if DHCPv4 is enabled on the interface, the host SHOULD attempt to acquire an IPv4 configuration using DHCPv4, in parallel with one or more reachability tests. This is accomplished by entering the INIT-REBOOT state and sending a DHCPREQUEST to the broadcast address, as specified in Section 4.4.2 of the DHCP specification [RFC2131].
如果主机在一个或多个网络上具有可操作的可路由IPv4地址，并且在接口上启用了DHCPv4，则主机应尝试使用DHCPv4获取IPv4配置，同时进行一个或多个可达性测试。按照DHCP规范[RFC2131]第4.4.2节的规定，这是通过进入INIT-REBOOT状态并向广播地址发送DHCPREQUEST来实现的。
If the host does not have an operable routable IPv4 address on any network, the host enters the INIT state and sends a DHCPDISCOVER packet to the broadcast address, as described in Section 4.4.1 of the DHCP specification [RFC2131]. If the host supports the Rapid Commit Option [RFC4039], it is possible that the exchange can be shortened from a 4-message exchange to a 2-message exchange.
如DHCP规范[RFC2131]第4.4.1节所述，如果主机在任何网络上没有可操作的可路由IPv4地址，主机将进入初始状态并向广播地址发送DHCPDISCOVER数据包。如果主机支持快速提交选项[RFC4039]，则可以将交换从4消息交换缩短为2消息交换。
If the host does not receive a response to a DHCPREQUEST or DHCPDISCOVER, then it retransmits as specified in Section 4.1 of the DHCP specification [RFC2131].
如果主机没有收到对DHCPREQUEST或DHCPDISCOVER的响应，则按照DHCP规范[RFC2131]第4.1节的规定重新传输。
As discussed in Section 4.4.4 of the DHCP specification [RFC2131], a host in INIT or REBOOTING state that knows the address of a DHCP server may use that address in the DHCPDISCOVER or DHCPREQUEST rather than the IPv4 broadcast address. In the INIT-REBOOT state, a DHCPREQUEST is sent to the broadcast address so that the host will
如DHCP规范[RFC2131]第4.4.4节所述，处于初始化或重新启动状态且知道DHCP服务器地址的主机可以在DHCPDISCOVER或DHCPREQUEST中使用该地址，而不是IPv4广播地址。在INIT-REBOOT状态下，会向广播地址发送DHCPREQUEST，以便主机
receive a response regardless of whether the previously configured IPv4 address is correct for the network to which it has connected.
接收响应，无论先前配置的IPv4地址对于其所连接的网络是否正确。
Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is not appropriate, since if the DHCP client has moved to another subnet, a DHCP server response cannot be routed back to the client since the DHCPREQUEST will bypass the DHCP relay and will contain an invalid source address.
在INIT-REBOOT状态下向单播地址发送DHCPREQUEST是不合适的，因为如果DHCP客户端已移动到另一个子网，则无法将DHCP服务器响应路由回客户端，因为DHCPREQUEST将绕过DHCP中继并包含无效的源地址。
DNAv4 applies only to previously configured addresses that had some lease lifetime associated with them, during which lifetime the address may be legitimately regarded as being reserved for exclusive use by the assigned host. DHCP-assigned addresses fit this description, but IPv4 Link-Local address [RFC3927] do not, since IPv4 Link-Local addresses are not handed out by an authoritative server and do not come with any guaranteed usable lifetime.
DNAv4仅适用于先前配置的地址，这些地址具有与之相关联的一些租约生存期，在此生存期内，该地址可能被合法地视为保留供分配的主机独占使用。DHCP分配的地址符合此描述，但IPv4链路本地地址[RFC3927]不符合此描述，因为IPv4链路本地地址不是由权威服务器分发的，并且没有任何保证的可用寿命。
A host's claim on an IPv4 Link-Local address is valid only as long as that host remains connected to the link, actively defending against probes for its chosen address. As soon as a host shuts down, sleeps, or otherwise disconnects from a link, it immediately relinquishes any claim it may have had on any IPv4 Link-Local address on that link. A host wishing to reclaim a previously used IPv4 Link-Local address MUST perform the full probing and announcement process required by "Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927] and MUST NOT attempt to use DNAv4 as a shortcut to bypass that process.
主机对IPv4链路本地地址的声明只有在该主机保持与该链路的连接并主动防御对其所选地址的探测时才有效。一旦主机关闭、休眠或以其他方式断开与链路的连接，它将立即放弃对该链路上任何IPv4链路本地地址的任何声明。希望回收以前使用的IPv4链路本地地址的主机必须执行“IPv4链路本地地址的动态配置”[RFC3927]所要求的完整探测和通告过程，并且不得尝试使用DNAv4作为绕过该过程的快捷方式。
Where the host does not have an operable routable IPv4 address on any network, the host MAY configure an IPv4 Link-Local address prior to entering the INIT state and sending a DHCPDISCOVER packet, as described in Section 2.3 of the DHCP specification [RFC2131]. Where a host can confirm that it remains connected to a network on which it possesses an operable routable IPv4 address, that address should be used, and the IPv4 Link-Local address is deprecated, as noted in Section 1.9 of the IPv4 Link-Local specification [RFC3927].
如果主机在任何网络上没有可操作的可路由IPv4地址，则主机可在进入初始状态并发送DHCPDISCOVER数据包之前配置IPv4链路本地地址，如DHCP规范[RFC2131]第2.3节所述。如IPv4链路本地规范[RFC3927]第1.9节所述，如果主机可以确认其仍然连接到其拥有可操作路由IPv4地址的网络，则应使用该地址，并且IPv4链路本地地址已被弃用。
Where a host has an operable routable IPv4 address on one or more networks but the reachability test cannot confirm the configuration and the DHCPv4 client does not receive a response after employing the retransmission algorithm, Section 3.2 of the DHCP specification [RFC2131] states that the client MAY choose to use the previously allocated network address and configuration parameters for the remainder of the unexpired lease.
如果主机在一个或多个网络上具有可操作的可路由IPv4地址，但可达性测试无法确认配置，且DHCPv4客户端在采用重传算法后未收到响应，则DHCP规范[RFC2131]第3.2节声明客户端可以选择在剩余的未到期租约中使用先前分配的网络地址和配置参数。
An implementation may use DNAv4 to confirm the configuration of manually assigned addresses. However, special consideration is required for this to produce reliable results, so it SHOULD NOT be enabled by default.
实现可以使用DNAv4来确认手动分配地址的配置。但是，为了产生可靠的结果，需要特别考虑，因此默认情况下不应启用它。
For the purposes of DNAv4, manually assigned addresses may be treated as equivalent to DHCP-assigned addresses with an infinite lifetime. This does not significantly increase the probability of an address conflict as long as the manually assigned address is reserved by the DHCP server or is outside the scope of addresses assigned by a DHCP server. However, where the manually assigned address is within an address scope utilized by a DHCP server, it is possible that the host will be unavailable when the DHCP server checks for a conflict prior to assigning the conflicting address. In this case, a host utilizing DNAv4 could confirm an address that had been assigned to another host.
出于DNAv4的目的，手动分配的地址可被视为等同于具有无限生存期的DHCP分配地址。只要手动分配的地址由DHCP服务器保留或不在DHCP服务器分配的地址范围内，这不会显著增加地址冲突的可能性。但是，如果手动分配的地址在DHCP服务器使用的地址范围内，则当DHCP服务器在分配冲突地址之前检查冲突时，主机可能不可用。在这种情况下，使用DNAv4的主机可以确认已分配给另一台主机的地址。
Typically, an address is manually assigned on a network because a dynamically assigned address was not suitable for some reason. Therefore, where DNAv4 and DHCP are run in parallel and DNAv4 confirms a manual configuration, it may be undesirable to allow this configuration to be overridden by DHCP, as described in Section 2.1. However, packet loss may cause the reachability test to fail while DHCP completes successfully, resulting in the host obtaining a dynamic address where a static address is desired. In order to provide for reliable reconfirmation of manually assigned addresses, reachability tests for manual configurations require a more aggressive retransmission strategy than that detailed in Section 4.1 of the DHCP specification [RFC2131]. For example, shorter retransmission intervals and more persistent retransmissions may be required.
通常，在网络上手动分配地址是因为动态分配的地址由于某些原因不适合。因此，当DNAv4和DHCP并行运行且DNAv4确认手动配置时，可能不希望允许DHCP覆盖此配置，如第2.1节所述。但是，当DHCP成功完成时，数据包丢失可能会导致可达性测试失败，从而导致主机获得需要静态地址的动态地址。为了提供手动分配地址的可靠再确认，手动配置的可达性测试需要比DHCP规范[RFC2131]第4.1节中详述的更积极的重传策略。例如，可能需要更短的重传间隔和更持久的重传。
Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and DHCP and inherits the security vulnerabilities of these two protocols.
检测IPv4（DNAv4）的网络连接基于ARP和DHCP，继承了这两个协议的安全漏洞。
ARP [RFC826] traffic is not secured, so an attacker gaining access to the network can spoof a response to the reachability test described in Section 2.1, leading the querier to conclude falsely that it is attached to a network that it is not connected to.
ARP[RFC826]流量不安全，因此获得网络访问权限的攻击者可以伪造对第2.1节所述可达性测试的响应，从而导致查询者错误地得出结论，即它连接到了未连接的网络。
Similarly, where DHCPv4 traffic is not secured, an attacker could masquerade as a DHCPv4 server, in order to convince the host that it was attached to a particular network. This and other threats
类似地，在DHCPv4通信不安全的情况下，攻击者可以伪装成DHCPv4服务器，以使主机确信它已连接到特定网络。这一威胁和其他威胁
relating to DHCPv4 are described in "Authentication for DHCP Messages" [RFC3118].
“DHCP消息的身份验证”[RFC3118]中描述了与DHCPv4相关的信息。
The effect of these attacks will typically be limited to denial of service, unless the host utilizes its IP configuration for other purposes, such as security configuration or location determination. For example, a host that disables its personal firewall based on evidence that it had attached to a home network could be compromised by spoofing of the DNAv4 reachability test. In general, adjustment of the security configuration based on DNAv4 is NOT RECOMMENDED.
这些攻击的影响通常仅限于拒绝服务，除非主机将其IP配置用于其他目的，如安全配置或位置确定。例如，如果主机根据其连接到家庭网络的证据禁用其个人防火墙，则可能会通过欺骗DNAv4可达性测试而受损。通常，不建议根据DNAv4调整安全配置。
Hosts that depend on secure IP configuration SHOULD NOT use DNAv4 but SHOULD instead utilize DHCP authentication [RFC3118], possibly in combination with the Rapid Commit Option [RFC4039].
依赖安全IP配置的主机不应使用DNAv4，而应使用DHCP身份验证[RFC3118]，可能与快速提交选项[RFC4039]结合使用。
[RFC826] Plummer, D., "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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[ACD] Cheshire, S., "IPv4 Address Conflict Detection", Work in Progress, July 2005.
[ACD]南柴郡，“IPv4地址冲突检测”，正在进行的工作，2005年7月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[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月。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118]Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[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月。
[RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 4039, March 2005.
[RFC4039]Park，S.，Kim，P.，和B.Volz，“动态主机配置协议版本4（DHCPv4）的快速提交选项”，RFC 4039，2005年3月。
The authors would like to acknowledge Greg Daley of Monash University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ralph Droms of Cisco Systems, Ted Lemon of Nominum, John Loughney of Nokia, Thomas Narten of IBM and David Hankins of ISC for contributions to this document.
作者要感谢莫纳什大学的格雷格·戴利、太阳微系统公司的埃里克·古特曼和埃里克·诺德马克、思科系统公司的拉尔夫·德罗姆斯、诺米姆公司的泰德·莱蒙、诺基亚公司的约翰·拉夫尼、IBM公司的托马斯·纳腾和ISC公司的大卫·汉金斯对本文件的贡献。
Authors' Addresses
作者地址
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 818 4011
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Phone: +1 425 818 4011
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
James Carlson Sun Microsystems, Inc 1 Network Drive Burlington, MA 01803-2757 USA
美国马萨诸塞州伯灵顿市网络大道1号詹姆斯·卡尔森太阳微系统公司01803-2757
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino, California 95014, USA
Stuart Cheshire Apple Computer，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 Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。