Network Working Group N. Moore
Request for Comments: 4429 Monash University CTIE
Category: Standards Track April 2006
Network Working Group N. Moore
Request for Comments: 4429 Monash University CTIE
Category: Standards Track April 2006
Optimistic Duplicate Address Detection (DAD) for IPv6
IPv6的乐观重复地址检测（DAD）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers.
乐观重复地址检测是对现有IPv6邻居发现（RFC 2461）和无状态地址自动配置（RFC 2462）进程的一种互操作修改。其目的是在成功的情况下最小化地址配置延迟，在失败的情况下尽可能减少中断，并保持与未修改的主机和路由器的互操作性。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Problem Statement ..........................................3
1.2. Definitions ................................................4
1.3. Address Types ..............................................4
1.4. Abbreviations ..............................................5
2. Optimistic DAD Behaviors ........................................6
2.1. Optimistic Addresses .......................................6
2.2. Avoiding Disruption ........................................6
2.3. Router Redirection .........................................7
2.4. Contacting the Router ......................................7
3. Modifications to RFC-Mandated Behavior ..........................8
3.1. General ....................................................8
3.2. Modifications to RFC 2461 Neighbor Discovery ...............8
3.3. Modifications to RFC 2462 Stateless Address
Autoconfiguration ..........................................9
4. Protocol Operation .............................................10
4.1. Simple Case ...............................................10
4.2. Collision Case ............................................10
4.3. Interoperation Cases ......................................11
4.4. Pathological Cases ........................................11
5. Security Considerations ........................................12
Appendix A. Probability of Collision ..............................13
A.1. The Birthday Paradox ......................................13
A.2. Individual Moving Nodes ...................................14
Normative References ..............................................15
Informative References ............................................15
Acknowledgements ..................................................16
1. Introduction ....................................................3
1.1. Problem Statement ..........................................3
1.2. Definitions ................................................4
1.3. Address Types ..............................................4
1.4. Abbreviations ..............................................5
2. Optimistic DAD Behaviors ........................................6
2.1. Optimistic Addresses .......................................6
2.2. Avoiding Disruption ........................................6
2.3. Router Redirection .........................................7
2.4. Contacting the Router ......................................7
3. Modifications to RFC-Mandated Behavior ..........................8
3.1. General ....................................................8
3.2. Modifications to RFC 2461 Neighbor Discovery ...............8
3.3. Modifications to RFC 2462 Stateless Address
Autoconfiguration ..........................................9
4. Protocol Operation .............................................10
4.1. Simple Case ...............................................10
4.2. Collision Case ............................................10
4.3. Interoperation Cases ......................................11
4.4. Pathological Cases ........................................11
5. Security Considerations ........................................12
Appendix A. Probability of Collision ..............................13
A.1. The Birthday Paradox ......................................13
A.2. Individual Moving Nodes ...................................14
Normative References ..............................................15
Informative References ............................................15
Acknowledgements ..................................................16
Optimistic Duplicate Address Detection (DAD) is a modification of the existing IPv6 Neighbor Discovery (ND) [RFC2461] and Stateless Address Autoconfiguration (SLAAC) [RFC2462] processes. The intention is to minimize address configuration delays in the successful case, and to reduce disruption as far as possible in the failure case.
乐观重复地址检测（DAD）是对现有IPv6邻居发现（ND）[RFC2461]和无状态地址自动配置（SLAAC）[RFC2462]过程的修改。目的是在成功的情况下最小化地址配置延迟，并在失败的情况下尽可能减少中断。
Optimistic DAD is a useful optimization because in most cases DAD is far more likely to succeed than fail. This is discussed further in Appendix A. Disruption is minimized by limiting nodes' participation in Neighbor Discovery while their addresses are still Optimistic.
乐观的DAD是一个有用的优化，因为在大多数情况下，DAD成功的可能性远远大于失败的可能性。这将在附录A中进一步讨论。通过限制节点在其地址仍然乐观的情况下参与邻居发现，可以最大限度地减少中断。
It is not the intention of this memo to improve the security, reliability, or robustness of DAD beyond that of existing standards, but merely to provide a method to make it faster.
本备忘录的目的并不是为了提高DAD的安全性、可靠性或健壮性，使其超越现有标准，而是提供一种使其更快的方法。
The existing IPv6 address configuration mechanisms provide adequate collision detection mechanisms for the fixed hosts they were designed for. However, a growing population of nodes need to maintain continuous network access despite frequently changing their network attachment. Optimizations to the DAD process are required to provide these nodes with sufficiently fast address configuration.
现有的IPv6地址配置机制为其设计的固定主机提供了足够的冲突检测机制。然而，越来越多的节点需要保持连续的网络访问，尽管它们的网络连接经常改变。需要对DAD进程进行优化，以便为这些节点提供足够快的地址配置。
An optimized DAD method needs to:
优化的DAD方法需要：
* provide interoperability with nodes using the current standards.
* 使用当前标准提供与节点的互操作性。
* remove the RetransTimer delay during address configuration.
* 在地址配置过程中删除重定时延迟。
* ensure that the probability of address collision is not increased.
* 确保地址冲突的概率不会增加。
* improve the resolution mechanisms for address collisions.
* 改进地址冲突的解析机制。
* minimize disruption in the case of a collision.
* 在发生碰撞时尽量减少中断。
It is not sufficient to merely reduce RetransTimer in order to reduce the handover delay, as values of RetransTimer long enough to guarantee detection of a collision are too long to avoid disruption of time-critical services.
仅仅减少Renstimer以减少切换延迟是不够的，因为足以保证冲突检测的Renstimer值太长，无法避免时间关键型服务中断。
Definitions of requirements keywords ('MUST NOT', 'SHOULD NOT', 'MAY', 'SHOULD', 'MUST') are in accordance with the IETF Best Current Practice, RFC 2119 [RFC2119]
需求关键词（“不得”、“不应”、“可能”、“应该”、“必须”）的定义符合IETF最佳现行实践RFC 2119[RFC2119]
Address Resolution - Process defined by [RFC2461], section 7.2.
地址解析-由[RFC2461]第7.2节定义的过程。
Neighbor Unreachability Detection (NUD) - Process defined by [RFC2461], section 7.3.
邻居不可达性检测（NUD）-由[RFC2461]第7.3节定义的过程。
Standard Node - A Standard Node is one that is compliant with [RFC2461] and [RFC2462].
标准节点-标准节点是符合[RFC2461]和[RFC2462]的节点。
Optimistic Node (ON) - An Optimistic Node is one that is compliant with the rules specified in this memo.
乐观节点（ON）-乐观节点是符合此备忘录中指定规则的节点。
Link - A communication facility or medium over which nodes can communicate at the link layer.
链路-节点可在链路层进行通信的通信设施或介质。
Neighbors - Nodes on the same link, which may therefore be competing for the same IP addresses.
邻居-同一链路上的节点，因此可能竞争相同的IP地址。
Tentative address (as per [RFC2462]) - an address whose uniqueness on a link is being verified, prior to its assignment to an interface. A Tentative address is not considered assigned to an interface in the usual sense. An interface discards received packets addressed to a Tentative address, but accepts Neighbor Discovery packets related to Duplicate Address Detection for the Tentative address.
暂定地址（根据[RFC2462]）-在将其分配给接口之前，正在验证其在链路上的唯一性的地址。在通常意义上，临时地址不被视为分配给接口。接口丢弃发送到暂定地址的接收数据包，但接受与暂定地址的重复地址检测相关的邻居发现数据包。
Optimistic address - an address that is assigned to an interface and available for use, subject to restrictions, while its uniqueness on a link is being verified. This memo introduces the Optimistic state and defines its behaviors and restrictions.
乐观地址-分配给接口并可供使用的地址，受限制，同时验证其在链接上的唯一性。此备忘录介绍乐观状态并定义其行为和限制。
Preferred address (as per [RFC2462]) - an address assigned to an interface whose use by upper-layer protocols is unrestricted. Preferred addresses may be used as the source (or destination) address of packets sent from (or to) the interface.
首选地址（根据[RFC2462]）-分配给上层协议使用不受限制的接口的地址。优选地址可用作从接口发送（或发送到接口）的数据包的源（或目的地）地址。
Deprecated address (as per [RFC2462]) - An address assigned to an interface whose use is discouraged, but not forbidden. A Deprecated address should no longer be used as a source address in new communications, but packets sent from or to Deprecated addresses are delivered as expected. A Deprecated address may continue to be used as a source address in communications where switching to a Preferred address causes hardship to a specific upper-layer activity (e.g., an existing TCP connection).
不推荐使用的地址（根据[RFC2462]）-分配给不鼓励但不禁止使用的接口的地址。不推荐使用的地址不应再用作新通信中的源地址，但从不推荐使用的地址发送或发送到不推荐使用的地址的数据包将按预期方式传递。不推荐使用的地址可以继续用作通信中的源地址，其中切换到首选地址会对特定上层活动（例如，现有TCP连接）造成困难。
DAD - Duplicate Address Detection. Technique used for SLAAC. See [RFC2462], section 5.4.
重复地址检测。用于SLAAC的技术。见[RFC2462]，第5.4节。
ICMP Redirect - See [RFC2461], section 4.5.
ICMP重定向-见[RFC2461]，第4.5节。
NA - Neighbor Advertisement. See [RFC2461], sections 4.4 and 7.
NA-邻居广告。参见[RFC2461]，第4.4节和第7节。
NC - Neighbor Cache. See [RFC2461], sections 5.1 and 7.3.
NC-邻居缓存。参见[RFC2461]，第5.1节和第7.3节。
ND - Neighbor Discovery. The process described in [RFC2461].
第二邻居发现。[RFC2461]中描述的过程。
NS - Neighbor Solicitation. See [RFC2461], sections 4.3 and 7.
NS-邻居请求。参见[RFC2461]，第4.3节和第7节。
RA - Router Advertisement. See [RFC2462], sections 4.2 and 6.
路由器广告。参见[RFC2462]，第4.2节和第6节。
RS - Router Solicitation. See [RFC2461], sections 4.1 and 6.
RS-路由器请求。参见[RFC2461]，第4.1节和第6节。
SLAAC - StateLess Address AutoConfiguration. The process described in [RFC2462].
SLAAC-无状态地址自动配置。[RFC2462]中描述的过程。
SLLAO - Source Link-Layer Address Option - an option to NS, RA, and RS messages, which gives the link-layer address of the source of the message. See [RFC2461], section 4.6.1.
SLLAO—源链路层地址选项—NS、RA和RS消息的选项，提供消息源的链路层地址。见[RFC2461]，第4.6.1节。
TLLAO - Target Link-Layer Address Option - an option to ICMP Redirect messages and Neighbor Advertisements. See [RFC2461], sections 4.4, 4.5, and 4.6.1.
TLLAO-目标链路层地址选项-ICMP重定向消息和邻居播发的选项。参见[RFC2461]，第4.4、4.5和4.6.1节。
This non-normative section discusses Optimistic DAD behaviors.
本非规范性章节讨论乐观的父亲行为。
[RFC2462] introduces the concept of Tentative (in 5.4) and Deprecated (in 5.5.4) addresses. Addresses that are neither are said to be Preferred. Tentative addresses may not be used for communication, and Deprecated addresses should not be used for new communications. These address states may also be used by other standards documents, for example, Default Address Selection [RFC3484].
[RFC2462]介绍了暂定（在5.4中）和不推荐（在5.5.4中）地址的概念。两个地址都不是首选地址。暂定地址不得用于通信，不推荐的地址不得用于新通信。这些地址状态也可由其他标准文档使用，例如，默认地址选择[RFC3484]。
This memo introduces a new address state, 'Optimistic', that is used to mark an address that is available for use but that has not completed DAD.
此备忘录引入了一个新的地址状态“乐观”，用于标记可供使用但尚未完成DAD的地址。
Unless noted otherwise, components of the IPv6 protocol stack should treat addresses in the Optimistic state equivalently to those in the Deprecated state, indicating that the address is available for use but should not be used if another suitable address is available. For example, Default Address Selection [RFC3484] uses the address state to decide which source address to use for an outgoing packet. Implementations should treat an address in state Optimistic as if it were in state Deprecated. If address states are recorded as individual flags, this can easily be achieved by also setting 'Deprecated' when 'Optimistic' is set.
除非另有说明，否则IPv6协议栈的组件应将处于乐观状态的地址等同于处于不推荐状态的地址，这表明该地址可供使用，但如果另一个合适的地址可用，则不应使用该地址。例如，默认地址选择[RFC3484]使用地址状态来决定用于传出数据包的源地址。实现应该将处于乐观状态的地址视为处于不推荐状态。如果将地址状态记录为单个标志，则在设置“乐观”时也可以通过设置“不推荐”来轻松实现。
It is important to note that the address lifetime rules of [RFC2462] still apply, and so an address may be Deprecated as well as Optimistic. When DAD completes without incident, the address becomes either a Preferred or a Deprecated address, as per [RFC2462].
需要注意的是，[RFC2462]的地址生存期规则仍然适用，因此一个地址可能会被弃用，也可能是乐观的。如[RFC2462]所述，当DAD完成时，地址将成为首选地址或不推荐使用的地址。
In order to avoid interference, it is important that an Optimistic Node does not send any messages from an Optimistic Address that will override its neighbors' Neighbor Cache (NC) entries for the address it is trying to configure: doing so would disrupt the rightful owner of the address in the case of a collision.
为了避免干扰，乐观节点不得从乐观地址发送任何消息，因为乐观地址会覆盖其邻居试图配置的地址的邻居缓存（NC）项：这样做会在发生冲突时中断地址的合法所有者。
This is achieved by:
这是通过以下方式实现的：
* Clearing the 'Override' flag in Neighbor Advertisements for Optimistic Addresses, which prevents neighbors from overriding their existing NC entries. The 'Override' flag is already defined [RFC2461] and used for Proxy Neighbor Advertisement.
* 清除邻居播发中乐观地址的“Override”标志，以防止邻居覆盖其现有NC条目。“覆盖”标志已定义[RFC2461]，并用于代理邻居播发。
* Never sending Neighbor Solicitations from an Optimistic Address. NSes include a Source Link-Layer Address Option (SLLAO), which may cause Neighbor Cache disruption. NSes sent as part of DAD are sent from the unspecified address, without a SLLAO.
* 从不从乐观的地址发送邻居请求。NSE包括源链路层地址选项（SLLAO），这可能会导致邻居缓存中断。作为DAD的一部分发送的NSE是从未指定的地址发送的，没有SLLAO。
* Never using an Optimistic Address as the source address of a Router Solicitation with a SLLAO. Another address, or the unspecified address, may be used, or the RS may be sent without a SLLAO.
* 决不要使用乐观地址作为SLLAO路由器请求的源地址。可以使用另一个地址或未指定的地址，或者可以在没有SLLAO的情况下发送RS。
An address collision with a router may cause a neighboring router's IsRouter flags for that address to be cleared. However, routers do not appear to use the IsRouter flag for anything, and the NA sent in response to the collision will reassert the IsRouter flag.
与路由器的地址冲突可能会导致清除相邻路由器该地址的IsRouter标志。但是，路由器似乎不使用IsRouter标志进行任何操作，为响应冲突而发送的NA将重新指定IsRouter标志。
Neighbor Solicitations cannot be sent from Optimistic Addresses, and so an ON cannot directly contact a neighbor that is not already in its Neighbor Cache. Instead, the ON forwards packets via its default router, relying on the router to forward the packets to their destination. In accordance with RFC 2461, the router should then provide the ON with an ICMP Redirect, which may include a Target Link-Layer Address Option (TLLAO). If it does, this will update the ON's NC, and direct communication can begin. If it does not, packets continue to be forwarded via the router until the ON has a non-Optimistic address from which to send an NS.
邻居请求不能从乐观地址发送，因此ON不能直接联系不在其邻居缓存中的邻居。相反，ON通过其默认路由器转发数据包，依靠路由器将数据包转发到其目的地。根据RFC 2461，路由器随后应向ON提供ICMP重定向，该重定向可包括目标链路层地址选项（TLLAO）。如果确实如此，这将更新ON的NC，并且可以开始直接通信。如果没有，数据包将继续通过路由器转发，直到ON有一个非乐观地址从中发送NS。
Generally, an RA will include a SLLAO, however this "MAY be omitted to facilitate in-bound load balancing over replicated interfaces" [RFC2461]. A node with only Optimistic Addresses is unable to determine the router's Link-Layer Address as it can neither send an RS to request a unicast RA, nor send an NS to request an NA. In this case, the ON will be unable to communicate with the router until at least one of its addresses is no longer Optimistic.
一般来说，RA将包括SLLAO，但“可省略此项以促进复制接口上的绑定内负载平衡”[RFC2461]。只有乐观地址的节点无法确定路由器的链路层地址，因为它既不能发送RS请求单播RA，也不能发送NS请求NA。在这种情况下，在至少一个地址不再乐观之前，ON将无法与路由器通信。
All normative text in this memo is contained in this section.
本备忘录中的所有规范性文本均包含在本节中。
* Optimistic DAD SHOULD only be used when the implementation is aware that the address is based on a most likely unique interface identifier (such as in [RFC2464]), generated randomly [RFC3041], or by a well-distributed hash function [RFC3972] or assigned by Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. Optimistic DAD SHOULD NOT be used for manually entered addresses.
* 只有当实现知道地址基于最可能的唯一接口标识符（如[RFC2464]中）、随机生成[RFC3041]或由分布良好的哈希函数[RFC3972]或由IPv6动态主机配置协议（DHCPv6）[RFC3315]分配时，才应使用乐观DAD。乐观DAD不应用于手动输入的地址。
* (modifies section 6.3.7) A node MUST NOT send a Router Solicitation with a SLLAO from an Optimistic Address. Router Solicitations SHOULD be sent from a non-Optimistic or the Unspecified Address; however, they MAY be sent from an Optimistic Address as long as the SLLAO is not included.
* （修改第6.3.7节）节点不得从乐观地址发送带有SLLAO的路由器请求。路由器请求应该从非乐观地址或未指定的地址发送；但是，只要不包括SLLAO，它们可以从乐观的地址发送。
* (modifies section 7.2.2) A node MUST NOT use an Optimistic Address as the source address of a Neighbor Solicitation.
* （修改第7.2.2节）节点不得使用乐观地址作为邻居请求的源地址。
* If the ON isn't told the SLLAO of the router in an RA, and it cannot determine this information without breaching the rules above, it MUST leave the address Tentative until DAD completes despite being unable to send any packets to the router.
* 如果ON没有告诉SLLAO RA中的路由器，并且它无法在不违反上述规则的情况下确定此信息，那么它必须暂时保留地址，直到DAD完成，尽管无法向路由器发送任何数据包。
* (modifies section 7.2.2) When a node has a unicast packet to send from an Optimistic Address to a neighbor, but does not know the neighbor's link-layer address, it MUST NOT perform Address Resolution. It SHOULD forward the packet to a default router on the link in the hope that the packet will be redirected. Otherwise, it SHOULD buffer the packet until DAD is complete.
* （修改第7.2.2节）当节点具有要从乐观地址发送到邻居的单播数据包，但不知道邻居的链路层地址时，它不得执行地址解析。它应该将数据包转发到链路上的默认路由器，希望数据包被重定向。否则，它应该缓冲数据包，直到DAD完成。
* (modifies section 5.5) A host MAY choose to configure a new address as an Optimistic Address. A host that does not know the SLLAO of its router SHOULD NOT configure a new address as Optimistic. A router SHOULD NOT configure an Optimistic Address.
* （修改第5.5节）主机可以选择将新地址配置为乐观地址。不知道其路由器的SLLAO的主机不应将新地址配置为乐观地址。路由器不应配置乐观地址。
* (modifies section 5.4.2) The host MUST join the all-nodes multicast address and the solicited-node multicast address of the Tentative address. The host SHOULD NOT delay before sending Neighbor Solicitation messages.
* （修改第5.4.2节）主机必须加入所有节点多播地址和暂定地址的请求节点多播地址。主机在发送邻居请求消息之前不应延迟。
* (modifies section 5.4) The Optimistic Address is configured and available for use on the interface immediately. The address MUST be flagged as 'Optimistic'.
* （修改第5.4节）乐观地址已配置并可立即在接口上使用。地址必须标记为“乐观”。
* When DAD completes for an Optimistic Address, the address is no longer Optimistic and it becomes Preferred or Deprecated according to the rules of RFC 2462.
* 当DAD完成对乐观地址的查询时，该地址不再是乐观地址，根据RFC 2462的规则，它将成为首选地址或不推荐地址。
* (modifies section 5.4.3) The node MUST NOT reply to a Neighbor Solicitation for an Optimistic Address from the unspecified address. Receipt of such an NS indicates that the address is a duplicate, and it MUST be deconfigured as per the behaviour specified in RFC 2462 for Tentative addresses.
* （修改第5.4.3节）节点不得回复来自未指定地址的乐观地址的邻居请求。收到此类NS表示地址是重复的，必须按照RFC 2462中规定的暂定地址行为对其进行重新配置。
* (modifies section 5.4.3) The node MUST reply to a Neighbor Solicitation for an Optimistic Address from a unicast address, but the reply MUST have the Override flag cleared (O=0).
* （修改第5.4.3节）节点必须答复来自单播地址的乐观地址的邻居请求，但答复必须清除覆盖标志（O=0）。
This non-normative section provides clarification of the interactions between Optimistic Nodes, and between Optimistic Nodes and Standard Nodes.
本非规范性部分澄清了乐观节点之间以及乐观节点和标准节点之间的交互。
The following cases all consider an Optimistic Node (ON) receiving a Router Advertisement containing a new prefix and deciding to autoconfigure a new Optimistic Address on that prefix.
下面的案例都考虑了一个乐观节点（on）接收一个包含新前缀的路由器广告，并决定在该前缀上自动配置一个新的乐观地址。
The ON will immediately send out a Neighbor Solicitation to determine if its new Optimistic Address is already in use.
ON将立即发送邻居请求，以确定其新的乐观地址是否已在使用中。
In the non-collision case, the Optimistic Address being configured by the new node is unused and not present in the Neighbor Caches of any of its neighbors.
在非冲突情况下，新节点配置的乐观地址未使用，并且不存在于其任何邻居的邻居缓存中。
There will be no response to its NS (sent from ::), and this NS will not modify the state of neighbors' Neighbor Caches.
不会对其NS（发送自：：）做出响应，并且此NS不会修改邻居的邻居缓存的状态。
The ON already has the link-layer address of the router (from the RA), and the router can determine the link-layer address of the ON through standard Address Resolution. Communications can begin as soon as the router and the ON have each other's link-layer addresses.
ON已经拥有路由器的链路层地址（来自RA），路由器可以通过标准地址解析确定ON的链路层地址。只要路由器和ON具有彼此的链路层地址，通信就可以开始。
After the appropriate DAD delay has completed, the address is no longer Optimistic, and becomes either Preferred or Deprecated as per RFC 2462.
在适当的DAD延迟完成后，地址不再乐观，并根据RFC 2462的规定成为首选地址或不推荐地址。
In the collision case, the Optimistic Address being configured by the new node is already in use by another node, and present in the Neighbor Caches (NCs) of neighbors that are communicating with this node.
在冲突情况下，新节点配置的乐观地址已经被另一个节点使用，并且存在于与该节点通信的邻居的邻居缓存（NC）中。
The NS sent by the ON has the unspecified source address, ::, and no SLLAO. This NS will not cause changes to the NC entries of neighboring hosts.
ON发送的NS具有未指定的源地址：：，并且没有SLLAO。此NS不会导致更改相邻主机的NC条目。
The ON will hopefully already know all it needs to about the router from the initial RA. However, if it needs to it can still send an RS to ask for more information, but it may not include a SLLAO. This forces an all-nodes multicast response from the router, but will not disrupt other nodes' NCs.
希望ON从最初的RA就已经知道了所有关于路由器的需要。但是，如果需要，它仍然可以发送RS以请求更多信息，但可能不包括SLLAO。这将强制来自路由器的所有节点多播响应，但不会中断其他节点的NCs。
In the course of establishing connections, the ON might have sent NAs in response to received NSes. Since NAs sent from Optimistic Addresses have O=0, they will not have overridden existing NC entries, although they may have resulted in a colliding entry being changed to state STALE. This change is recoverable through standard NUD.
在建立连接的过程中，ON可能已发送NAs以响应收到的NSE。由于从乐观地址发送的NAs具有O=0，因此它们不会覆盖现有NC条目，尽管它们可能会导致冲突条目更改为state STALE。此更改可通过标准NUD恢复。
When an NA is received from the collidee defending the address, the ON immediately stops using the address and deconfigures it.
当收到来自该地址的碰撞保护器的NA时，ON立即停止使用该地址并取消对其进行解析。
Of course, in the meantime the ON may have sent packets that identify it as the owner of its new Optimistic Address (for example, Binding Updates in Mobile IPv6 [RFC3775]). This may incur some penalty to the ON, in the form of broken connections, and some penalty to the rightful owner of the address, since it will receive (and potentially reply to) the misdirected packets. It is for this reason that Optimistic DAD should be used only where the probability of collision is very low.
当然，与此同时，ON可能已经发送了将其标识为新乐观地址所有者的数据包（例如，移动IPv6[RFC3775]中的绑定更新）。这可能会以断开连接的形式对ON产生一些惩罚，并对地址的合法所有者产生一些惩罚，因为它将接收（并可能回复）错误定向的数据包。正是因为这个原因，乐观的DAD应该只在碰撞概率非常低的情况下使用。
Once the Optimistic Address has completed DAD, it acts exactly like a normal address, and so interoperation cases only arise while the address is Optimistic.
乐观地址完成DAD后，其行为与正常地址完全相同，因此只有在地址乐观时才会出现互操作情况。
If an ON attempts to configure an address currently Tentatively assigned to a Standard Node, the Standard Node will see the Neighbor Solicitation and deconfigure the address.
如果ON尝试配置当前暂时分配给标准节点的地址，则标准节点将看到邻居请求并取消配置该地址。
If a node attempts to configure an ON's Optimistic Address, the ON will see the NS and deconfigure the address.
如果节点尝试配置ON的乐观地址，ON将看到NS并取消配置该地址。
Optimistic DAD suffers from similar problems to Standard DAD; for example, duplicates are not guaranteed to be detected if packets are lost.
乐观的父亲和标准的父亲有着相似的问题；例如，如果数据包丢失，则不能保证检测到重复数据。
These problems exist, and are not gracefully recoverable, in Standard DAD. Their probability in both Optimistic and Standard DAD can be reduced by increasing the RFC 2462 DupAddrDetectTransmits variable to greater than 1.
这些问题在标准DAD中存在，并且无法正常恢复。通过将RFC 2462 DUPAddrDetect变量增加到大于1，可以降低它们在乐观DAD和标准DAD中的概率。
This version of Optimistic DAD is dependent on the details of the router behavior, e.g., that the router includes SLLAOs in RAs and that the router is willing to redirect traffic for the ON. Where the router does not behave in this way, the behavior of Optimistic DAD inherently reverts to that of Standard DAD.
此版本的乐观DAD取决于路由器行为的细节，例如，路由器在RAs中包含SLLAO，并且路由器愿意为on重定向流量。如果路由器不以这种方式工作，乐观型DAD的行为会固有地恢复到标准DAD的行为。
There are existing security concerns with Neighbor Discovery and Stateless Address Autoconfiguration, and this memo does not purport to fix them. However, this memo does not significantly increase security concerns either.
邻居发现和无状态地址自动配置存在安全问题，本备忘录并不打算解决这些问题。然而，这份备忘录也没有显著增加安全问题。
Secure Neighbor Discovery (SEND) [RFC3971] provides protection against the threats to Neighbor Discovery described in [RFC3756]. Optimistic Duplicate Address Detection does not introduce any additional threats to Neighbor Discovery if SEND is used.
安全邻居发现（SEND）[RFC3971]针对[RFC3756]中描述的邻居发现威胁提供保护。如果使用SEND，乐观重复地址检测不会给邻居发现带来任何额外的威胁。
Optimistic DAD takes steps to ensure that if another node is already using an address, the proper link-layer address in existing Neighbor Cache entries is not replaced with the link-layer address of the Optimistic Node. However, there are still scenarios where incorrect entries may be created, if only temporarily. For example, if a router (while forwarding a packet) sends out a Neighbor Solicitation for an address, the Optimistic Node may respond first, and if the router has no pre-existing link-layer address for that IP address, it will accept the response and (incorrectly) forward any queued packets to the Optimistic Node. The Optimistic Node may then respond in an incorrect manner (e.g., sending a TCP RST in response to an unknown TCP connection). Such transient conditions should be short-lived, in most cases.
乐观DAD采取步骤确保，如果另一个节点已在使用地址，则现有邻居缓存项中的正确链路层地址不会替换为乐观节点的链路层地址。但是，仍然存在可能创建不正确条目的情况，即使只是暂时的。例如，如果路由器（在转发分组时）发送邻居请求地址，乐观节点可以首先响应，并且如果路由器没有该IP地址的预先存在的链路层地址，它将接受响应并（错误地）将任何排队的分组转发给乐观节点。乐观节点随后可能以不正确的方式响应（例如，发送TCP RST以响应未知TCP连接）。在大多数情况下，这种瞬态条件应该是短暂的。
Likewise, an Optimistic Node can still inject IP packets into the Internet that will in effect be "spoofed" packets appearing to come from the legitimate node. In some cases, those packets may lead to errors or other operational problems, though one would expect that upper-layer protocols would generally treat such packets robustly, in the same way they must treat old and other duplicate packets.
类似地，乐观节点仍然可以将IP数据包注入互联网，而这些数据包实际上将被“伪造”为来自合法节点的数据包。在某些情况下，这些数据包可能会导致错误或其他操作问题，尽管人们预计上层协议通常会以处理旧数据包和其他重复数据包的相同方式来处理这些数据包。
In assessing the usefulness of Duplicate Address Detection, the probability of collision must be considered. Various mechanisms such as SLAAC [RFC2462] and DHCPv6 [RFC3315] attempt to guarantee the uniqueness of the address. The uniqueness of SLAAC depends on the reliability of the manufacturing process (so that duplicate L2 addresses are not assigned) and human factors if L2 addresses can be manually assigned. The uniqueness of DHCPv6-assigned addresses relies on the correctness of implementation to ensure that no two nodes can be given the same address.
在评估重复地址检测的有用性时，必须考虑冲突的概率。各种机制，如SLAAC[RFC2462]和DHCPv6[RFC3315]试图保证地址的唯一性。SLAAC的唯一性取决于制造过程的可靠性（因此不会分配重复的L2地址）和人为因素（如果L2地址可以手动分配）。DHCPv6分配地址的唯一性依赖于实现的正确性，以确保没有两个节点可以被赋予相同的地址。
"Privacy Extensions to SLAAC" [RFC3041] avoids these potential error cases by picking an Interface Identifier (IID) at random from 2^62 possible 64-bit IIDs (allowing for the reserved U and G bits). No attempt is made to guarantee uniqueness, but the probability can be easily estimated, and as the following discussion shows, probability of collision is exceedingly small.
“SLAAC的隐私扩展”[RFC3041]通过从2^62个可能的64位IID（允许保留的U和G位）中随机选取接口标识符（IID），避免了这些潜在的错误情况。没有人试图保证唯一性，但可以很容易地估计概率，正如下面的讨论所示，碰撞的概率非常小。
When considering collision probability, the Birthday Paradox is generally mentioned. When randomly selecting k values from n possibilities, the probability of two values being the same is:
在考虑碰撞概率时，通常会提到生日悖论。从n个可能性中随机选择k个值时，两个值相同的概率为：
Pb(n,k) = 1-( n! / [ (n-k)! . n^k] )
Pb(n,k) = 1-( n! / [ (n-k)! . n^k] )
Calculating the probability of collision with this method is difficult, however, as one of the terms is n!, and (2^62)! is an unwieldy number. We can, however, calculate an upper bound for the probability of collision:
然而，用这种方法计算碰撞概率是困难的，因为其中一项是n！，和（2^62）！这是一个难以处理的数字。然而，我们可以计算碰撞概率的上限：
Pb(n,k) <= 1-( [(n-k+1)/n] ^ [k-1] )
Pb(n,k) <= 1-( [(n-k+1)/n] ^ [k-1] )
which lets us calculate that even for large networks the probability of any two nodes colliding is very small indeed:
这让我们可以计算出，即使是大型网络，任何两个节点碰撞的概率也非常小：
Pb(2^62, 500) <= 5.4e-14
Pb(2^62, 5000) <= 5.4e-12
Pb(2^62, 50000) <= 5.4e-10
Pb(2^62, 500000) <= 5.4e-08
Pb(2^62, 500) <= 5.4e-14
Pb(2^62, 5000) <= 5.4e-12
Pb(2^62, 50000) <= 5.4e-10
Pb(2^62, 500000) <= 5.4e-08
The upper-bound formula used above was taken from "Random Generation of Interface Identifiers", by M. Bagnulo, I. Soto, A. Garcia-Martinez, and A. Azcorra, and is used with the kind permission of the authors.
上面使用的上限公式取自M.Bagnulo、I.Soto、A.Garcia Martinez和A.Azcorra的“随机生成接口标识符”，并经作者许可使用。
When considering the effect of collisions on an individual node, we do not need to consider the Birthday Paradox. When a node moves into a network with K existing nodes, the probability that it will not collide with any of the distinct addresses in use is simply 1-K/N. If it moves to such networks M times, the probability that it will not cause a collision on any of those moves is (1-K/N)^M; thus, the probability of it causing at least one collision is:
当考虑碰撞对单个节点的影响时，我们不需要考虑生日悖论。当一个节点移动到一个有K个现有节点的网络中时，它不会与使用中的任何不同地址发生冲突的概率仅为1-K/N。如果它移动到此类网络M次，它不会在这些移动中的任何一次上造成冲突的概率为（1-K/N）^M；因此，导致至少一次碰撞的概率为：
Pc(n,k,m) = 1-[(1-k/n)^m]
Pc(n,k,m) = 1-[(1-k/n)^m]
Even considering a very large number of moves (m = 600000, slightly more than one move per minute for one year) and rather crowded networks (k=50000 nodes per network), the odds of collision for a given node are vanishingly small:
即使考虑到大量移动（m=600000，一年内每分钟移动一次略多于一次）和相当拥挤的网络（k=50000个节点/网络），给定节点的碰撞几率也非常小：
Pc(2^62, 5000, 600000) = 6.66e-10
Pc(2^62, 50000, 600000) = 6.53e-09
Pc(2^62, 5000, 600000) = 6.66e-10
Pc(2^62, 50000, 600000) = 6.53e-09
Each such collision affects two nodes, so the probability of being affected by a collision is twice this. Even if the node moves into networks of 50000 nodes once per minute for 100 years, the probability of it causing or suffering a collision at any point are a little over 1 in a million.
每一次这样的碰撞都会影响两个节点，因此受到碰撞影响的概率是这一概率的两倍。即使该节点在100年内每分钟移动一次50000个节点的网络，它在任何一点引起或遭受碰撞的概率也略高于百万分之一。
Pc(2^62, 50000, 60000000) * 2 = 1.3e-06
Pc(2^62, 50000, 60000000) * 2 = 1.3e-06
Normative References
规范性引用文件
[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月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
Informative References
资料性引用
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC2464，1998年12月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756]Nikander，P.，Kempf，J.，和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 37562004年5月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
Acknowledgements
致谢
There is some precedent for this work in expired Internet-Drafts and in discussions in the MobileIP WG mailing list and at IETF-54. A similar concept occurs in the 'Optimistic' bit used by R. Koodli and C. Perkins in the now expired, "Fast Handovers in Mobile IPv6".
这项工作在过期的互联网草案以及MobileIP工作组邮件列表和IETF-54中的讨论中有一些先例。R.Koodli和C.Perkins在现已过期的“移动IPv6中的快速切换”中使用的“乐观”位也有类似的概念。
Thanks to Greg Daley, Richard Nelson, Brett Pentland and Ahmet Sekercioglu at Monash University CTIE for their feedback and encouragement. More information is available at:
感谢莫纳什大学CTIE的Greg Daley、Richard Nelson、Brett Pentland和Ahmet Sekercioglu的反馈和鼓励。有关更多信息，请访问：
<http://www.ctie.monash.edu.au/ipv6/fastho/>
<http://www.ctie.monash.edu.au/ipv6/fastho/>
Thanks to all the MobileIP and IPng/IPv6 WG members who have contributed to the debate, especially and alphabetically: Jari Arkko, Marcelo Bagnulo, JinHyeock Choi, Youn-Hee Han, James Kempf, Thomas Narten, Pekka Nikander, Erik Nordmark, Soohong 'Daniel' Park, Mohan Parthasarathy, Ed Remmel, Pekka Savola, Hesham Soliman, Ignatious Souvatzis, Jinmei Tatuya, Dave Thaler, Pascal Thubert, Christian Vogt, Vladislav Yasevich, and Alper Yegin.
感谢所有为辩论做出贡献的MobileIP和IPng/IPv6工作组成员，特别是按字母顺序排列的成员：Jari Arkko、Marcelo Bagnulo、JinHyeock Choi、Youn Hee Han、James Kempf、Thomas Narten、Pekka Nikander、Erik Nordmark、Soohong‘Daniel’Park、Mohan Parthasarathy、Ed Remmel、Pekka Savola、Hesham Soliman、Ignatious Souvatzis，金梅·塔图亚、戴夫·泰勒、帕斯卡·苏伯特、克里斯蒂安·沃格特、弗拉迪斯拉夫·亚塞维奇和阿尔帕·耶金。
This work has been supported by the Australian Telecommunications Cooperative Research Centre (ATcrc):
这项工作得到了澳大利亚电信合作研究中心（ATcrc）的支持：
<http://www.telecommunications.crc.org.au/>
<http://www.telecommunications.crc.org.au/>
Author's Address
作者地址
Nick 'Sharkey' Moore Centre for Telecommunications and Information Engineering Monash University 3800 Victoria, Australia
澳大利亚维多利亚州莫纳什大学电信和信息工程尼克·夏基·摩尔中心3800
Comments should be sent to <sharkey@zoic.org> and/or the IPv6 Working Group mailing list. Please include 'RFC4429' in the Subject line.
评论应发送至<sharkey@zoic.org>和/或IPv6工作组邮件列表。请在主题行中包含“RFC4429”。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。