Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6059 Ericsson
Category: Standards Track G. Daley
ISSN: 2070-1721 Netstar Logicalis
November 2010
Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6059 Ericsson
Category: Standards Track G. Daley
ISSN: 2070-1721 Netstar Logicalis
November 2010
Simple Procedures for Detecting Network Attachment in IPv6
IPv6中检测网络连接的简单过程
Abstract
摘要
Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for Detecting Network Attachment in IPv6 hosts, and procedures for routers to support such services.
检测网络连接允许主机评估其现有寻址或路由配置是否对新连接的网络有效。本文档提供了检测IPv6主机中网络连接的简单过程，以及路由器支持此类服务的过程。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6059.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6059.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Link Identification Model . . . . . . . . . . . . . . . . 4
1.4. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 5
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. The Simple DNA Address Table (SDAT) . . . . . . . . . . . . . 7
5. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. On Receipt of a Router Advertisement . . . . . . . . . . . 7
5.2. After Assignment of a DHCPv6 Address . . . . . . . . . . . 8
5.3. Steps Involved in Detecting Link Change . . . . . . . . . 8
5.4. Link-Layer Indication . . . . . . . . . . . . . . . . . . 8
5.5. Sending Neighbor Discovery probes . . . . . . . . . . . . 9
5.5.1. Sending Router Solicitations . . . . . . . . . . . . . 9
5.5.2. Sending Neighbor Solicitations . . . . . . . . . . . . 9
5.5.3. Concurrent Sending of RS and NS Probes . . . . . . . . 9
5.5.4. Initiating DHCPv6 Exchange . . . . . . . . . . . . . . 9
5.6. Contents of the Neighbor Discovery Messages . . . . . . . 10
5.6.1. Neighbor Solicitation Messages . . . . . . . . . . . . 10
5.6.2. Router Solicitation Messages . . . . . . . . . . . . . 10
5.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 11
5.7.1. Receiving Neighbor Advertisements . . . . . . . . . . 11
5.7.2. Receiving Router Advertisements . . . . . . . . . . . 11
5.7.3. Conflicting Results . . . . . . . . . . . . . . . . . 11
5.8. Further Host Operations . . . . . . . . . . . . . . . . . 11
5.9. On Connecting to a New Point of Attachment . . . . . . . . 12
5.10. Periodic Maintenance of the SDAT . . . . . . . . . . . . . 12
5.11. Recommended Retransmission Behavior . . . . . . . . . . . 12
6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 13
7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Issues with Confirming Manually Assigned Addresses . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Link Identification Model . . . . . . . . . . . . . . . . 4
1.4. DNA Overview . . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Working Assumptions . . . . . . . . . . . . . . . . . . . 5
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. The Simple DNA Address Table (SDAT) . . . . . . . . . . . . . 7
5. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. On Receipt of a Router Advertisement . . . . . . . . . . . 7
5.2. After Assignment of a DHCPv6 Address . . . . . . . . . . . 8
5.3. Steps Involved in Detecting Link Change . . . . . . . . . 8
5.4. Link-Layer Indication . . . . . . . . . . . . . . . . . . 8
5.5. Sending Neighbor Discovery probes . . . . . . . . . . . . 9
5.5.1. Sending Router Solicitations . . . . . . . . . . . . . 9
5.5.2. Sending Neighbor Solicitations . . . . . . . . . . . . 9
5.5.3. Concurrent Sending of RS and NS Probes . . . . . . . . 9
5.5.4. Initiating DHCPv6 Exchange . . . . . . . . . . . . . . 9
5.6. Contents of the Neighbor Discovery Messages . . . . . . . 10
5.6.1. Neighbor Solicitation Messages . . . . . . . . . . . . 10
5.6.2. Router Solicitation Messages . . . . . . . . . . . . . 10
5.7. Response Gathering . . . . . . . . . . . . . . . . . . . . 11
5.7.1. Receiving Neighbor Advertisements . . . . . . . . . . 11
5.7.2. Receiving Router Advertisements . . . . . . . . . . . 11
5.7.3. Conflicting Results . . . . . . . . . . . . . . . . . 11
5.8. Further Host Operations . . . . . . . . . . . . . . . . . 11
5.9. On Connecting to a New Point of Attachment . . . . . . . . 12
5.10. Periodic Maintenance of the SDAT . . . . . . . . . . . . . 12
5.11. Recommended Retransmission Behavior . . . . . . . . . . . 12
6. Pseudocode for Simple DNA . . . . . . . . . . . . . . . . . . 13
7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Relationship to DNAv4 . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Issues with Confirming Manually Assigned Addresses . 18
Hosts require procedures to simply and reliably identify if they have moved to a network to which they had been recently connected. In order to detect reconnection to a previously visited network, router and neighbor discovery messages are used to collect reachability and configuration information. This information is used to detect if the host has attached to a link for which it may still have valid address and other configuration information, and which it can use until it receives confirmation through either the Neighbor Discovery protocol or DHCPv6.
主机需要简单可靠地识别它们是否已移动到最近连接到的网络的过程。为了检测与先前访问的网络的重新连接，路由器和邻居发现消息用于收集可达性和配置信息。此信息用于检测主机是否已连接到其可能仍具有有效地址和其他配置信息的链路，并且在通过邻居发现协议或DHCPv6收到确认之前可以使用这些信息。
This document incorporates feedback from host and router operating systems implementors, which seeks to make implementation and adoption of IPv6 change detection procedures simple for general use.
本文档结合了主机和路由器操作系统实施者的反馈，旨在使IPv6变更检测过程的实施和采用变得简单，便于通用。
The goal of this document is to specify a simple procedure for Detecting Network Attachment (Simple DNA) that has the following characteristics.
本文档的目标是指定一个检测网络连接（简单DNA）的简单程序，该程序具有以下特征。
o Routers do not have to be modified to support this scheme.
o 路由器不必修改以支持此方案。
o The most common use cases are optimized.
o 对最常见的用例进行了优化。
o In the worst case, detection latency is equal to that of standard neighbor discovery so that performance is never degraded.
o 在最坏的情况下，检测延迟等于标准邻居发现的延迟，因此性能永远不会降低。
o False positives are not acceptable. A host must not wrongly conclude that it has reattached to a previously visited network.
o 假阳性是不可接受的。主机不得错误地认为它已重新连接到以前访问过的网络。
o False negatives are acceptable. A host may fail to identify a previously visited link correctly and attempt to acquire fresh addressing and configuration information.
o 假阴性是可以接受的。主机可能无法正确识别以前访问过的链路，并尝试获取新的地址和配置信息。
The Simple DNA protocol provides substantial benefits over standard neighbor discovery procedures [RFC4861] in some scenarios and does not provide any benefit at all in certain other scenarios. This is intentional as Simple DNA was designed for simplicity rather than completeness. In particular, the Simple DNA protocol provides maximum benefits when a host moves between a small set of known links. When a host moves to a completely new link that is previously unknown, the performance of the Simple DNA protocol will be identical to that using standard neighbor discovery procedures [RFC4861]. In this case, the main benefit of the Simple DNA protocol is to
在某些情况下，简单DNA协议比标准邻居发现程序[RFC4861]提供了实质性的好处，而在某些其他情况下根本没有任何好处。这是有意的，因为简单的DNA是为了简单而不是完整而设计的。特别是，当主机在一小部分已知链路之间移动时，简单的DNA协议提供了最大的好处。当主机移动到以前未知的全新链路时，简单DNA协议的性能将与使用标准邻居发现程序的性能相同[RFC4861]。在这种情况下，简单DNA协议的主要好处是
immediately flush out the inoperable addresses and configuration instead of timing them out. The Simple DNA procedure provides support for addresses configured using either IPv6 Stateless Address Autoconfiguration [RFC4862] or DHCPv6 [RFC3315]. It does not support manually configured addresses since they are not widely used and can cause unpredictable results and/or aggressive probing behavior (see Appendix A).
立即清除不可操作的地址和配置，而不是对其进行计时。简单的DNA过程支持使用IPv6无状态地址自动配置[RFC4862]或DHCPv6[RFC3315]配置的地址。它不支持手动配置的地址，因为它们没有被广泛使用，并且可能导致不可预测的结果和/或攻击性探测行为（参见附录A）。
Earlier methods of Detecting Network Attachment, e.g., the procedure defined in [DNA-PROTOCOL], relied on detecting whether the host was still connected to the same link. If the host was attached to the same link, all information related to the link such as the routers, prefixes, and configuration parameters was considered to be valid. The Simple DNA protocol follows an alternate approach where it relies on probing each previously known router to determine whether to use information learnt from THAT router. This allows Simple DNA to probe routers learnt from multiple earlier attachments to optimize movement between a known set of links.
早期检测网络连接的方法，例如[DNA-PROTOCOL]中定义的程序，依赖于检测主机是否仍然连接到同一链路。如果主机连接到同一链路，则与该链路相关的所有信息（如路由器、前缀和配置参数）均视为有效。简单DNA协议遵循另一种方法，即它依赖于探测每个先前已知的路由器，以确定是否使用从该路由器学到的信息。这允许简单的DNA探测从多个早期附件中学习到的路由器，以优化已知链接集之间的移动。
Detecting Network Attachment is performed by hosts after detecting a link-layer "up" indication. The host uses a combination of unicast Neighbor Solicitations (NSs) and multicast Router Solicitations (RSs) in order to determine whether previously encountered routers are present on the link, in which case an existing configuration can be reused. If previously encountered routers are not present, then either IPv6 Stateless Address Autoconfiguration and/or DHCPv6 is used for configuration.
检测网络连接由主机在检测到链路层“向上”指示后执行。主机使用单播邻居请求（NSs）和多播路由器请求（RSs）的组合来确定链路上是否存在以前遇到的路由器，在这种情况下，可以重用现有配置。如果以前遇到的路由器不存在，则使用IPv6无状态地址自动配置和/或DHCPv6进行配置。
Hosts implementing Simple DNA may also send DHCPv6 packets, as described in Section 5.5.4. Since Simple DNA does not modify the DHCPv6 protocol or state machine, the operation of DHCPv6 is unchanged.
实现简单DNA的主机也可以发送DHCPv6数据包，如第5.5.4节所述。由于Simple DNA不修改DHCPv6协议或状态机，因此DHCPv6的操作保持不变。
Routers that follow the standard neighbor discovery procedure described in [RFC4861] will delay the router advertisement (RA) by a random period between 0 and MAX_RA_DELAY_TIME (defined to be 500 ms) as described in Section 6.2.6 of [RFC4861]. In addition, consecutive RAs sent to the all-nodes multicast address are rate limited to no more than one advertisement every MIN_DELAY_BETWEEN_RAS (defined to be 3 seconds). This will result in a worst-case delay of 3.5 seconds in the absence of any packet loss.
遵循[RFC4861]中所述标准邻居发现程序的路由器将按照[RFC4861]第6.2.6节所述，将路由器通告（RA）延迟0到最大延迟时间（定义为500 ms）之间的随机周期。此外，发送到所有节点多播地址的连续RAs的速率限制为在两个RAs（定义为3秒）之间每分钟延迟不超过一个播发。在没有任何数据包丢失的情况下，这将导致3.5秒的最坏情况延迟。
Hosts implementing Simple DNA can detect the presence of a previously encountered router using unicast Neighbor Solicitations. As a result, where the host with a valid configuration is returning to a previously encountered link, delays in the sending of a Router Advertisement (RA) will not delay configuration as long as NS probing is successful. However, in situations where the host is attaching to a link for the first time, or where it does not have a valid IP address on the link, it will be dependent on the receipt of an RA for stateless autoconfiguration. In these situations, delays in the receipt of an RA can be significant and may result in service disruption.
实现简单DNA的主机可以使用单播邻居请求检测以前遇到的路由器的存在。因此，在具有有效配置的主机返回到先前遇到的链路的情况下，只要NS探测成功，路由器通告（RA）的发送延迟将不会延迟配置。但是，在主机第一次连接到链路的情况下，或者在链路上没有有效的IP地址的情况下，它将依赖于无状态自动配置RA的接收。在这些情况下，收到RA的延迟可能非常严重，并可能导致服务中断。
There are a series of assumptions about the network environment that underpin these procedures.
有一系列关于网络环境的假设支撑着这些过程。
o The combination of the link-layer address and the link-local IPv6 address of a router is unique across links.
o 路由器的链路层地址和链路本地IPv6地址的组合在链路中是唯一的。
o Hosts receive indications when a link layer comes up. Without this, they would not know when to commence the DNA procedure.
o 当链路层出现时，主机接收指示。没有这一点，他们就不知道什么时候开始DNA程序。
If these assumptions do not hold, host change detection systems will not function optimally. In that case, they may occasionally detect change spuriously or experience some delay in Detecting Network Attachment. The delays so experienced will be no longer than those caused by following the standard neighbor discovery procedure described in [RFC4861].
如果这些假设不成立，主机更改检测系统将无法最佳运行。在这种情况下，他们可能偶尔会错误地检测到更改，或者在检测网络连接时遇到一些延迟。所经历的延迟不会超过[RFC4861]中所述的标准邻居发现程序所造成的延迟。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
+---------------------+---------------------------------------------+
| Term | Definition |
+---------------------+---------------------------------------------+
| Valid IPv6 address | An IPv6 address configured on the node that |
| | has a valid lifetime greater than zero. |
| | |
| Operable IPv6 | An IPv6 address configured on the node that |
| address | can be used safely on the current link. |
| | |
| Router identifier | Identifier formed using the link-local |
| | address of a router along with its |
| | link-layer address. |
| | |
| D-Flag | Flag indicating whether the address was |
| | obtained using Stateless Address |
| | Autoconfiguration (SLAAC) or DHCPv6. If it |
| | is set to 0, then SLAAC was used to |
| | configure the address. If it is set to 1, |
| | then DHCPv6 was used to configure the |
| | address. |
| | |
| O-Flag | Flag indicating whether the address is |
| | operable. If it is set to 0, the address |
| | is inoperable. If it is set to 1, the |
| | address is operable. |
| | |
| S-Flag | Flag indicating whether SEND [RFC3971] was |
| | used in the Router Advertisement that |
| | resulted in the creation/modification of |
| | this SDAT entry. If it is set to 0, then |
| | SEND was not used. If it is set to 1, then |
| | SEND was used. |
| | |
| Candidate Router | A router address in the SDAT that is |
| Address | associated with at least one valid address. |
| | |
| Candidate Router | A set of router addresses that has been |
| Set | identified for NS-based probing. |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Term | Definition |
+---------------------+---------------------------------------------+
| Valid IPv6 address | An IPv6 address configured on the node that |
| | has a valid lifetime greater than zero. |
| | |
| Operable IPv6 | An IPv6 address configured on the node that |
| address | can be used safely on the current link. |
| | |
| Router identifier | Identifier formed using the link-local |
| | address of a router along with its |
| | link-layer address. |
| | |
| D-Flag | Flag indicating whether the address was |
| | obtained using Stateless Address |
| | Autoconfiguration (SLAAC) or DHCPv6. If it |
| | is set to 0, then SLAAC was used to |
| | configure the address. If it is set to 1, |
| | then DHCPv6 was used to configure the |
| | address. |
| | |
| O-Flag | Flag indicating whether the address is |
| | operable. If it is set to 0, the address |
| | is inoperable. If it is set to 1, the |
| | address is operable. |
| | |
| S-Flag | Flag indicating whether SEND [RFC3971] was |
| | used in the Router Advertisement that |
| | resulted in the creation/modification of |
| | this SDAT entry. If it is set to 0, then |
| | SEND was not used. If it is set to 1, then |
| | SEND was used. |
| | |
| Candidate Router | A router address in the SDAT that is |
| Address | associated with at least one valid address. |
| | |
| Candidate Router | A set of router addresses that has been |
| Set | identified for NS-based probing. |
+---------------------+---------------------------------------------+
Table 1: Simple DNA Terminology
表1：简单DNA术语
In order to correctly perform the procedure described in this document, the host needs to maintain a data structure called the Simple DNA address table (SDAT). The host needs to maintain this data structure for each interface on which it performs Simple DNA. Each entry in the SDAT table will be indexed by the router identifier (link-local + link-layer address of the router) and consists of at least the following parameters. Fields tagged as [S] are used for addresses configured using SLAAC. Fields tagged as [D] are used for addresses obtained using DHCPv6. Fields tagged as [S+D] are used in both cases.
为了正确执行本文档中描述的程序，主机需要维护一个称为简单DNA地址表（SDAT）的数据结构。主机需要为其执行简单DNA操作的每个接口维护此数据结构。SDAT表中的每个条目将由路由器标识符（路由器的链路本地+链路层地址）编制索引，并至少包含以下参数。标记为[S]的字段用于使用SLAAC配置的地址。标记为[D]的字段用于使用DHCPv6获得的地址。两种情况下都使用标记为[S+D]的字段。
o [S+D] Link-local IPv6 address of the router(s)
o [S+D]路由器的链路本地IPv6地址
o [S+D] Link-layer (MAC) address of the router(s)
o [S+D]路由器的链路层（MAC）地址
o [S+D] Flag indicating whether the address was obtained using SLAAC or DHCPv6. (The D-Flag)
o [S+D]标志，指示地址是使用SLAAC还是DHCPv6获取的。（D旗）
o [S+D] IPv6 address and its related parameters like valid lifetime, preferred lifetime, etc.
o [S+D]IPv6地址及其相关参数，如有效生存期、首选生存期等。
o [S] Prefix from which the address was formed.
o [S] 形成地址的前缀。
o [S] Flag indicating whether SEND was used. (The S-Flag)
o [S] 指示是否使用发送的标志。（S旗）
o [D] DHCP-specific information in case DHCPv6 [RFC3315] was used to acquire the address. This information includes the DUID, the IAID, a flag indicating IA_NA/IA_TA, and configuration information such as DNS server address, NTP server address, etc.
o [D] 使用DHCPv6[RFC3315]获取地址时的DHCP特定信息。此信息包括DUID、IAID、指示IA_NA/IA_TA的标志以及配置信息，如DNS服务器地址、NTP服务器地址等。
o [S+D] Flag indicating whether the address is operable. (The O-Flag)
o [S+D]标志，指示地址是否可操作。（O旗）
On connecting to a new point of attachment, the host performs the Detecting Network Attachment procedure in order to determine whether the existing addressing and configuration information are still valid.
在连接到新的连接点时，主机执行检测网络连接过程，以确定现有的寻址和配置信息是否仍然有效。
When the host receives a Router Advertisement and the router identifier of the sending router is not present in the SDAT, the host processes the Router Advertisement as specified in Section 6.3.4 of [RFC4861]. Additionally, the host performs the following operations.
当主机接收到路由器公告且发送路由器的路由器标识符不存在于SDAT中时，主机按照[RFC4861]第6.3.4节的规定处理路由器公告。此外，主机还执行以下操作。
If the Router Advertisement is protected by SEND, the S-Flag MUST be set to 1 in the SDAT entries created/modified by this RA.
如果路由器广告受发送保护，则在由该RA创建/修改的SDAT条目中，S标志必须设置为1。
o The host configures addresses out of the autoconfigurable prefixes advertised in the RA, as specified in [RFC4862]. The host MUST add an SDAT entry (indexed by this router identifier) for each such address the host configures.
o 主机根据[RFC4862]中的规定，从RA中公布的自动配置前缀中配置地址。主机必须为主机配置的每个此类地址添加SDAT条目（由该路由器标识符索引）。
o The host might have already configured addresses out of the autoconfigurable prefixes advertised in the RA. This could be a result of receiving the prefix in an RA from another router on the same link. The host MUST add an SDAT entry (indexed by this router identifier) for each such address the host had already configured.
o 主机可能已经在RA中公布的自动配置前缀之外配置了地址。这可能是从同一链路上的另一个路由器接收RA中的前缀的结果。主机必须为主机已配置的每个此类地址添加SDAT条目（由该路由器标识符索引）。
o The host might have DHCPv6-assigned addresses that are known to be operable on the link. The host MUST add an SDAT entry (indexed by this router identifier) for each such DHCPv6 address.
o 主机可能具有DHCPv6分配的地址，这些地址已知可在链路上操作。主机必须为每个这样的DHCPv6地址添加SDAT条目（由该路由器标识符索引）。
After the host is assigned an address by a DHCPv6 server, it needs to associate the address with the routers on link. The host MUST create one SDAT entry for each of the on-link routers associated with the DHCPv6-assigned address.
DHCPv6服务器为主机分配地址后，它需要将该地址与链路上的路由器相关联。主机必须为每个与DHCPv6分配地址关联的链路上路由器创建一个SDAT条目。
The steps involved in basic detection of network attachment are:
网络连接的基本检测所涉及的步骤包括：
o Link-layer indication
o 链路层指示
o Sending of neighbor discovery probes
o 发送邻居发现探测
o Response gathering and assessment
o 反应收集和评估
These steps are described below.
这些步骤如下所述。
In order to start detection of network attachment procedures, a host typically requires a link-layer indication that the medium has become available [RFC4957].
为了开始检测网络连接过程，主机通常需要链路层指示，表明介质已可用[RFC4957]。
After the indication is received, the host MUST mark all currently configured (non-tentative) IP addresses as inoperable until the change detection process completes. It MUST also set all Neighbor
收到指示后，主机必须将所有当前配置（非暂定）的IP地址标记为不可操作，直到更改检测过程完成。它还必须设置所有邻居
Cache (NC) entries for the routers on its Default Router List to STALE. This is done to speed up the acquisition of a new default router in case the host attaches to a previously unvisited link.
默认路由器列表上的路由器缓存（NC）项已过时。这样做是为了在主机连接到以前未访问的链路时加快获取新的默认路由器。
When a host receives a link-layer "up" indication, it SHOULD immediately send a Router Solicitation (as specified in Section 6.3.7 of [RFC4861]). The Router Solicitation is sent to the all-routers multicast address using a link-local address as the source address [RFC4861]. Even if the host is in possession of more than one valid IPv6 address, it MUST send only one router solicitation using a valid link-local address as the source address.
当主机收到链路层“向上”指示时，应立即发送路由器请求（如[RFC4861]第6.3.7节所述）。路由器请求使用链路本地地址作为源地址发送到所有路由器多播地址[RFC4861]。即使主机拥有多个有效的IPv6地址，它也必须使用有效的链路本地地址作为源地址，仅发送一个路由器请求。
The host iterates through the SDAT to identify a set of candidate routers for NS-based probing. Each router in the SDAT that is associated with at least one valid address is added to the candidate router set exactly once. For each router in the candidate router set, the host MUST send a unicast Neighbor Solicitation to the router's link-local address it obtained from the lookup on the SDAT. The host MUST set the link-layer destination address in each of these neighbor solicitations to the link-layer address of the router stored in the SDAT. The host MUST NOT send unicast Neighbor Solicitations to a router that is not associated to a valid address in the SDAT. If at least one entry in the SDAT for a given router had the S-Flag set, the host SHOULD use SEND to secure the NS probe being sent to the router.
主机通过SDAT进行迭代，以确定用于基于NS的探测的一组候选路由器。SDAT中与至少一个有效地址相关联的每个路由器被精确地添加到候选路由器集中一次。对于候选路由器集中的每个路由器，主机必须向其从SDAT上的查找中获得的路由器链路本地地址发送单播邻居请求。主机必须将每个邻居请求中的链路层目标地址设置为存储在SDAT中的路由器的链路层地址。主机不得向与SDAT中的有效地址不关联的路由器发送单播邻居请求。如果给定路由器的SDAT中至少有一个条目设置了S标志，则主机应使用SEND来保护发送到路由器的NS探测器。
The host SHOULD send the Neighbor-Solicitation-based unicast probes in parallel with the multicast Router Solicitation. Since sending NSs is just an optimization, doing the NSs and the RS in parallel ensures that the procedure does not run slower than it would if it only used a Router Solicitation.
主机应与多播路由器请求并行发送基于邻居请求的单播探测。由于发送NSs只是一种优化，并行执行NSs和RS可确保该过程不会比仅使用路由器请求时运行得慢。
NOTE: A Simple DNA implementation SHOULD limit its NS-based probing to at most six previously seen routers.
注意：一个简单的DNA实现应该将其基于NS的探测限制为最多六个以前见过的路由器。
On receiving a link-layer "up" indication, the host will initiate a DHCPv6 exchange (with the timing and protocol as specified in [RFC3315]) in order to verify whether the addresses and configuration
收到链路层“向上”指示后，主机将启动DHCPv6交换（按照[RFC3315]中规定的时间和协议），以验证地址和配置是否正确
obtained using DHCPv6 are still usable on the link. Note that DHCPv6, as specified today, only attempts to confirm addresses obtained on the most recently attached link.
使用DHCPv6获得的链接仍然可用。请注意，如今天所述，DHCPv6仅尝试确认在最近连接的链接上获得的地址。
This section describes the contents of the neighbor solicitation probe messages sent during the probing procedure.
本节介绍在探测过程中发送的邻居请求探测消息的内容。
Source Address: A link-local address assigned to the probing host.
源地址：分配给探测主机的链路本地地址。
Destination Address: The link-local address of the router being probed as learned from the SDAT.
目的地地址：从SDAT获取的被探测路由器的链路本地地址。
Hop Limit: 255
跃点限制：255
ND Options:
ND选项：
Target Address: The link-local address of the router being probed as learnt from the SDAT.
目标地址：从SDAT获取的被探测路由器的链路本地地址。
Link-Layer Header:
链接层标题：
Destination Address: The link-layer (MAC) address of the router being probed as learnt from the SDAT.
目的地址：从SDAT获悉的被探测路由器的链路层（MAC）地址。
The probing node SHOULD include the source link-layer address option in the probe messages.
探测节点应在探测消息中包含源链路层地址选项。
This section describes the contents of the router solicitation probe message sent during the probing procedure.
本节介绍在探测过程中发送的路由器请求探测消息的内容。
Source Address: A link-local address assigned to the probing host.
源地址：分配给探测主机的链路本地地址。
Destination Address: The all-routers multicast address.
目的地址：所有路由器的多播地址。
Hop Limit: 255
跃点限制：255
The probing node SHOULD NOT include the source link-layer address option in the probe messages.
探测节点不应在探测消息中包含源链路层地址选项。
When a Neighbor Advertisement is received from a router in response to an NS probe, the host MUST verify that both the IPv6 and link-layer (MAC) addresses of the router match the expected values before utilizing the configuration associated with the detected network (prefixes, MTU, etc.). The host MUST then go through the SDAT and mark the addresses (both SLAAC and DHCPv6 acquired) associated with the router as operable.
当从路由器接收到邻居播发以响应NS探测时，主机必须验证路由器的IPv6和链路层（MAC）地址是否与预期值匹配，然后才能使用与检测到的网络相关联的配置（前缀、MTU等）。然后，主机必须通过SDAT并将与路由器相关的地址（SLAAC和DHCPv6都已获取）标记为可操作。
On reception of a Router Advertisement, the host MUST go through the SDAT and mark all the addresses associated with the router (both SLAAC and DHCPv6 acquired) as inoperable. The host MUST then process the Router Advertisement as specified in Section 6.3.4 of [RFC4861].
在接收到路由器广告时，主机必须通过SDAT并将与路由器相关的所有地址（获取SLAAC和DHCPv6）标记为不可操作。然后，主机必须按照[RFC4861]第6.3.4节的规定处理路由器公告。
Where the conclusions obtained from the Neighbor Solicitation/ Advertisement from a given router and the RS/RA exchange with the same router differ, the results obtained from the RS/RA will be considered definitive. In case the Neighbor Advertisement was secured using SEND and the Router Advertisement was not, the host MUST wait for SEND_NA_GRACE_TIME to see if a SEND-secured RA is received. If a SEND-secured RA is not received, the conclusions obtained from the NS/NA exchange will be considered definitive.
如果从给定路由器的邻居请求/广告以及与同一路由器的RS/RA交换中获得的结论不同，则从RS/RA中获得的结果将被认为是确定的。如果邻居播发是使用SEND保护的，而路由器播发不是，则主机必须等待SEND_NA_GRACE_时间，以查看是否接收到发送保护的RA。如果未收到发送安全RA，则从NS/NA交换获得的结论将被视为最终结论。
Where the conclusions obtained from the Neighbor Solicitation/ Advertisement for a given DHCPv6-assigned address and the conclusions obtained from the DHCPv6 exchange differ, the results obtained from the DHCPv6 exchange will be considered definitive.
如果从给定DHCPv6分配地址的邻居征集/广告中获得的结论与从DHCPv6交换中获得的结论不同，则从DHCPv6交换中获得的结果将被认为是确定的。
Operations subsequent to Detecting Network Attachment depend upon whether or not the host has reconnected to a previously visited network.
检测网络连接后的操作取决于主机是否已重新连接到先前访问的网络。
After confirming the reachability of the associated router using an NS/NA pair, the host performs the following steps.
在使用NS/NA对确认关联路由器的可达性后，主机执行以下步骤。
o The host SHOULD rejoin any solicited nodes' multicast groups for addresses it continues to use.
o 主机应重新加入任何请求节点的多播组，以获得其继续使用的地址。
o The host SHOULD select a default router as described in Section 6.3.6 of [RFC4861].
o 主机应选择[RFC4861]第6.3.6节所述的默认路由器。
If the host has determined that it has reattached to a previously visited link, it SHOULD NOT perform duplicate address detection on the addresses that have been confirmed to be operable.
如果主机已确定已重新连接到先前访问的链路，则不应对已确认可操作的地址执行重复地址检测。
If the NS-based probe with a router did not complete or if the RS-based probe on the same router completed with different prefixes than the ones in the SDAT, the host MUST begin address configuration techniques, as indicated in a received Router Advertisement [RFC4861] [RFC4862].
如果带路由器的基于NS的探测未完成，或者如果同一路由器上基于RS的探测使用不同于SDAT中前缀的前缀完成，则主机必须开始地址配置技术，如接收到的路由器公告[RFC4861][RFC4862]中所示。
A host usually maintains SDAT entries from some number of previously visited networks. When the host attaches to a previously unknown network, it MAY need to discard some older SDAT entries.
主机通常维护一些以前访问过的网络的SDAT条目。当主机连接到以前未知的网络时，可能需要丢弃一些旧的SDAT条目。
The host SHOULD maintain the SDAT table by removing entries when the valid lifetime for the prefix and address expires, that is, at the same time that the prefix is removed from the Prefix List in [RFC4861]. The host SHOULD also remove a router from an SDAT entry when that router stops advertising a particular prefix. When three consecutive RAs from a particular router have not included a prefix, then the router should be removed from the corresponding SDAT entry. Likewise, if a router starts advertising a prefix for which there already exists an SDAT entry,then that router should be added to the SDAT entry.
主机应在前缀和地址的有效生存期到期时，即从[RFC4861]中的前缀列表中删除前缀的同时，通过删除条目来维护SDAT表。当路由器停止播发特定前缀时，主机还应从SDAT条目中删除路由器。当特定路由器的三个连续RAs未包含前缀时，应将路由器从相应的SDAT条目中删除。同样，如果路由器开始公布已经存在SDAT条目的前缀，则该路由器应添加到SDAT条目中。
Where the NS probe does not complete successfully, it usually implies that the host is not attached to the network whose configuration is being tested. In such circumstances, there is typically little value in aggressively retransmitting unicast neighbor solicitations that do not elicit a response.
如果NS探测器未成功完成，则通常意味着主机未连接到正在测试其配置的网络。在这种情况下，主动重发不会引起响应的单播邻居请求通常没有什么价值。
Where unicast Neighbor Solicitations and Router Solicitations are sent in parallel, one strategy is to forsake retransmission of Neighbor Solicitations and to allow retransmission only of Router Solicitations or DHCPv6. In order to reduce competition between unicast Neighbor Solicitations and Router Solicitations and DHCPv6
在并行发送单播邻居请求和路由器请求的情况下，一种策略是放弃邻居请求的重传，并且只允许路由器请求或DHCPv6的重传。为了减少单播邻居请求和路由器请求与DHCPv6之间的竞争
retransmissions, a DNAv6 implementation that retransmits may utilize the retransmission strategy described in the DHCPv6 specification [RFC3315], scheduling DNAv6 retransmissions between Router Solicitations or DHCPv6 retransmissions.
重传，一种DNAv6实现，重传可利用DHCPv6规范[RFC3315]中描述的重传策略，在路由器请求或DHCPv6重传之间调度DNAv6重传。
If a response is received to any unicast Neighbor Solicitation, pending retransmissions of the same MUST be canceled. A Simple DNA implementation SHOULD NOT retransmit a Neighbor Solicitation more than twice. To provide damping in the case of spurious link-up indications, the host SHOULD NOT perform the Simple DNA procedure more than once a second.
如果收到对任何单播邻居请求的响应，则必须取消该请求的挂起重传。一个简单的DNA实现不应该重传邻居请求超过两次。为了在虚假连接指示的情况下提供阻尼，宿主不应每秒执行一次以上的简单DNA程序。
/* Link-up indication received on INTERFACE */
/* Start Simple DNA process */
/* Link-up indication received on INTERFACE */
/* Start Simple DNA process */
/* Mark all addresses as inoperable */
Configured_Address_List=Get_Address_List(INTERFACE);
for each Configured_Address in Configured_Address_List
{
if (Get_Address_State(Configured_Address)!=AS_TENTATIVE)
{
Set_Address_State(Configured_Address,AS_INOPERABLE);
}
}
/* Mark all addresses as inoperable */
Configured_Address_List=Get_Address_List(INTERFACE);
for each Configured_Address in Configured_Address_List
{
if (Get_Address_State(Configured_Address)!=AS_TENTATIVE)
{
Set_Address_State(Configured_Address,AS_INOPERABLE);
}
}
/* Mark all routers' NC entries as STALE to speed up */
/* acquisition of new router if link change has occurred */
for each Router_Address in DEFAULT_ROUTER_LIST
{
NCEntry=Get_Neighbor_Cache_Entry(Router_Address);
Set_Neighbor_Cache_Entry_State(NCEntry,NCS_STALE);
}
/* Mark all routers' NC entries as STALE to speed up */
/* acquisition of new router if link change has occurred */
for each Router_Address in DEFAULT_ROUTER_LIST
{
NCEntry=Get_Neighbor_Cache_Entry(Router_Address);
Set_Neighbor_Cache_Entry_State(NCEntry,NCS_STALE);
}
/* Thread A : Send Router Solicitation */
RS_Target_Address=FF02::2;
RS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);
Send_Router_Solicitation(RS_Source_Address,RS_Target_Address);
/* Thread A : Send Router Solicitation */
RS_Target_Address=FF02::2;
RS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);
Send_Router_Solicitation(RS_Source_Address,RS_Target_Address);
/* Thread B : Send Neighbor Solicitation(s) */
Previously_Known_Router_List=Get_Router_List_from_SDAT();
NS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);
/* Thread B : Send Neighbor Solicitation(s) */
Previously_Known_Router_List=Get_Router_List_from_SDAT();
NS_Source_Address=Get_Any_Link_Local_Address(INTERFACE);
for each Router_Address in Previously_Known_Router_List
{
if (Get_Any_Valid_Address_from_SDAT(Router_Address))
{
Send_Neighbor_Solicitation(NS_Source_Address,
Router_Address.L3_Address,
Router_Address.L2_Address);
}
}
for each Router_Address in Previously_Known_Router_List
{
if (Get_Any_Valid_Address_from_SDAT(Router_Address))
{
Send_Neighbor_Solicitation(NS_Source_Address,
Router_Address.L3_Address,
Router_Address.L2_Address);
}
}
/* Thread C : Response collection of RAs */
/* Thread C : Response collection of RAs */
/* Received Router Advertisement processing */
/* Only for RAs received from routers in the SDAT */
/* Received Router Advertisement processing */
/* Only for RAs received from routers in the SDAT */
L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
/* Mark all the addresses associated with the router as inoperable */
for each SDAT_Entry in SDAT_Entry_List
{
Set_Address_State(SDAT_Entry,AS_INOPERABLE);
}
/* Mark all the addresses associated with the router as inoperable */
for each SDAT_Entry in SDAT_Entry_List
{
Set_Address_State(SDAT_Entry,AS_INOPERABLE);
}
/* Ignore further NAs from this router */
/* after delaying for x milliseconds */
Add_Router_to_NA_Ignore_List(L3_Source,SEND_NA_GRACE_PERIOD);
/* Ignore further NAs from this router */
/* after delaying for x milliseconds */
Add_Router_to_NA_Ignore_List(L3_Source,SEND_NA_GRACE_PERIOD);
/* Perform Standard RA processing as per RFC 4861 / RFC 4862 */
/* Perform Standard RA processing as per RFC 4861 / RFC 4862 */
/* Thread D : Response collection of NAs */
/* Thread D : Response collection of NAs */
/* Received Neighbor Advertisement processing */
/* Only for NAs received as response to DNA NSs */
/* Received Neighbor Advertisement processing */
/* Only for NAs received as response to DNA NSs */
L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
L3_Source=Get_L3_Source(RECEIVED_MESSAGE);
L2_Source=Get_L2_Source(RECEIVED_MESSAGE);
if (Is_Router_on_NA_Ignore_List(L3_Source)) {
/* Ignore message and wait for next message */
continue;
}
if (Is_Router_on_NA_Ignore_List(L3_Source)) {
/* Ignore message and wait for next message */
continue;
}
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
SDAT_Entry_List=Get_Entries_from_SDAT_L2L3(L3_Source,L2_Source));
for each SDAT_Entry in SDAT_Entry_List
{
/* Address is operable. */
Set_Address_State(SDAT_Entry,AS_OPERABLE);
/* Configure on Interface */
}
for each SDAT_Entry in SDAT_Entry_List
{
/* Address is operable. */
Set_Address_State(SDAT_Entry,AS_OPERABLE);
/* Configure on Interface */
}
Figure 1: Pseudocode for Simple DNA
图1：简单DNA的伪代码
NOTE: This section does not include any pseudocode for sending of the DHCPv6 packets since the DHCPv6 exchange is orthogonal to the Simple DNA process.
注意：本节不包括用于发送DHCPv6数据包的任何伪代码，因为DHCPv6交换与简单DNA过程正交。
SEND_NA_GRACE_TIME
送你一次恩典
Definition: An optional period to wait after Neighbor Solicitation before adopting a non-SEND RA's link change information.
定义：在采用非发送RA的链路更改信息之前，在邻居请求之后等待的可选时间段。
Value: 40 milliseconds
值：40毫秒
DNAv4 [RFC4436] specifies a set of steps that optimize the (common) case of reattachment to an IPv4 network that a host has been connected to previously by attempting to reuse a previous (but still valid) configuration. This document shares the same goal as DNAv4 (that of minimizing the handover latency in moving between points of attachment) but differs in the steps it performs to achieve this goal. Another difference is that this document supports stateless autoconfiguration of addresses in addition to addresses configured using DHCPv6.
DNAv4[RFC4436]指定了一组步骤，通过尝试重用以前（但仍然有效）的配置，优化主机先前已连接到的IPv4网络重新连接的（常见）情况。本文档与DNAv4的目标相同（即在连接点之间移动时最小化切换延迟），但为实现此目标而执行的步骤不同。另一个区别是，除了使用DHCPv6配置的地址外，本文档还支持无状态地址自动配置。
A host may receive Router Advertisements from non-SEND devices, after receiving a link-layer indication. While it is necessary to assess quickly whether a host has moved to another network, it is important that the host's current secured SEND [RFC3971] router information is not replaced by an attacker that spoofs an RA and purports to change the link.
在接收到链路层指示之后，主机可以从非发送设备接收路由器广告。虽然有必要快速评估主机是否已移动到另一个网络，但重要的是主机当前的安全发送[RFC3971]路由器信息不会被伪造RA并声称更改链接的攻击者所取代。
As such, the host SHOULD send a Neighbor Solicitation to the existing SEND router upon link-up indication as described above in Section 5.4. The host SHOULD then ensure that unsecured router
因此，主机应根据上文第5.4节所述的链路指示向现有发送路由器发送邻居请求。然后主机应确保不安全的路由器
information does not cause deletion of existing SEND state, within MIN_DELAY_BETWEEN_RAS, in order to allow for a present SEND router to respond.
信息不会导致在两个RAS之间的最小延迟内删除现有发送状态，以允许当前发送路由器响应。
If the current default router is a SEND-secured router, the host SHOULD wait SEND_NA_GRACE_TIME after transmission before adopting a new default router.
如果当前默认路由器是发送安全路由器，则主机应在传输后等待发送时间，然后再采用新的默认路由器。
Even if SEND signatures on RAs are used, it may not be immediately clear if the router is authorized to make such advertisements. As such, a host SHOULD NOT treat such devices as secure until and unless authorization delegation discovery is successful.
即使使用RAs上的发送签名，也可能无法立即确定路由器是否有权发布此类广告。因此，除非授权委托发现成功，否则主机不应将此类设备视为安全设备。
Unless SEND or another form of secure address configuration is used, the DNA procedure does not in itself provide positive, secure authentication of the router(s) on the network, or authentication of the network itself, as would be provided, e.g., by mutual authentication at the link layer. Therefore, when such assurance is not available, the host MUST NOT make any security-sensitive decisions based on the DNA procedure alone. In particular, it MUST NOT decide that it has moved from an untrusted to a trusted network, and MUST NOT make any security decisions that depend on the determination that such a transition has occurred.
除非使用SEND或另一种形式的安全地址配置，否则DNA过程本身并不提供网络上路由器的肯定、安全认证，或网络本身的认证，例如，通过链路层的相互认证。因此，当无法获得此类保证时，宿主不得仅基于DNA程序做出任何安全敏感决策。特别是，它不能确定它已从不受信任的网络移动到受信任的网络，也不能做出任何依赖于已发生这种转换的确定的安全决策。
This document is the product of a discussion the authors had with Bernard Aboba, Thomas Narten, Erik Nordmark, and Dave Thaler at IETF 69. The authors would like to thank them for clearly detailing the requirements of the solution and the goals it needed to meet and for helping to explore the solution space. The authors would like to thank the authors and editors of the complete DNA specification for detailing the overall problem space and solutions. The authors would like to thank Jari Arkko for driving the evolution of a simple and probabilistic DNA solution. The authors would like to thank Bernard Aboba, Thomas Narten, Jari Arkko, Sathya Narayan, Julien Laganier, Domagoj Premec, Jin Hyeock-Choi, Alfred Hoenes, Frederic Rossi, Ralph Droms, Ted Lemon, Erik Nordmark, Lars Eggert, Brian Carpenter, and Yaron Sheffer for performing reviews on the document and providing valuable comments to drive the document forward.
本文件是作者与Bernard Aboba、Thomas Narten、Erik Nordmark和Dave Thaler在IETF 69上讨论的结果。作者要感谢他们清楚地详细说明了解决方案的要求和需要达到的目标，并帮助探索解决方案空间。作者们要感谢《完整DNA规范》的作者和编辑们详细介绍了整个问题空间和解决方案。作者要感谢Jari Arkko推动了简单概率DNA解决方案的发展。作者要感谢Bernard Aboba、Thomas Narten、Jari Arkko、Sathya Narayan、Julien Laganier、Domagoj Premec、Jin Hyeock Choi、Alfred Hoenes、Frederic Rossi、Ralph Droms、Ted Lemon、Erik Nordmark、Lars Eggert、Brian Carpenter、，以及Yaron Sheffer对该文件进行审查，并提供有价值的意见以推动该文件的发展。
[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月。
[RFC3315] Droms, R., 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.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[DNA-PROTOCOL] Narayanan, S., Ed., "Design Alternative for Detecting Network Attachment in IPv6 Networks (DNAv6 Design Alternative)", Work in Progress, November 2009.
[DNA-PROTOCOL]Narayanan，S.，编辑，“IPv6网络中检测网络连接的设计备选方案（DNAv6设计备选方案）”，正在进行的工作，2009年11月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436]Aboba，B.，Carlson，J.，和S.Cheshire，“检测IPv4中的网络连接（DNAv4）”，RFC 44362006年3月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., and A. Yegin, "Link-Layer Event Notifications for Detecting Network Attachments", RFC 4957, August 2007.
[RFC4957]Krishnan，S.，Montavont，N.，Njedjou，E.，Veerepalli，S.，和A.Yegin，“用于检测网络附件的链路层事件通知”，RFC 4957，2007年8月。
Even though DNAv4 [RFC4436] supports verification of manually assigned addresses, this feature of DNAv4 has not been widely implemented or used. There are two major issues that come up with confirming manually assigned addresses using Simple DNA.
尽管DNAv4[RFC4436]支持验证手动分配的地址，但DNAv4的这一功能尚未得到广泛实现或使用。使用简单的DNA确认手动分配的地址有两个主要问题。
o When DHCPv6 or SLAAC addresses are used for probing, there is no need to aggressively retransmit lost probes. This is because the address configuration falls back to vanilla DHCPv6 or SLAAC, and the host will eventually obtain an address. This is not the case with manually assigned addresses. If the probes are lost, the host runs the risk of ending up with no addresses at all. Hence, aggressive retransmissions are necessary.
o 当DHCPv6或SLAAC地址用于探测时，不需要主动重新传输丢失的探测。这是因为地址配置退回到普通的DHCPv6或SLAAC，主机最终将获得一个地址。手动分配地址的情况并非如此。如果探测器丢失，主机将面临最终没有地址的风险。因此，积极的重新传输是必要的。
o Another issue comes up when the host moves between two networks, one where manual addressing is being used (say, NET1) and the other where dynamic addressing (stateless autoconfiguration or DHCPv6) is being used (say, NET2). Since the host can obtain a dynamic address in some situations, it will need to send Simple DNA probes and may also engage in a DHCPv6 exchange. In a situation where the host moves to NET1 and the NS probes are lost and in addition an RA is not received, the host will not be able to confirm that it attached to NET1, and therefore that it should use the manual configuration for that network. As a result, if DHCPv6 is enabled on NET1, then the host could mistakenly obtain a dynamic address and configuration instead of using the manual configuration. To prevent this problem, Simple DNA probing needs to continue even after the DHCPv6 exchange has completed, and DNA probes need to take precedence over DHCPv6, contrary to the advice provided in Section 5.7.3.
o 当主机在两个网络之间移动时，会出现另一个问题，一个网络使用手动寻址（如NET1），另一个网络使用动态寻址（无状态自动配置或DHCPv6）（如NET2）。由于宿主在某些情况下可以获得动态地址，因此它需要发送简单的DNA探针，还可能参与DHCPv6交换。在主机移动到NET1且NS探测器丢失且未收到RA的情况下，主机将无法确认其已连接到NET1，因此应使用该网络的手动配置。因此，如果在NET1上启用了DHCPv6，那么主机可能会错误地获取动态地址和配置，而不是使用手动配置。为防止此问题，即使在DHCPv6交换完成后，也需要继续进行简单的DNA探测，并且与第5.7.3节中提供的建议相反，DNA探测需要优先于DHCPv6。
Given these issues, it is NOT RECOMMENDED to use manual addressing with Simple DNA.
鉴于这些问题，不建议使用简单DNA的手动寻址。
Authors' Addresses
作者地址
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大皇家山镇
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Greg Daley Netstar Logicalis Level 6/616 St Kilda Road Melbourne, Victoria 3004 Australia
澳大利亚维多利亚州墨尔本市圣基尔达路616号6层格雷格·戴利·Netstar Logicalis 3004
Phone: +61 401 772 770
EMail: hoskuld@hotmail.com
Phone: +61 401 772 770
EMail: hoskuld@hotmail.com