Network Working Group S. Cheshire
Request for Comments: 3927 Apple Computer
Category: Standards Track B. Aboba
Microsoft Corporation
E. Guttman
Sun Microsystems
May 2005
Network Working Group S. Cheshire
Request for Comments: 3927 Apple Computer
Category: Standards Track B. Aboba
Microsoft Corporation
E. Guttman
Sun Microsystems
May 2005
Dynamic Configuration of IPv4 Link-Local Addresses
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.
要参与广域IP网络，主机需要为其接口配置IP地址，可以由用户手动配置，也可以从网络上的源（如动态主机配置协议（DHCP）服务器）自动配置。不幸的是，这样的地址配置信息可能并不总是可用的。因此，即使没有可用的地址配置，主机也能够依赖于IP网络功能的有用子集是有益的。本文档描述了主机如何自动配置具有169.254/16前缀内IPv4地址的接口，该地址对于与连接到同一物理（或逻辑）链路的其他设备的通信有效。
IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.
IPv4链路本地地址不适合与未直接连接到同一物理（或逻辑）链路的设备进行通信，仅在稳定、可路由的地址不可用的情况下使用（如在自组织或隔离网络上）。本文档不建议在同一接口上同时配置IPv4链路本地地址和可路由地址。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements. . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . 5
1.4. Application Layer Protocol Considerations . . . . . . . 6
1.5. Autoconfiguration Issues. . . . . . . . . . . . . . . . 7
1.6. Alternate Use Prohibition . . . . . . . . . . . . . . . 7
1.7. Multiple Interfaces . . . . . . . . . . . . . . . . . . 8
1.8. Communication with Routable Addresses . . . . . . . . . 8
1.9. When to configure an IPv4 Link-Local Address. . . . . . 8
2. Address Selection, Defense and Delivery . . . . . . . . . . . 9
2.1. Link-Local Address Selection. . . . . . . . . . . . . . 10
2.2. Claiming a Link-Local Address . . . . . . . . . . . . . 11
2.3. Shorter Timeouts. . . . . . . . . . . . . . . . . . . . 13
2.4. Announcing an Address . . . . . . . . . . . . . . . . . 13
2.5. Conflict Detection and Defense. . . . . . . . . . . . . 13
2.6. Address Usage and Forwarding Rules. . . . . . . . . . . 14
2.7. Link-Local Packets Are Not Forwarded. . . . . . . . . . 16
2.8. Link-Local Packets are Local. . . . . . . . . . . . . . 16
2.9. Higher-Layer Protocol Considerations. . . . . . . . . . 17
2.10. Privacy Concerns. . . . . . . . . . . . . . . . . . . . 17
2.11. Interaction between DHCPv4 and IPv4 Link-Local
State Machines. . . . . . . . . . . . . . . . . . . . . 17
3. Considerations for Multiple Interfaces. . . . . . . . . . . . 18
3.1. Scoped Addresses. . . . . . . . . . . . . . . . . . . . 18
3.2. Address Ambiguity . . . . . . . . . . . . . . . . . . . 19
3.3. Interaction with Hosts with Routable Addresses. . . . . 20
3.4. Unintentional Autoimmune Response . . . . . . . . . . . 21
4. Healing of Network Partitions . . . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Application Programming Considerations. . . . . . . . . . . . 24
6.1. Address Changes, Failure and Recovery . . . . . . . . . 24
6.2. Limited Forwarding of Locators. . . . . . . . . . . . . 24
6.3. Address Ambiguity . . . . . . . . . . . . . . . . . . . 25
7. Router Considerations . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References. . . . . . . . . . . . . . . . . . 26
10.2. Informative References. . . . . . . . . . . . . . . . . 26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A - Prior Implementations. . . . . . . . . . . . . . . . 28
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements. . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . 5
1.4. Application Layer Protocol Considerations . . . . . . . 6
1.5. Autoconfiguration Issues. . . . . . . . . . . . . . . . 7
1.6. Alternate Use Prohibition . . . . . . . . . . . . . . . 7
1.7. Multiple Interfaces . . . . . . . . . . . . . . . . . . 8
1.8. Communication with Routable Addresses . . . . . . . . . 8
1.9. When to configure an IPv4 Link-Local Address. . . . . . 8
2. Address Selection, Defense and Delivery . . . . . . . . . . . 9
2.1. Link-Local Address Selection. . . . . . . . . . . . . . 10
2.2. Claiming a Link-Local Address . . . . . . . . . . . . . 11
2.3. Shorter Timeouts. . . . . . . . . . . . . . . . . . . . 13
2.4. Announcing an Address . . . . . . . . . . . . . . . . . 13
2.5. Conflict Detection and Defense. . . . . . . . . . . . . 13
2.6. Address Usage and Forwarding Rules. . . . . . . . . . . 14
2.7. Link-Local Packets Are Not Forwarded. . . . . . . . . . 16
2.8. Link-Local Packets are Local. . . . . . . . . . . . . . 16
2.9. Higher-Layer Protocol Considerations. . . . . . . . . . 17
2.10. Privacy Concerns. . . . . . . . . . . . . . . . . . . . 17
2.11. Interaction between DHCPv4 and IPv4 Link-Local
State Machines. . . . . . . . . . . . . . . . . . . . . 17
3. Considerations for Multiple Interfaces. . . . . . . . . . . . 18
3.1. Scoped Addresses. . . . . . . . . . . . . . . . . . . . 18
3.2. Address Ambiguity . . . . . . . . . . . . . . . . . . . 19
3.3. Interaction with Hosts with Routable Addresses. . . . . 20
3.4. Unintentional Autoimmune Response . . . . . . . . . . . 21
4. Healing of Network Partitions . . . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6. Application Programming Considerations. . . . . . . . . . . . 24
6.1. Address Changes, Failure and Recovery . . . . . . . . . 24
6.2. Limited Forwarding of Locators. . . . . . . . . . . . . 24
6.3. Address Ambiguity . . . . . . . . . . . . . . . . . . . 25
7. Router Considerations . . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. References. . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References. . . . . . . . . . . . . . . . . . 26
10.2. Informative References. . . . . . . . . . . . . . . . . 26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A - Prior Implementations. . . . . . . . . . . . . . . . 28
As the Internet Protocol continues to grow in popularity, it becomes increasingly valuable to be able to use familiar IP tools such as FTP not only for global communication, but for local communication as well. For example, two people with laptop computers supporting IEEE 802.11 Wireless LANs [802.11] may meet and wish to exchange files. It is desirable for these people to be able to use IP application software without the inconvenience of having to manually configure static IP addresses or set up a DHCP server [RFC2131].
随着互联网协议的不断普及，能够使用熟悉的IP工具（如FTP）不仅用于全球通信，而且也用于本地通信变得越来越有价值。例如，两个拥有支持IEEE 802.11无线局域网[802.11]的笔记本电脑的人可能会会面并希望交换文件。这些人希望能够使用IP应用软件，而不必手动配置静态IP地址或设置DHCP服务器[RFC2131]。
This document describes a method by which a host may automatically configure an interface with an IPv4 address in the 169.254/16 prefix that is valid for Link-Local communication on that interface. This is especially valuable in environments where no other configuration mechanism is available. The IPv4 prefix 169.254/16 is registered with the IANA for this purpose. Allocation of IPv6 Link-Local addresses is described in "IPv6 Stateless Address Autoconfiguration" [RFC2462].
本文档描述了一种方法，通过该方法，主机可以自动配置具有169.254/16前缀的IPv4地址的接口，该地址对该接口上的链路本地通信有效。在没有其他配置机制的环境中，这一点尤其重要。为此，向IANA注册了IPv4前缀169.254/16。“IPv6无状态地址自动配置”[RFC2462]中描述了IPv6链路本地地址的分配。
Link-Local communication using IPv4 Link-Local addresses is only suitable for communication with other devices connected to the same physical (or logical) link. Link-Local communication using IPv4 Link-Local addresses is not suitable for communication with devices not directly connected to the same physical (or logical) link.
使用IPv4链路本地地址的链路本地通信仅适用于与连接到同一物理（或逻辑）链路的其他设备的通信。使用IPv4链路本地地址的链路本地通信不适合与未直接连接到同一物理（或逻辑）链路的设备进行通信。
Microsoft Windows 98 (and later) and Mac OS 8.5 (and later) already support this capability. This document standardizes usage, prescribing rules for how IPv4 Link-Local addresses are to be treated by hosts and routers. In particular, it describes how routers are to behave when receiving packets with IPv4 Link-Local addresses in the source or destination address. With respect to hosts, it discusses claiming and defending addresses, maintaining Link-Local and routable IPv4 addresses on the same interface, and multi-homing issues.
Microsoft Windows 98（及更高版本）和Mac OS 8.5（及更高版本）已经支持此功能。本文档规范了使用，规定了主机和路由器如何处理IPv4链路本地地址的规则。特别是，它描述了路由器在接收源地址或目标地址中包含IPv4链路本地地址的数据包时的行为。关于主机，它讨论了请求和保护地址、在同一接口上维护链路本地和可路由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" [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照“RFC中使用的关键词”[RFC2119]中的描述进行解释。
This document describes Link-Local addressing, for IPv4 communication between two hosts on a single link. A set of hosts is considered to be "on the same link", if:
本文档描述了单个链路上两台主机之间IPv4通信的链路本地寻址。一组主机被视为“在同一链路上”，如果：
- 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路由器之类的设备。
This document uses the term "routable address" to refer to all valid unicast IPv4 addresses outside the 169.254/16 prefix that may be forwarded via routers. This includes all global IP addresses and private addresses such as Net 10/8 [RFC1918], but not loopback addresses such as 127.0.0.1.
本文档使用术语“可路由地址”来指代169.254/16前缀之外的所有可通过路由器转发的有效单播IPv4地址。这包括所有全局IP地址和专用地址，如Net 10/8[RFC1918]，但不包括环回地址，如127.0.0.1。
Wherever this document uses the term "host" when describing use of IPv4 Link-Local addresses, the text applies equally to routers when they are the source of or intended destination of packets containing IPv4 Link-Local source or destination addresses.
当本文档在描述IPv4链路本地地址的使用时使用术语“主机”时，当路由器是包含IPv4链路本地源或目标地址的数据包的源或预期目标时，本文本同样适用于路由器。
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 IP address.
如果本文件在ARP数据包的上下文中使用术语“发送方IP地址”或“目标IP地址”，则它指的是ARP规范[RFC826]中标识为“ar$spa”（发送方协议地址）和“ar$tpa”（目标协议地址）的ARP数据包字段。对于本文档中描述的ARP的使用，每个字段始终包含一个IP地址。
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 '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.
在本文档中，术语“ARP探测”用于指在本地链路上广播的ARP请求包，其“发送方IP地址”为零。“发送方硬件地址”必须包含发送数据包的接口的硬件地址。“目标硬件地址”字段被忽略，应设置为全零。“目标IP地址”字段必须设置为要探测的地址。
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.
在本文档中，术语“ARP公告”用于指在本地链路上广播的ARP请求包，与上述ARP探测相同，只是发送方和目标IP地址字段都包含被公告的IP地址。
Constants are introduced in all capital letters. Their values are given in Section 9.
常量以大写字母表示。第9节给出了它们的值。
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 Mbps, have a round-trip latency of at most one second, and support ARP [RFC826]. 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]，以及以至少1Mbps的数据速率运行、具有最多1秒的往返延迟且支持ARP[RFC826]的其他链路层技术。本文件使用术语“IEEE 802”时，本文本同样适用于任何此类网络技术。
Link-layer technologies that support ARP but operate at rates below 1 Mbps or latencies above one second may need to specify different values for the following parameters:
支持ARP但以低于1Mbps的速率或超过1秒的延迟运行的链路层技术可能需要为以下参数指定不同的值：
(a) the number of, and interval between, ARP probes, see PROBE_NUM, PROBE_MIN, PROBE_MAX defined in Section 2.2.1
(a) ARP探测的数量和间隔，见第2.2.1节中定义的探测数量、探测最小值和探测最大值
(b) the number of, and interval between, ARP announcements, see ANNOUNCE_NUM and ANNOUNCE_INTERVAL defined in Section 2.4
(b) ARP公告的数量和间隔，请参见第2.4节中定义的公告数量和公告间隔
(c) the maximum rate at which address claiming may be attempted, see RATE_LIMIT_INTERVAL and MAX_CONFLICTS defined in Section 2.2.1
(c) 尝试地址声明的最大速率，请参阅第2.2.1节中定义的速率限制间隔和最大冲突
(d) the time interval between conflicting ARPs below which a host MUST reconfigure instead of attempting to defend its address, see DEFEND_INTERVAL defined in Section 2.5
(d) 冲突ARP之间的时间间隔，低于此时间间隔主机必须重新配置，而不是试图保护其地址，请参阅第2.5节中定义的保护间隔
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, the application of claim-and-defend mechanisms to such networks is outside the scope of this document.
不支持ARP的链路层技术可以使用其他技术来确定特定IP地址当前是否正在使用。然而，对此类网络应用索赔和抗辩机制不在本文件范围之内。
This specification is intended for use with small ad hoc networks -- a single link containing only a few hosts. Although 65024 IPv4 Link-Local addresses are available in principle, attempting to use all those addresses on a single link would result in a high probability of address conflicts, requiring a host to take an inordinate amount of time to find an available address.
本规范旨在用于小型自组织网络——仅包含少数主机的单一链路。虽然65024 IPv4链路本地地址原则上是可用的，但尝试在单个链路上使用所有这些地址将导致地址冲突的高概率，这需要主机花费大量时间来查找可用地址。
Network operators with more than 1300 hosts on a single link may want to consider dividing that single link into two or more subnets. A host connecting to a link that already has 1300 hosts, selecting an IPv4 Link-Local address at random, has a 98% chance of selecting an unused IPv4 Link-Local address on the first try. A host has a 99.96%
在单个链路上具有超过1300个主机的网络运营商可能要考虑将该单个链路划分为两个或多个子网。连接到已有1300台主机的链路的主机，随机选择IPv4链路本地地址，在第一次尝试时有98%的几率选择未使用的IPv4链路本地地址。主机拥有99.96%的
chance of selecting an unused IPv4 Link-Local address within two tries. The probability that it will have to try more than ten times is about 1 in 10^17.
在两次尝试中选择未使用的IPv4链路本地地址的机会。它必须尝试10次以上的概率约为1/10^17。
IPv4 Link-Local addresses and their dynamic configuration have profound implications upon applications which use them. This is discussed in Section 6. Many applications fundamentally assume that addresses of communicating peers are routable, relatively unchanging and unique. These assumptions no longer hold with IPv4 Link-Local addresses, or a mixture of Link-Local and routable IPv4 addresses.
IPv4链路本地地址及其动态配置对使用它们的应用程序有着深远的影响。第6节对此进行了讨论。许多应用程序基本上假定通信对等方的地址是可路由的、相对不变的和唯一的。这些假设不再适用于IPv4链路本地地址，也不再适用于链路本地地址和可路由IPv4地址的混合。
Therefore while many applications will work properly with IPv4 Link-Local addresses, or a mixture of Link-Local and routable IPv4 addresses, others may do so only after modification, or will exhibit reduced or partial functionality.
因此，虽然许多应用程序可以使用IPv4链路本地地址或链路本地地址和可路由IPv4地址的混合地址正常工作，但其他应用程序可能仅在修改后才能这样做，或者将显示出减少的或部分的功能。
In some cases it may be infeasible for the application to be modified to operate under such conditions.
在某些情况下，将应用程序修改为在此类条件下运行可能是不可行的。
IPv4 Link-Local addresses should therefore only be used where stable, routable addresses are not available (such as on ad hoc or isolated networks) or in controlled situations where these limitations and their impact on applications are understood and accepted. This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.
因此，IPv4链路本地地址应仅在稳定的、可路由的地址不可用的情况下（如在特设或隔离网络上）或在理解和接受这些限制及其对应用程序的影响的受控情况下使用。本文档不建议在同一接口上同时配置IPv4链路本地地址和可路由地址。
Use of IPv4 Link-Local addresses in off-link communication is likely to cause application failures. This can occur within any application that includes embedded addresses, if an IPv4 Link-Local address is embedded when communicating with a host that is not on the link. Examples of applications that embed addresses include IPsec, Kerberos 4/5, FTP, RSVP, SMTP, SIP, X-Windows/Xterm/Telnet, Real Audio, H.323, and SNMP [RFC3027].
在非链路通信中使用IPv4链路本地地址可能会导致应用程序失败。如果在与不在该链路上的主机通信时嵌入了IPv4链路本地地址，则这可能发生在包含嵌入地址的任何应用程序中。嵌入地址的应用程序示例包括IPsec、Kerberos 4/5、FTP、RSVP、SMTP、SIP、X-Windows/Xterm/Telnet、Real Audio、H.323和SNMP[RFC3027]。
To preclude use of IPv4 Link-Local addresses in off-link communication, the following cautionary measures are advised:
为避免在非链路通信中使用IPv4链路本地地址，建议采取以下警告措施：
a. IPv4 Link-Local addresses MUST NOT be configured in the DNS. Mapping from IPv4 addresses to host names is conventionally done by issuing DNS queries for names of the form, "x.x.x.x.in-addr.arpa." When used for link-local addresses, which have significance only on the local link, it is inappropriate to send such DNS queries beyond the local link. DNS clients MUST NOT send DNS queries for any name that falls within the "254.169.in-addr.arpa." domain.
a. 不得在DNS中配置IPv4链路本地地址。传统上，从IPv4地址到主机名的映射是通过对“x.x.x.x.in-addr.arpa”形式的名称发出DNS查询来完成的。当用于仅在本地链路上有意义的链路本地地址时，将此类DNS查询发送到本地链路之外是不合适的。DNS客户端不得发送DNS查询以查找“254.169.in addr.arpa.”域中的任何名称。
DNS recursive name servers receiving queries from non-compliant clients for names within the "254.169.in-addr.arpa." domain MUST by default return RCODE 3, authoritatively asserting that no such name exists in the Domain Name System.
DNS递归名称服务器从不符合要求的客户端接收对“254.169.in addr.arpa.”域内名称的查询，默认情况下必须返回RCODE 3，授权断言域名系统中不存在此类名称。
b. Names that are globally resolvable to routable addresses should be used within applications whenever they are available. Names that are resolvable only on the local link (such as through use of protocols such as Link Local Multicast Name Resolution [LLMNR]) MUST NOT be used in off-link communication. IPv4 addresses and names that can only be resolved on the local link SHOULD NOT be forwarded beyond the local link. IPv4 Link-Local addresses SHOULD only be sent when a Link-Local address is used as the source and/or destination address. This strong advice should hinder limited scope addresses and names from leaving the context in which they apply.
b. 可全局解析为可路由地址的名称应在应用程序中使用，只要它们可用。只能在本地链路上解析的名称（例如通过使用链路本地多播名称解析[LLMNR]等协议）不得用于非链路通信。只能在本地链路上解析的IPv4地址和名称不应转发到本地链路之外。只有当链接本地地址用作源地址和/或目标地址时，才应发送IPv4链接本地地址。这种强烈的建议应该会阻止有限范围的地址和名称离开应用它们的上下文。
c. If names resolvable to globally routable addresses are not available, but the globally routable addresses are, they should be used instead of IPv4 Link-Local addresses.
c. 如果可解析为全局可路由地址的名称不可用，但全局可路由地址可用，则应使用它们而不是IPv4链路本地地址。
Implementations of IPv4 Link-Local address autoconfiguration MUST expect address conflicts, and MUST be prepared to handle them gracefully by automatically selecting a new address whenever a conflict is detected, as described in Section 2. This requirement to detect and handle address conflicts applies during the entire period that a host is using a 169.254/16 IPv4 Link-Local address, not just during initial interface configuration. For example, address conflicts can occur well after a host has completed booting if two previously separate networks are joined, as described in Section 4.
IPv4链路本地地址自动配置的实现必须预料到地址冲突，并且必须准备好在检测到冲突时自动选择新地址，以优雅地处理这些冲突，如第2节所述。检测和处理地址冲突的要求适用于主机使用169.254/16 IPv4链路本地地址的整个期间，而不仅仅是在初始接口配置期间。例如，如第4节所述，如果连接了两个以前独立的网络，则在主机完成引导后，地址冲突可能会发生。
Note that addresses in the 169.254/16 prefix SHOULD NOT be configured manually or by a DHCP server. Manual or DHCP configuration may cause a host to use an address in the 169.254/16 prefix without following the special rules regarding duplicate detection and automatic configuration that pertain to addresses in this prefix. While the DHCP specification [RFC2131] indicates that a DHCP client SHOULD probe a newly received address with ARP, this is not mandatory. Similarly, while the DHCP specification recommends that a DHCP server SHOULD probe an address using an ICMP Echo Request before allocating it, this is also not mandatory, and even if the server does this, IPv4 Link-Local addresses are not routable, so a DHCP server not directly connected to a link cannot detect whether a host on that link is already using the desired IPv4 Link-Local address.
请注意，169.254/16前缀中的地址不应手动配置或由DHCP服务器配置。手动或DHCP配置可能会导致主机使用169.254/16前缀中的地址，而不遵循与此前缀中的地址有关的重复检测和自动配置的特殊规则。虽然DHCP规范[RFC2131]指出DHCP客户端应使用ARP探测新接收的地址，但这不是强制性的。类似地，虽然DHCP规范建议DHCP服务器在分配地址之前应使用ICMP回显请求探测地址，但这也不是强制性的，即使服务器这样做，IPv4链路本地地址也不可路由，因此，未直接连接到链路的DHCP服务器无法检测该链路上的主机是否已在使用所需的IPv4链路本地地址。
Administrators wishing to configure their own local addresses (using manual configuration, a DHCP server, or any other mechanism not described in this document) should use one of the existing private address prefixes [RFC1918], not the 169.254/16 prefix.
希望配置自己的本地地址（使用手动配置、DHCP服务器或本文档中未描述的任何其他机制）的管理员应使用现有的专用地址前缀[RFC1918]之一，而不是169.254/16前缀。
Additional considerations apply to hosts that support more than one active interface where one or more of these interfaces support IPv4 Link-Local address configuration. These considerations are discussed in Section 3.
其他注意事项适用于支持多个活动接口的主机，其中一个或多个接口支持IPv4链路本地地址配置。第3节讨论了这些注意事项。
There will be cases when devices with a configured Link-Local address will need to communicate with a device with a routable address configured on the same physical link, and vice versa. The rules in Section 2.6 allow this communication.
在某些情况下，具有配置的链路本地地址的设备将需要与具有在同一物理链路上配置的可路由地址的设备通信，反之亦然。第2.6节中的规则允许这种通信。
This allows, for example, a laptop computer with only a routable address to communicate with web servers world-wide using its globally-routable address while at the same time printing those web pages on a local printer that has only an IPv4 Link-Local address.
例如，这允许仅具有可路由地址的笔记本电脑使用其全局可路由地址与全球web服务器通信，同时在仅具有IPv4链接本地地址的本地打印机上打印这些网页。
Having addresses of multiple different scopes assigned to an interface, with no adequate way to determine in what circumstances each address should be used, leads to complexity for applications and confusion for users. A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both an operable routable address and an IPv4 Link-Local address configured on the same interface. The term "operable address" is used to mean an address which works effectively for communication in the current network context (see below). When an operable routable address is available on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address on that interface. However, during the transition (in either direction) between using routable and IPv4 Link-Local addresses both MAY be in use at once subject to these rules:
将多个不同作用域的地址分配给一个接口，而没有足够的方法来确定每个地址应该在什么情况下使用，这会导致应用程序的复杂性和用户的困惑。链路上有地址的主机可以与该链路上的所有其他设备通信，无论这些设备使用链路本地地址还是可路由地址。出于这些原因，主机不应在同一接口上同时配置可操作路由地址和IPv4链路本地地址。术语“可操作地址”用于指在当前网络环境中有效用于通信的地址（见下文）。当接口上有可用的可操作路由地址时，主机不应在该接口上分配IPv4链路本地地址。但是，在使用可路由和IPv4链路本地地址之间的转换（在任何方向）期间，根据以下规则，两个本地地址可能同时被使用：
1. The assignment of an IPv4 Link-Local address on an interface is based solely on the state of the interface, and is independent of any other protocols such as DHCP. A host MUST NOT alter its behavior and use of other protocols such as DHCP because the host has assigned an IPv4 Link-Local address to an interface.
1. 接口上IPv4链路本地地址的分配仅基于接口的状态，与任何其他协议（如DHCP）无关。主机不得改变其行为和其他协议（如DHCP）的使用，因为主机已将IPv4链路本地地址分配给接口。
2. If a host finds that an interface that was previously configured with an IPv4 Link-Local address now has an operable routable address available, the host MUST use the routable address when initiating new communications, and MUST cease advertising the availability of the IPv4 Link-Local address through whatever mechanisms that address had been made known to others. The host SHOULD continue to use the IPv4 Link-Local address for communications already underway, and MAY continue to accept new communications addressed to the IPv4 Link-Local address. Ways in which an operable routable address might become available on an interface include:
2. 如果主机发现以前配置有IPv4链路本地地址的接口现在有可用的可操作路由地址，则主机在启动新通信时必须使用该可路由地址，并且必须停止通过向其他人公布IPv4链路本地地址的任何机制来宣传该地址的可用性。主机应继续使用IPv4链路本地地址进行已在进行的通信，并可能继续接受寻址到IPv4链路本地地址的新通信。可操作的可路由地址在接口上可用的方式包括：
* Manual configuration * Address assignment through DHCP * Roaming of the host to a network on which a previously assigned address becomes operable
* 手动配置*通过DHCP进行地址分配*将主机漫游到以前分配的地址可操作的网络
3. If a host finds that an interface no longer has an operable routable address available, the host MAY identify a usable IPv4 Link-Local address (as described in section 2) and assign that address to the interface. Ways in which an operable routable address might cease to be available on an interface include:
3. 如果主机发现接口不再具有可用的可操作路由地址，则主机可以识别可用的IPv4链路本地地址（如第2节所述），并将该地址分配给接口。可操作的可路由地址在接口上可能不再可用的方式包括：
* Removal of the address from the interface through manual configuration * Expiration of the lease on the address assigned through DHCP * Roaming of the host to a new network on which the address is no longer operable.
* 通过手动配置从接口中删除地址*通过DHCP分配的地址租约到期*主机漫游到不再可操作地址的新网络。
The determination by the system of whether an address is "operable" is not clear cut and many changes in the system context (e.g., router changes) may affect the operability of an address. In particular roaming of a host from one network to another is likely -- but not certain -- to change the operability of a configured address but detecting such a move is not always trivial.
系统对地址是否“可操作”的确定并不明确，系统上下文中的许多更改（例如，路由器更改）可能会影响地址的可操作性。特别是，主机从一个网络漫游到另一个网络很可能（但不确定）改变配置地址的可操作性，但检测这样的移动并不总是微不足道的。
"Detection of Network Attachment (DNA) in IPv4" [DNAv4] provides further discussion of address assignment and operability determination.
“IPv4中网络连接（DNA）的检测”[DNAv4]提供了地址分配和可操作性确定的进一步讨论。
The following section explains the IPv4 Link-Local address selection algorithm, how IPv4 Link-Local addresses are defended, and how IPv4 packets with IPv4 Link-Local addresses are delivered.
以下部分介绍IPv4链路本地地址选择算法、IPv4链路本地地址的防御方式以及具有IPv4链路本地地址的IPv4数据包的传送方式。
Windows and Mac OS hosts that already implement Link-Local IPv4 address auto-configuration are compatible with the rules presented in this section. However, should any interoperability problem be discovered, this document, not any prior implementation, defines the standard.
已经实现链路本地IPv4地址自动配置的Windows和Mac OS主机与本节中介绍的规则兼容。但是，如果发现任何互操作性问题，则本文档（而不是之前的任何实现）定义了该标准。
When a host wishes to configure an IPv4 Link-Local address, it selects an address using a pseudo-random number generator with a uniform distribution in the range from 169.254.1.0 to 169.254.254.255 inclusive.
当主机希望配置IPv4链路本地地址时，它将使用伪随机数生成器选择一个地址，该地址的均匀分布范围为169.254.1.0到169.254.254.255（含169.254.255）。
The IPv4 prefix 169.254/16 is registered with the IANA for this purpose. The first 256 and last 256 addresses in the 169.254/16 prefix are reserved for future use and MUST NOT be selected by a host using this dynamic configuration mechanism.
为此，向IANA注册了IPv4前缀169.254/16。169.254/16前缀中的前256个和后256个地址保留供将来使用，主机不得使用此动态配置机制选择。
The pseudo-random number generation algorithm MUST be chosen so that different hosts do not generate the same sequence of numbers. If the host has access to persistent information that is different for each host, such as its IEEE 802 MAC address, then the pseudo-random number generator SHOULD be seeded using a value derived from this information. This means that even without using any other persistent storage, a host will usually select the same IPv4 Link-Local address each time it is booted, which can be convenient for debugging and other operational reasons. Seeding the pseudo-random number generator using the real-time clock or any other information which is (or may be) identical in every host is NOT suitable for this purpose, because a group of hosts that are all powered on at the same time might then all generate the same sequence, resulting in a never-ending series of conflicts as the hosts move in lock-step through exactly the same pseudo-random sequence, conflicting on every address they probe.
必须选择伪随机数生成算法，以便不同的主机不会生成相同的数字序列。如果主机可以访问每个主机不同的持久性信息，例如其IEEE 802 MAC地址，则应使用从该信息导出的值对伪随机数生成器进行种子设定。这意味着，即使不使用任何其他持久性存储，主机在每次启动时通常也会选择相同的IPv4链路本地地址，这便于调试和其他操作原因。使用实时时钟或在每个主机中相同（或可能相同）的任何其他信息对伪随机数生成器进行种子设定不适合于此目的，因为一组同时通电的主机可能会生成相同的序列，当主机通过完全相同的伪随机序列锁步移动时，会导致一系列无休止的冲突，在它们探测的每个地址上都会发生冲突。
Hosts that are equipped with persistent storage MAY, for each interface, record the IPv4 address they have selected. On booting, hosts with a previously recorded address SHOULD use that address as their first candidate when probing. This increases the stability of addresses. For example, if a group of hosts are powered off at night, then when they are powered on the next morning they will all resume using the same addresses, instead of picking different addresses and potentially having to resolve conflicts that arise.
配备永久性存储的主机可以为每个接口记录它们选择的IPv4地址。引导时，具有以前记录的地址的主机应在探测时将该地址用作其第一个候选地址。这增加了地址的稳定性。例如，如果一组主机在夜间关机，那么当它们在第二天早上开机时，它们都将使用相同的地址继续工作，而不是选择不同的地址，并可能不得不解决出现的冲突。
After it has selected an IPv4 Link-Local address, a host MUST test to see if the IPv4 Link-Local address is already in use before beginning to use it. When a network interface transitions from an inactive to an active state, the host does not have knowledge of what IPv4 Link-Local addresses may currently be in use on that link, since the point of attachment may have changed or the network interface may have been inactive when a conflicting address was claimed.
选择IPv4链路本地地址后，主机必须先测试IPv4链路本地地址是否已在使用中，然后才能开始使用它。当网络接口从非活动状态转换为活动状态时，主机不知道该链路上当前使用的IPv4链路本地地址，因为在声明冲突地址时，连接点可能已更改，或者网络接口可能已处于非活动状态。
Were the host to immediately begin using an IPv4 Link-Local address which is already in use by another host, this would be disruptive to that other host. Since it is possible that the host has changed its point of attachment, a routable address may be obtainable on the new network, and therefore it cannot be assumed that an IPv4 Link-Local address is to be preferred.
如果主机立即开始使用另一台主机已在使用的IPv4链路本地地址，这将对另一台主机造成中断。由于主机可能已更改其连接点，因此可在新网络上获得可路由地址，因此不能假定首选IPv4链路本地地址。
Before using the IPv4 Link-Local address (e.g., using it as the source address in an IPv4 packet, or as the Sender IPv4 address in an ARP packet) a host MUST perform the probing test described below to achieve better confidence that using the IPv4 Link-Local address will not cause disruption.
在使用IPv4链路本地地址（例如，将其用作IPv4数据包中的源地址，或用作ARP数据包中的发送方IPv4地址）之前，主机必须执行以下所述的探测测试，以更好地确信使用IPv4链路本地地址不会导致中断。
Examples of events that involve an interface becoming active include:
涉及激活接口的事件示例包括：
Reboot/startup Wake from sleep (if network interface was inactive during sleep) Bringing up previously inactive network interface IEEE 802 hardware link-state change (appropriate for the media type and security mechanisms which apply) indicates that an interface has become active. Association with a wireless base station or ad hoc network.
从睡眠中重新启动/启动唤醒（如果网络接口在睡眠期间处于非活动状态）启动以前处于非活动状态的网络接口IEEE 802硬件链路状态更改（适用于应用的媒体类型和安全机制）表示接口已变为活动状态。与无线基站或自组织网络的关联。
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.5.
当然，主机不得定期执行此检查。如第2.5节所述，这将浪费网络带宽，而且由于主机能够被动地发现冲突，因此没有必要这样做。
On a link-layer such as IEEE 802 that supports ARP, conflict detection is done using ARP probes. On link-layer technologies that do not support ARP other techniques may be available for determining whether a particular IPv4 address is currently in use. However, the application of claim-and-defend mechanisms to such networks is outside the scope of this document.
在支持ARP的链路层（如IEEE 802）上，使用ARP探测进行冲突检测。在不支持ARP的链路层技术上，可以使用其他技术来确定特定IPv4地址当前是否正在使用。然而，对此类网络应用索赔和抗辩机制不在本文件范围之内。
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, 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地址”字段必须设置为要探测的地址。以这种方式构造的带有全零“发送方IP地址”的ARP请求称为“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, PROBE_MIN to PROBE_MAX seconds apart. 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 MUST select a new pseudo-random address and repeat the process. 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 the interface the host is attempting to configure, then the host MUST similarly treat this as an address conflict and select a new address as above. This can occur if two (or more) hosts attempt to configure the same IPv4 Link-Local address at the same time.
当准备好开始探测时，主机应等待在0到PROBE_wait秒范围内均匀选择的随机时间间隔，然后发送PROBE_NUM PROBE数据包，每个探测数据包随机间隔，PROBE_MIN到PROBE_MAX秒。如果在此期间，从探测过程开始到最后一个探测数据包发送后的通告等待秒，主机在执行探测的接口上接收到任何ARP数据包（请求*或*回复），其中数据包的“发送方IP地址”是被探测的地址，然后主机必须将此地址视为其他主机正在使用，并且必须选择一个新的伪随机地址并重复此过程。此外，如果在此期间主机接收到任何ARP探测，其中数据包的“目标IP地址”是被探测的地址，而数据包的“发送方硬件地址”不是主机试图配置的接口的硬件地址，然后主机必须类似地将其视为地址冲突，并如上所述选择一个新地址。如果两个（或多个）主机试图同时配置相同的IPv4链路本地地址，则可能会发生这种情况。
A host should maintain a counter of the number of address conflicts it has experienced in the process of trying to acquire an address, and if the number of conflicts exceeds MAX_CONFLICTS then the host MUST limit the rate at which it probes for new addresses to no more than one new address per RATE_LIMIT_INTERVAL. This is to prevent catastrophic ARP storms in pathological failure cases, such as a rogue host that answers all ARP probes, causing legitimate hosts to go into an infinite loop attempting to select a usable address.
主机应维护其在尝试获取地址过程中遇到的地址冲突数计数器，如果冲突数超过最大冲突数，则主机必须将其探测新地址的速率限制为每个速率限制间隔不超过一个新地址。这是为了防止在病理性故障情况下发生灾难性的ARP风暴，例如一个回答所有ARP探测的恶意主机，导致合法主机进入无限循环，试图选择一个可用地址。
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 claimed the desired IPv4 Link-Local address.
如果在传输最后一个ARP探测后的几秒钟内未收到冲突的ARP应答或ARP探测，则主机已成功声明所需的IPv4链路本地地址。
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出版物，为这些技术上的探测等待、探测数量、探测最小值和探测最大值提供指导。
Having probed to determine a unique address to use, the host MUST then announce its claimed 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.
在探测确定要使用的唯一地址后，主机必须通过广播annound_NUM ARP announces来宣布其声明的地址，广播间隔为秒。ARP公告与上述ARP探测相同，只是现在发送方和目标IP地址都设置为主机新选择的IPv4地址。这些ARP公告的目的是确保链路上的其他主机没有从以前可能使用相同地址的其他主机遗留的过时ARP缓存项。
Address conflict detection is not limited to the address selection phase, 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 IPv4 Link-Local address. At any time, if a host receives an ARP packet (request *or* reply) on an interface where the 'sender IP address' is the IP address the host has configured for that interface, but the 'sender hardware address' does not match the hardware address of that interface, then this is a conflicting ARP packet, indicating an address conflict.
当主机发送ARP探测时，地址冲突检测不限于地址选择阶段。地址冲突检测是一个持续的过程，只要主机使用IPv4链路本地地址，该过程就会生效。在任何时候，如果主机在“发送方IP地址”是主机为该接口配置的IP地址的接口上收到ARP数据包（请求*或*回复），但“发送方硬件地址”与该接口的硬件地址不匹配，则这是一个冲突的ARP数据包，表示地址冲突。
A host MUST respond to a conflicting ARP packet as described in either (a) or (b) below:
主机必须响应以下（A）或（b）中所述的冲突ARP数据包：
(a) Upon receiving a conflicting ARP packet, a host MAY elect to immediately configure a new IPv4 Link-Local address as described above, or
(a) 在接收到冲突的ARP数据包时，主机可以选择如上所述立即配置新的IPv4链路本地地址，或者
(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. 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
(b) 如果主机当前有活动的TCP连接或出于其他原因希望保留相同的IPv4地址，并且在最后的保护间隔秒内没有看到任何其他冲突的ARP数据包，那么它可以选择通过记录接收冲突的ARP数据包的时间来尝试保护其地址，然后广播一个ARP公告，给出自己的IP和硬件地址作为ARP的发送方地址。完成此操作后，主机可以继续正常使用该地址，而无需任何进一步的特殊操作。然而，如果这不是第一次
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 configure a new IPv4 Link-Local address 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.
主机已看到冲突的ARP数据包，并且前一个冲突的ARP数据包记录的时间是最近的，在保护间隔秒内，则主机必须立即停止使用此地址，并如上所述配置新的IPv4链路本地地址。这是必要的，以确保两台主机不会陷入一个无休止的循环，因为两台主机都试图保护相同的地址。
A host MUST respond to conflicting ARP packets as described in either (a) or (b) above. A host MUST NOT ignore conflicting ARP packets.
主机必须响应上述（A）或（b）中所述的冲突ARP数据包。主机不能忽略冲突的ARP数据包。
Forced address reconfiguration may be disruptive, causing TCP connections to be broken. However, it is expected that such disruptions will be rare, and if inadvertent address duplication happens, then disruption of communication is inevitable, no matter how the addresses were assigned. 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节所述，这缓解了地址重新配置带来的一些安全威胁。
Immediately configuring 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.
一旦检测到冲突，立即配置新地址是尽快恢复有用通信的最佳方式。上述广播单个ARP公告以保护地址的机制通过帮助提高两个冲突主机中的一个能够保留其地址的机会，在一定程度上缓解了问题。
All ARP packets (*replies* as well as requests) that contain a Link-Local 'sender IP address' MUST be sent using link-layer broadcast instead of link-layer unicast. This aids timely detection of duplicate addresses. An example illustrating how this helps is given in Section 4.
包含链路本地“发送方IP地址”的所有ARP数据包（*回复*以及请求）必须使用链路层广播而不是链路层单播发送。这有助于及时检测重复地址。第4节给出了一个示例，说明了这是如何起作用的。
A host implementing this specification has additional rules to conform to, whether or not it has an interface configured with an IPv4 Link-Local address.
实现此规范的主机需要遵守其他规则，无论其是否具有配置了IPv4链路本地地址的接口。
Since each interface on a host may have an IPv4 Link-Local address in addition to zero or more other addresses configured by other means (e.g., manually or via a DHCP server), a host may have to make a
由于主机上的每个接口除了通过其他方式（例如，手动或通过DHCP服务器）配置的零个或多个其他地址外，还可能具有IPv4链路本地地址，因此主机可能必须
choice about what source address to use when it sends a packet or initiates a TCP connection.
选择发送数据包或启动TCP连接时使用的源地址。
Where both an IPv4 Link-Local and a routable address are available on the same interface, the routable address should be preferred as the source address for new communications, but packets sent from or to the IPv4 Link-Local address are still delivered as expected. The IPv4 Link-Local address may continue to be used as a source address in communications where switching to a preferred address would cause communications failure because of the requirements of an upper-layer protocol (e.g., an existing TCP connection). For more details, see Section 1.7.
如果IPv4链路本地地址和可路由地址在同一接口上都可用，则应首选可路由地址作为新通信的源地址，但从IPv4链路本地地址发送或发送到IPv4链路本地地址的数据包仍按预期传送。IPv4链路本地地址可继续用作通信中的源地址，其中由于上层协议（例如，现有TCP连接）的要求，切换到首选地址将导致通信失败。有关更多详细信息，请参见第1.7节。
A multi-homed host needs to select an outgoing interface whether or not the destination is an IPv4 Link-Local address. Details of that process are beyond the scope of this specification. After selecting an interface, the multi-homed host should send packets involving IPv4 Link-Local addresses as specified in this document, as if the selected interface were the host's only interface. See Section 3 for further discussion of multi-homed hosts.
无论目标是否为IPv4链路本地地址，多宿主主机都需要选择传出接口。该过程的细节超出了本规范的范围。选择接口后，多宿主主机应发送包含本文档中指定的IPv4链路本地地址的数据包，就像所选接口是主机的唯一接口一样。有关多宿主主机的进一步讨论，请参见第3节。
Whichever interface is used, if the destination address is in the 169.254/16 prefix (excluding the address 169.254.255.255, which is the broadcast address for the Link-Local prefix), then the sender MUST ARP for the destination address and then send its packet directly to the destination on the same physical link. This MUST be done whether the interface is configured with a Link-Local or a routable IPv4 address.
无论使用哪种接口，如果目标地址在169.254/16前缀中（不包括地址169.254.255.255，这是链路本地前缀的广播地址），则发送方必须对目标地址进行ARP，然后将其数据包直接发送到同一物理链路上的目标。无论接口配置为本地链路地址还是可路由IPv4地址，都必须执行此操作。
In many network stacks, achieving this functionality may be as simple as adding a routing table entry indicating that 169.254/16 is directly reachable on the local link. This approach will not work for routers or multi-homed hosts. Refer to section 3 for more discussion of multi-homed hosts.
在许多网络堆栈中，实现此功能可能非常简单，只需添加一个路由表条目，指示169.254/16可在本地链路上直接访问。这种方法不适用于路由器或多主机。有关多宿主主机的更多讨论，请参阅第3节。
The host MUST NOT send a packet with an IPv4 Link-Local destination address to any router for forwarding.
主机不得将具有IPv4链路本地目标地址的数据包发送到任何路由器进行转发。
If the destination address is a unicast address outside the 169.254/16 prefix, then the host SHOULD use an appropriate routable IPv4 source address, if it can. If for any reason the host chooses to send the packet with an IPv4 Link-Local source address (e.g., no routable address is available on the selected interface), then it MUST ARP for the destination address and then send its packet, with
如果目标地址是169.254/16前缀之外的单播地址，则主机应使用适当的可路由IPv4源地址（如果可以）。如果出于任何原因，主机选择使用IPv4链路本地源地址（例如，所选接口上没有可用的可路由地址）发送数据包，则必须对目标地址进行ARP，然后使用
an IPv4 Link-Local source address and a routable destination IPv4 address, directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding.
IPv4链路本地源地址和可路由目标IPv4地址，直接连接到同一物理链路上的目标。主机不得将数据包发送到任何路由器进行转发。
In the case of a device with a single interface and only an Link-Local IPv4 address, this requirement can be paraphrased as "ARP for everything".
对于具有单个接口且只有链路本地IPv4地址的设备，此要求可以解释为“ARP for everything”。
In many network stacks, achieving this "ARP for everything" behavior may be as simple as having no primary IP router configured, having the primary IP router address configured to 0.0.0.0, or having the primary IP router address set to be the same as the host's own Link-Local IPv4 address. For suggested behavior in multi-homed hosts, see Section 3.
在许多网络堆栈中，实现这种“ARP for everything”行为可能很简单，比如没有配置主IP路由器，将主IP路由器地址配置为0.0.0.0，或者将主IP路由器地址设置为与主机自己的链路本地IPv4地址相同。有关多宿主主机中的建议行为，请参见第3节。
A sensible default for applications which are sending from an IPv4 Link-Local address is to explicitly set the IPv4 TTL to 1. This is not appropriate in all cases as some applications may require that the IPv4 TTL be set to other values.
对于从IPv4链路本地地址发送的应用程序，一个合理的默认设置是显式地将IPv4 TTL设置为1。这并不适用于所有情况，因为某些应用程序可能要求将IPv4 TTL设置为其他值。
An IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it, regardless of the TTL in the IPv4 header. Similarly, a router or other host MUST NOT indiscriminately answer all ARP Requests for addresses in the 169.254/16 prefix. A router may of course answer ARP Requests for one or more IPv4 Link-Local address(es) that it has legitimately claimed for its own use according to the claim-and-defend protocol described in this document.
源地址和/或目标地址位于169.254/16前缀中的IPv4数据包不得发送到任何路由器进行转发，并且接收此类数据包的任何网络设备不得转发该数据包，无论IPv4报头中的TTL如何。同样，路由器或其他主机不得不加区别地回答169.254/16前缀中地址的所有ARP请求。路由器当然可以根据本文档中描述的声明和保护协议，对一个或多个IPv4链路本地地址的ARP请求进行应答，该地址是路由器合法声明供自己使用的。
This restriction also applies to multicast packets. IPv4 packets with a Link-Local source address MUST NOT be forwarded outside the local link even if they have a multicast destination address.
此限制也适用于多播数据包。具有链路本地源地址的IPv4数据包不得在本地链路之外转发，即使它们具有多播目标地址。
The non-forwarding rule means that hosts may assume that all 169.254/16 destination addresses are "on-link" and directly reachable. The 169.254/16 address prefix MUST NOT be subnetted. This specification utilizes ARP-based address conflict detection, which functions by broadcasting on the local subnet. Since such broadcasts are not forwarded, were subnetting to be allowed then address conflicts could remain undetected.
非转发规则意味着主机可以假设所有169.254/16目标地址都是“在链路上”且可直接访问的。169.254/16地址前缀不得为子网。该规范利用基于ARP的地址冲突检测，通过在本地子网上广播来实现。由于此类广播未转发，如果允许子网，则地址冲突可能仍无法检测到。
This does not mean that Link-Local devices are forbidden from any communication outside the local link. IP hosts that implement both Link-Local and conventional routable IPv4 addresses may still use their routable addresses without restriction as they do today.
这并不意味着链路本地设备被禁止在本地链路之外进行任何通信。同时实现链路本地和传统可路由IPv4地址的IP主机可能仍然像今天一样不受限制地使用其可路由地址。
Similar considerations apply at layers above IP.
类似的考虑也适用于IP以上的层。
For example, designers of Web pages (including automatically generated web pages) SHOULD NOT contain links with embedded IPv4 Link-Local addresses if those pages are viewable from hosts outside the local link where the addresses are valid.
例如，如果可以从地址有效的本地链接之外的主机查看网页（包括自动生成的网页），则网页的设计者不应包含具有嵌入IPv4链接本地地址的链接。
As IPv4 Link-Local addresses may change at any time and have limited scope, IPv4 Link-Local addresses MUST NOT be stored in the DNS.
由于IPv4链路本地地址可能随时更改，并且作用域有限，因此IPv4链路本地地址不得存储在DNS中。
Another reason to restrict leakage of IPv4 Link-Local addresses outside the local link is privacy concerns. If IPv4 Link-Local addresses are derived from a hash of the MAC address, some argue that they could be indirectly associated with an individual, and thereby used to track that individual's activities. Within the local link the hardware addresses in the packets are all directly observable, so as long as IPv4 Link-Local addresses don't leave the local link they provide no more information to an intruder than could be gained by direct observation of hardware addresses.
限制本地链路外部IPv4链路本地地址泄漏的另一个原因是隐私问题。如果IPv4链路本地地址是从MAC地址的散列中派生出来的，一些人认为它们可能间接地与某个人关联，从而用于跟踪该个人的活动。在本地链路中，数据包中的硬件地址都可以直接观察到，因此只要IPv4链路本地地址不离开本地链路，它们就不会向入侵者提供比直接观察硬件地址所能获得的更多的信息。
2.11. Interaction between DHCPv4 client and IPv4 Link-Local State Machines
2.11. DHCPv4客户端和IPv4链路本地状态机之间的交互
As documented in Appendix A, early implementations of IPv4 Link-Local have modified the DHCP state machine. Field experience shows that these modifications reduce the reliability of the DHCP service.
如附录A所述，IPv4本地链路的早期实现修改了DHCP状态机。现场经验表明，这些修改降低了DHCP服务的可靠性。
A device that implements both IPv4 Link-Local and a DHCPv4 client should not alter the behavior of the DHCPv4 client to accommodate IPv4 Link-Local configuration. In particular configuration of an IPv4 Link-Local address, whether or not a DHCP server is currently responding, is not sufficient reason to unconfigure a valid DHCP lease, to stop the DHCP client from attempting to acquire a new IP address, to change DHCP timeouts or to change the behavior of the DHCP state machine in any other way.
同时实现IPv4链路本地和DHCPv4客户端的设备不应改变DHCPv4客户端的行为以适应IPv4链路本地配置。尤其是IPv4链路本地地址的配置，无论DHCP服务器当前是否响应，都不足以取消配置有效的DHCP租约、阻止DHCP客户端尝试获取新IP地址、更改DHCP超时或以任何其他方式更改DHCP状态机的行为。
Further discussion of this issue is provided in "Detection of Network Attachment (DNA) in IPv4" [DNAv4].
有关此问题的进一步讨论，请参见“IPv4中网络连接（DNA）的检测”[DNAv4]。
The considerations outlined here also apply whenever a host has multiple IP addresses, whether or not it has multiple physical interfaces. Other examples of multiple interfaces include different logical endpoints (tunnels, virtual private networks etc.) and multiple logical networks on the same physical medium. This is often referred to as "multi-homing".
无论主机是否具有多个物理接口，只要主机具有多个IP地址，此处概述的注意事项也适用。多接口的其他示例包括不同的逻辑端点（隧道、虚拟专用网络等）和同一物理介质上的多个逻辑网络。这通常被称为“多归宿”。
Hosts which have more than one active interface and elect to implement dynamic configuration of IPv4 Link-Local addresses on one or more of those interfaces will face various problems. This section lists these problems but does no more than indicate how one might solve them. At the time of this writing, there is no silver bullet which solves these problems in all cases, in a general way. Implementors must think through these issues before implementing the protocol specified in this document on a system which may have more than one active interface as part of a TCP/IP stack capable of multi-homing.
具有多个活动接口并选择在其中一个或多个接口上实现IPv4链路本地地址动态配置的主机将面临各种问题。本节列出了这些问题，但只说明了如何解决这些问题。在撰写本文时，还没有一种灵丹妙药能够从总体上解决所有情况下的这些问题。在系统上实施本文档中指定的协议之前，实施者必须仔细考虑这些问题，该系统可能具有多个活动接口，作为能够多宿主的TCP/IP堆栈的一部分。
A host may be attached to more than one network at the same time. It would be nice if there was a single address space used in every network, but this is not the case. Addresses used in one network, be it a network behind a NAT or a link on which IPv4 Link-Local addresses are used, cannot be used in another network and have the same effect.
一台主机可以同时连接到多个网络。如果每个网络中都使用一个地址空间就好了，但事实并非如此。在一个网络中使用的地址，无论是NAT后面的网络还是使用IPv4链路本地地址的链路，都不能在另一个网络中使用，并且具有相同的效果。
It would also be nice if addresses were not exposed to applications, but they are. Most software using TCP/IP which await messages receives from any interface at a particular port number, for a particular transport protocol. Applications are generally only aware (and care) that they have received a message. The application knows the address of the sender to which the application will reply.
如果地址不向应用程序公开，那也很好，但它们是公开的。对于特定的传输协议，大多数使用TCP/IP的软件等待从特定端口号的任何接口接收消息。应用程序通常只知道（并注意）它们已收到消息。应用程序知道应用程序将答复的发件人的地址。
The first scoped address problem is source address selection. A multi-homed host has more than one address. Which address should be used as the source address when sending to a particular destination? This question is usually answered by referring to a routing table, which expresses on which interface (with which address) to send, and how to send (should one forward to a router, or send directly). The choice is made complicated by scoped addresses because the address range in which the destination lies may be ambiguous. The table may not be able to yield a good answer. This problem is bound up with next-hop selection, which is discussed in Section 3.2.
第一个作用域地址问题是源地址选择。多宿主主机有多个地址。发送到特定目的地时，应使用哪个地址作为源地址？这个问题通常通过参考路由表来回答，路由表表示在哪个接口（使用哪个地址）上发送，以及如何发送（应该转发到路由器，还是直接发送）。作用域地址使选择变得复杂，因为目标所在的地址范围可能不明确。这个表格可能无法给出一个好的答案。这个问题与下一跳选择有关，将在第3.2节中讨论。
The second scoped address problem arises from scoped parameters leaking outside their scope. This is discussed in Section 7.
第二个作用域地址问题源于作用域参数泄漏到其作用域之外。第7节对此进行了讨论。
It is possible to overcome these problems. One way is to expose scope information to applications such that they are always aware of what scope a peer is in. This way, the correct interface could be selected, and a safe procedure could be followed with respect to forwarding addresses and other scoped parameters. There are other possible approaches. None of these methods have been standardized for IPv4 nor are they specified in this document. A good API design could mitigate the problems, either by exposing address scopes to 'scoped-address aware' applications or by cleverly encapsulating the scoping information and logic so that applications do the right thing without being aware of address scoping.
克服这些问题是可能的。一种方法是向应用程序公开作用域信息，以便应用程序始终知道对等方所处的作用域。通过这种方式，可以选择正确的接口，并且可以遵循有关转发地址和其他作用域参数的安全过程。还有其他可能的方法。这些方法均未针对IPv4进行标准化，也未在本文档中指定。一个好的API设计可以通过向“作用域地址感知”的应用程序公开地址作用域，或者通过巧妙地封装作用域信息和逻辑，使应用程序在不知道地址作用域的情况下做正确的事情来缓解问题。
An implementer could undertake to solve these problems, but cannot simply ignore them. With sufficient experience, it is hoped that specifications will emerge explaining how to overcome scoped address multi-homing problems.
实施者可以承诺解决这些问题，但不能简单地忽略它们。有了足够的经验，希望规范能够出现，解释如何克服范围限制，解决多宿主问题。
This is a core problem with respect to IPv4 Link-Local destination addresses being reachable on more than one interface. What should a host do when it needs to send to Link-Local destination L and L can be resolved using ARP on more than one link?
这是IPv4链路本地目标地址在多个接口上可访问的核心问题。当主机需要发送到链路本地目的地L，并且L可以在多个链路上使用ARP解决时，主机应该怎么做？
Even if a Link-Local address can be resolved on only one link at a given moment, there is no guarantee that it will remain unambiguous in the future. Additional hosts on other interfaces may claim the address L as well.
即使在给定时刻只能在一条链路上解析一个链路本地地址，也不能保证它在将来仍然是明确的。其他接口上的其他主机也可以声明地址L。
One possibility is to support this only in the case where the application specifically expresses which interface to send from.
一种可能性是仅在应用程序明确表示从哪个接口发送的情况下支持此功能。
There is no standard or obvious solution to this problem. Existing application software written for the IPv4 protocol suite is largely incapable of dealing with address ambiguity. This does not preclude an implementer from finding a solution, writing applications which are able to use it, and providing a host which can support dynamic configuration of IPv4 Link-Local addresses on more than one interface. This solution will almost surely not be generally applicable to existing software and transparent to higher layers, however.
这个问题没有标准或明显的解决方案。为IPv4协议套件编写的现有应用程序软件在很大程度上无法处理地址模糊问题。这并不妨碍实现者找到解决方案，编写能够使用它的应用程序，并提供一台能够支持在多个接口上动态配置IPv4链路本地地址的主机。然而，这种解决方案几乎肯定不会普遍适用于现有软件，也不会对更高层透明。
Given that the IP stack must have the outbound interface associated with a packet that needs to be sent to a Link-Local destination address, interface selection must occur. The outbound interface
鉴于IP堆栈必须具有与需要发送到链路本地目标地址的数据包相关联的出站接口，因此必须进行接口选择。出站接口
cannot be derived from the packet's header parameters such as source or destination address (e.g., by using the forwarding table lookup). Therefore, outbound interface association must be done explicitly through other means. The specification does not stipulate those means.
无法从数据包的头参数（如源地址或目标地址）派生（例如，通过使用转发表查找）。因此，出站接口关联必须通过其他方式显式完成。规范没有规定这些方法。
Attention is paid in this specification to transition from the use of IPv4 Link-Local addresses to routable addresses (see Section 1.5). The intention is to allow a host with a single interface to first support Link-Local configuration then gracefully transition to the use of a routable address. Since the host transitioning to the use of a routable address may temporarily have more than one address active, the scoped address issues described in Section 3.1 will apply. When a host acquires a routable address, it does not need to retain its Link-Local address for the purpose of communicating with other devices on the link that are themselves using only Link-Local addresses: any host conforming to this specification knows that regardless of source address an IPv4 Link-Local destination must be reached by forwarding directly to the destination, not via a router; it is not necessary for that host to have a Link-Local source address in order to send to a Link-Local destination address.
本规范注意从IPv4链路本地地址的使用过渡到可路由地址（见第1.5节）。其目的是允许具有单个接口的主机首先支持链路本地配置，然后优雅地过渡到使用可路由地址。由于过渡到使用可路由地址的主机可能暂时有多个地址处于活动状态，因此第3.1节中描述的作用域地址问题将适用。当主机获取可路由地址时，它不需要保留其链路本地地址来与链路上本身仅使用链路本地地址的其他设备通信：符合本规范的任何主机都知道，无论源地址如何，都必须通过直接转发到目的地来到达IPv4链路本地目的地，不是通过路由器；为了发送到链路本地目标地址，该主机不必具有链路本地源地址。
A host with an IPv4 Link-Local address may send to a destination which does not have an IPv4 Link-Local address. If the host is not multi-homed, the procedure is simple and unambiguous: Using ARP and forwarding directly to on-link destinations is the default route. If the host is multi-homed, however, the routing policy is more complex, especially if one of the interfaces is configured with a routable address and the default route is (sensibly) directed at a router accessible through that interface. The following example illustrates this problem and provides a common solution to it.
具有IPv4链路本地地址的主机可以发送到没有IPv4链路本地地址的目标。如果主机不是多宿主机，则过程简单明了：使用ARP并直接转发到链路上的目的地是默认路由。但是，如果主机是多宿主的，则路由策略更为复杂，特别是如果其中一个接口配置了可路由地址，并且默认路由（合理地）指向可通过该接口访问的路由器。下面的示例说明了此问题，并提供了一个常见的解决方案。
i1 +---------+ i2 i3 +-------+
ROUTER-------= HOST1 =---------= HOST2 |
link1 +---------+ link2 +-------+
i1 +---------+ i2 i3 +-------+
ROUTER-------= HOST1 =---------= HOST2 |
link1 +---------+ link2 +-------+
In the figure above, HOST1 is connected to link1 and link2. Interface i1 is configured with a routable address, while i2 is an IPv4 Link-Local address. HOST1 has its default route set to ROUTER's address, through i1. HOST1 will route to destinations in 169.254/16 to i2, sending directly to the destination.
在上图中，主机1连接到link1和link2。接口i1配置为可路由地址，而i2配置为IPv4链路本地地址。HOST1通过i1将其默认路由设置为路由器的地址。HOST1将路由到169.254/16中的目的地到i2，直接发送到目的地。
HOST2 has a configured (non-Link-Local) IPv4 address assigned to i3.
HOST2已将配置的（非链路本地）IPv4地址分配给i3。
Using a name resolution or service discovery protocol HOST1 can discover HOST2's address. Since HOST2's address is not in 169.254/16, HOST1's routing policy will send datagrams to HOST2 via i1, to the ROUTER. Unless there is a route from ROUTER to HOST2, the datagrams sent from HOST1 to HOST2 will not reach it.
使用名称解析或服务发现协议，HOST1可以发现HOST2的地址。由于HOST2的地址不在169.254/16中，因此HOST1的路由策略将通过i1向HOST2发送数据报到路由器。除非有从路由器到主机2的路由，否则从主机1发送到主机2的数据报不会到达它。
One solution to this problem is for a host to attempt to reach any host locally (using ARP) for which it receives an unreachable ICMP error message (ICMP message codes 0, 1, 6 or 7 [RFC792]). The host tries all its attached links in a round robin fashion. This has been implemented successfully for some IPv6 hosts, to circumvent exactly this problem. In terms of this example, HOST1 upon failing to reach HOST2 via the ROUTER, will attempt to forward to HOST2 via i2 and succeed.
此问题的一种解决方案是，主机尝试在本地（使用ARP）访问其接收到无法访问的ICMP错误消息（ICMP消息代码0、1、6或7[RFC792]）的任何主机。主机以循环方式尝试其所有连接的链接。这已经在一些IPv6主机上成功实现，以完全避免此问题。在本例中，HOST1在无法通过路由器到达HOST2时，将尝试通过i2转发到HOST2并成功。
It may also be possible to overcome this problem using techniques described in section 3.2, or other means not discussed here. This specification does not provide a standard solution, nor does it preclude implementers from supporting multi-homed configurations, provided that they address the concerns in this section for the applications which will be supported on the host.
也可以使用第3.2节中描述的技术或此处未讨论的其他方法来克服此问题。本规范不提供标准解决方案，也不排除实施者支持多宿主配置，前提是他们解决了本节中有关主机上支持的应用程序的问题。
Care must be taken if a multi-homed host can support more than one interface on the same link, all of which support IPv4 Link-Local autoconfiguration. If these interfaces attempt to allocate the same address, they will defend the host against itself -- causing the claiming algorithm to fail. The simplest solution to this problem is to run the algorithm independently on each interface configured with IPv4 Link-Local addresses.
如果多宿主主机可以在同一链路上支持多个接口（所有接口都支持IPv4链路本地自动配置），则必须小心。如果这些接口试图分配相同的地址，它们将保护主机不受自身攻击——导致声明算法失败。这个问题最简单的解决方案是在配置了IPv4链路本地地址的每个接口上独立运行该算法。
In particular, ARP packets which appear to claim an address which is assigned to a specific interface, indicate conflict only if they are received on that interface and their hardware address is of some other interface.
特别是，ARP数据包似乎声称分配给特定接口的地址，仅当它们在该接口上接收并且它们的硬件地址是某个其他接口时才表示冲突。
If a host has two interfaces on the same link, then claiming and defending on those interfaces must ensure that they end up with different addresses just as if they were on different hosts. Note that some of the ways a host may find itself with two interfaces on the same link may be unexpected and non-obvious, such as when a host has Ethernet and 802.11 wireless, but those two links are (possibly even without the knowledge of the host's user) bridged together.
如果主机在同一链路上有两个接口，那么在这些接口上进行声明和防御必须确保它们最终使用不同的地址，就像它们在不同的主机上一样。请注意，主机在同一链路上使用两个接口的某些方式可能是意外和不明显的，例如当主机具有以太网和802.11无线时，但这两个链路（甚至可能在主机用户不知道的情况下）桥接在一起。
Hosts on disjoint network links may configure the same IPv4 Link-Local address. If these separate network links are later joined or bridged together, then there may be two hosts which are now on the same link, trying to use the same address. When either host attempts to communicate with any other host on the network, it will at some point broadcast an ARP packet which will enable the hosts in question to detect that there is an address conflict.
不相交网络链路上的主机可以配置相同的IPv4链路本地地址。如果这些单独的网络链路后来连接或桥接在一起，则可能有两台主机现在位于同一链路上，试图使用相同的地址。当任一主机尝试与网络上的任何其他主机通信时，它将在某个点广播ARP数据包，这将使相关主机能够检测到存在地址冲突。
When these address conflicts are detected, the subsequent forced reconfiguration may be disruptive, causing TCP connections to be broken. However, it is expected that such disruptions will be rare. It should be relatively uncommon for networks to be joined while hosts on those networks are active. Also, 65024 addresses are available for IPv4 Link-Local use, so even when two small networks are joined, the chance of conflict for any given host is fairly small.
当检测到这些地址冲突时，随后的强制重新配置可能会中断，导致TCP连接中断。然而，预计这种破坏将是罕见的。当网络上的主机处于活动状态时，加入网络应该比较少见。此外，65024个地址可供IPv4链路本地使用，因此即使两个小型网络连接在一起，任何给定主机发生冲突的可能性也相当小。
When joining two large networks (defined as networks with a substantial number of hosts per segment) there is a greater chance of conflict. In such networks, it is likely that the joining of previously separated segments will result in one or more hosts needing to change their IPv4 Link-Local address, with subsequent loss of TCP connections. In cases where separation and re-joining is frequent, as in remotely bridged networks, this could prove disruptive. However, unless the number of hosts on the joined segments is very large, the traffic resulting from the join and subsequent address conflict resolution will be small.
当连接两个大型网络（定义为每个网段具有大量主机的网络）时，冲突的可能性更大。在这种网络中，以前分离的段的连接可能会导致一个或多个主机需要更改其IPv4链路本地地址，从而导致TCP连接的丢失。在分离和重新连接频繁的情况下，如在远程桥接网络中，这可能会造成中断。但是，除非连接段上的主机数量非常大，否则连接和后续地址冲突解决所产生的通信量将很小。
Sending ARP replies that have IPv4 Link-Local sender addresses via broadcast instead of unicast ensures that these conflicts can be detected as soon as they become potential problems, but no sooner. For example, if two disjoint network links are joined, where hosts A and B have both configured the same Link-Local address, X, they can remain in this state until A, B or some other host attempts to initiate communication. If some other host C now sends an ARP request for address X, and hosts A and B were to both reply with conventional unicast ARP replies, then host C might be confused, but A and B still wouldn't know there is a problem because neither would have seen the other's packet. Sending these replies via broadcast allows A and B to see each other's conflicting ARP packets and respond accordingly.
通过广播（而不是单播）发送具有IPv4链路本地发送方地址的ARP回复可确保在这些冲突成为潜在问题时立即检测到它们，但不会很快。例如，如果连接了两个不相交的网络链路，其中主机A和B都配置了相同的链路本地地址X，则它们可以保持此状态，直到A、B或某些其他主机尝试启动通信。如果其他主机C现在发送地址X的ARP请求，并且主机A和B都使用传统的单播ARP应答进行应答，那么主机C可能会感到困惑，但A和B仍然不知道存在问题，因为它们都不会看到另一个的数据包。通过广播发送这些回复可以让A和B看到彼此冲突的ARP数据包并做出相应的响应。
Note that sending periodic gratuitous ARPs in an attempt to detect these conflicts sooner is not necessary, wastes network bandwidth, and may actually be detrimental. For example, if the network links were joined only briefly, and were separated again before any new
请注意，为了更快地检测这些冲突而发送周期性的免费ARP是不必要的，它浪费了网络带宽，实际上可能是有害的。例如，如果网络链接只是短暂地连接，并且在任何新连接之前再次分离
communication involving A or B were initiated, then the temporary conflict would have been benign and no forced reconfiguration would have been required. Triggering an unnecessary forced reconfiguration in this case would not serve any useful purpose. Hosts SHOULD NOT send periodic gratuitous ARPs.
如果启动了涉及A或B的通信，那么临时冲突将是良性的，不需要强制重新配置。在这种情况下，触发不必要的强制重新配置不会起到任何有用的作用。主机不应定期发送免费的ARP。
The use of IPv4 Link-Local Addresses may open a network host to new attacks. In particular, a host that previously did not have an IP address, and no IP stack running, was not susceptible to IP-based attacks. By configuring a working address, the host may now be vulnerable to IP-based attacks.
使用IPv4链路本地地址可能会使网络主机遭受新的攻击。特别是，以前没有IP地址且没有运行IP堆栈的主机不易受到基于IP的攻击。通过配置工作地址，主机现在可能容易受到基于IP的攻击。
The ARP protocol [RFC826] is insecure. 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.
ARP协议[RFC826]不安全。恶意主机可能在网络上发送欺诈性ARP数据包，干扰其他主机的正确操作。例如，主机很容易回答所有ARP请求，并给出自己的硬件地址，从而声称拥有网络上的每个地址。
NOTE: There are certain kinds of local links, such as wireless LANs, that provide no physical security. Because of the existence of these links it would be very unwise for an implementer to assume that when a device is communicating only on the local link it can dispense with normal security precautions. Failure to implement appropriate security measures could expose users to considerable risks.
注意：某些类型的本地链路（如无线局域网）不提供物理安全性。由于这些链路的存在，实现者认为当设备仅在本地链路上通信时，可以免除正常的安全预防措施是非常不明智的。未能实施适当的安全措施可能会使用户面临相当大的风险。
A host implementing IPv4 Link-Local configuration has an additional vulnerability to selective reconfiguration and disruption. It is possible for an on-link attacker to issue ARP packets which would cause a host to break all its connections by switching to a new address. The attacker could force the host implementing IPv4 Link-Local configuration to select certain addresses, or prevent it from ever completing address selection. This is a distinct threat from that posed by spoofed ARPs, described in the preceding paragraph.
实现IPv4链路本地配置的主机还存在另一个易受选择性重新配置和中断影响的漏洞。链路上的攻击者可能会发出ARP数据包，从而导致主机通过切换到新地址中断其所有连接。攻击者可以强制实施IPv4链路本地配置的主机选择某些地址，或阻止其完成地址选择。这是一种不同于前一段所述的欺骗ARP所造成的威胁。
Implementations and users should also note that a node that gives up an address and reconfigures, as required by section 2.5, allows the possibility that another node can easily and successfully hijack existing TCP connections.
实现和用户还应注意，根据第2.5节的要求，放弃地址并重新配置的节点允许另一个节点轻松成功地劫持现有TCP连接。
Implementers are advised that the Internet Protocol architecture expects every networked device or host must implement security which is adequate to protect the resources to which the device or host has access, including the network itself, against known or credible threats. Even though use of IPv4 Link-Local addresses may reduce the
建议实施者，互联网协议体系结构要求每个联网设备或主机必须实施足以保护设备或主机可访问的资源（包括网络本身）免受已知或可信威胁的安全性。即使使用IPv4链路本地地址可能会降低
number of threats to which a device is exposed, implementers of devices supporting the Internet Protocol must not assume that a customer's local network is free from security risks.
设备面临的威胁数量，支持Internet协议的设备的实施者不得假设客户的本地网络没有安全风险。
While there may be particular kinds of devices, or particular environments, for which the security provided by the network is adequate to protect the resources that are accessible by the device, it would be misleading to make a general statement to the effect that the requirement to provide security is reduced for devices using IPv4 Link-Local addresses as a sole means of access.
虽然可能存在特定类型的设备或特定环境，但网络提供的安全性足以保护设备可访问的资源，如果笼统地说，对于使用IPv4链路本地地址作为唯一访问手段的设备，降低了提供安全性的要求，那将是一种误导。
In all cases, whether or not IPv4 Link-Local addresses are used, it is necessary for implementers of devices supporting the Internet Protocol to analyze the known and credible threats to which a specific host or device might be subjected, and to the extent that it is feasible, to provide security mechanisms which ameliorate or reduce the risks associated with such threats.
在所有情况下，无论是否使用IPv4链路本地地址，支持互联网协议的设备的实施者都有必要分析特定主机或设备可能受到的已知和可信威胁，并且在可行的范围内，提供安全机制，以改善或减少与此类威胁相关的风险。
Use of IPv4 Link-Local autoconfigured addresses presents additional challenges to writers of applications and may result in existing application software failing.
IPv4链路本地自动配置地址的使用给应用程序编写者带来了额外的挑战，并可能导致现有应用程序软件失败。
IPv4 Link-Local addresses used by an application may change over time. Some application software encountering an address change will fail. For example, existing client TCP connections will be aborted, servers whose addresses change will have to be rediscovered, blocked reads and writes will exit with an error condition, and so on.
应用程序使用的IPv4链路本地地址可能会随时间而变化。某些应用软件遇到地址更改时将失败。例如，现有的客户端TCP连接将被中止，地址更改的服务器将被重新发现，阻塞的读写操作将以错误条件退出，等等。
Vendors producing application software which will be used on IP implementations supporting IPv4 Link-Local address configuration SHOULD detect and cope with address change events. Vendors producing IPv4 implementations supporting IPv4 Link-Local address configuration SHOULD expose address change events to applications.
生产将用于支持IPv4链路本地地址配置的IP实现的应用软件的供应商应检测并处理地址更改事件。生产支持IPv4链路本地地址配置的IPv4实现的供应商应向应用程序公开地址更改事件。
IPv4 Link-Local addresses MUST NOT be forwarded via an application protocol (for example in a URL), to a destination that is not on the same link. This is discussed further in Sections 2.9 and 3.
IPv4链路本地地址不得通过应用程序协议（例如URL）转发到不在同一链路上的目标。这将在第2.9节和第3节中进一步讨论。
Existing distributed application software that forwards address information may fail. For example, FTP [RFC959] (when not using passive mode) transmits the IP address of the client. Suppose a client starts up and obtains its IPv4 configuration at a time when it
转发地址信息的现有分布式应用程序软件可能会失败。例如，FTP[RFC959]（不使用被动模式时）传输客户端的IP地址。假设一个客户机启动并在启动时获得其IPv4配置
has only a Link-Local address. Later, the host gets a global IP address, and the client contacts an FTP server outside the local link. If the FTP client transmits its old Link-Local address instead of its new global IP address in the FTP "port" command, then the FTP server will be unable to open a data connection back to the client, and the FTP operation will fail.
只有一个链接本地地址。之后，主机会获得一个全局IP地址，客户端会在本地链接之外联系FTP服务器。如果FTP客户端在FTP“端口”命令中传输其旧的链路本地地址而不是新的全局IP地址，则FTP服务器将无法打开返回客户端的数据连接，FTP操作将失败。
Application software run on a multi-homed host that supports IPv4 Link-Local address configuration on more than one interface may fail.
在多主机主机上运行的应用程序软件在多个接口上支持IPv4链路本地地址配置，可能会失败。
This is because application software assumes that an IPv4 address is unambiguous, that it can refer to only one host. IPv4 Link-Local addresses are unique only on a single link. A host attached to multiple links can easily encounter a situation where the same address is present on more than one interface, or first on one interface, later on another; in any case associated with more than one host. Most existing software is not prepared for this ambiguity. In the future, application programming interfaces could be developed to prevent this problem. This issue is discussed in Section 3.
这是因为应用软件假定IPv4地址是明确的，它只能引用一个主机。IPv4链路本地地址仅在单个链路上是唯一的。连接到多个链路的主机很容易遇到一种情况，即同一地址出现在多个接口上，或者先出现在一个接口上，然后出现在另一个接口上；在任何情况下都与多个主机关联。大多数现有软件都没有为这种模糊性做好准备。将来，可以开发应用程序编程接口来防止这个问题。第3节讨论了这个问题。
A router MUST NOT forward a packet with an IPv4 Link-Local source or destination address, irrespective of the router's default route configuration or routes obtained from dynamic routing protocols.
路由器不得转发具有IPv4链路本地源或目标地址的数据包，无论路由器的默认路由配置或从动态路由协议获得的路由如何。
A router which receives a packet with an IPv4 Link-Local source or destination address MUST NOT forward the packet. This prevents forwarding of packets back onto the network segment from which they originated, or to any other segment.
接收具有IPv4链路本地源或目标地址的数据包的路由器不得转发该数据包。这可防止将数据包转发回其来源的网段或任何其他网段。
The IANA has allocated the prefix 169.254/16 for the use described in this document. The first and last 256 addresses in this range (169.254.0.x and 169.254.255.x) are allocated by Standards Action, as defined in "Guidelines for Writing an IANA" (BCP 26) [RFC2434]. No other IANA services are required by this document.
IANA已将前缀169.254/16分配给本文件所述用途。此范围内的第一个和最后256个地址（169.254.0.x和169.254.255.x）由标准行动分配，定义见“编写IANA指南”（BCP 26）[RFC2434]。本文件不需要其他IANA服务。
The following timing constants are used in this protocol; they are not intended to be user configurable.
本协议中使用了以下定时常数：；它们不是用户可配置的。
PROBE_WAIT 1 second (initial random delay) PROBE_NUM 3 (number of probe packets) PROBE_MIN 1 second (minimum delay till repeated probe) PROBE_MAX 2 seconds (maximum delay till 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秒（初始随机延迟）探测数量3（探测数据包数量）探测最少1秒（重复探测之前的最小延迟）探测最多2秒（重复探测之前的最大延迟）宣布等待2秒（宣布之前的延迟）宣布数量2（宣布数据包数量）宣布间隔2秒（公告数据包之间的时间）最大冲突10（速率限制前的最大冲突）速率限制间隔60秒（连续尝试之间的延迟）防御间隔10秒（防御ARP之间的最小间隔）。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[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标准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。
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC959]Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC959，1985年10月。
[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月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[RFC3027]Holdrege，M.和P.Srisuresh，“IP网络地址转换器的协议复杂性”，RFC 3027，2001年1月。
[DNAv4] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", Work in Progress, July 2004.
[DNAv4]Aboba，B.，“IPv4中网络连接（DNA）的检测”，正在进行的工作，2004年7月。
[LLMNR] Esibov, L., Aboba, B. and D. Thaler, "Linklocal Multicast Name Resolution (LLMNR)", Work in Progress, June 2004.
[LLMNR]Esibov，L.，Aboba，B.和D.Thaler，“链接本地多播名称解析（LLMNR）”，正在进行的工作，2004年6月。
Acknowledgments
致谢
We would like to thank (in alphabetical order) Jim Busse, Pavani Diwanji, Donald Eastlake 3rd, Robert Elz, Peter Ford, Spencer Giacalone, Josh Graessley, Brad Hards, Myron Hattig, Hugh Holbrook, Christian Huitema, Richard Johnson, Kim Yong-Woon, Mika Liljeberg, Rod Lopez, Keith Moore, Satish Mundra, Thomas Narten, Erik Nordmark, Philip Nye, Howard Ridenour, Daniel Senie, Dieter Siegmund, Valery Smyslov, and Ryan Troll for their contributions.
我们要感谢（按字母顺序排列）吉姆·巴斯、帕瓦尼·迪万吉、唐纳德·伊斯特莱克三世、罗伯特·埃尔兹、彼得·福特、斯宾塞·贾卡隆、乔什·格拉斯利、布拉德·哈德斯、迈伦·哈蒂格、休·霍尔布鲁克、克里斯蒂安·惠特马、理查德·约翰逊、金永焕、米卡·利耶伯格、罗德·洛佩兹、基思·摩尔、萨蒂什·蒙德拉、托马斯·纳腾、埃里克·诺德马克、菲利普·奈、，霍华德·里德努尔、丹尼尔·塞尼、迪特尔·西格蒙德、瓦莱里·斯米斯洛夫和瑞安·特罗尔感谢他们的贡献。
Appendix A - Prior Implementations
附录A-以前的实施
A.1. Apple Mac OS 8.x and 9.x.
A.1. 苹果MacOS8.x和9.x。
Mac OS chooses the IP address on a pseudo-random basis. The selected address is saved in persistent storage for continued use after reboot, when possible.
Mac OS在伪随机的基础上选择IP地址。所选地址保存在永久性存储器中，以便在可能的情况下重新启动后继续使用。
Mac OS sends nine DHCPDISCOVER packets, with an interval of two seconds between packets. If no response is received from any of these requests (18 seconds), it will autoconfigure.
Mac OS发送9个DHCPDISCOVER数据包，数据包之间的间隔为2秒。如果没有收到来自这些请求中任何一个的响应（18秒），它将自动配置。
Upon finding that a selected address is in use, Mac OS will select a new random address and try again, at a rate limited to no more than one attempt every two seconds.
在发现所选地址正在使用时，Mac OS将选择一个新的随机地址并重试，速率限制为每两秒不超过一次。
Autoconfigured Mac OS systems check for the presence of a DHCP server every five minutes. If a DHCP server is found but Mac OS is not successful in obtaining a new lease, it keeps the existing autoconfigured IP address. If Mac OS is successful at obtaining a new lease, it drops all existing connections without warning. This may cause users to lose sessions in progress. Once a new lease is obtained, Mac OS will not allocate further connections using the autoconfigured IP address.
自动配置的Mac OS系统每五分钟检查一次DHCP服务器的存在。如果找到DHCP服务器，但Mac OS无法成功获得新租约，则会保留现有自动配置的IP地址。如果Mac OS成功获得新租约，它会在没有警告的情况下删除所有现有连接。这可能会导致用户丢失正在进行的会话。一旦获得新租约，Mac OS将不会使用自动配置的IP地址分配更多连接。
Mac OS systems do not send packets addressed to a Link-Local address to the default gateway if one is present; these addresses are always resolved on the local segment.
Mac OS系统不会将地址为链路本地地址的数据包发送到默认网关（如果存在）；这些地址总是在本地段上解析。
Mac OS systems by default send all outgoing unicast packets with a TTL of 255. All multicast and broadcast packets are also sent with a TTL of 255 if they have a source address in the 169.254/16 prefix.
默认情况下，Mac OS系统发送TTL为255的所有传出单播数据包。如果源地址位于169.254/16前缀中，则所有多播和广播数据包也会以255的TTL发送。
Mac OS implements media sense where the hardware (and driver software) supports this. As soon as network connectivity is detected, a DHCPDISCOVER will be sent on the interface. This means that systems will immediately transition out of autoconfigured mode as soon as connectivity is restored.
Mac OS在硬件（和驱动程序软件）支持的情况下实现媒体感知。一旦检测到网络连接，就会在接口上发送DHCPDISCOVER。这意味着，一旦连接恢复，系统将立即脱离自动配置模式。
Mac OS X chooses the IP address on a pseudo-random basis. The selected address is saved in memory so that it can be re-used during subsequent autoconfiguration attempts during a single boot of the system.
Mac OS X以伪随机方式选择IP地址。所选地址保存在内存中，以便在系统单次启动期间的后续自动配置尝试中重新使用。
Autoconfiguration of a Link-Local address depends on the results of the DHCP process. DHCP sends two packets, with timeouts of one and two seconds. If no response is received (three seconds), it begins autoconfiguration. DHCP continues sending packets in parallel for a total time of 60 seconds.
链路本地地址的自动配置取决于DHCP进程的结果。DHCP发送两个数据包，超时时间为1秒和2秒。如果没有收到响应（三秒），则开始自动配置。DHCP继续并行发送数据包，总时间为60秒。
At the start of autoconfiguration, it generates 10 unique random IP addresses, and probes each one in turn for 2 seconds. It stops probing after finding an address that is not in use, or the list of addresses is exhausted.
在自动配置开始时，它会生成10个唯一的随机IP地址，并依次探测每个地址2秒钟。它在找到未使用的地址或地址列表已用尽后停止探测。
If DHCP is not successful, it waits five minutes before starting over again. Once DHCP is successful, the autoconfigured Link-Local address is given up. The Link-Local subnet, however, remains configured.
如果DHCP未成功，它将等待五分钟，然后重新启动。一旦DHCP成功，自动配置的链路本地地址将被放弃。但是，链路本地子网仍保持配置状态。
Autoconfiguration is only attempted on a single interface at any given moment in time.
在任何给定时刻，仅在单个接口上尝试自动配置。
Mac OS X ensures that the connected interface with the highest priority is associated with the Link-Local subnet. Packets addressed to a Link-Local address are never sent to the default gateway, if one is present. Link-local addresses are always resolved on the local segment.
Mac OS X确保具有最高优先级的连接接口与链路本地子网相关联。地址为链路本地地址的数据包永远不会发送到默认网关（如果存在）。链路本地地址始终在本地段上解析。
Mac OS X implements media sense where the hardware and driver support it. When the network media indicates that it has been connected, the autoconfiguration process begins again, and attempts to re-use the previously assigned Link-Local address. When the network media indicates that it has been disconnected, the system waits four seconds before de-configuring the Link-Local address and subnet. If the connection is restored before that time, the autoconfiguration process begins again. If the connection is not restored before that time, the system chooses another interface to autoconfigure.
Mac OS X在硬件和驱动程序支持的地方实现媒体感知。当网络媒体指示其已连接时，自动配置过程将再次开始，并尝试重新使用以前分配的链路本地地址。当网络媒体指示其已断开连接时，系统将等待四秒钟，然后再取消配置链路本地地址和子网。如果在此之前恢复了连接，则自动配置过程将再次开始。如果在此之前未恢复连接，系统将选择另一个接口进行自动配置。
Mac OS X by default sends all outgoing unicast packets with a TTL of 255. All multicast and broadcast packets are also sent with a TTL of 255 if they have a source address in the 169.254/16 prefix.
默认情况下，Mac OS X发送TTL为255的所有传出单播数据包。如果源地址位于169.254/16前缀中，则所有多播和广播数据包也会以255的TTL发送。
Windows 98/98SE systems choose their IPv4 Link-Local address on a pseudo-random basis. The address selection algorithm is based on computing a hash on the interface's MAC address, so that a large collection of hosts should obey the uniform probability distribution in choosing addresses within the 169.254/16 address space. Deriving
Windows 98/98SE系统以伪随机方式选择其IPv4链路本地地址。地址选择算法基于计算接口MAC地址的哈希，因此大量主机在选择169.254/16地址空间内的地址时应遵循统一的概率分布。衍生
the initial IPv4 Link-Local address from the interface's MAC address also ensures that systems rebooting will obtain the same autoconfigured address, unless a conflict is detected.
接口MAC地址中的初始IPv4链路本地地址还确保系统重新启动时将获得相同的自动配置地址，除非检测到冲突。
When in INIT state, the Windows 98/98SE DHCP Client sends out a total of 4 DHCPDISCOVERs, with an inter-packet interval of 6 seconds. When no response is received after all 4 packets (24 seconds), it will autoconfigure an address.
当处于初始状态时，Windows 98/98SE DHCP客户端总共发送4个DHCPDISCOVERs，包间间隔为6秒。当在所有4个数据包（24秒）之后没有收到响应时，它将自动配置地址。
The autoconfigure retry count for Windows 98/98SE systems is 10. After trying 10 autoconfigured IPv4 addresses, and finding all are taken, the host will boot without an IPv4 address.
Windows 98/98SE系统的自动配置重试计数为10。在尝试10个自动配置的IPv4地址并找到所有地址后，主机将在没有IPv4地址的情况下启动。
Autoconfigured Windows 98/98SE systems check for the presence of a DHCP server every five minutes. If a DHCP server is found but Windows 98 is not successful in obtaining a new lease, it keeps the existing autoconfigured IPv4 Link-Local address. If Windows 98/98SE is successful at obtaining a new lease, it drops all existing connections without warning. This may cause users to lose sessions in progress. Once a new lease is obtained, Windows 98/98SE will not allocate further connections using the autoconfigured IPv4 Link-Local address.
自动配置的Windows 98/98SE系统每五分钟检查一次DHCP服务器的存在。如果找到DHCP服务器，但Windows 98无法成功获得新租约，则会保留现有自动配置的IPv4链路本地地址。如果Windows 98/98SE成功获得新租约，它会在没有警告的情况下删除所有现有连接。这可能会导致用户丢失正在进行的会话。一旦获得新租约，Windows 98/98SE将不会使用自动配置的IPv4链路本地地址分配更多连接。
Windows 98/98SE systems with an IPv4 Link-Local address do not send packets addressed to an IPv4 Link-Local address to the default gateway if one is present; these addresses are always resolved on the local segment.
具有IPv4链路本地地址的Windows 98/98SE系统不会将地址为IPv4链路本地地址的数据包发送到默认网关（如果存在）；这些地址总是在本地段上解析。
Windows 98/98SE systems by default send all outgoing unicast packets with a TTL of 128. TTL configuration is performed by setting the Windows Registry Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services:\Tcpip\ Parameters\DefaultTTL of type REG_DWORD to the appropriate value. However, this default TTL will apply to all packets. While this facility could be used to set the default TTL to 255, it cannot be used to set the default TTL of IPv4 Link-Local packets to one (1), while allowing other packets to be sent with a TTL larger than one.
默认情况下，Windows 98/98SE系统发送TTL为128的所有传出单播数据包。TTL配置是通过将Windows注册表项HKEY\U LOCAL\U MACHINE\SYSTEM\CurrentControlSet\Services:\Tcpip\Parameters\DefaultTTL REG\U DWORD类型设置为适当的值来执行的。但是，此默认TTL将应用于所有数据包。虽然此功能可用于将默认TTL设置为255，但不能用于将IPv4链路本地数据包的默认TTL设置为1，同时允许使用大于1的TTL发送其他数据包。
Windows 98/98SE systems do not implement media sense. This means that network connectivity issues (such as a loose cable) may prevent a system from contacting the DHCP server, thereby causing it to auto-configure. When the connectivity problem is fixed (such as when the cable is re-connected) the situation will not immediately correct itself. Since the system will not sense the re-connection, it will remain in autoconfigured mode until an attempt is made to reach the DHCP server.
Windows 98/98SE系统不实现媒体感知。这意味着网络连接问题（如电缆松动）可能会阻止系统联系DHCP服务器，从而导致其自动配置。连接问题修复后（例如重新连接电缆时），情况不会立即自行纠正。由于系统不会检测到重新连接，因此将保持自动配置模式，直到尝试访问DHCP服务器。
The DHCP server included with Windows 98SE Internet Connection Sharing (ICS) (a NAT implementation) allocates out of the 192.168/16 private address space by default.
默认情况下，Windows 98SE Internet连接共享（ICS）（NAT实现）中包含的DHCP服务器分配192.168/16专用地址空间。
However, it is possible to change the allocation prefix via a registry key, and no checks are made to prevent allocation out of the IPv4 Link-Local prefix. When configured to do so, Windows 98SE ICS will rewrite packets from the IPv4 Link-Local prefix and forward them beyond the local link. Windows 98SE ICS does not automatically route for the IPv4 Link-Local prefix, so that hosts obtaining addresses via DHCP cannot communicate with autoconfigured-only devices.
但是，可以通过注册表项更改分配前缀，并且不进行任何检查以防止分配到IPv4链路本地前缀之外。当配置为这样做时，Windows 98SE ICS将重写IPv4链路本地前缀中的数据包，并将其转发到本地链路之外。Windows 98SE ICS不会自动路由IPv4链路本地前缀，因此通过DHCP获取地址的主机无法与仅自动配置的设备通信。
Other home gateways exist that allocate addresses out of the IPv4 Link-Local prefix by default. Windows 98/98SE systems can use a 169.254/16 IPv4 Link-Local address as the source address when communicating with non-Link-Local hosts. Windows 98/98SE does not support router solicitation/advertisement. Windows 98/98SE systems will not automatically discover a default gateway when in autoconfigured mode.
默认情况下，其他家庭网关会在IPv4链路本地前缀之外分配地址。当与非链路本地主机通信时，Windows 98/98SE系统可以使用169.254/16 IPv4链路本地地址作为源地址。Windows 98/98SE不支持路由器请求/播发。Windows 98/98SE系统在自动配置模式下不会自动发现默认网关。
The autoconfiguration behavior of Windows XP, Windows 2000, and Windows ME systems is identical to Windows 98/98SE except in the following respects:
Windows XP、Windows 2000和Windows ME系统的自动配置行为与Windows 98/98SE相同，但在以下方面不同：
Media Sense Router Discovery Silent RIP
媒体感知路由器发现静默RIP
Windows XP, 2000, and ME implement media sense. As soon as network connectivity is detected, a DHCPREQUEST or DHCPDISCOVER will be sent on the interface. This means that systems will immediately transition out of autoconfigured mode as soon as connectivity is restored.
Windows XP、2000和ME实现媒体感知。一旦检测到网络连接，就会在接口上发送DHCPREQUEST或DHCPDISCOVER。这意味着，一旦连接恢复，系统将立即脱离自动配置模式。
Windows XP, 2000, and ME also support router discovery, although it is turned off by default. Windows XP and 2000 also support a RIP listener. This means that they may inadvertently discover a default gateway while in autoconfigured mode.
Windows XP、2000和ME也支持路由器发现，尽管默认情况下它是关闭的。Windows XP和2000还支持RIP侦听器。这意味着他们可能会在自动配置模式下无意中发现默认网关。
ICS on Windows XP/2000/ME behaves identically to Windows 98SE with respect to address allocation and NATing of Link-Local prefixes.
Windows XP/2000/ME上的ICS在地址分配和链接本地前缀的本地设置方面的行为与Windows 98SE相同。
Authors' Addresses
作者地址
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
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 818 4011
EMail: bernarda@microsoft.com
Phone: +1 425 818 4011
EMail: bernarda@microsoft.com
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
埃里克·古特曼太阳微系统公司。74915德国威伯斯塔特
Phone: +49 7263 911 701
EMail: erik@spybeam.org
Phone: +49 7263 911 701
EMail: erik@spybeam.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。