Internet Engineering Task Force (IETF) Z. Shelby, Ed.
Request for Comments: 6775 Sensinode
Updates: 4944 S. Chakrabarti
Category: Standards Track Ericsson
ISSN: 2070-1721 E. Nordmark
Cisco Systems
C. Bormann
Universitaet Bremen TZI
November 2012
Internet Engineering Task Force (IETF) Z. Shelby, Ed.
Request for Comments: 6775 Sensinode
Updates: 4944 S. Chakrabarti
Category: Standards Track Ericsson
ISSN: 2070-1721 E. Nordmark
Cisco Systems
C. Bormann
Universitaet Bremen TZI
November 2012
Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
低功耗无线个人区域网（6LoWPANs）上IPv6邻居发现优化
Abstract
摘要
The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non-transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low-power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here.
IETF在低功耗无线个人区域网（6LoWPAN）上的IPv6工作定义了6LoWPAN，如IEEE 802.15.4。由于节能，这种和其他类似的链路技术限制或不使用多播信令。此外，无线网络可能不会严格遵循IP子网和IP链路的传统概念。IPv6邻居发现并不是为不可传输的无线链路而设计的，因为它依赖于传统的IPv6链路概念，并且大量使用多播，这使得它在低功耗和有损网络中效率低下，有时甚至不切实际。本文档描述了对IPv6邻居发现的简单优化、其寻址机制以及低功耗无线个人区域网络和类似网络的重复地址检测。因此，该文档更新了RFC4944，以指定此处定义的优化的使用。
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/rfc6775.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6775.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................4
1.1. The Shortcomings of IPv6 Neighbor Discovery ................5
1.2. Applicability ..............................................6
1.3. Goals and Assumptions ......................................7
1.4. Substitutable Features .....................................8
2. Terminology .....................................................9
3. Protocol Overview ..............................................11
3.1. Extensions to RFC 4861 ....................................11
3.2. Address Assignment ........................................12
3.3. Host-to-Router Interaction ................................13
3.4. Router-to-Router Interaction ..............................14
3.5. Neighbor Cache Management .................................14
4. New Neighbor Discovery Options and Messages ....................15
4.1. Address Registration Option ...............................15
4.2. 6LoWPAN Context Option ....................................17
4.3. Authoritative Border Router Option ........................19
4.4. Duplicate Address Messages ................................20
5. Host Behavior ..................................................22
5.1. Forbidden Actions .........................................22
5.2. Interface Initialization ..................................22
5.3. Sending a Router Solicitation .............................23
5.4. Processing a Router Advertisement .........................23
5.4.1. Address Configuration ..............................23
5.4.2. Storing Contexts ...................................24
5.4.3. Maintaining Prefix and Context Information .........24
5.5. Registration and Neighbor Unreachability Detection ........25
5.5.1. Sending a Neighbor Solicitation ....................25
5.5.2. Processing a Neighbor Advertisement ................25
5.5.3. Recovering from Failures ...........................26
5.6. Next-Hop Determination ....................................26
5.7. Address Resolution ........................................27
1. Introduction ....................................................4
1.1. The Shortcomings of IPv6 Neighbor Discovery ................5
1.2. Applicability ..............................................6
1.3. Goals and Assumptions ......................................7
1.4. Substitutable Features .....................................8
2. Terminology .....................................................9
3. Protocol Overview ..............................................11
3.1. Extensions to RFC 4861 ....................................11
3.2. Address Assignment ........................................12
3.3. Host-to-Router Interaction ................................13
3.4. Router-to-Router Interaction ..............................14
3.5. Neighbor Cache Management .................................14
4. New Neighbor Discovery Options and Messages ....................15
4.1. Address Registration Option ...............................15
4.2. 6LoWPAN Context Option ....................................17
4.3. Authoritative Border Router Option ........................19
4.4. Duplicate Address Messages ................................20
5. Host Behavior ..................................................22
5.1. Forbidden Actions .........................................22
5.2. Interface Initialization ..................................22
5.3. Sending a Router Solicitation .............................23
5.4. Processing a Router Advertisement .........................23
5.4.1. Address Configuration ..............................23
5.4.2. Storing Contexts ...................................24
5.4.3. Maintaining Prefix and Context Information .........24
5.5. Registration and Neighbor Unreachability Detection ........25
5.5.1. Sending a Neighbor Solicitation ....................25
5.5.2. Processing a Neighbor Advertisement ................25
5.5.3. Recovering from Failures ...........................26
5.6. Next-Hop Determination ....................................26
5.7. Address Resolution ........................................27
5.8. Sleeping ..................................................27
5.8.1. Picking an Appropriate Registration Lifetime .......27
5.8.2. Behavior on Wakeup .................................28
6. Router Behavior for 6LRs and 6LBRs .............................28
6.1. Forbidden Actions .........................................28
6.2. Interface Initialization ..................................29
6.3. Processing a Router Solicitation ..........................29
6.4. Periodic Router Advertisements ............................30
6.5. Processing a Neighbor Solicitation ........................30
6.5.1. Checking for Duplicates ............................30
6.5.2. Returning Address Registration Errors ..............31
6.5.3. Updating the Neighbor Cache ........................31
6.5.4. Next-Hop Determination .............................32
6.5.5. Address Resolution between Routers .................32
7. Border Router Behavior .........................................32
7.1. Prefix Determination ......................................33
7.2. Context Configuration and Management ......................33
8. Substitutable Feature Behavior .................................34
8.1. Multihop Prefix and Context Distribution ..................34
8.1.1. 6LBRs Sending Router Advertisements ................35
8.1.2. Routers Sending Router Solicitations ...............35
8.1.3. Routers Processing Router Advertisements ...........35
8.1.4. Storing the Information ............................36
8.1.5. Sending Router Advertisements ......................36
8.2. Multihop Duplicate Address Detection ......................37
8.2.1. Message Validation for DAR and DAC .................38
8.2.2. Conceptual Data Structures .........................39
8.2.3. 6LR Sending a Duplicate Address Request ............39
8.2.4. 6LBR Receiving a Duplicate Address Request .........39
8.2.5. Processing a Duplicate Address Confirmation ........40
8.2.6. Recovering from Failures ...........................40
9. Protocol Constants .............................................41
10. Examples ......................................................42
10.1. Message Examples .........................................42
10.2. Host Bootstrapping Example ...............................43
10.2.1. Host Bootstrapping Messages .......................45
10.3. Router Interaction Example ...............................46
10.3.1. Bootstrapping a Router ............................46
10.3.2. Updating the Neighbor Cache .......................47
11. Security Considerations .......................................47
12. IANA Considerations ...........................................48
13. Interaction with Other Neighbor Discovery Extensions ..........49
14. Guidelines for New Features ...................................49
15. Acknowledgments ...............................................52
16. References ....................................................52
16.1. Normative References .....................................52
16.2. Informative References ...................................53
5.8. Sleeping ..................................................27
5.8.1. Picking an Appropriate Registration Lifetime .......27
5.8.2. Behavior on Wakeup .................................28
6. Router Behavior for 6LRs and 6LBRs .............................28
6.1. Forbidden Actions .........................................28
6.2. Interface Initialization ..................................29
6.3. Processing a Router Solicitation ..........................29
6.4. Periodic Router Advertisements ............................30
6.5. Processing a Neighbor Solicitation ........................30
6.5.1. Checking for Duplicates ............................30
6.5.2. Returning Address Registration Errors ..............31
6.5.3. Updating the Neighbor Cache ........................31
6.5.4. Next-Hop Determination .............................32
6.5.5. Address Resolution between Routers .................32
7. Border Router Behavior .........................................32
7.1. Prefix Determination ......................................33
7.2. Context Configuration and Management ......................33
8. Substitutable Feature Behavior .................................34
8.1. Multihop Prefix and Context Distribution ..................34
8.1.1. 6LBRs Sending Router Advertisements ................35
8.1.2. Routers Sending Router Solicitations ...............35
8.1.3. Routers Processing Router Advertisements ...........35
8.1.4. Storing the Information ............................36
8.1.5. Sending Router Advertisements ......................36
8.2. Multihop Duplicate Address Detection ......................37
8.2.1. Message Validation for DAR and DAC .................38
8.2.2. Conceptual Data Structures .........................39
8.2.3. 6LR Sending a Duplicate Address Request ............39
8.2.4. 6LBR Receiving a Duplicate Address Request .........39
8.2.5. Processing a Duplicate Address Confirmation ........40
8.2.6. Recovering from Failures ...........................40
9. Protocol Constants .............................................41
10. Examples ......................................................42
10.1. Message Examples .........................................42
10.2. Host Bootstrapping Example ...............................43
10.2.1. Host Bootstrapping Messages .......................45
10.3. Router Interaction Example ...............................46
10.3.1. Bootstrapping a Router ............................46
10.3.2. Updating the Neighbor Cache .......................47
11. Security Considerations .......................................47
12. IANA Considerations ...........................................48
13. Interaction with Other Neighbor Discovery Extensions ..........49
14. Guidelines for New Features ...................................49
15. Acknowledgments ...............................................52
16. References ....................................................52
16.1. Normative References .....................................52
16.2. Informative References ...................................53
The IPv6-over-IEEE 802.15.4 [RFC4944] document specifies how IPv6 is carried over an IEEE 802.15.4 network with the help of an adaptation layer that sits between the Media Access Control (MAC) layer and the IP network layer. A link in a Low-power Wireless Personal Area Network (LoWPAN) is characterized as lossy, low-power, low-bit-rate, short-range; with many nodes saving energy with long sleep periods. Multicast as used in IPv6 Neighbor Discovery (ND) [RFC4861] is not desirable in such a wireless low-power and lossy network. Moreover, LoWPAN links are asymmetric and non-transitive in nature. A LoWPAN is potentially composed of a large number of overlapping radio ranges. Although a given radio range has broadcast capabilities, the aggregation of these is a complex Non-Broadcast Multiple Access (NBMA) [RFC2491] structure with generally no LoWPAN-wide multicast capabilities. Link-local scope is in reality defined by reachability and radio strength. Thus, we can consider a LoWPAN to be made up of links with undetermined connectivity properties as in [RFC5889], along with the corresponding address model assumptions defined therein.
IEEE 802.15.4上的IPv6[RFC4944]文档指定了如何借助位于媒体访问控制（MAC）层和IP网络层之间的适配层在IEEE 802.15.4网络上承载IPv6。低功率无线个人区域网（LoWPAN）中的链路具有有损、低功率、低比特率、短距离的特点；多个节点可通过长睡眠时间节省能源。IPv6邻居发现（ND）[RFC4861]中使用的多播在这种无线低功耗和有损网络中是不可取的。此外，低泛链接在本质上是不对称和非传递的。低范围可能由大量重叠的无线电范围组成。尽管给定的无线电范围具有广播能力，但这些能力的集合是一个复杂的非广播多址（NBMA）[RFC2491]结构，通常没有低泛宽多播能力。链路局部范围实际上是由可达性和无线电强度定义的。因此，我们可以考虑由如[RCF589]中具有未确定连通性的链路组成的LoWPAN，以及其中定义的相应的地址模型假设。
This specification introduces the following optimizations to IPv6 Neighbor Discovery [RFC4861] specifically aimed at low-power and lossy networks such as LoWPANs:
本规范对IPv6邻居发现[RFC4861]进行了以下优化，特别针对低功耗和有损网络，如LoWPANs：
o Host-initiated interactions to allow for sleeping hosts.
o 主机启动的交互允许休眠主机。
o Elimination of multicast-based address resolution for hosts.
o 消除主机基于多播的地址解析。
o A host address registration feature using a new option in unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages.
o 在单播邻居请求（NS）和邻居公告（NA）消息中使用新选项的主机地址注册功能。
o A new Neighbor Discovery option to distribute 6LoWPAN header compression context to hosts.
o 一个新的邻居发现选项，用于向主机分发6LoWPAN头压缩上下文。
o Multihop distribution of prefix and 6LoWPAN header compression context.
o 前缀和6LoWPAN头压缩上下文的多跳分布。
o Multihop Duplicate Address Detection (DAD), which uses two new ICMPv6 message types.
o 多跳重复地址检测（DAD），它使用两种新的ICMPv6消息类型。
The two multihop items can be substituted by a routing protocol mechanism if that is desired; see Section 1.4.
如果需要，两个多跳项可以由路由协议机制替代；见第1.4节。
The document defines three new ICMPv6 message options: the Address Registration Option (ARO), the Authoritative Border Router Option (ABRO), and the 6LoWPAN Context Option (6CO). It also defines two new ICMPv6 message types: the Duplicate Address Request (DAR) and the Duplicate Address Confirmation (DAC).
该文档定义了三个新的ICMPv6消息选项：地址注册选项（ARO）、权威边界路由器选项（ABRO）和6LoWPAN上下文选项（6CO）。它还定义了两种新的ICMPv6消息类型：重复地址请求（DAR）和重复地址确认（DAC）。
IPv6 Neighbor Discovery [RFC4861] provides several important mechanisms used for router discovery, address resolution, Duplicate Address Detection, and Redirect messages, along with prefix and parameter discovery.
IPv6邻居发现[RFC4861]提供了几种重要的机制，用于路由器发现、地址解析、重复地址检测和重定向消息，以及前缀和参数发现。
Following power-on and initialization of the network in IPv6 Ethernet networks, a node joins the solicited-node multicast address on the interface and then performs Duplicate Address Detection (DAD) for the acquired link-local address by sending a solicited-node multicast message to the link. After that, it sends multicast messages to the all-routers multicast address to solicit Router Advertisements (RAs). If the host receives a valid RA with the A (autonomous address configuration) flag, it autoconfigures the IPv6 address with the advertised prefix in the RA message. Besides this, the IPv6 routers usually send RAs periodically on the network. RAs are sent to the all-nodes multicast address. Nodes send Neighbor Solicitation/ Neighbor Advertisement messages to resolve the IPv6 address of the destination on the link. The Neighbor Solicitation messages used for address resolution are multicast. The Duplicate Address Detection procedure and the use of periodic Router Advertisement messages assume that the nodes are powered on and reachable most of the time.
在IPv6以太网中的网络通电和初始化之后，节点在接口上加入请求节点多播地址，然后通过向链路发送请求节点多播消息，对获取的链路本地地址执行重复地址检测（DAD）。之后，它向所有路由器的多播地址发送多播消息以请求路由器广告（RAs）。如果主机接收到带有（自治地址配置）标志的有效RA，它将在RA消息中使用播发前缀自动配置IPv6地址。此外，IPv6路由器通常在网络上定期发送RAs。RAs被发送到所有节点的多播地址。节点发送邻居请求/邻居公告消息以解析链路上目标的IPv6地址。用于地址解析的邻居请求消息是多播的。重复地址检测过程和定期路由器广告消息的使用假设节点大部分时间处于通电状态且可访问。
In Neighbor Discovery, the routers find the hosts by assuming that a subnet prefix maps to one broadcast domain, and then they multicast Neighbor Solicitation messages to find the host and its link-layer address. Furthermore, the DAD use of multicast assumes that all hosts that autoconfigure IPv6 addresses from the same prefix can be reached using link-local multicast messages.
在邻居发现中，路由器通过假设子网前缀映射到一个广播域来查找主机，然后它们多播邻居请求消息以查找主机及其链路层地址。此外，多播的DAD使用假设可以使用链路本地多播消息访问从同一前缀自动配置IPv6地址的所有主机。
Note that the L (on-link) bit in the Prefix Information Option (PIO) can be set to zero in Neighbor Discovery, which makes the host not use multicast Neighbor Solicitation (NS) messages for address resolution of other hosts, but routers still use multicast NS messages to find the hosts.
请注意，在邻居发现中，前缀信息选项（PIO）中的L（链路上）位可以设置为零，这使得主机不使用多播邻居请求（NS）消息来解析其他主机的地址，但路由器仍然使用多播NS消息来查找主机。
Due to the lossy nature of wireless communication and a changing radio environment, the IPv6-link node-set may change due to external physical factors. Thus, the link is often unstable, and the nodes appear to be moving without necessarily moving physically.
由于无线通信的有损性质和不断变化的无线电环境，IPv6链路节点集可能会由于外部物理因素而发生变化。因此，链路通常是不稳定的，节点似乎在移动，而不一定在物理上移动。
A LoWPAN can use two types of link-layer addresses: 16-bit short addresses and 64-bit unique addresses as defined in [RFC4944]. Moreover, the available link-layer payload size is on the order of less than 100 bytes; thus, header compression is very useful.
LoWPAN可以使用两种类型的链路层地址：16位短地址和[RFC4944]中定义的64位唯一地址。此外，可用链路层有效负载大小大约小于100字节；因此，报头压缩非常有用。
Considering the above characteristics in a LoWPAN, and the IPv6 Neighbor Discovery [RFC4861] protocol design, some optimizations and extensions to Neighbor Discovery are useful for the wide deployment of IPv6 over low-power and lossy networks (example: 6LoWPAN and other homogeneous low-power networks).
考虑到LoWPAN中的上述特征以及IPv6邻居发现[RFC4861]协议设计，对邻居发现的一些优化和扩展有助于在低功耗和有损网络（例如：6LoWPAN和其他同构低功耗网络）上广泛部署IPv6。
In its Section 1, [RFC4861] foresees a document that covers operating IP over a particular link type and defines an exception to the otherwise general applicability of unmodified [RFC4861]. The present specification improves the usage of IPv6 Neighbor Discovery for LoWPANs in order to save energy and processing power of such nodes. This document thus updates [RFC4944] to specify the use of the optimizations defined here.
在其第1节中，[RFC4861]预见了一份涵盖特定链路类型上的操作IP的文件，并定义了未经修改的[RFC4861]的一般适用性的例外情况。本规范改进了IPv6邻居发现在LoWPANs中的使用，以节省此类节点的能量和处理能力。因此，本文档更新了[RFC4944]，以指定此处定义的优化的使用。
The applicability of this specification is limited to LoWPANs where all nodes on the subnet implement these optimizations in a homogeneous way. Although it is noted that some of these optimizations may be useful outside of 6LoWPANs, for example, in general IPv6 low-power and lossy networks and possibly even in combination with [RFC4861], the usage of such combinations is out of scope of this document.
本规范的适用范围仅限于低端，其中子网上的所有节点都以同构方式实现这些优化。尽管需要注意的是，其中一些优化可能在6LoWPANs之外有用，例如，在一般IPv6低功耗和有损网络中，甚至可能与[RFC4861]结合使用，但此类组合的使用超出了本文档的范围。
In this document, we specify a set of behaviors between hosts and routers in LoWPANs. An implementation that adheres to this document MUST implement those behaviors. The document also specifies a set of behaviors (multihop prefix or context dissemination and, separately, multihop Duplicate Address Detection) that are needed in route-over configurations. An implementation of this specification MUST support those pieces, unless the implementation supports some alternative ("substitute") from some other specification.
在本文中，我们在LoWPANs中指定主机和路由器之间的一组行为。遵循本文档的实现必须实现这些行为。该文档还指定了路由覆盖配置中需要的一组行为（多跳前缀或上下文传播，以及单独的多跳重复地址检测）。本规范的实现必须支持这些部分，除非该实现支持其他规范中的某些替代（“替代”）。
The optimizations described in this document apply to different topologies. They are most useful for route-over and mesh-under configurations in Mesh topologies. However, Star topology configurations will also benefit from the optimizations due to reduced signaling, robust handling of the non-transitive link, and header compression context information.
本文档中描述的优化适用于不同的拓扑。它们对于网格拓扑中的“在网格上布线”和“在网格下布线”配置最为有用。然而，星形拓扑配置也将受益于优化，因为减少了信令、对非传递链路的健壮处理以及报头压缩上下文信息。
The document has the following main goals and assumptions.
该文件有以下主要目标和假设。
Goals:
目标：
o Optimize Neighbor Discovery with a mechanism that is minimal yet sufficient for the operation in both mesh-under and route-over configurations.
o 使用一种机制优化邻居发现，该机制最小，但足以在网格下和路由上配置中进行操作。
o Minimize signaling by avoiding the use of multicast flooding and reducing the use of link-scope multicast messages.
o 通过避免使用多播泛洪和减少链路范围多播消息的使用来最小化信令。
o Optimize the interfaces between hosts and their default routers.
o 优化主机及其默认路由器之间的接口。
o Provide support for sleeping hosts.
o 为休眠主机提供支持。
o Disseminate context information to hosts as needed by 6LoWPAN header compression [RFC6282].
o 根据6LoWPAN标头压缩[RFC6282]的需要向主机分发上下文信息。
o Disseminate context information and prefix information from the border to all routers in a LoWPAN.
o 将上下文信息和前缀信息从边界传播到低范围内的所有路由器。
o Provide a multihop Duplicate Address Detection mechanism suitable for route-over LoWPANs.
o 提供适用于LoWPANs上路由的多跳重复地址检测机制。
Assumptions:
假设：
o 64-bit Extended Unique Identifier (EUI-64) [EUI64] addresses are globally unique, and the LoWPAN is homogeneous.
o 64位扩展唯一标识符（EUI-64）[EUI64]地址是全局唯一的，并且LoWPAN是同构的。
o All nodes in the network have an EUI-64 Interface ID in order to do address autoconfiguration and detect duplicate addresses.
o 网络中的所有节点都有一个EUI-64接口ID，以便进行地址自动配置和检测重复地址。
o The link-layer technology is assumed to be low-power and lossy, exhibiting undetermined connectivity, such as IEEE 802.15.4 [RFC4944]. However, the address registration mechanism might be useful for other link-layer technologies.
o 链路层技术被认为是低功耗和有损的，表现出不确定的连接性，如IEEE 802.15.4[RFC4944]。然而，地址注册机制可能对其他链路层技术有用。
o A 6LoWPAN is configured to share one or more global IPv6 address prefixes to enable hosts to move between routers in the LoWPAN without changing their IPv6 addresses.
o 6LoWPAN配置为共享一个或多个全局IPv6地址前缀，以使主机能够在LoWPAN中的路由器之间移动，而无需更改其IPv6地址。
o When using the multihop DAD mechanism (Section 8.2), each 6LoWPAN Router (6LR) registers with all the 6LoWPAN Border Routers (6LBRs) available in the LoWPAN.
o 使用多跳DAD机制（第8.2节）时，每个6LoWPAN路由器（6LR）向LoWPAN中可用的所有6LoWPAN边界路由器（6LBR）注册。
o If IEEE 802.15.4 16-bit short addresses are used, then some technique is used to ensure the uniqueness of those link-layer addresses. That could be done using DHCPv6, Address Registration Option-based Duplicate Address Detection (specified in Section 8.2), or other techniques outside of the scope of this document.
o 如果使用IEEE 802.15.4 16位短地址，则使用某种技术来确保这些链路层地址的唯一性。这可以使用DHCPv6、基于地址注册选项的重复地址检测（在第8.2节中指定）或本文档范围之外的其他技术来实现。
o In order to preserve the uniqueness of addresses (see Section 5.4 of [RFC4862]) not derived from an EUI-64, they must be either assigned or checked for duplicates in the same way throughout the LoWPAN. This can be done using DHCPv6 for assignment and/or using the Duplicate Address Detection mechanism specified in Section 8.2 (or any other protocols developed for that purpose).
o 为了保持并非源自EUI-64的地址（见[RFC4862]第5.4节）的唯一性，必须在整个LoWPAN中以相同的方式分配或检查重复地址。这可以使用DHCPv6进行分配和/或使用第8.2节中规定的重复地址检测机制（或为此目的开发的任何其他协议）来完成。
o In order for 6LoWPAN header compression [RFC6282] to operate correctly, the compression context must match for all the hosts, 6LRs, and 6LBRs that can send, receive, or forward a given packet. If Section 8.1 is used to distribute context information, this implies that all the 6LBRs must coordinate the context information they distribute within a single LoWPAN.
o 为了使6LoWPAN报头压缩[RFC6282]正常工作，压缩上下文必须与所有能够发送、接收或转发给定数据包的主机、6LRs和6LBR匹配。如果第8.1节用于分发上下文信息，这意味着所有6LBR必须在单个LoWPAN内协调其分发的上下文信息。
o This specification describes the operation of ND within a single LoWPAN. The participation of a node in multiple LoWPANs simultaneously may be possible but is out of scope of this document.
o 本规范描述了ND在单个低量程内的操作。一个节点同时参与多个LoWPANs是可能的，但不在本文档的范围内。
o Since the LoWPAN shares its prefix(es) throughout the network, mobility of nodes within the LoWPAN is transparent. Inter-LoWPAN mobility is out of scope of this document.
o 由于LoWPAN在整个网络中共享其前缀，因此LoWPAN内节点的移动性是透明的。LoWPAN间的流动性不在本文件的范围内。
This document defines the optimization of Neighbor Discovery messages for the host-router interface and introduces two new mechanisms in a route-over topology.
本文档定义了主机路由器接口邻居发现消息的优化，并介绍了路由拓扑中的两种新机制。
Unless specified otherwise (in a document that defines a routing protocol that is used in a 6LoWPAN), this document applies to networks with any routing protocol. However, because the routing protocol may provide good alternate mechanisms, this document defines certain features as "substitutable", meaning they can be substituted by a routing protocol specification that provides mechanisms achieving the same overall effect.
除非另有规定（在定义6LoWPAN中使用的路由协议的文档中），否则本文档适用于具有任何路由协议的网络。然而，由于路由协议可能提供良好的替代机制，本文档将某些功能定义为“可替代”，这意味着它们可以被提供实现相同总体效果的机制的路由协议规范所替代。
The features that are substitutable (individually or in a group):
可替代的特征（单独或成组）：
o Multihop distribution of prefix and 6LoWPAN header compression context
o 前缀和6LoWPAN头压缩上下文的多跳分布
o Multihop Duplicate Address Detection
o 多跳重复地址检测
Thus, multihop prefix distribution (the ABRO) and the 6LoWPAN Context Option (6CO) for distributing header compression contexts go hand in hand. If substitution is intended for one of them, then both of them MUST be substituted.
因此，用于分发报头压缩上下文的多跳前缀分发（ABRO）和6LoWPAN上下文选项（6CO）是齐头并进的。如果要替换其中一个，则必须同时替换两个。
Guidelines for feature implementation and deployment are provided in Section 14.
第14节提供了功能实现和部署指南。
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]中所述进行解释。
This specification requires readers to be familiar with all the terms and concepts that are discussed in "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919], "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944], and "IP Addressing Model in Ad Hoc Networks" [RFC5889].
本规范要求读者熟悉“针对IP版本6（IPv6）的邻居发现”[RFC4861]、“IPv6无状态地址自动配置”[RFC4862]、“低功耗无线个人区域网络（6LoWPANs）上的IPv6:概述、假设、问题陈述和目标”[RFC4919]中讨论的所有术语和概念，“通过IEEE 802.15.4网络传输IPv6数据包”[RFC4944]和“自组织网络中的IP寻址模型”[RFC5889]。
This specification makes extensive use of the same terminology defined in [RFC4861], unless otherwise defined below.
本规范广泛使用了[RFC4861]中定义的相同术语，除非下文另有定义。
6LoWPAN link: A wireless link determined by single IP hop reachability of neighboring nodes. These are considered links with undetermined connectivity properties as in [RFC5889].
6LoWPAN链路：由相邻节点的单个IP跳可达性确定的无线链路。这些链路被视为具有[RFC5889]中未确定的连接属性的链路。
6LoWPAN Node (6LN): A 6LoWPAN node is any host or router participating in a LoWPAN. This term is used when referring to situations in which either a host or router can play the role described.
6LoWPAN节点（6LN）：6LoWPAN节点是参与LoWPAN的任何主机或路由器。此术语用于指主机或路由器可以扮演所述角色的情况。
6LoWPAN Router (6LR): An intermediate router in the LoWPAN that is able to send and receive Router Advertisements (RAs) and Router Solicitations (RSs) as well as forward and route IPv6 packets. 6LoWPAN routers are present only in route-over topologies.
6LoWPAN路由器（6LR）：LoWPAN中的中间路由器，能够发送和接收路由器广告（RAs）和路由器请求（RSs），以及转发和路由IPv6数据包。6LoWPAN路由器仅存在于路由拓扑中。
6LoWPAN Border Router (6LBR): A border router located at the junction of separate 6LoWPAN networks or between a 6LoWPAN network and another IP network. There may be one or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the responsible authority for IPv6 prefix propagation for the 6LoWPAN network it is serving. An isolated LoWPAN also contains a 6LBR in the network, which provides the prefix(es) for the isolated network.
6LoWPAN边界路由器（6LBR）：位于独立6LoWPAN网络连接处或6LoWPAN网络与另一IP网络之间的边界路由器。6LoWPAN网络边界处可能有一个或多个6LBR。6LBR是其所服务的6LoWPAN网络IPv6前缀传播的负责机构。隔离LoWPAN在网络中还包含一个6LBR，它为隔离网络提供前缀（es）。
Router: Either a 6LR or a 6LBR. Note that nothing in this document precludes a node being a router on some interfaces and a host on other interfaces as allowed by [RFC2460].
路由器：6LR或6LBR。注意，本文档中的任何内容都不排除[RFC2460]允许的节点在某些接口上是路由器，在其他接口上是主机。
Mesh-under: A topology where nodes are connected to a 6LBR through a mesh using link-layer forwarding. Thus, in a mesh-under configuration, all IPv6 hosts in a LoWPAN are only one IP hop away from the 6LBR. This topology simulates the typical IP-subnet topology with one router with multiple nodes in the same subnet.
下网格：一种拓扑，其中节点通过使用链路层转发的网格连接到6LBR。因此，在配置下的网状网中，低范围内的所有IPv6主机距离6LBR只有一个IP跃点。此拓扑模拟典型的IP子网拓扑，其中一个路由器在同一子网中有多个节点。
Route-over: A topology where hosts are connected to the 6LBR through the use of intermediate layer-3 (IP) routing. Here, hosts are typically multiple IP hops away from a 6LBR. The route-over topology typically consists of a 6LBR, a set of 6LRs, and hosts.
Route over：主机通过使用中间层3（IP）路由连接到6LBR的拓扑。这里，主机通常是距离6LBR的多个IP跃点。拓扑上的路由通常由一个6LBR、一组6LR和主机组成。
Non-transitive link: A link that exhibits asymmetric reachability as defined in Section 2.2 of [RFC4861].
非传递链路：如[RFC4861]第2.2节所定义，具有不对称可达性的链路。
IP-over-foo document: A specification that covers operating IP over a particular link type, for example, [RFC4944] "Transmission of IPv6 Packets over IEEE 802.15.4 Networks".
IP over foo文档：一种规范，涵盖在特定链路类型上操作IP，例如，[RFC4944]“通过IEEE 802.15.4网络传输IPv6数据包”。
Header compression context: Address information shared across a LoWPAN and used by 6LoWPAN header compression [RFC6282] to enable the elision of information that would otherwise be sent repeatedly. In a "context", a (potentially partial) address is associated with a Context Identifier (CID), which is then used in header compression as a shortcut for (parts of) a source or destination address.
Header compression context：在LoWPAN上共享的地址信息，由6LoWPAN Header compression[RFC6282]使用，以避免重复发送的信息。在“上下文”中，一个（可能是部分的）地址与一个上下文标识符（CID）相关联，然后在报头压缩中使用该标识符作为源地址或目标地址（部分）的快捷方式。
Registration: The process during which a LoWPAN node sends a Neighbor Solicitation message with an Address Registration Option to a router creating a Neighbor Cache Entry (NCE) for the LoWPAN node with a specific timeout. Thus, for 6LoWPAN routers, the Neighbor Cache doesn't behave like a cache. Instead, it behaves as a registry of all the host addresses that are attached to the router.
注册：LoWPAN节点向路由器发送带有地址注册选项的邻居请求消息的过程，路由器为LoWPAN节点创建具有特定超时的邻居缓存条目（NCE）。因此，对于6LoWPAN路由器，邻居缓存的行为不像缓存。相反，它充当连接到路由器的所有主机地址的注册表。
These Neighbor Discovery optimizations are applicable to both mesh-under and route-over configurations. In a mesh-under configuration, only 6LoWPAN Border Routers and hosts exist; there are no 6LoWPAN routers in mesh-under topologies.
这些邻居发现优化既适用于网格下配置，也适用于路由上配置。在配置下的mesh中，仅存在6LoWPAN边界路由器和主机；网状拓扑下没有6LoWPAN路由器。
The most important part of the optimizations is the evolved host-to-router interaction that allows for sleeping nodes and avoids using multicast Neighbor Discovery messages except for the case of a host finding an initial set of default routers, and redoing such determination when that set of routers have become unreachable.
优化最重要的部分是演化的主机到路由器交互，该交互允许休眠节点，并避免使用多播邻居发现消息，除非主机找到一组初始默认路由器，并在无法访问该组路由器时重新进行此类确定。
The protocol also provides for header compression [RFC6282] by carrying header compression information in a new option in Router Advertisement messages.
该协议还通过在路由器广告消息的新选项中携带报头压缩信息来提供报头压缩[RFC6282]。
In addition, there are separate mechanisms that can be used between 6LRs and 6LBRs to perform multihop Duplicate Address Detection and distribution of the prefix and compression context information from the 6LBRs to all the 6LRs, which in turn use normal Neighbor Discovery mechanisms to convey this information to the hosts.
此外，在6LRs和6LBRs之间可以使用单独的机制来执行多跳重复地址检测，并将前缀和压缩上下文信息从6LBRs分发到所有6LRs，而所有6LRs又使用正常的邻居发现机制将此信息传送到主机。
The protocol is designed so that the host-to-router interaction is not affected by the configuration of the 6LoWPAN; the host-to-router interaction is the same in a mesh-under and route-over configuration.
该协议的设计使主机到路由器的交互不受6LoWPAN配置的影响；主机到路由器的交互在网状结构下和路由上的配置中是相同的。
This document specifies the following optimizations and extensions to IPv6 Neighbor Discovery [RFC4861]:
本文档指定了IPv6邻居发现[RFC4861]的以下优化和扩展：
o Host-initiated refresh of Router Advertisement information. This removes the need for periodic or unsolicited Router Advertisements from routers to hosts.
o 主机启动的路由器播发信息刷新。这消除了从路由器到主机的定期或未经请求的路由器广告的需要。
o No Duplicate Address Detection (DAD) is performed if EUI-64-based IPv6 addresses are used (as these addresses are assumed to be globally unique).
o 如果使用基于EUI-64的IPv6地址，则不会执行重复地址检测（DAD）（因为假定这些地址是全局唯一的）。
o DAD is optional if DHCPv6 is used to assign addresses.
o 如果使用DHCPv6分配地址，则DAD是可选的。
o A new address registration mechanism using a new Address Registration Option between hosts and routers. This removes the need for routers to use multicast Neighbor Solicitations to find hosts and supports sleeping hosts. This also enables the same IPv6 address prefix(es) to be used across a route-over 6LoWPAN. It provides the host-to-router interface for Duplicate Address Detection.
o 在主机和路由器之间使用新地址注册选项的新地址注册机制。这消除了路由器使用多播邻居请求来查找主机的需要，并支持休眠主机。这还允许在6LoWPAN上的路由上使用相同的IPv6地址前缀。它为重复地址检测提供主机到路由器接口。
o A new Router Advertisement option, the 6LoWPAN Context Option, for context information used by 6LoWPAN header compression.
o 一个新的路由器广告选项，6LoWPAN上下文选项，用于6LoWPAN头压缩使用的上下文信息。
o A new mechanism to perform Duplicate Address Detection across a route-over 6LoWPAN using the new Duplicate Address Request and Duplicate Address Confirmation messages.
o 使用新的重复地址请求和重复地址确认消息，通过6LoWPAN跨路由执行重复地址检测的新机制。
o New mechanisms to distribute prefixes and context information across a route-over network that uses a new Authoritative Border Router Option to control the flooding of configuration changes.
o 通过网络在路由上分发前缀和上下文信息的新机制，使用新的权威边界路由器选项控制配置更改的泛滥。
o A few new default protocol constants are introduced, and some existing Neighbor Discovery protocol constants are tuned.
o 引入了一些新的默认协议常数，并对一些现有的邻居发现协议常数进行了调整。
Hosts in a 6LoWPAN configure their IPv6 addresses as specified in [RFC4861] and [RFC4862] based on the information received in Router Advertisement messages. The use of the M (managed address configuration) flag in this optimization is, however, more restrictive than in [RFC4861]. When the M flag is set, a host is assumed to use DHCPv6 to assign any non-EUI-64 addresses. When the M flag is not set, the nodes in the LoWPAN support Duplicate Address Detection; thus, a host can then safely use the address registration mechanism to check non-EUI-64 addresses for uniqueness.
6LoWPAN中的主机根据路由器公告消息中接收到的信息，按照[RFC4861]和[RFC4862]中的规定配置其IPv6地址。然而，与[RFC4861]相比，在该优化中使用M（托管地址配置）标志更具限制性。设置M标志时，假定主机使用DHCPv6分配任何非EUI-64地址。当未设置M标志时，LoWPAN中的节点支持重复地址检测；因此，主机可以安全地使用地址注册机制来检查非EUI-64地址的唯一性。
6LRs MAY use the same mechanisms to configure their IPv6 addresses.
6LR可以使用相同的机制来配置其IPv6地址。
The 6LBRs are responsible for managing the prefix(es) assigned to the 6LoWPAN, using manual configuration, DHCPv6 Prefix Delegation [RFC3633], or other mechanisms. In an isolated LoWPAN, a Unique Local Address (ULA) [RFC4193] prefix SHOULD be generated by the 6LBR.
6LBRs负责使用手动配置、DHCPv6前缀委派[RFC3633]或其他机制管理分配给6LoWPAN的前缀。在隔离的低电平范围内，6LBR应生成唯一的本地地址（ULA）[RFC4193]前缀。
A host sends Router Solicitation messages at startup and also when the Neighbor Unreachability Detection (NUD) of one of its default routers fails.
主机在启动时以及在其默认路由器之一的邻居不可访问性检测（NUD）失败时发送路由器请求消息。
Hosts receive Router Advertisement messages typically containing the Authoritative Border Router Option (ABRO) and may optionally contain one or more 6LoWPAN Context Options (6COs) in addition to the existing Prefix Information Options (PIOs) as described in [RFC4861].
主机接收通常包含权威边界路由器选项（ABRO）的路由器广告消息，并且除了[RFC4861]中描述的现有前缀信息选项（PIO）之外，还可以选择包含一个或多个6LoWPAN上下文选项（6COs）。
When a host has configured a non-link-local IPv6 address, it registers that address with one or more of its default routers using the Address Registration Option (ARO) in an NS message. The host chooses a lifetime of the registration and repeats the ARO periodically (before the lifetime runs out) to maintain the registration. The lifetime should be chosen in such a way as to maintain the registration even while a host is sleeping. Likewise, mobile nodes that often change their point of attachment should use a suitably short lifetime. See Section 5.5 for registration details and Section 9 for protocol constants.
当主机配置了非链路本地IPv6地址时，它会使用NS消息中的地址注册选项（ARO）向其一个或多个默认路由器注册该地址。主机选择注册的生存期，并定期（在生存期结束之前）重复ARO以维护注册。选择生存期时，应确保即使在主机睡眠时也能保持注册。同样，经常改变其连接点的移动节点应该使用适当短的生存期。注册详情见第5.5节，协议常数见第9节。
The registration fails when an ARO is returned to the host with a non-zero Status. One reason may be that the router determines that the IPv6 address is already used by another host, i.e., is used by a host with a different EUI-64. This can be used to support non-EUI-64-based addresses such as temporary IPv6 addresses [RFC4941] or addresses based on an Interface ID that is an IEEE 802.15.4 16-bit short address. Failure can also occur if the Neighbor Cache on that router is full.
当ARO以非零状态返回主机时，注册失败。一个原因可能是路由器确定IPv6地址已经被另一个主机使用，即被具有不同EUI-64的主机使用。这可用于支持非基于EUI-64的地址，例如临时IPv6地址[RFC4941]或基于作为IEEE 802.15.4 16位短地址的接口ID的地址。如果路由器上的邻居缓存已满，也可能发生故障。
The re-registration of an address can be combined with Neighbor Unreachability Detection (NUD) of the router, since both use unicast Neighbor Solicitation messages. This makes things efficient when a host wakes up to send a packet and needs to both perform NUD to check that the router is still reachable and refresh its registration with the router.
地址的重新注册可以与路由器的邻居不可达性检测（NUD）相结合，因为两者都使用单播邻居请求消息。当主机醒来发送数据包时，需要执行NUD以检查路由器是否仍然可以访问，并刷新其与路由器的注册时，这将提高效率。
The response to an address registration might not be immediate, since in route-over configurations the 6LR might perform Duplicate Address Detection against the 6LBR. A host retransmits the Address Registration Option until it is acknowledged by the receipt of an Address Registration Option.
对地址注册的响应可能不会立即生效，因为在路由切换配置中，6LR可能会对6LBR执行重复地址检测。主机重新传输地址注册选项，直到收到地址注册选项确认。
As part of the optimizations, address resolution is not performed by multicasting Neighbor Solicitation messages as in [RFC4861]. Instead, the routers maintain Neighbor Cache Entries for all registered IPv6 addresses. If the address is not in the Neighbor
作为优化的一部分，地址解析并不像[RFC4861]中那样通过多播邻居请求消息来执行。相反，路由器为所有注册的IPv6地址维护邻居缓存条目。如果地址不在邻居中
Cache in the router, then the address either doesn't exist, is assigned to a host attached to some other router in the 6LoWPAN, or is external to the 6LoWPAN. In a route-over configuration, the routing protocol is used to route such packets toward the destination.
缓存在路由器中，则地址要么不存在，要么分配给连接到6LoWPAN中其他路由器的主机，要么在6LoWPAN外部。在路由覆盖配置中，路由协议用于将此类数据包路由到目的地。
The new router-to-router interaction is only for the route-over configuration where 6LRs are present. See also Section 1.4.
新的路由器到路由器交互仅适用于存在6LR的route over配置。另见第1.4节。
6LRs MUST act like a host during system startup and prefix configuration by sending Router Solicitation messages and autoconfiguring their IPv6 addresses, unlike routers in [RFC4861].
与[RFC4861]中的路由器不同，6LRs必须在系统启动和前缀配置期间充当主机，发送路由器请求消息并自动配置其IPv6地址。
When multihop prefix and context dissemination are used, then the 6LRs store the ABRO, 6CO, and prefix information received (directly or indirectly) from the 6LBRs and redistribute this information in the Router Advertisement they send to other 6LRs or send to hosts in response to a Router Solicitation. There is a Version Number field in the ABRO (see Section 4.3), which is used to limit the flooding of updated information between the 6LRs.
当使用多跳前缀和上下文传播时，6LR存储（直接或间接）从6LBRs接收的ABRO、6CO和前缀信息，并在发送给其他6LR或发送给主机以响应路由器请求的路由器广告中重新分发该信息。ABRO中有一个版本号字段（见第4.3节），用于限制6LR之间更新信息的泛滥。
A 6LR can perform Duplicate Address Detection against one or more 6LBRs using the new Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC) messages, which carry the information from the Address Registration Option. The DAR and DAC messages will be forwarded between the 6LR and 6LBRs; thus, the [RFC4861] rule for checking hop limit=255 does not apply to the DAR and DAC messages. Those multihop DAD messages MUST NOT modify any Neighbor Cache Entries on the routers, since we do not have the security benefits provided by the hop limit=255 check.
6LR可以使用新的重复地址请求（DAR）和重复地址确认（DAC）消息对一个或多个6LBR执行重复地址检测，这些消息携带地址注册选项中的信息。DAR和DAC消息将在6LR和6LBRs之间转发；因此，用于检查跃点限制=255的[RFC4861]规则不适用于DAR和DAC消息。这些多跳DAD消息不能修改路由器上的任何邻居缓存项，因为我们没有hop limit=255检查提供的安全优势。
The use of explicit registrations with lifetimes, plus the desire to not multicast Neighbor Solicitation messages for hosts, imply that we manage the Neighbor Cache Entries (NCEs) slightly differently than in [RFC4861]. This results in three different types of NCEs, and the types specify how those entries can be removed:
使用生命周期的显式注册，加上不希望为主机多播邻居请求消息，意味着我们对邻居缓存项（NCE）的管理与[RFC4861]中略有不同。这将导致三种不同类型的NCE，这些类型指定如何删除这些条目：
Garbage-collectible: Entries that are subject to the normal rules in [RFC4861] that allow for garbage collection when low on memory.
垃圾回收：受[RFC4861]中正常规则约束的条目，允许在内存不足时进行垃圾回收。
Registered: Entries that have an explicit registered lifetime and are kept until this lifetime expires or they are explicitly unregistered.
已注册：具有显式注册生存期并保留到该生存期到期或显式取消注册的条目。
Tentative: Entries that are temporary with a short lifetime, which typically get converted to Registered entries.
暂定项：具有短生存期的临时项，通常会转换为已注册项。
Note that the type of the NCE is orthogonal to the states specified in [RFC4861].
注意，NCE的类型与[RFC4861]中规定的状态正交。
When a host interacts with a router by sending Router Solicitations, this results in a Tentative NCE. Once a router has successfully had a node register with it, the result is a Registered NCE. When routers send RAs to hosts, and when routers receive RA messages or receive multicast NS messages from other routers, the result is Garbage-collectible NCEs. There can only be one kind of NCE for an IP address at a time.
当主机通过发送路由器请求与路由器进行交互时，这将导致一个暂时的异常。一旦路由器成功注册了一个节点，结果就是注册了一个NCE。当路由器向主机发送RAs时，当路由器从其他路由器接收RA消息或多播NS消息时，结果是垃圾回收。IP地址一次只能有一种NCE。
Neighbor Cache Entries on routers can additionally be added or deleted by a routing protocol used in the 6LoWPAN. This is useful if the routing protocol carries the link-layer addresses of the neighboring routers. Depending on the details of such routing protocols, such NCEs could be either Registered or Garbage-collectible.
路由器上的邻居缓存项还可以通过6LoWPAN中使用的路由协议添加或删除。如果路由协议携带相邻路由器的链路层地址，则这是有用的。根据这些路由协议的细节，这些NCE可以是注册的，也可以是垃圾回收的。
This section defines new Neighbor Discovery message options used by this specification. The Address Registration Option is used by hosts, whereas the Authoritative Border Router Option and 6LoWPAN Context Option are used in the substitutable router-to-router interaction. This section also defines the new router-to-router Duplicate Address Request and Duplicate Address Confirmation messages.
本节定义了本规范使用的新邻居发现消息选项。地址注册选项由主机使用，而权威边界路由器选项和6LoWPAN上下文选项用于可替代的路由器到路由器的交互。本节还定义了新的路由器到路由器重复地址请求和重复地址确认消息。
The routers need to know the set of host IP addresses that are directly reachable and their corresponding link-layer addresses. This needs to be maintained as the radio reachability changes. For this purpose, an Address Registration Option (ARO) is introduced, which can be included in unicast NS messages sent by hosts. Thus, it can be included in the unicast NS messages that a host sends as part of NUD to determine that it can still reach a default router. The ARO is used by the receiving router to reliably maintain its Neighbor Cache. The same option is included in corresponding NA messages with a Status field indicating the success or failure of the registration. This option is always host initiated.
路由器需要知道可直接访问的主机IP地址集及其相应的链路层地址。这需要随着无线电可达性的变化而保持。为此，引入了地址注册选项（ARO），它可以包含在主机发送的单播NS消息中。因此，它可以包括在主机作为NUD的一部分发送的单播NS消息中，以确定它仍然可以到达默认路由器。接收路由器使用ARO可靠地维护其邻居缓存。相同的选项包含在相应的NA消息中，状态字段指示注册的成功或失败。此选项始终由主机启动。
The information contained in the ARO is also included in the multihop DAR and DAC messages used between 6LRs and 6LBRs, but the option itself is not used in those messages.
ARO中包含的信息也包含在6LRs和6LBRs之间使用的多跳DAR和DAC消息中，但这些消息中不使用选项本身。
The ARO is required for reliability and power saving. The lifetime field provides flexibility to the host to register an address that should be usable (continue to be advertised by the 6LR in the routing protocol, etc.) during its intended sleep schedule.
ARO是可靠性和节能所必需的。lifetime字段为主机提供了灵活性，可以注册一个在其预定睡眠计划期间应该可用的地址（继续由6LR在路由协议中公布，等等）。
The sender of the NS also includes the EUI-64 [EUI64] of the interface from which it is registering an address. This is used as a unique ID for the detection of duplicate addresses. It is used to tell the difference between the same node re-registering its address and a different node (with a different EUI-64) registering an address that is already in use by someone else. The EUI-64 is also used to deliver an NA carrying an error Status code to the EUI-64-based link-local IPv6 address of the host (see Section 6.5.2).
NS的发送方还包括其从中注册地址的接口的EUI-64[EUI64]。它用作检测重复地址的唯一ID。它用于区分重新注册其地址的同一节点与注册已被其他人使用的地址的不同节点（具有不同的EUI-64）之间的差异。EUI-64还用于将带有错误状态代码的NA传送到主机的基于EUI-64的链路本地IPv6地址（见第6.5.2节）。
When the ARO is used by hosts, an SLLAO (Source Link-Layer Address Option) [RFC4861] MUST be included, and the address that is to be registered MUST be the IPv6 source address of the NS message.
当主机使用ARO时，必须包括SLLAO（源链路层地址选项）[RFC4861]，并且要注册的地址必须是NS消息的IPv6源地址。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EUI-64 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EUI-64 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Type: 33
类型：33
Length: 8-bit unsigned integer. The length of the option in units of 8 bytes. Always 2.
长度：8位无符号整数。选项的长度，以8字节为单位。总是2。
Status: 8-bit unsigned integer. Indicates the status of a registration in the NA response. MUST be set to 0 in NS messages. See below.
状态：8位无符号整数。指示NA响应中注册的状态。在NS消息中必须设置为0。见下文。
Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留：此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Registration Lifetime: 16-bit unsigned integer. The amount of time in units of 60 seconds that the router should retain the NCE for the sender of the NS that includes this option.
注册生存期：16位无符号整数。路由器应为包含此选项的NS的发送方保留NCE的时间量（以60秒为单位）。
EUI-64: 64 bits. This field is used to uniquely identify the interface of the Registered Address by including the EUI-64 identifier [EUI64] assigned to it unmodified.
EUI-64:64位。此字段用于通过包含未修改分配给注册地址的EUI-64标识符[EUI64]，唯一标识注册地址的接口。
The Status values used in NAs are:
NAs中使用的状态值为：
+--------+--------------------------------------------+
| Status | Description |
+--------+--------------------------------------------+
| 0 | Success |
| 1 | Duplicate Address |
| 2 | Neighbor Cache Full |
| 3-255 | Allocated using Standards Action [RFC5226] |
+--------+--------------------------------------------+
+--------+--------------------------------------------+
| Status | Description |
+--------+--------------------------------------------+
| 0 | Success |
| 1 | Duplicate Address |
| 2 | Neighbor Cache Full |
| 3-255 | Allocated using Standards Action [RFC5226] |
+--------+--------------------------------------------+
Table 1
表1
The 6LoWPAN Context Option (6CO) carries prefix information for LoWPAN header compression and is similar to the PIO of [RFC4861]. However, the prefixes can be remote as well as local to the LoWPAN, since header compression potentially applies to all IPv6 addresses. This option allows for the dissemination of multiple contexts identified by a CID for use as specified in [RFC6282]. A context may be a prefix of any length or an address (/128), and up to 16 6COs may be carried in an RA message.
6LoWPAN上下文选项（6CO）携带用于LoWPAN报头压缩的前缀信息，类似于[RFC4861]的PIO。然而，前缀可以是远程的，也可以是本地的，因为报头压缩可能适用于所有IPv6地址。此选项允许传播由CID标识的多个上下文，以便按照[RFC6282]中的规定使用。上下文可以是任意长度的前缀或地址（/128），RA消息中最多可携带16个6COs。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Context Length | Res |C| CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Context Prefix .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |Context Length | Res |C| CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Context Prefix .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: 6LoWPAN Context Option Format
图1:6LoWPAN上下文选项格式
Type: 34
类型：34
Length: 8-bit unsigned integer. The length of the option (including the Type and Length fields) in units of 8 bytes. May be 2 or 3, depending on the length of the Context Prefix field.
长度：8位无符号整数。选项的长度（包括类型和长度字段），以8字节为单位。可以是2或3，具体取决于上下文前缀字段的长度。
Context Length: 8-bit unsigned integer. The number of leading bits in the Context Prefix field that are valid. The value ranges from 0 to 128. If it is more than 64, then the Length MUST be 3.
上下文长度：8位无符号整数。上下文前缀字段中有效的前导位数。该值的范围为0到128。如果大于64，则长度必须为3。
C: 1-bit context Compression flag. This flag indicates if the context is valid for use in compression. A context that is not valid MUST NOT be used for compression but SHOULD be used in decompression in case another compressor has not yet received the updated context information. This flag is used to manage the context life cycle based on the recommendations in Section 7.2.
C：1位上下文压缩标志。此标志指示上下文是否可用于压缩。无效的上下文不得用于压缩，但应在另一个压缩器尚未收到更新的上下文信息的情况下用于解压缩。该标志用于根据第7.2节中的建议管理上下文生命周期。
CID: 4-bit Context Identifier for this prefix information. The CID is used by context-based header compression as specified in [RFC6282]. The list of CIDs for a LoWPAN is configured on the 6LBR that originates the context information for the 6LoWPAN.
CID:此前缀信息的4位上下文标识符。CID由[RFC6282]中指定的基于上下文的标头压缩使用。LoWPAN的CID列表在6LBR上配置，6LBR生成6LoWPAN的上下文信息。
Res, Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Res，Reserved：此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Valid Lifetime: 16-bit unsigned integer. The length of time in units of 60 seconds (relative to the time the packet is received) that the context is valid for the purpose of header compression or decompression. A value of all zero bits (0x0) indicates that this context entry MUST be removed immediately.
有效生存期：16位无符号整数。上下文对于报头压缩或解压缩有效的时间长度，单位为60秒（相对于接收数据包的时间）。所有零位（0x0）的值表示必须立即删除此上下文条目。
Context Prefix: The IPv6 prefix or address corresponding to the CID field. The valid length of this field is included in the Context Length field. This field is padded with zeros in order to make the option a multiple of 8 bytes.
上下文前缀：与CID字段对应的IPv6前缀或地址。此字段的有效长度包含在上下文长度字段中。此字段用零填充，以使选项为8字节的倍数。
The Authoritative Border Router Option (ABRO) is needed when RA messages are used to disseminate prefixes and context information across a route-over topology. In this case, 6LRs receive PIOs from other 6LRs. This implies that a 6LR can't just let the most recently received RA win. In order to be able to reliably add and remove prefixes from the 6LoWPAN, we need to carry information from the authoritative 6LBR. This is done by introducing a version number that the 6LBR sets and that 6LRs propagate as they propagate the prefix and context information with this ABRO. When there are multiple 6LBRs, they would have separate version number spaces. Thus, this option needs to carry the IP address of the 6LBR that originated that set of information.
当RA消息用于在拓扑上的路由上传播前缀和上下文信息时，需要使用权威边界路由器选项（ABRO）。在这种情况下，6LR从其他6LR接收PIO。这意味着6LR不能让最近收到的RA获胜。为了能够可靠地从6LoWPAN中添加和删除前缀，我们需要从权威的6LBR中携带信息。这是通过引入一个版本号来实现的，该版本号由6LBR设置，6LRs通过该ABRO传播前缀和上下文信息。当有多个6LBR时，它们将有单独的版本号空格。因此，该选项需要携带产生该信息集的6LBR的IP地址。
The ABRO MUST be included in all RA messages in the case when RAs are used to propagate information between routers (as described in Section 8.2).
当RAs用于在路由器之间传播信息时（如第8.2节所述），ABRO必须包含在所有RA消息中。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 3 | Version Low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version High | Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 6LBR Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 3 | Version Low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version High | Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 6LBR Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Type: 35
类型：35
Length: 8-bit unsigned integer. The length of the option in units of 8 bytes. Always 3.
长度：8位无符号整数。选项的长度，以8字节为单位。总是3。
Version Low, Version High: Together, Version Low and Version High constitute the Version Number field, a 32-bit unsigned integer where Version Low is the least significant 16 bits and Version High is the most significant
版本低、版本高：版本低和版本高共同构成版本号字段，一个32位无符号整数，其中版本低是最低有效16位，版本高是最高有效
16 bits. The version number corresponding to this set of information contained in the RA message. The authoritative 6LBR originating the prefix increases this version number each time its set of prefix or context information changes.
16位。与RA消息中包含的这组信息相对应的版本号。每当前缀集或上下文信息更改时，发起前缀的权威6LBR将增加此版本号。
Valid Lifetime: 16-bit unsigned integer. The length of time in units of 60 seconds (relative to the time the packet is received) that this set of border router information is valid. A value of all zero bits (0x0) assumes a default value of 10,000 (~one week).
有效生存期：16位无符号整数。这组边界路由器信息有效的时间长度，以60秒为单位（相对于接收数据包的时间）。所有零位（0x0）的值假定默认值为10000（~一周）。
Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留：此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
6LBR Address: IPv6 address of the 6LBR that is the origin of the included version number.
6LBR地址：6LBR的IPv6地址，它是包含版本号的来源。
For the multihop DAD exchanges between a 6LR and 6LBR as specified in Section 8.2, there are two new ICMPv6 message types called the Duplicate Address Request (DAR) and the Duplicate Address Confirmation (DAC). We avoid reusing the NS and NA messages for this purpose, since these messages are not subject to the hop limit=255 check as they are forwarded by intermediate 6LRs. The information contained in the messages is otherwise the same as would be in an NS carrying an ARO, with the message format inlining the fields that are in the ARO.
对于第8.2节中规定的6LR和6LBR之间的多跳DAD交换，有两种新的ICMPv6消息类型，称为重复地址请求（DAR）和重复地址确认（DAC）。为此，我们避免重用NS和NA消息，因为这些消息不受跃点限制=255检查的约束，因为它们是由中间6LR转发的。消息中包含的信息与携带ARO的NS中的信息相同，消息格式内联ARO中的字段。
The DAR and DAC use the same message format with different ICMPv6 type values, and the Status field is only meaningful in the DAC message.
DAR和DAC使用具有不同ICMPv6类型值的相同消息格式，状态字段仅在DAC消息中有意义。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EUI-64 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Registered Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ EUI-64 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Registered Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP fields:
IP字段：
IPv6 Source: A non-link-local address of the sending router.
IPv6源：发送路由器的非链路本地地址。
IPv6 Destination: In a DAR, a non-link-local address of a 6LBR. In a DAC, this is just the source from the DAR.
IPv6目的地：在DAR中，6LBR的非链路本地地址。在DAC中，这只是来自DAR的源。
Hop Limit: Set to MULTIHOP_HOPLIMIT on transmit. MUST be ignored on receipt.
跃点限制：在传输时设置为多跳\跃点限制。必须在收到时忽略。
ICMP Fields:
ICMP字段：
Type: 157 for the DAR and 158 for the DAC.
类型：DAR为157，DAC为158。
Code: Set to zero on transmit. MUST be ignored on receipt.
代码：传输时设置为零。必须在收到时忽略。
Checksum: The ICMP checksum. See [RFC4443].
校验和：ICMP校验和。参见[RFC4443]。
Status: 8-bit unsigned integer. Indicates the status of a registration in the DAC. MUST be set to 0 in the DAR. See Table 1.
状态：8位无符号整数。指示DAC中注册的状态。在DAR中必须设置为0。见表1。
Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留：此字段未使用。发送方必须将其初始化为零，接收方必须忽略它。
Registration Lifetime: 16-bit unsigned integer. The amount of time in units of 60 seconds that the 6LBR should retain the DAD table entry (Section 8.2.2) for the Registered Address. A value of 0 indicates in a DAR that the DAD table entry should be removed.
注册生存期：16位无符号整数。6LBR应为注册地址保留DAD表条目（第8.2.2节）的时间量（以60秒为单位）。值0表示DAR中应删除DAD表项。
EUI-64: 64 bits. This field is used to uniquely identify the interface of the Registered Address by including the EUI-64 identifier [EUI64] assigned to it unmodified.
EUI-64:64位。此字段用于通过包含未修改分配给注册地址的EUI-64标识符[EUI64]，唯一标识注册地址的接口。
Registered Address: 128-bit field. Carries the host address that was contained in the IPv6 Source field in the NS that contained the ARO sent by the host.
注册地址：128位字段。携带包含主机发送的ARO的NS中IPv6源字段中包含的主机地址。
Hosts in a LoWPAN use the ARO in the NS messages they send as a way to maintain the Neighbor Cache in the routers, thereby removing the need for multicast NSs to do address resolution. Unlike in [RFC4861], the hosts initiate updating the information they receive in RAs by sending RSs before the information expires. Finally, when NUD indicates that one or all default routers have become unreachable, then the host uses RSs to find a new set of default routers.
低端主机在发送的NS消息中使用ARO作为维护路由器中邻居缓存的一种方式，从而消除了多播NSs进行地址解析的需要。与[RFC4861]不同，主机通过在信息过期之前发送RSs来更新RAs中接收到的信息。最后，当NUD指示一个或所有默认路由器无法访问时，主机使用RSs查找一组新的默认路由器。
A host MUST NOT multicast an NS message.
主机不得多播NS消息。
When the interface on a host is initialized, it follows the specification in [RFC4861]. A link-local address is formed based on the EUI-64 identifier [EUI64] assigned to the interface as per [RFC4944] or the appropriate IP-over-foo document for the link, and then the host sends RS messages as described in [RFC4861] Section 6.3.7.
当主机上的接口初始化时，它遵循[RFC4861]中的规范。根据[RFC4944]分配给接口的EUI-64标识符[EUI64]或链路的适当IP over foo文档，形成链路本地地址，然后主机发送RS消息，如[RFC4861]第6.3.7节所述。
There is no need to join the solicited-node multicast address, since nobody multicasts NSs in this type of network. A host MUST join the all-nodes multicast address.
不需要加入请求的节点多播地址，因为没有人在这种类型的网络中多播NSs。主机必须加入所有节点的多播地址。
The RS is formatted as specified in [RFC4861] and sent to the IPv6 all-routers multicast address (see [RFC4861] Section 6.3.7 for details). An SLLAO MUST be included to enable unicast RAs in response. An unspecified source address MUST NOT be used in RS messages.
RS按照[RFC4861]中的规定进行格式化，并发送到IPv6所有路由器多播地址（有关详细信息，请参阅[RFC4861]第6.3.7节）。必须包括SLLAO以启用单播RAs响应。RS消息中不得使用未指定的源地址。
If the link layer supports a way to send packets to some kind of all-routers anycast link-layer address, then that MAY be used to convey these packets to a router.
如果链路层支持将分组发送到某种类型的所有路由器选播链路层地址的方式，则可以使用该方式将这些分组传送到路由器。
Since hosts do not depend on multicast RAs to discover routers, the hosts need to intelligently retransmit RSs whenever the default router list is empty, one of its default routers becomes unreachable, or the lifetime of the prefixes and contexts in the previous RA is about to expire. The RECOMMENDED rate of retransmissions is to initially send up to 3 (MAX_RTR_SOLICITATIONS) RS messages separated by at least 10 seconds (RTR_SOLICITATION_INTERVAL) as specified in [RFC4861], and then switch to slower retransmissions. After the initial retransmissions, the host SHOULD do truncated binary exponential backoff [ETHERNET] of the retransmission timer for each subsequent retransmission, truncating the increase of the retransmission timer at 60 seconds (MAX_RTR_SOLICITATION_INTERVAL). In all cases, the RS retransmissions are terminated when an RA is received. See Section 9 for protocol constants.
由于主机不依赖多播RAs来发现路由器，因此每当默认路由器列表为空、其中一个默认路由器无法访问或前一个RA中的前缀和上下文的生存期即将到期时，主机需要智能地重新传输RSs。建议的重新传输速率是，按照[RFC4861]中的规定，最初最多发送3条（最大RTR请求）RS消息，间隔至少10秒（RTR请求间隔），然后切换到较慢的重新传输。初始重传后，主机应为每次后续重传执行重传计时器的截断二进制指数退避[ETHERNET]，将重传计时器的增量截断为60秒（最大RTR请求间隔）。在所有情况下，RS重传在接收到RA时终止。协议常数见第9节。
The processing of RAs is as in [RFC4861], with the addition of handling the 6CO and triggering address registration when a new address has been configured. Furthermore, the SLLAO MUST be included in the RA. Unlike in [RFC4861], the maximum value of the RA Router Lifetime field MAY be up to 0xFFFF (approximately 18 hours).
RAs的处理如[RFC4861]中所述，另外还有处理6CO和在配置新地址时触发地址注册。此外，SLLAO必须包含在RA中。与[RFC4861]不同，RA路由器生存期字段的最大值可能高达0xFFFF（约18小时）。
Should the host erroneously receive a PIO with the L (on-link) flag set, then that PIO MUST be ignored.
如果主机错误地接收到设置了L（链路上）标志的PIO，则必须忽略该PIO。
Address configuration follows [RFC4862]. For an address not derived from an EUI-64, the M flag of the RA determines how the address can be configured. If the M flag is set in the RA, then DHCPv6 MUST be used to assign the address. If the M flag is not set, then the address can be configured by any other means (and duplicate detection is performed as part of the registration process).
地址配置遵循[RFC4862]。对于不是从EUI-64派生的地址，RA的M标志确定如何配置该地址。如果RA中设置了M标志，则必须使用DHCPv6分配地址。如果未设置M标志，则可以通过任何其他方式配置地址（并且作为注册过程的一部分执行重复检测）。
Once an address has been configured, it will be registered by unicasting an NS with an ARO to one or more routers.
一旦一个地址被配置，它将通过将一个带有ARO的NS单播到一个或多个路由器来注册。
The host maintains a conceptual data structure for the context information it receives from the routers. This structure is called the context table. It includes the CID, the prefix (from the Context Prefix field in the 6CO), the Compression bit, and the Valid Lifetime. A context table entry that has the Compression bit clear is used for decompression when receiving packets but MUST NOT be used for compression when sending packets.
主机维护从路由器接收的上下文信息的概念数据结构。这种结构称为上下文表。它包括CID、前缀（来自6CO中的上下文前缀字段）、压缩位和有效生存期。压缩位为clear的上下文表条目在接收数据包时用于解压缩，但在发送数据包时不得用于压缩。
When a 6CO is received in an RA, it is used to add or update the information in the context table. If the CID field in the 6CO matches an existing context table entry, then that entry is updated with the information in the 6CO. If the Valid Lifetime field in the 6CO is zero, then the entry is immediately deleted.
当RA中收到6CO时，它用于添加或更新上下文表中的信息。如果6CO中的CID字段与现有上下文表条目匹配，则该条目将使用6CO中的信息进行更新。如果6CO中的有效生存期字段为零，则立即删除该条目。
If there is no matching entry in the context table, and the Valid Lifetime field is non-zero, then a new context is added to the context table. The 6CO is used to update the created entry.
如果上下文表中没有匹配项，并且有效生存期字段为非零，则会向上下文表添加新上下文。6CO用于更新创建的条目。
When the 6LBR changes the context information, a host might not immediately notice. And in the worst case, a host might have stale context information. For this reason, 6LBRs use the recommendations in Section 7.2 for carefully managing the context life cycle. Nodes should be careful about using header compression in RA messages that include 6COs.
当6LBR更改上下文信息时，主机可能不会立即注意到。在最坏的情况下，主机可能有过时的上下文信息。因此，6LBR使用第7.2节中的建议仔细管理上下文生命周期。节点应该注意在包含6COs的RA消息中使用头压缩。
The prefix information is timed out as specified in [RFC4861]. When the Valid Lifetime for a context table entry expires, the entry is placed in a receive-only mode, which is the equivalent of receiving a 6CO for that context with C=0. The entry is held in receive-only mode for a period of twice the default Router Lifetime, after which the entry is removed.
前缀信息按照[RFC4861]中的规定超时。当上下文表项的有效生存期到期时，该项将被置于仅接收模式，这相当于接收C=0的该上下文的6CO。该条目在仅接收模式下保留两倍于默认路由器生存期的时间，然后删除该条目。
A host should inspect the various lifetimes to determine when it should next initiate sending an RS to ask for any updates to the information. The lifetimes that matter are the default Router Lifetime, the Valid Lifetime in the PIOs, and the Valid Lifetime in the 6CO. The host SHOULD unicast one or more RSs to the router well before the shortest of those lifetimes (across all the prefixes and all the contexts) expires and then switch to multicast RS messages if there is no response to the unicasts. The retransmission behavior for the RSs is specified in Section 5.3.
主机应检查不同的生存期，以确定下一次何时启动发送RS以请求对信息进行任何更新。重要的生存期是默认路由器生存期、PIO中的有效生存期和6CO中的有效生存期。主机应在最短的生存期（跨越所有前缀和所有上下文）到期之前，将一个或多个RSs单播到路由器，然后如果对单播没有响应，则切换到多播RS消息。第5.3节规定了RSs的重传行为。
Hosts send unicast NS messages to register their IPv6 addresses, and also to do NUD to verify that their default routers are still reachable. The registration is performed by the host including an ARO in the NS it sends. Even if the host doesn't have data to send, but is expecting others to try to send packets to the host, the host needs to maintain its NCEs in the routers. This is done by sending NS messages with an ARO to the router well in advance of the Registration Lifetime expiring. NS messages are retransmitted up to MAX_UNICAST_SOLICIT times using a minimum timeout of RETRANS_TIMER until the host receives an NA message with an ARO.
主机发送单播NS消息以注册其IPv6地址，并执行NUD以验证其默认路由器是否仍然可以访问。注册由主机执行，主机在其发送的NS中包含ARO。即使主机没有要发送的数据，但希望其他人尝试向主机发送数据包，主机也需要在路由器中维护其连接。这是通过在注册生命周期到期之前向路由器发送带有ARO的NS消息来实现的。在主机接收到带有ARO的NA消息之前，NS消息将使用最小的RETRANS\u TIMER（重传计时器超时时间）重传最多可达最大单播请求次数。
Hosts that receive RA messages from multiple default routers SHOULD attempt to register with more than one of them in order to increase the robustness of the network.
从多个默认路由器接收RA消息的主机应尝试向其中多个路由器注册，以提高网络的健壮性。
Note that NUD probes can be suppressed by reachability confirmations from transport protocols or applications as specified in [RFC4861].
注意，可以通过[RFC4861]中规定的传输协议或应用程序的可达性确认来抑制NUD探测。
When a host knows it will no longer use a router it is registered to, it SHOULD de-register with the router by sending an NS with an ARO containing a lifetime of 0. To handle the case when a host loses connectivity with the default router involuntarily, the host SHOULD use a suitably low Registration Lifetime.
当主机知道它将不再使用它注册到的路由器时，它应该通过发送一个包含生存期为0的ARO的NS向路由器注销。若要处理主机意外失去与默认路由器的连接的情况，主机应使用适当的低注册生存期。
The host triggers sending NS messages containing an ARO when a new address is configured, when it discovers a new default router, or well before the Registration Lifetime expires. Such an NS MUST include an SLLAO, since the router needs to record the link-layer address of the host. An unspecified source address MUST NOT be used in NS messages.
主机在配置新地址、发现新的默认路由器时或在注册生存期到期之前触发发送包含ARO的NS消息。这样的NS必须包括SLLAO，因为路由器需要记录主机的链路层地址。NS消息中不得使用未指定的源地址。
A host handles NA messages as specified in [RFC4861], with added logic described in this section for handling the ARO.
主机按照[RFC4861]中的规定处理NA消息，并在本节中添加了用于处理ARO的逻辑。
In addition to the normal validation of an NA and its options, the ARO (if present) is verified as follows. If the Length field is not two, the option is silently ignored. If the EUI-64 field does not match the EUI-64 of the interface, the option is silently ignored.
除了NA及其选项的正常验证外，ARO（如果存在）的验证如下。如果长度字段不是2，则该选项将被静默忽略。如果EUI-64字段与接口的EUI-64不匹配，则会自动忽略该选项。
If the Status field is zero, then the address registration was successful. The host saves the Registration Lifetime from the ARO for use to trigger a new NS well before the lifetime expires. If the Status field is not equal to zero, the address registration has failed.
如果状态字段为零，则地址注册成功。主机保存来自ARO的注册生存期，以便在生存期到期之前触发新的NS。如果状态字段不等于零，则地址注册失败。
The procedure for maintaining reachability information about a neighbor is the same as in [RFC4861] Section 7.3, with the exception that address resolution is not performed.
维护邻居的可达性信息的程序与[RFC4861]第7.3节中的程序相同，但不执行地址解析。
The address registration procedure may fail for two reasons: no response to NSs is received (NUD failure), or an ARO with a failure Status (Status > 0) is received. In the case of NUD failure, the entry for that router will be removed; thus, address registration is no longer of importance. When an ARO with a non-zero Status field is received, this indicates that registration for that address has failed. A failure Status of one indicates that a duplicate address was detected, and the procedure described in [RFC4862] Section 5.4.5 is followed. The host MUST NOT use the address it tried to register. If the host has valid registrations with other routers, these MUST be removed by registering with each using a zero ARO lifetime.
地址注册过程失败可能有两个原因：没有收到对NSs的响应（NUD失败），或者接收到故障状态（状态>0）的ARO。在NUD故障的情况下，该路由器的条目将被删除；因此，地址注册不再重要。当接收到具有非零状态字段的ARO时，这表示该地址的注册失败。故障状态为1表示检测到重复地址，并遵循[RFC4862]第5.4.5节中描述的程序。主机不能使用它试图注册的地址。如果主机具有与其他路由器的有效注册，则必须通过使用零ARO生存期向每个路由器注册来删除这些注册。
A Status code of two indicates that the Neighbor Cache of that router is full. In this case, the host SHOULD remove this router from its default router list and attempt to register with another router. If the host's default router list is empty, it needs to revert to sending RSs as specified in Section 5.3.
状态代码为2表示该路由器的邻居缓存已满。在这种情况下，主机应从其默认路由器列表中删除此路由器，并尝试向其他路由器注册。如果主机的默认路由器列表为空，则需要按照第5.3节的规定恢复发送RSs。
Other failure codes may be defined in future documents.
其他故障代码可在未来的文件中定义。
The IP address of the next hop for a destination is determined as follows. Destinations to the link-local prefix (fe80::) are always sent on the link to that destination. It is assumed that link-local addresses are formed as specified in Section 5.2 from the EUI-64, and address resolution is not performed. Packets are sent to link-local destinations by reversing the procedure in Appendix A of [RFC4291].
目的地下一跳的IP地址确定如下。链接本地前缀（fe80:：）的目的地始终通过链接发送到该目的地。假设链路本地地址按照第5.2节的规定从EUI-64中形成，并且不执行地址解析。通过颠倒[RFC4291]附录A中的程序，将数据包发送至链路本地目的地。
Multicast addresses are considered to be on-link and are resolved as specified in [RFC4944] or the appropriate IP-over-foo document. Note that [RFC4944] only defines how to represent a multicast destination address in the LoWPAN header. Support for multicast scopes larger than link-local needs an appropriate multicast routing algorithm.
多播地址被视为在链路上，并按照[RFC4944]或适当的IP over foo文档中的规定进行解析。请注意，[RFC4944]仅定义如何在LoWPAN报头中表示多播目标地址。支持大于本地链路的多播作用域需要合适的多播路由算法。
All other prefixes are assumed to be off-link [RFC5889]. Anycast addresses are always considered to be off-link. They are therefore sent to one of the routers in the default router list.
所有其他前缀均假定为断开链接[RFC5889]。选播地址始终被视为断开链接。因此，它们被发送到默认路由器列表中的一个路由器。
A LoWPAN node is not required to maintain a minimum of one buffer per neighbor as specified in [RFC4861], since packets are never queued while waiting for address resolution.
按照[RFC4861]中的规定，LoWPAN节点不需要为每个邻居至少保留一个缓冲区，因为在等待地址解析时，数据包从不排队。
The address registration mechanism and the SLLAO in RA messages provide sufficient a priori state in routers and hosts to resolve an IPv6 address to its associated link-layer address. As all prefixes except the link-local prefix and multicast addresses are always assumed to be off-link, multicast-based address resolution between neighbors is not needed.
地址注册机制和SLLAO-in-RA消息在路由器和主机中提供足够的先验状态，以将IPv6地址解析为其关联的链路层地址。由于除了链路本地前缀和多播地址之外的所有前缀都假定为断开链路，因此不需要在邻居之间进行基于多播的地址解析。
Link-layer addresses for neighbors are stored in NCEs [RFC4861]. In order to achieve LoWPAN compression, most global addresses are formed using a link-layer address. Thus, a host can reduce memory usage by optimizing for this case and only storing link-layer address information if it differs from the link-layer address corresponding to the Interface ID of the IPv6 address (i.e., differs in more than the on-link/global bit being inverted).
邻居的链路层地址存储在NCEs[RFC4861]中。为了实现低泛压缩，大多数全局地址使用链路层地址形成。因此，主机可以通过针对这种情况进行优化并仅在链路层地址信息不同于对应于IPv6地址的接口ID的链路层地址（即，不同于被反转的链路上/全局位）时存储链路层地址信息来减少内存使用。
It is often advantageous for battery-powered hosts in LoWPANs to keep a low duty cycle. The optimizations described in this document enable hosts to sleep, as further described in this section. Routers may want to cache traffic destined to a host that is sleeping, but such functionality is out of the scope of this document.
电池供电的主机保持低占空比通常是有利的。本文档中描述的优化使主机能够睡眠，本节将进一步介绍。路由器可能希望缓存发送到休眠主机的流量，但此类功能不在本文档的范围内。
As all ND messages are initiated by the hosts, this allows a host to sleep or otherwise be unreachable between NS/NA message exchanges. The ARO attached to NS messages indicates to a router to keep the NCE for that address valid for the period in the Registration Lifetime field. A host should choose a sleep time appropriate for its energy characteristics and set a Registration Lifetime larger than the sleep time to ensure that the registration is renewed successfully (considering, for example, clock drift and additional time for potential retransmissions of the re-registration). External configuration of a host should also consider the stability of the network (how quickly the topology changes) when choosing its sleep
由于所有ND消息都是由主机启动的，这允许主机在NS/NA消息交换之间休眠或无法访问。附加到NS消息的ARO指示路由器在注册生存期字段中保持该地址的NCE在一段时间内有效。主机应选择适合其能量特性的睡眠时间，并将注册生存期设置为大于睡眠时间，以确保成功更新注册（例如，考虑时钟漂移和重新注册的潜在重新传输的额外时间）。主机的外部配置也应该考虑网络的稳定性（选择拓扑的速度有多快）。
time (and thus Registration Lifetime). A dynamic network requires a shorter sleep time so that routers don't keep invalid NCEs for nodes longer than necessary.
时间（以及注册生命周期）。动态网络需要更短的睡眠时间，这样路由器就不会让节点的无效睡眠时间超过需要的时间。
When a host wakes up from a sleep period, it SHOULD refresh its current address registrations that will time out before the next wakeup. This is done by sending NS messages with an ARO as described in Section 5.5.1. The host may also need to refresh its prefix and context information by sending a new unicast RS (the maximum Router Lifetime is about 18 hours, whereas the maximum Registration Lifetime is about 45.5 days). If after wakeup the host (using NUD) determines that some or all previous default routers have become unreachable, then the host will send multicast RSs to discover new default router(s) and restart the address registration process.
当主机从睡眠期唤醒时，它应该刷新其当前地址注册，该注册将在下次唤醒前超时。如第5.5.1节所述，通过ARO发送NS消息。主机可能还需要通过发送新的单播RS来刷新其前缀和上下文信息（最大路由器生存期约为18小时，而最大注册生存期约为45.5天）。如果在唤醒主机后（使用NUD）确定某些或所有以前的默认路由器无法访问，则主机将发送多播RSs以发现新的默认路由器并重新启动地址注册过程。
Both 6LRs and 6LBRs maintain the Neighbor Cache [RFC4861] based on the AROs they receive in NA messages from hosts, ND packets from other nodes, and, potentially, a routing protocol used in the 6LoWPAN as outlined in Section 3.5.
6LRs和6LBR都基于从主机接收的NA消息中的ARO、从其他节点接收的ND数据包以及可能在6LoWPAN中使用的路由协议维护邻居缓存[RFC4861]，如第3.5节所述。
The routers SHOULD NOT garbage-collect Registered NCEs (see Section 3.4), since they need to retain them until the Registration Lifetime expires. Similarly, if NUD on the router determines that the host is UNREACHABLE (based on the logic in [RFC4861]), the NCE SHOULD NOT be deleted but rather retained until the Registration Lifetime expires. A renewed ARO should mark the cache entry as STALE. Thus, for 6LoWPAN routers, the Neighbor Cache doesn't behave like a cache. Instead, it behaves as a registry of all the host addresses that are attached to the router.
路由器不应垃圾收集已注册的NCE（见第3.4节），因为它们需要保留这些NCE，直到注册寿命到期。类似地，如果路由器上的NUD确定主机不可访问（基于[RFC4861]中的逻辑），则不应删除NCE，而应保留NCE，直到注册生存期到期。更新的ARO应将缓存项标记为过时。因此，对于6LoWPAN路由器，邻居缓存的行为不像缓存。相反，它充当连接到路由器的所有主机地址的注册表。
Routers MAY implement the Default Router Preference (Prf) extension [RFC4191] and use that to indicate to the host whether the router is a 6LBR or a 6LR. If this is implemented, then 6LRs with no route to a border router MUST set Prf to (11) for low preference, other 6LRs MUST set Prf to (00) for normal preference, and 6LBRs MUST set Prf to (01) for high preference.
路由器可以实现默认路由器首选项（Prf）扩展[RFC4191]，并使用该扩展向主机指示路由器是6LBR还是6LR。如果执行此操作，则没有到边界路由器路由的6LRs必须将Prf设置为（11）低优先，其他6LRs必须将Prf设置为（00）正常优先，6LBRs必须将Prf设置为（01）高优先。
Even if a router in a route-over topology can reach both a host and another target, because of radio propagation it generally cannot know whether the host can directly reach the other target. Therefore, it cannot assume that Redirect will actually work from one host to another. Therefore, it SHOULD NOT send Redirect messages. The only
即使拓扑上的路由中的路由器可以到达主机和另一个目标，由于无线传播，它通常无法知道主机是否可以直接到达另一个目标。因此，它不能假设重定向将从一台主机实际工作到另一台主机。因此，它不应该发送重定向消息。唯一的
potential exception to this "SHOULD NOT" is when the deployment/ implementation has a way to know how the host can reach the intended target. Hence, it is RECOMMENDED that the implementation by default does not send Redirect messages but can be configurable when the deployment calls for this. In contrast, for mesh-under topologies, the same considerations about Redirects apply as in [RFC4861].
这种“不应该”的潜在例外情况是，部署/实现有办法知道主机如何到达预期目标。因此，建议实现在默认情况下不发送重定向消息，但在部署调用此消息时可以进行配置。相反，对于拓扑下的网格，有关重定向的注意事项与[RFC4861]中的相同。
A router MUST NOT set the L (on-link) flag in the PIOs, since that might trigger hosts to send multicast NSs.
路由器不得在PIO中设置L（链路上）标志，因为这可能会触发主机发送多播NSs。
The 6LBR router interface initialization behavior is the same as in [RFC4861]. However, in a dynamic configuration scenario (see Section 8.1), a 6LR comes up as a non-router and waits to receive the advertisement for configuring its own interface address first, before setting its interfaces to be advertising interfaces and turning into a router.
6LBR路由器接口初始化行为与[RFC4861]中相同。然而，在动态配置场景中（参见第8.1节），6LR作为非路由器出现，并等待接收广告以首先配置其自己的接口地址，然后将其接口设置为广告接口并转变为路由器。
A router processes RS messages as specified in [RFC4861]. The differences relate to the inclusion of ABROs in the RA messages and the exclusive use of unicast RAs. If a 6LR has received an ABRO from a 6LBR, then it will include that option unmodified in the RA messages it sends. And, if the 6LR has received RAs -- whether with the same prefixes and context information or different -- from a different 6LBR, then it will need to keep those prefixes and that context information separately so that the RAs the 6LR sends will maintain the association between the ABRO and the prefixes and context information. The router can tell which 6LBR originated the prefixes and context information from the 6LBR Address field in the ABRO. When a router has information tied to multiple ABROs, a single RS will result in multiple RAs each containing a different ABRO.
路由器按照[RFC4861]中的规定处理RS消息。这些差异与RA消息中包含ABROs和独家使用单播RAs有关。如果6LR已从6LBR接收到ABRO，则它将在发送的RA消息中包含未修改的选项。而且，如果6LR从不同的6LBR接收到RAs（无论是具有相同的前缀和上下文信息还是不同的），那么它将需要分别保留这些前缀和上下文信息，以便6LR发送的RAs将保持ABRO与前缀和上下文信息之间的关联。路由器可以从ABRO中的6LBR地址字段判断前缀和上下文信息是由哪个6LBR产生的。当路由器将信息绑定到多个ABRO时，单个RS将导致多个RAs，每个RAs包含不同的ABRO。
When the ABRO Valid Lifetime associated with a 6LBR times out, all information related to that 6LBR MUST be removed. As an implementation note, it is recommended that RAs are sent sufficiently more frequently than the ABRO Valid Lifetime so that missing an RA does not result in removing all information related to a 6LBR.
当与6LBR相关的ABRO有效寿命超时时，必须删除与该6LBR相关的所有信息。作为实施说明，建议发送RAs的频率要比ABRO有效生存期的频率高，以便丢失RA不会导致删除与6LBR相关的所有信息。
An RS might be received from a host that has not yet registered its address with the router. Thus, the router MUST NOT modify an existing NCE based on the SLLAO from the RS. However, a router MAY create a Tentative NCE based on the SLLAO. Such a Tentative NCE SHOULD be timed out in TENTATIVE_NCE_LIFETIME seconds, unless a registration converts it into a Registered NCE.
可能从尚未向路由器注册其地址的主机接收RS。因此，路由器不得基于RS中的SLLAO修改现有NCE。然而，路由器可基于SLLAO创建临时NCE。除非注册将其转换为已注册的NCE，否则此类暂定NCE应在暂定NCE生命周期内超时。
A 6LR or 6LBR MUST include an SLLAO in the RAs it sends; this is required so that the hosts will know the link-layer address of the router. Unlike in [RFC4861], the maximum value of the RA Router Lifetime field MAY be up to 0xFFFF (approximately 18 hours).
6LR或6LBR必须在其发送的RAs中包含SLLAO；这是必需的，以便主机知道路由器的链路层地址。与[RFC4861]不同，RA路由器生存期字段的最大值可能高达0xFFFF（约18小时）。
Unlike [RFC4861], which suggests multicast RAs, this specification improves the exchange by always unicasting RAs in response to RSs. This is possible, since the RS always includes an SLLAO, which is used by the router to unicast the RA.
与[RFC4861]不同，它建议多播RAs，该规范通过总是单播RAs来响应RSs来改进交换。这是可能的，因为RS总是包括SLLAO，路由器使用SLLAO单播RA。
A router does not need to send any periodic RA messages, since the hosts will solicit updated information by sending RSs before the lifetimes expire.
路由器不需要发送任何定期RA消息，因为主机将在生存期到期之前通过发送RSs请求更新信息。
However, if the routers use RAs to distribute prefix and/or context information across a route-over topology, that might require periodic RA messages. Such RAs are sent using the configurable MinRtrAdvInterval and MaxRtrAdvInterval as per [RFC4861].
但是，如果路由器使用RAs在拓扑上的路由上分布前缀和/或上下文信息，则可能需要周期性的RA消息。根据[RFC4861]，使用可配置的MinRtrAdvInterval和MaxRtrAdvInterval发送此类RAs。
A router handles NS messages as specified in [RFC4861], with added logic described in this section for handling the ARO.
路由器按照[RFC4861]中的规定处理NS消息，并在本节中添加用于处理ARO的逻辑。
In addition to the normal validation of an NS and its options, the ARO is verified as follows (if present). If the Length field is not two, or if the Status field is not zero, then the NS is silently ignored.
除了NS及其选项的正常验证外，ARO的验证如下（如果存在）。如果长度字段不是两个，或者状态字段不是零，则NS将被静默忽略。
If the source address of the NS is the unspecified address, or if no SLLAO is included, then any included ARO is ignored, that is, the NS is processed as if it did not contain an ARO.
如果NS的源地址是未指定的地址，或者如果没有包含SLLAO，则忽略任何包含的ARO，也就是说，NS的处理方式与不包含ARO一样。
If the NS contains a valid ARO, then the router inspects its Neighbor Cache on the arriving interface to see if it is a duplicate. It isn't a duplicate if (1) there is no NCE for the IPv6 source address of the NS or (2) there is such an NCE and the EUI-64 is the same. Otherwise, it is a duplicate address. Note that if multihop DAD (Section 8.2) is used, then the checks are slightly different, to take into account Tentative NCEs. In the case where it is a duplicate address, then the router responds with a unicast NA message with the ARO Status field set to one (to indicate that the address is a duplicate) as described in Section 6.5.2. In this case, there is no modification to the Neighbor Cache.
如果NS包含一个有效的ARO，那么路由器会检查到达接口上的邻居缓存，看看它是否重复。如果（1）NS的IPv6源地址没有NCE，或者（2）存在这样的NCE，并且EUI-64相同，则这不是重复。否则，它是一个重复的地址。请注意，如果使用多跳DAD（第8.2节），则检查略有不同，以考虑暂时性差异。如果它是一个重复的地址，那么路由器将按照第6.5.2节中的描述，用一条单播NA消息响应，并将ARO状态字段设置为1（以指示该地址是重复的）。在这种情况下，不会修改邻居缓存。
Address registration errors are not sent back to the source address of the NS due to a possible risk of L2 address collision. Instead, the NA is sent to the link-local IPv6 address with the Interface ID part derived from the EUI-64 field of the ARO as per [RFC4944]. In particular, this means that the universal/local bit needs to be inverted. The NA is formatted with a copy of the ARO from the NS, but with the Status field set to indicate the appropriate error.
由于可能存在二级地址冲突的风险，地址注册错误不会发送回NS的源地址。相反，NA被发送到链路本地IPv6地址，其接口ID部分根据[RFC4944]从ARO的EUI-64字段派生。特别是，这意味着需要反转通用/本地位。NA使用来自NS的ARO副本进行格式化，但状态字段设置为指示适当的错误。
The error is sent to the link-local address with the Interface ID derived from the EUI-64. Thus, if the ARO was from and for a short address, the L2 destination address for the NA with the ARO error will be the 64-bit unique address.
错误被发送到链路本地地址，接口ID来自EUI-64。因此，如果ARO来自短地址，则带有ARO错误的NA的L2目标地址将是64位唯一地址。
If the ARO did not result in a duplicate address being detected as above, then if the Registration Lifetime is non-zero the router creates (if it didn't exist) or updates (otherwise) an NCE for the IPv6 source address of the NS. If the Neighbor Cache is full and a new entry needs to be created, then the router responds with a unicast NA with the ARO Status field set to two (to indicate that the router's Neighbor Cache is full) as described in Section 6.5.2.
如果ARO未导致如上所述检测到重复地址，则如果注册生存期为非零，路由器将为NS的IPv6源地址创建（如果不存在）或更新（否则）NCE。如果邻居缓存已满且需要创建一个新条目，则路由器将按照第6.5.2节所述，使用单播NA响应，ARO状态字段设置为2（以指示路由器的邻居缓存已满）。
The Registration Lifetime and the EUI-64 are recorded in the NCE. A unicast NA is then sent in response to the NS. This NA SHOULD include a copy of the ARO, with the Status field set to zero. A TLLAO (Target Link-Layer Address Option) [RFC4861] is not required in the NA, since the host already knows the router's link-layer address from RAs.
注册寿命和EUI-64记录在NCE中。然后发送单播NA以响应NS。此NA应包括ARO的副本，状态字段设置为零。NA中不需要TLLAO（目标链路层地址选项）[RFC4861]，因为主机已经从RAs知道路由器的链路层地址。
If the ARO contains a zero Registration Lifetime, then any existing NCE for the IPv6 source address of the NS MUST be deleted and an NA sent as above.
如果ARO包含零注册生存期，则必须删除NS的IPv6源地址的任何现有NCE，并如上所述发送NA。
Should the Registration Lifetime in an NCE expire, then the router MUST delete the cache entry.
如果NCE中的注册生存期到期，则路由器必须删除缓存项。
The addition and removal of Registered NCEs would result in notifying the routing protocol.
添加和删除已注册NCE将导致通知路由协议。
Note: If the substitutable multihop DAD (Section 8.2) is used, then the updating of the Neighbor Cache is slightly different due to Tentative NCEs.
注意：如果使用了可替代的多跳DAD（第8.2节），则邻居缓存的更新会因延迟而略有不同。
In order to deliver a packet destined for a 6LN registered with a router, next-hop determination is slightly different for routers than for hosts (see Section 5.6). The routing table is checked to determine the next-hop IP address. A Registered NCE determines if the next-hop IP address is on-link. It is the responsibility of the routing protocol of the router to maintain on-link information about its registered neighbors. Tentative NCEs MUST NOT be used to determine on-link status of the registered nodes.
为了将数据包发送到路由器注册的6LN，路由器的下一跳确定与主机的下一跳确定略有不同（参见第5.6节）。检查路由表以确定下一跳IP地址。注册的NCE确定下一跳IP地址是否在链路上。路由器的路由协议负责维护其注册邻居的链路信息。不能使用临时通知来确定已注册节点的链路状态。
There needs to be a mechanism somewhere for the routers to discover each other's link-layer addresses. If the routing protocol used between the routers provides this, then there is no need for the routers to use the ARO between each other. Otherwise, the routers SHOULD use the ARO. When routers use the ARO to register with each other and multihop DAD (Section 8.2) is in use, then care must be taken to ensure that there isn't a flood of ARO-carrying messages sent to the 6LBR as each router hears an ARO from their neighboring routers. The details for this scenario are out of scope of this document.
路由器需要有一种机制来发现彼此的链路层地址。如果路由器之间使用的路由协议提供了这一点，那么路由器之间就不需要使用ARO。否则，路由器应使用ARO。当路由器使用ARO相互注册，且多跳DAD（第8.2节）正在使用时，必须注意确保当每个路由器听到来自其相邻路由器的ARO时，不会有大量ARO携带发送到6LBR的消息。此场景的详细信息超出了本文档的范围。
Routers MAY also use multicast NSs as in [RFC4861] to resolve each others link-layer addresses. Thus, routers MAY multicast NSs for other routers, for example, as a result of receiving some routing protocol update. Routers MUST respond to multicast NSs. This implies that routers MUST join the solicited-node multicast addresses as specified in [RFC4861].
路由器也可以使用[RFC4861]中的多播NSs来解析彼此的链路层地址。因此，例如，作为接收一些路由协议更新的结果，路由器可以为其他路由器多播NSs。路由器必须响应多播NSs。这意味着路由器必须加入[RFC4861]中指定的请求节点多播地址。
A 6LBR handles the sending of RAs and processing of NSs from hosts as specified above in Section 6. A 6LBR SHOULD always include an ABRO in the RAs it sends, listing itself as the 6LBR address. This requires that the 6LBR maintain the version number in stable storage and increase the version number when some information in its RAs changes. The information whose change affects the version is in the PIOs (the prefixes or their lifetimes) and in the 6CO (the prefixes, CIDs, or lifetimes).
6LBR按照上文第6节的规定处理从主机发送RAs和处理NSs。6LBR应始终在其发送的RAs中包含ABRO，并将其自身列为6LBR地址。这要求6LBR将版本号保存在稳定的存储器中，并在其RAs中的某些信息发生变化时增加版本号。其更改影响版本的信息位于PIO（前缀或其生存期）和6CO（前缀、CID或生存期）中。
In addition, a 6LBR is somehow configured with the prefix or prefixes that are assigned to the LoWPAN and advertises those in RAs as in [RFC4861]. In the case of route-over, those prefixes can be disseminated to all the 6LRs using the technique discussed in
此外，6LBR以某种方式配置了分配给LoWPAN的一个或多个前缀，并在RAs中播发这些前缀，如[RFC4861]所示。在route over的情况下，可以使用中讨论的技术将这些前缀分发到所有6LR
Section 8.1. However, there might be mechanisms outside of the scope of this document that can be used as a substitute for prefix dissemination in the route-over topology (see Section 1.4).
第8.1节。但是，可能存在本文件范围之外的机制，可替代拓扑上路由中的前缀传播（见第1.4节）。
If the 6LoWPAN uses header compression [RFC6282] with context, then the 6LBR needs to manage the CIDs and advertise those in RAs by including 6COs in its RAs so that directly attached hosts are informed about the CIDs. Below, we specify things to consider when the 6LBR needs to add, remove, or change the context information. In the case of route-over, the context information is disseminated to all the 6LRs using the technique discussed in Section 8, unless a different specification provides a substitute for this multihop distribution.
如果6LoWPAN在上下文中使用头压缩[RFC6282]，则6LBR需要管理CID，并通过在其RAs中包含6COs在RAs中公布这些CID，以便将CID通知直接连接的主机。下面，我们指定当6LBR需要添加、删除或更改上下文信息时要考虑的事项。在路由覆盖的情况下，使用第8节中讨论的技术将上下文信息传播给所有6LR，除非不同的规范提供了该多跳分布的替代品。
The prefix or prefixes used in a LoWPAN can be manually configured or can be acquired using DHCPv6 Prefix Delegation [RFC3633]. For a LoWPAN that is isolated from the network either permanently or occasionally, the 6LBR can assign a ULA prefix using [RFC4193]. The ULA prefix should be stored in stable storage so that the same prefix is used after a failure of the 6LBR. If the LoWPAN has multiple 6LBRs, then they should be configured with the same set of prefixes. The set of prefixes is included in the RA messages as specified in [RFC4861].
LoWPAN中使用的一个或多个前缀可以手动配置，也可以使用DHCPv6前缀委派[RFC3633]获取。对于永久或偶尔与网络隔离的低量程，6LBR可使用[RFC4193]分配ULA前缀。ULA前缀应存储在稳定的存储器中，以便在6LBR发生故障后使用相同的前缀。如果LoWPAN有多个6LBR，则应使用相同的前缀集对其进行配置。按照[RFC4861]中的规定，前缀集包含在RA消息中。
If the LoWPAN uses header compression [RFC6282] with context, then the 6LBR must be configured with context information and related CIDs. If the LoWPAN has multiple 6LBRs, then they MUST be configured with the same context information and CIDs. As noted in [RFC6282], maintaining consistency of context information is crucial for ensuring that packets will be decompressed correctly.
如果LoWPAN将头压缩[RFC6282]与上下文一起使用，则6LBR必须配置上下文信息和相关CID。如果LoWPAN有多个6LBR，则必须使用相同的上下文信息和CID对其进行配置。如[RFC6282]所述，保持上下文信息的一致性对于确保正确解压缩数据包至关重要。
The context information carried in RA messages originates at 6LBRs and must be disseminated to all the routers and hosts within the LoWPAN. RAs include one 6CO for each context.
RA消息中携带的上下文信息起源于6LBRs，必须传播到LoWPAN内的所有路由器和主机。RAs为每个上下文包括一个6CO。
For the dissemination of context information using the 6CO, a strict life cycle SHOULD be used in order to ensure that the context information stays synchronized throughout the LoWPAN. New context information SHOULD be introduced into the LoWPAN with C=0, to ensure that it is known by all nodes that may have to perform header decompression based on this context information. Only when it is reasonable to assume that this information was successfully disseminated SHOULD an option with C=1 be sent, enabling the actual use of the context information for compression.
对于使用6CO传播上下文信息，应使用严格的生命周期，以确保上下文信息在整个LoWPAN中保持同步。应将新的上下文信息引入C=0的LoWPAN，以确保所有可能必须基于此上下文信息执行头解压缩的节点都知道它。只有在合理地假设此信息已成功传播时，才应发送一个C=1的选项，从而允许实际使用上下文信息进行压缩。
Conversely, to avoid the situation where nodes send packets that make use of previous values of contexts -- which would result in ambiguity when receiving a packet that uses a recently changed context -- old values of a context SHOULD be taken out of use for a while before new values are assigned to this specific context. That is, in preparation for a change of context information, its dissemination SHOULD continue for at least MIN_CONTEXT_CHANGE_DELAY with C=0. Only when it is reasonable to assume that the fact that the context is now invalid was successfully disseminated should the CID be taken out of dissemination or reused with a different Context Prefix field. In the latter case, dissemination of the new value again SHOULD start with C=0, as above.
相反，为了避免节点发送使用以前的上下文值的数据包的情况——这在接收使用最近更改的上下文的数据包时会导致歧义——在将新值分配给该特定上下文之前，应该暂时停止使用上下文的旧值。也就是说，在为上下文信息的更改做准备时，其传播应至少在C=0的情况下持续至少MIN_context_change_延迟。只有在合理地假设上下文现在无效的事实已成功传播时，才应将CID从传播中取出或使用不同的上下文前缀字段重新使用。在后一种情况下，新值的传播应再次从C=0开始，如上所述。
Normally, in a 6LoWPAN multihop network, the RA messages are used to disseminate prefixes and context information to all the 6LRs in a route-over topology. If all routers are configured to use a substitute mechanism for such information distribution, any remaining use of the 6LoWPAN-ND mechanisms is governed by the substitute specification.
通常，在6LoWPAN多跳网络中，RA消息用于通过拓扑向路由中的所有6LR传播前缀和上下文信息。如果所有路由器都配置为使用替代机制进行此类信息分发，则6LoWPAN ND机制的任何剩余使用均受替代规范管辖。
There is also the option for a 6LR to perform multihop DAD (for IPv6 addresses not derived from an EUI-64) against a 6LBR in a route-over topology by using the DAR and DAC messages. This is substitutable because there might be other ways to either allocate a unique address, such as DHCPv6 [RFC3315], or use other future mechanisms for multihop DAD. Again, in this case, any remaining use of the 6LoWPAN-ND mechanisms is governed by the substitute specification.
6LR还可以选择使用DAR和DAC消息对路由拓扑中的6LBR执行多跳DAD（对于不是从EUI-64派生的IPv6地址）。这是可以替代的，因为可能有其他方法来分配唯一地址，例如DHCPv6[RFC3315]，或者使用其他未来的机制来实现多跳DAD。同样，在这种情况下，6LoWPAN ND机构的任何剩余使用均受替代规范的约束。
To be clear: Implementations MUST support the features described in Sections 8.1 and 8.2, unless the implementation supports some alternative ("substitute") from some other specification.
需要明确的是：实现必须支持第8.1节和第8.2节中描述的功能，除非实现支持其他规范中的某些替代（“替代”）。
The multihop distribution relies on RS messages and RA messages sent between routers, and using the ABRO version number to control the propagation of the information (prefixes and context information) that is being sent in the RAs.
多跳分发依赖于路由器之间发送的RS消息和RA消息，并使用ABRO版本号控制RAs中发送的信息（前缀和上下文信息）的传播。
This multihop distribution mechanism can handle arbitrary information from an arbitrary number of 6LBRs. However, the semantics of the context information requires that all the 6LNs use the same information whether they send, forward, or receive compressed packets. Thus, the manager of the 6LBRs needs to somehow ensure that the context information is in synchrony across the 6LBRs. This can be handled in different ways. One possible way to ensure it is to
这种多跳分发机制可以处理任意数量的6LBR中的任意信息。然而，上下文信息的语义要求所有6LN使用相同的信息，无论它们是发送、转发还是接收压缩包。因此，6LBRs的管理者需要以某种方式确保上下文信息在6LBRs之间是同步的。这可以用不同的方法处理。确保这一点的一个可能方法是
treat the context and prefix information as originating from some logical or virtual source, which in essence means that it looks like the information is distributed from a single source.
将上下文和前缀信息视为源自某个逻辑或虚拟源，这本质上意味着它看起来像是来自单个源的信息。
If a set of 6LBRs behave as a single one (using mechanisms out of scope of this document) so that the prefixes and contexts and the ABRO version number will be the same from all the 6LBRs, then those 6LBRs can pick a single IP address to use in the ABRO.
如果一组6LBR表现为单个6LBR（使用本文件范围外的机制），因此所有6LBR的前缀、上下文和ABRO版本号都相同，则这些6LBR可以选择一个IP地址用于ABRO。
6LBRs supporting multihop prefix and context distribution MUST include an ABRO in each of their RAs. The ABRO Version Number field is used to keep prefix and context information consistent throughout the LoWPAN, along with the guidelines in Section 7.2. Each time any information in the set of PIOs or 6COs changes, the ABRO version is increased by one.
支持多跳前缀和上下文分发的6LBR必须在每个RAs中包含ABRO。ABRO版本号字段用于在整个LoWPAN中保持前缀和上下文信息的一致性，以及第7.2节中的指南。每当PIO或6COs集合中的任何信息发生变化时，ABRO版本将增加一个。
This requires that the 6LBR maintain the PIO, 6CO, and ABRO Version Number in stable storage, since an old version number will be silently ignored by the 6LRs.
这要求6LBR将PIO、6CO和ABRO版本号保持在稳定的存储器中，因为旧版本号将被6LRs默默忽略。
In a 6LoWPAN, unless substituted, multihop distribution is done using RA messages. Thus, on interface initialization, a router (6LR) MUST send RS messages following the rules specified for hosts in [RFC4861]. This in turn will cause the routers to respond with RA messages that can then be used to initially seed the prefix and context information.
在6LoWPAN中，除非替换，否则多跳分发是使用RA消息完成的。因此，在接口初始化时，路由器（6LR）必须按照[RFC4861]中为主机指定的规则发送RS消息。这反过来会导致路由器响应RA消息，然后这些消息可用于最初对前缀和上下文信息进行种子设定。
If multihop distribution is not done using RA messages, then the routers follow [RFC4861], which states that they merely do some consistency checks; in this case, nothing in Section 8.1 applies. Otherwise, the routers will check and record the prefix and context information from the received RAs, and use that information as follows.
如果没有使用RA消息进行多跳分发，则路由器遵循[RFC4861]，这表明它们只进行一些一致性检查；在这种情况下，第8.1节中的任何内容均不适用。否则，路由器将检查并记录来自接收到的RAs的前缀和上下文信息，并按如下方式使用该信息。
If a received RA does not contain an ABRO, then the RA MUST be silently ignored.
如果接收到的RA不包含ABRO，则必须默默地忽略RA。
The router uses the 6LBR Address field in the ABRO to check if it has previously received information from the 6LBR. If it finds no such information, then it just records the 6LBR address, Version, Valid Lifetime, and the associated prefixes and context information. If the 6LBR is previously known, then the Version Number field MUST be
路由器使用ABRO中的6LBR地址字段来检查之前是否从6LBR接收到信息。如果没有找到此类信息，则只记录6LBR地址、版本、有效生存期以及相关的前缀和上下文信息。如果之前已知6LBR，则版本号字段必须为
compared against the recorded version number for that 6LBR. If the version number received in the packet is less than the stored version number, then the information in the RA is silently ignored. Otherwise, the recorded information and version number are updated.
与该6LBR的记录版本号进行比较。如果数据包中接收到的版本号小于存储的版本号，则RA中的信息将被静默忽略。否则，将更新记录的信息和版本号。
The router keeps state for each 6LBR that it sees with an ABRO. This includes the version number, the Valid Lifetime, and the complete set of PIOs and 6COs. The prefixes are timed out based on the Valid Lifetime in the PIO. The Context Prefix is timed out based on the Valid Lifetime in the 6CO.
路由器通过ABRO为其看到的每个6LBR保留状态。这包括版本号、有效生存期以及完整的PIO和6COs集。前缀将根据PIO中的有效生存期超时。上下文前缀根据6CO中的有效生存期超时。
While the prefixes and context information are stored in the router, their valid and preferred lifetimes are decremented as time passes. This ensures that when the router is in turn later advertising that information in the RAs it sends, the 'expiry time' doesn't accidentally move further into the future. For example, if a 6CO with a Valid Lifetime of 10 minutes is received at time T, and the router includes this in an RA it sends at time T+5 minutes, the Valid Lifetime in the 6CO it sends will be only 5 minutes.
当前缀和上下文信息存储在路由器中时，它们的有效和首选生存时间会随着时间的推移而减少。这确保了当路由器随后依次在其发送的RAs中发布该信息时，“到期时间”不会意外地进一步移动到将来。例如，如果在时间T接收到有效生存期为10分钟的6CO，并且路由器在时间T+5分钟时发送的RA中包含此内容，则其发送的6CO中的有效生存期将仅为5分钟。
When multihop distribution is performed using RA messages, the routers MUST ensure that the ABRO always stays together with the prefixes and context information received with that ABRO. Thus, if the router has received prefix P1 with an ABRO saying it is from one 6LBR, and prefix P2 from another 6LBR, then the router MUST NOT include the two prefixes in the same RA message. Prefix P1 MUST be in an RA that includes an ABRO from the first 6LBR, etc. Note that multiple 6LBRs might advertise the same prefix and context information, but they still need to be associated with the 6LBRs that advertised them.
当使用RA消息执行多跳分发时，路由器必须确保ABRO始终与该ABRO接收的前缀和上下文信息保持在一起。因此，如果路由器接收到前缀P1，ABRO表示它来自一个6LBR，而前缀P2来自另一个6LBR，则路由器不得在同一RA消息中包含这两个前缀。前缀P1必须位于RA中，该RA包括来自第一个6LBR的ABRO等。请注意，多个6LBR可能会公布相同的前缀和上下文信息，但它们仍然需要与公布它们的6LBR关联。
The routers periodically send RAs as in [RFC4861]. This is for the benefit of the other routers receiving the prefixes and context information. The routers also respond to RSs by unicasting RA messages. In both cases, the above constraint of keeping the ABRO together with 'its' prefixes and context information applies.
路由器定期发送RAs，如[RFC4861]所示。这有利于接收前缀和上下文信息的其他路由器。路由器还通过单播RA消息来响应RSs。在这两种情况下，上述将ABRO与“its”前缀和上下文信息保持在一起的约束都适用。
When a router receives new information from a 6LBR, that is, either it hears from a new 6LBR (a new 6LBR address in the ABRO) or the ABRO version number of an existing 6LBR has increased, then it is useful to send out a few triggered updates. The recommendation is to behave the same as when an interface has become an advertising interface as described in [RFC4861], that is, send up to three RA messages. This ensures rapid propagation of new information to all the 6LRs.
当路由器接收到来自6LBR的新信息时，即它从新6LBR（ABRO中的新6LBR地址）或现有6LBR的ABRO版本号增加，则发送一些触发更新是有用的。建议与[RFC4861]中所述的接口变为广告接口时的行为相同，即最多发送三条RA消息。这确保了新信息快速传播到所有6LR。
The ARO can be used, in addition to registering an address in a 6LR, to have the 6LR verify that the address isn't used by some other host known to the 6LR. However, that isn't sufficient in a route-over topology (or in a LoWPAN with multiple 6LBRs), since some host attached to another 6LR could be using the same address. There might be different ways for the 6LRs to coordinate such duplicate address detection in the future, or addresses could be assigned using a DHCPv6 server that verifies uniqueness as part of the assignment.
除了在6LR中注册地址外，还可以使用ARO让6LR验证该地址是否未被6LR已知的其他主机使用。但是，这在拓扑上的路由（或具有多个6LBR的LoWPAN）中是不够的，因为连接到另一个6LR的某些主机可能使用相同的地址。将来6LR可能有不同的方法来协调这种重复地址检测，或者可以使用DHCPv6服务器来分配地址，该服务器将验证唯一性作为分配的一部分。
This specification offers a substitutable simple technique for 6LRs and 6LBRs to perform DAD that reuses the information from the ARO in the DAR and DAC messages. This technique is not needed when the Interface ID in the address is based on an EUI-64, since those are assumed to be globally unique. The technique assumes that either the 6LRs register with all the 6LBRs or the network uses some out-of-scope mechanism to keep the DAD tables in the 6LBRs synchronized.
本规范为6LRs和6LBRs提供了一种可替代的简单技术来执行DAD，该技术重用DAR和DAC消息中来自ARO的信息。当地址中的接口ID基于EUI-64时，不需要这种技术，因为这些被认为是全局唯一的。该技术假设6LRs向所有6LBRs注册，或者网络使用一些超出范围的机制来保持6LBRs中的DAD表同步。
The multihop DAD mechanism is used synchronously the first time an address is registered with a particular 6LR. That is, the ARO is not returned to the host until multihop DAD has been completed against the 6LBRs. For existing registrations in the 6LR, multihop DAD needs to be repeated against the 6LBRs to ensure that the entry for the address in the 6LBRs does not time out, but that can be done asynchronously with the response to the hosts. One method to achieve this is to track how much is left of the lifetime the 6LR registered with the 6LBRs and to re-register with the 6LBR when this lifetime is about to run out.
第一次向特定6LR注册地址时，同步使用多跳DAD机制。也就是说，在针对6LBRs完成多跳DAD之前，ARO不会返回到主机。对于6LR中的现有注册，需要针对6LBRs重复多跳DAD，以确保6LBRs中的地址条目不会超时，但这可以通过对主机的响应异步完成。实现这一点的一种方法是跟踪6LR向6LBRs注册的生存期剩余多少，并在该生存期即将结束时重新向6LBR注册。
For synchronous multihop DAD, the 6LR performs some additional checks to ensure that it has an NCE it can use to respond to the host when it receives a response from a 6LBR. This consists of checking for an already existing (Tentative or Registered) NCE for the Registered Address with a different EUI-64. If such a Registered NCE exists, then the 6LR SHOULD respond that the address is a duplicate. If such a Tentative NCE exists, then the 6LR SHOULD silently ignore the ARO, thereby relying on the host retransmitting the ARO. This is needed to handle the case when multiple hosts try to register the same IPv6 address at the same time. If no NCE exists, then the 6LR MUST create a Tentative NCE with the EUI-64 and the SLLAO. This entry will be used to send the response to the host when the 6LBR responds positively.
对于同步多跳DAD，6LR执行一些额外的检查，以确保其具有NCE，可用于在接收到来自6LBR的响应时响应主机。这包括检查具有不同EUI-64的注册地址的已存在（暂定或注册）NCE。如果存在此类已注册的NCE，则6LR应响应该地址为重复地址。如果存在这样一个暂时的NCE，那么6LR应该默默地忽略ARO，从而依赖于主机重新传输ARO。当多台主机试图同时注册同一IPv6地址时，需要使用此选项。如果不存在NCE，则6LR必须使用EUI-64和SLLAO创建一个暂定NCE。当6LBR做出肯定响应时，此条目将用于向主机发送响应。
When a 6LR receives an NS containing an ARO with a non-zero Registration Lifetime and it has no existing Registered NCE, then with this mechanism the 6LR will invoke synchronous multihop DAD.
当6LR接收到一个NS，其中包含一个具有非零注册生存期的ARO，并且它没有现有的注册NCE时，6LR将使用此机制调用同步多跳DAD。
The 6LR will unicast a DAR message to one or more 6LBRs, where the DAR contains the host's address in the Registered Address field. The DAR will be forwarded by 6LRs until it reaches the 6LBR; hence, its IPv6 Hop Limit field will not be 255 when received by the 6LBR. The 6LBR will respond with a DAC message, which will have a hop limit less than 255 when it reaches the 6LR.
6LR将向一个或多个6LBR单播DAR消息，其中DAR在注册地址字段中包含主机地址。DAR将由6LRs转发，直到到达6LBR；因此，当6LBR接收到其IPv6跃点限制字段时，该字段不会为255。6LBR将以DAC消息响应，当到达6LR时，该消息的跃点限制将小于255。
When the 6LR receives the DAC from the 6LBR, it will look for a matching (same IP address and EUI-64) (Tentative or Registered) NCE. If no such entry is found, then the DAC is silently ignored. If an entry is found and the DAC had Status=0, then the 6LR will mark the Tentative NCE as Registered. In all cases, when an entry is found, then the 6LR will respond to the host with an NA, copying the Status and EUI-64 fields from the DAC to an ARO in the NA. In case the status is an error, then the destination IP address of the NA is derived from the EUI-64 field of the DAC.
当6LR从6LBR接收到DAC时，它将查找匹配的（相同的IP地址和EUI-64）（暂定或注册）NCE。如果没有找到这样的条目，则DAC将被静默忽略。如果找到条目且DAC的状态为0，则6LR将临时NCE标记为已注册。在所有情况下，当找到条目时，6LR将用NA响应主机，将状态和EUI-64字段从DAC复制到NA中的ARO。如果状态为错误，则从DAC的EUI-64字段导出NA的目标IP地址。
A Tentative NCE SHOULD be timed out TENTATIVE_NCE_LIFETIME seconds after it was created in order to allow for another host to attempt to register the IPv6 address.
临时NCE应在创建后的临时NCE生存期秒超时，以允许其他主机尝试注册IPv6地址。
A node MUST silently discard any received DAR and DAC messages for which at least one of the following validity checks is not satisfied:
节点必须以静默方式丢弃任何接收到的DAR和DAC消息，这些消息至少不满足以下有效性检查之一：
o If the message includes an IP Authentication Header, the message authenticates correctly.
o 如果消息包含IP身份验证标头，则消息将正确进行身份验证。
o ICMP Checksum is valid.
o ICMP校验和有效。
o ICMP Code is 0.
o ICMP代码为0。
o ICMP Length (derived from the IP length) is 32 or more bytes.
o ICMP长度（源自IP长度）为32个或更多字节。
o The Registered Address is not a multicast address.
o 注册地址不是多播地址。
o All included options have a length that is greater than zero.
o 所有包含的选项的长度都大于零。
o The IP source address is not the unspecified address, nor is it a multicast address.
o IP源地址不是未指定的地址，也不是多播地址。
The contents of the Reserved field and of any unrecognized options MUST be ignored. Future backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values.
必须忽略保留字段和任何无法识别的选项的内容。未来对协议的向后兼容更改可能会指定保留字段的内容或添加新选项；向后不兼容的更改可能使用不同的代码值。
Note that due to the forwarding of the DAR and DAC messages between the 6LR and 6LBR, there is no hop-limit check on receipt for these ICMPv6 message types.
请注意，由于在6LR和6LBR之间转发DAR和DAC消息，这些ICMPv6消息类型在接收时没有跃点限制检查。
A 6LBR implementing multihop DAD needs to maintain some state separate from the Neighbor Cache. We call this conceptual data structure the DAD table. It is indexed by the IPv6 address -- the Registered Address in the DAR -- and contains the EUI-64 and the Registration Lifetime of the host that is using that address.
实现多跳DAD的6LBR需要保持与邻居缓存分离的一些状态。我们称这种概念数据结构为DAD表。它由IPv6地址（DAR中的注册地址）编制索引，并包含EUI-64和使用该地址的主机的注册生存期。
When a 6LR that implements multihop DAD receives an NS from a host, and subject to the above checks, the 6LR forms and sends a DAR to at least one 6LBR. The DAR contains the following information:
当实现多跳DAD的6LR从主机接收到NS时，根据上述检查，6LR将形成DAR并向至少一个6LBR发送DAR。DAR包含以下信息：
o In the IPv6 source address, a global address of the 6LR.
o 在IPv6源地址中，6LR的全局地址。
o In the IPv6 destination address, the address of the 6LBR.
o 在IPv6目标地址中，6LBR的地址。
o In the IPv6 hop limit, MULTIHOP_HOPLIMIT.
o 在IPv6跃点限制中，多跳限制。
o The Status field MUST be set to zero.
o 状态字段必须设置为零。
o The EUI-64 and Registration Lifetime are copied from the ARO received from the host.
o EUI-64和注册生存期从从主机接收的ARO复制。
o The Registered Address set to the IPv6 address of the host, that is, the sender of the triggering NS.
o 注册地址设置为主机的IPv6地址，即触发NS的发送方。
When a 6LR receives an NS from a host with a zero Registration Lifetime, then, in addition to removing the NCE for the host as specified in Section 6, a DAR is sent to the 6LBRs as above.
当6LR从注册寿命为零的主机接收到NS时，除了按照第6节的规定删除主机的NCE外，还将如上所述向6LBRs发送DAR。
A router MUST NOT modify the Neighbor Cache as a result of receiving a DAR.
路由器不得因接收DAR而修改邻居缓存。
When a 6LBR that implements the substitutable multihop DAD receives a DAR from a 6LR, it performs the message validation specified in Section 8.2.1. If the DAR is valid, the 6LBR proceeds to look for the Registration Address in the DAD table. If an entry is found and the recorded EUI-64 is different than the EUI-64 in the DAR, then it
当实现可替代多跳DAD的6LBR从6LR接收到DAR时，它将执行第8.2.1节中规定的消息验证。如果DAR有效，6LBR继续在DAD表中查找注册地址。如果找到条目，并且记录的EUI-64与DAR中的EUI-64不同，则
returns a DAC NA with the Status set to 1 ('Duplicate Address'). Otherwise, it returns a DAC with Status set to zero and updates the lifetime.
返回状态设置为1（“重复地址”）的DAC NA。否则，它将返回一个状态设置为零的DAC并更新生存期。
If no entry is found in the DAD table and the Registration Lifetime is non-zero, then an entry is created and the EUI-64 and Registered Address from the DAR are stored in that entry.
如果在DAD表中找不到条目且注册生存期非零，则创建条目，并将来自DAR的EUI-64和注册地址存储在该条目中。
If an entry is found in the DAD table, the EUI-64 matches, and the Registration Lifetime is zero, then the entry is deleted from the table.
如果在DAD表中找到条目，EUI-64匹配，并且注册生存期为零，则该条目将从表中删除。
In both of the above cases, the 6LBR forms a DAC with the information copied from the DAR and the Status field is set to zero. The DAC is sent back to the 6LR, i.e., back to the source of the DAR. The IPv6 hop limit is set to MULTIHOP_HOPLIMIT.
在上述两种情况下，6LBR使用从DAR复制的信息形成DAC，并且状态字段设置为零。DAC发送回6LR，即返回DAR源。IPv6跃点限制设置为多跳限制。
When a 6LR implementing multihop DAD receives a DAC message, then it first validates the message per Section 8.2.1. For a valid DAC, if there is no Tentative NCE matching the Registered Address and EUI-64, then the DAC is silently ignored. Otherwise, the information in the DAC and in the Tentative NCE is used to form an NA to send to the host. The Status code is copied from the DAC to the ARO that is sent to the host. In the case where the DAC indicates an error (the Status is non-zero), the NA is returned to the host as described in Section 6.5.2, and the Tentative NCE for the Registered Address is removed. Otherwise, it is made into a Registered NCE.
当实现多跳DAD的6LR接收到DAC消息时，它首先根据第8.2.1节验证该消息。对于有效的DAC，如果没有与注册地址和EUI-64匹配的NCE，则DAC将被静默忽略。否则，DAC和NCE中的信息用于形成要发送到主机的NA。状态代码从DAC复制到发送到主机的ARO。如果DAC指示错误（状态为非零），则按照第6.5.2节所述将NA返回主机，并删除注册地址的暂定NCE。否则，它将成为一个注册的NCE。
A router MUST NOT modify the Neighbor Cache as a result of receiving a DAC, unless there is a Tentative NCE matching the IPv6 address and EUI-64.
路由器不得因接收DAC而修改邻居缓存，除非存在与IPv6地址和EUI-64匹配的临时NCE。
If there is no response from a 6LBR after RETRANS_TIMER [RFC4861], then the 6LR would retransmit the DAR to the 6LBR up to MAX_UNICAST_SOLICIT [RFC4861] times. After this, the 6LR SHOULD respond to the host with an ARO Status of zero.
如果在重新发送计时器[RFC4861]后6LBR没有响应，则6LR将向6LBR重新发送DAR，最多发送MAX_单播请求[RFC4861]次。在此之后，6LR应以零ARO状态响应主机。
This section defines the relevant protocol constants used in this document based on a subset of [RFC4861] constants. "*" indicates constants modified from [RFC4861], and "+" indicates new constants.
本节根据[RFC4861]常量的子集定义了本文件中使用的相关协议常量。“*”表示从[RFC4861]修改的常数，“+”表示新常数。
Additional protocol constants are defined in Section 4.
第4节定义了其他协议常数。
6LBR Constants:
6LBR常数：
MIN_CONTEXT_CHANGE_DELAY+ 300 seconds
最小上下文更改延迟+300秒
6LR Constants:
6LR常数：
MAX_RTR_ADVERTISEMENTS 3 transmissions
最多3次传输
MIN_DELAY_BETWEEN_RAS* 10 seconds
10秒之间的最小延迟
MAX_RA_DELAY_TIME* 2 seconds
最大延迟时间*2秒
TENTATIVE_NCE_LIFETIME+ 20 seconds
暂定寿命+20秒
Router Constants:
路由器常数：
MULTIHOP_HOPLIMIT+ 64
多跳限制+64
Host Constants:
主机常数：
RTR_SOLICITATION_INTERVAL* 10 seconds
RTR_请求间隔*10秒
MAX_RTR_SOLICITATIONS 3 transmissions
最大请求3次传输
MAX_RTR_SOLICITATION_INTERVAL+ 60 seconds
最大请求间隔+60秒
STEP
步
6LN 6LR
6Ln6LR
| |
| |
1. | ---------- Router Solicitation --------> |
1. | ---------- Router Solicitation --------> |
| [SLLAO] |
|[老挝语]|
| |
| |
2. | <-------- Router Advertisement --------- |
2. | <-------- Router Advertisement --------- |
| [PIO + 6CO + ABRO + SLLAO] |
| [PIO + 6CO + ABRO + SLLAO] |
Figure 2: Basic Router Solicitation/Router Advertisement Exchange between a Node and a 6LR or 6LBR
图2：节点与6LR或6LBR之间的基本路由器请求/路由器广告交换
6LN 6LR
6Ln6LR
| |
| |
1. | ------- NS with Address Registration ------> |
1. | ------- NS with Address Registration ------> |
| [ARO + SLLAO] |
|[ARO+SLLAO]|
| |
| |
2. | <----- NA with Address Registration -------- |
2. | <----- NA with Address Registration -------- |
| [ARO with Status] |
|[具有身份的ARO]|
Figure 3: Neighbor Discovery Address Registration
图3：邻居发现地址注册
6LN 6LR 6LBR
6Ln6LR6LBR
| | |
| | |
1. | --- NS with Address Reg --> | |
1. | --- NS with Address Reg --> | |
| [ARO + SLLAO] | |
| [ARO + SLLAO] | |
| | |
| | |
2. | | ----------- DAR ----------> |
2. | | ----------- DAR ----------> |
| | |
| | |
3. | | <---------- DAC ----------- |
3. | | <---------- DAC ----------- |
| | |
| | |
4. | <-- NA with Address Reg --- | |
4. | <-- NA with Address Reg --- | |
| [ARO with Status] |
|[具有身份的ARO]|
Figure 4: Neighbor Discovery Address Registration with Multihop DAD
图4：使用多跳DAD注册邻居发现地址
The following example describes the address bootstrapping scenarios using the improved ND mechanisms specified in this document. It is assumed that the 6LN first performs a sequence of operations in order to get secure access at the link layer of the LoWPAN and obtain a key for link-layer security. The methods of how to establish link-layer security are out of scope of this document. In this example, an IEEE 802.15.4 6LN forms a 16-bit short IPv6 address without using DHCPv6 (i.e., the M flag is not set in the RAs).
下面的示例描述了使用本文档中指定的改进ND机制的地址引导方案。假设6LN首先执行一系列操作，以便在LoWPAN的链路层获得安全访问并获得链路层安全密钥。如何建立链接层安全性的方法超出了本文档的范围。在此示例中，IEEE 802.15.4 6LN在不使用DHCPv6的情况下形成16位短IPv6地址（即，RAs中未设置M标志）。
1. After obtaining link-layer security, a 6LN assigns a link-local IPv6 address to itself. A link-local IPv6 address is configured based on the 6LN's EUI-64 link-layer address formed as per [RFC4944].
1. 在获得链路层安全性后，6LN将链路本地IPv6地址分配给自身。根据[RFC4944]形成的6LN的EUI-64链路层地址配置链路本地IPv6地址。
2. Next, the 6LN determines one or more default routers in the network by sending an RS to the all-routers multicast address with the SLLAO set to its EUI-64 link-local address. If the 6LN was able to obtain the link-layer address of a router through its link-layer operations, then the 6LN may form a link-local destination IPv6 address for the router and send it a unicast RS.
2. 接下来，6LN通过将SLLAO设置为其EUI-64链路本地地址向所有路由器多播地址发送RS来确定网络中的一个或多个默认路由器。如果6LN能够通过其链路层操作获得路由器的链路层地址，则6LN可以形成路由器的链路本地目的地IPv6地址并向其发送单播RS。
The 6LR responds with a unicast RA to the IP source address using the SLLAO from the RS (it may have created a Tentative NCE). See Figure 2.
6LR使用来自RS的SLLAO以单播RA响应IP源地址（它可能创建了一个临时NCE）。参见图2。
3. In order to communicate more than one IP hop away, the 6LN configures a global IPv6 address. In order to save overhead, this 6LN wishes to configure its IPv6 address based on a 16-bit short address as per [RFC4944]. As the network is unmanaged (M flag not set in the RA), the 6LN randomly chooses a 16-bit link-layer address and forms a Tentative IPv6 address from it.
3. 为了与多个IP跃点进行通信，6LN配置了一个全局IPv6地址。为了节省开销，此6LN希望根据[RFC4944]基于16位短地址配置其IPv6地址。由于网络处于非托管状态（RA中未设置M标志），6LN随机选择一个16位链路层地址，并从中形成一个暂定IPv6地址。
4. Next, the 6LN registers that address with one or more of its default routers by sending a unicast NS message with an ARO containing its Tentative global IPv6 address to register, the Registration Lifetime, and its EUI-64. An SLLAO is also included with the link-layer address corresponding to the address being registered. If a successful (Status 0) NA message is received, the address can then be used, and the 6LN assumes that it has been successfully checked for duplicates. If a duplicate address (Status 1) NA message is received, the 6LN then removes the temporary IPv6 address and 16-bit link-layer address and goes back to step 3. If a Neighbor Cache Full (Status 2) message is received, the 6LN attempts to register with another default router or, if none, goes back to step 2. See Figure 3. Note that an NA message returning an error would be sent back to the link-local EUI-64-based IPv6 address of the 6LN instead of the 16-bit (duplicate) address.
4. 接下来，6LN通过发送一条单播NS消息，其中包含要注册的暂定全局IPv6地址、注册生存期和EUI-64的ARO，向其一个或多个默认路由器注册该地址。SLLAO还包括与正在注册的地址对应的链路层地址。如果收到成功（状态0）NA消息，则可以使用该地址，6LN假定已成功检查该地址是否重复。如果收到重复地址（状态1）NA消息，则6LN将删除临时IPv6地址和16位链路层地址，并返回步骤3。如果收到邻居缓存已满（状态2）消息，6LN将尝试向另一个默认路由器注册，如果没有，则返回步骤2。参见图3。请注意，返回错误的NA消息将发送回6LN的链路本地基于EUI-64的IPv6地址，而不是16位（重复）地址。
5. The 6LN now performs maintenance by sending a new NS address registration before the lifetime expires.
5. 6LN现在通过在生存期到期之前发送新的NS地址注册来执行维护。
If multihop DAD and multihop prefix and context distribution are used, the effect of the 6LRs and hosts following the above bootstrapping process is a "wavefront" of 6LRs and hosts being configured, spreading outward from the 6LBRs: First, the hosts and 6LRs that can directly reach a 6LBR would receive one or more RAs and then configure and register their IPv6 addresses. Once that is done, they would enable the routing protocol and start sending out RAs. That would result in a new set of 6LRs and hosts to receive responses to their RSs, form and register their addresses, etc. That repeats until all of the 6LRs and hosts have been configured.
如果使用多跳DAD和多跳前缀以及上下文分布，则在上述引导过程之后，6LRs和主机的效果是6LRs和主机被配置的“波前”，从6LBRs向外扩散：首先，可以直接到达6LBR的主机和6LR将接收一个或多个RAs，然后配置并注册其IPv6地址。一旦完成，他们将启用路由协议并开始发送RAs。这将产生一组新的6LR和主机，以接收对其RSs的响应，形成并注册其地址等。这些响应将重复，直到所有6LR和主机都已配置完毕。
This section provides specific message examples related to the bootstrapping process described above. When discussing messages, the following notation is used:
本节提供与上述引导过程相关的特定消息示例。讨论信息时，使用以下符号：
LL64: Link-local address based on the EUI-64, which is also the 802.15.4 long address.
LL64：基于EUI-64的链路本地地址，也是802.15.4长地址。
GP16: Global address based on the 802.15.4 short address. This address may not be unique.
GP16：基于802.15.4短地址的全局地址。此地址可能不是唯一的。
GP64: Global addresses derived from the EUI-64 address as specified in [RFC4944].
GP64：从[RFC4944]中指定的EUI-64地址派生的全局地址。
MAC64: EUI-64 address used as the link-layer address.
MAC64:用作链路层地址的EUI-64地址。
MAC16: IEEE 802.15.4 16-bit short address.
MAC16:IEEE 802.15.4 16位短地址。
Note that some implementations may use LL64 and GP16 style addresses instead of LL64 and GP64. In the following, we will show an example message flow as to how a node uses LL64 to register a GP16 address for multihop DAD verification.
注意，一些实现可能使用LL64和GP16样式的地址，而不是LL64和GP64。在下面，我们将展示一个示例消息流，说明节点如何使用LL64注册用于多跳DAD验证的GP16地址。
6LN-----RS-------->6LR
Src= LL64 (6LN)
Dst= all-router-link-scope-multicast
SLLAO= MAC64 (6LN)
6LN-----RS-------->6LR
Src= LL64 (6LN)
Dst= all-router-link-scope-multicast
SLLAO= MAC64 (6LN)
6LR------RA--------->6LN
Src= LL64 (6LR)
Dst= LL64 (6LN)
6LR------RA--------->6LN
Src= LL64 (6LR)
Dst= LL64 (6LN)
Note: Source address of RA must be a link-local address (Section 4.2 of RFC 4861).
注：RA的源地址必须是链路本地地址（RFC 4861第4.2节）。
6LN-------NS Reg------>6LR
Src= GP16 (6LN)
Dst= LL64 (6LR)
ARO
SLLAO= MAC16 (6LN)
6LN-------NS Reg------>6LR
Src= GP16 (6LN)
Dst= LL64 (6LR)
ARO
SLLAO= MAC16 (6LN)
6LR---------DAR----->6LBR
Src= GP64 or GP16 (6LR)
Dst= GP64 or GP16 (6LBR)
Registered Address= GP16 (6LN) and EUI-64 (6LN)
6LR---------DAR----->6LBR
Src= GP64 or GP16 (6LR)
Dst= GP64 or GP16 (6LBR)
Registered Address= GP16 (6LN) and EUI-64 (6LN)
6LBR-------DAC--------->6LR
Src= GP64 or GP16 (6LBR)
Dst= GP64 or GP16 (6LR)
Copy of information from DAR
6LBR-------DAC--------->6LR
Src= GP64 or GP16 (6LBR)
Dst= GP64 or GP16 (6LR)
Copy of information from DAR
If Status is a success:
如果状态为成功：
6LR ---------NA-Reg------->6LN
Src= LL64 (6LR)
Dst= GP16 (6LN)
ARO with Status = 0
6LR ---------NA-Reg------->6LN
Src= LL64 (6LR)
Dst= GP16 (6LN)
ARO with Status = 0
If Status is not a success:
如果状态不是成功：
6LR ---------NA-Reg-------->6LN
Src= LL64 (6LR)
Dst= LL64 (6LN) --> Derived from the EUI-64 of ARO
ARO with Status > 0
6LR ---------NA-Reg-------->6LN
Src= LL64 (6LR)
Dst= LL64 (6LN) --> Derived from the EUI-64 of ARO
ARO with Status > 0
Figure 5: Detailed Message Address Examples
图5：详细的消息地址示例
In the route-over topology, when a routing protocol is run across 6LRs, the bootstrapping and Neighbor Cache management are handled a little differently. The description in this paragraph provides only a guideline for an implementation.
在route over拓扑中，当路由协议在6LR上运行时，引导和邻居缓存管理的处理方式略有不同。本段中的说明仅提供实施指南。
At the initialization of a 6LR, it may choose to bootstrap as a host with the help of a parent 6LR if the substitutable multihop DAD is performed with the 6LBR. The Neighbor Cache management of a router and address resolution among the neighboring routers are described in Sections 6.5.3 and 6.5.5, respectively. In this example, we assume that the neighboring 6LoWPAN link is secure.
在6LR初始化时，如果使用6LBR执行可替换的多跳DAD，则它可以选择在父6LR的帮助下作为主机引导。路由器的邻居缓存管理和相邻路由器之间的地址解析分别在第6.5.3和6.5.5节中描述。在本例中，我们假设相邻的6LoWPAN链路是安全的。
In this scenario, the bootstrapping 6LR, 'R1', is multiple hops away from the 6LBR and surrounded by other 6LR neighbors. Initially, R1 behaves as a host. It sends a multicast RS and receives an RA from one or more neighboring 6LRs. R1 picks one 6LR as its temporary default router and performs address resolution via this default router. Note that if multihop DAD is not required (e.g., in a managed network or using EUI-64-based addresses), then it does not need to pick a temporary default router; however, it may still want to send the initial RS message if it wants to autoconfigure its address with the global prefix disseminated by the 6LBR.
在这种情况下，引导6LR“R1”是距离6LBR的多个跃点，并被其他6LR邻居包围。最初，R1作为主机运行。它发送多播RS并从一个或多个相邻的6LR接收RA。R1选择一个6LR作为其临时默认路由器，并通过该默认路由器执行地址解析。注意，如果不需要多跳DAD（例如，在托管网络中或使用基于EUI-64的地址），则不需要选择临时默认路由器；但是，如果它想用6LBR传播的全局前缀自动配置其地址，它可能仍然希望发送初始RS消息。
Based on the information received in the RAs, R1 updates its cache with entries for all the neighboring 6LRs. Upon completion of the address registration, the bootstrapping router deletes the temporary entry of the default router, and the routing protocol is started.
根据RAs中接收到的信息，R1使用所有相邻6LR的条目更新其缓存。地址注册完成后，引导路由器删除默认路由器的临时条目，并启动路由协议。
Also note that R1 may refresh its multihop DAD registration directly with the 6LBR (using the next-hop neighboring 6LR determined by the routing protocol for reaching the 6LBR).
还要注意的是，R1可以直接用6LBR刷新其多跳DAD注册（使用路由协议确定的下一跳相邻6LR到达6LBR）。
In this example, there are three 6LRs: R1, R2, and R3. Initially, when R2 boots, it sees only R1, and accordingly R2 creates an NCE for R1. Now assume that R2 receives a valid routing update from router R3. R2 does not have any NCE for R3. If the implementation of R2 supports detecting link-layer addresses from the routing information packets, then it directly updates its Neighbor Cache using that link-layer information. If this is not possible, then R2 should perform multicast NS with the source set with its link-local or global address, depending on the scope of the source IP address received in the routing update packet. The target address of the NS message is the source IPv6 address of the received routing update packet. The format of the NS message is as described in Section 4.3 of [RFC4861].
在本例中，有三个6LR:R1、R2和R3。最初，当R2引导时，它只看到R1，因此R2为R1创建一个NCE。现在假设R2从路由器R3接收到有效的路由更新。R2对R3没有任何NCE。如果R2的实现支持从路由信息包中检测链路层地址，那么它将使用该链路层信息直接更新其邻居缓存。如果这是不可能的，那么R2应该根据路由更新包中接收到的源IP地址的范围，使用其链路本地或全局地址设置的源来执行多播NS。NS消息的目标地址是接收到的路由更新数据包的源IPv6地址。NS消息的格式如[RFC4861]第4.3节所述。
More generally, any 6LR that receives a valid route update from a neighboring router for which it does not have any NCE is required to update its Neighbor Cache as described above.
更一般地说，任何6LR从没有任何NCE的相邻路由器接收有效路由更新，都需要如上所述更新其相邻缓存。
The router (6LR and 6LBR) IP addresses learned via ND are not redistributed to the routing protocol.
通过ND获取的路由器（6LR和6LBR）IP地址不会重新分配到路由协议。
The security considerations of IPv6 ND [RFC4861] and address autoconfiguration [RFC4862] apply. Additional considerations can be found in [RFC3756].
IPv6 ND[RFC4861]和地址自动配置[RFC4862]的安全注意事项适用。有关其他注意事项，请参见[RFC3756]。
There is a slight modification to those considerations, due to the fact that in this specification the M flag in the RAs disables the use of stateless address autoconfiguration for addresses not derived from EUI-64. Thus, a rogue router on the link can force the use of only DHCP for short addresses, whereas in [RFC4861] and [RFC4862] the rogue router could only cause the addition of DHCP and not disable stateless address autoconfiguration for short addresses.
由于在本规范中，RAs中的M标志禁止对非从EUI-64派生的地址使用无状态地址自动配置，因此对这些注意事项稍作修改。因此，链路上的恶意路由器可以强制短地址仅使用DHCP，而在[RFC4861]和[RFC4862]中，恶意路由器只能导致添加DHCP，而不能禁用短地址的无状态地址自动配置。
This specification assumes that the link layer is sufficiently protected -- for instance, by using MAC-sublayer cryptography. Thus, its threat model is no different from that of IPv6 ND [RFC4861]. The first trust model listed in Section 3 of [RFC3756] applies here. However, any future 6LoWPAN security protocol that applies to ND for the 6LoWPAN protocol is out of scope of this document.
本规范假设链路层受到充分保护——例如，通过使用MAC子层加密。因此，其威胁模型与IPv6 ND[RFC4861]的威胁模型没有什么不同。[RFC3756]第3节中列出的第一个信任模型适用于此处。但是，适用于ND的任何未来6LoWPAN安全协议不在本文档范围内。
The multihop DAD mechanisms rely on DAR and DAC messages that are forwarded by 6LRs, and as a result the hop_limit=255 check on the receiver does not apply to those messages. This implies that any node on the Internet could successfully send such messages. We avoid any additional security issues due to this by requiring that the routers never modify the NCE due to such messages, and that they discard them unless they are received on an interface that has been explicitly configured to use these optimizations.
多跳DAD机制依赖于由6LRs转发的DAR和DAC消息，因此接收器上的hop_limit=255检查不适用于这些消息。这意味着Internet上的任何节点都可以成功发送此类消息。我们通过要求路由器从不因此类消息而修改NCE，并要求它们丢弃NCE，除非它们是在已明确配置为使用这些优化的接口上接收的，从而避免由此产生的任何附加安全问题。
In some future deployments, one might want to use SEcure Neighbor Discovery (SEND) [RFC3971] [RFC3972]. This is possible with the ARO as sent between hosts and routers, since the address that is being registered is the IPv6 source address of the NS and SEND verifies the IPv6 source address of the packet. Applying SEND to the router-to-router communication in this document is out of scope.
在未来的一些部署中，可能需要使用安全邻居发现（SEND）[RFC3971][RFC3972]。这在主机和路由器之间发送ARO时是可能的，因为正在注册的地址是NS的IPv6源地址，SEND验证数据包的IPv6源地址。在本文档中应用发送到路由器到路由器的通信超出范围。
This document registers three new ND option types under the subregistry "IPv6 Neighbor Discovery Option Formats":
本文档在子区域“IPv6邻居发现选项格式”下注册了三种新的ND选项类型：
o Address Registration Option (33) o 6LoWPAN Context Option (34) o Authoritative Border Router Option (35)
o 地址注册选项（33）o 6LoWPAN上下文选项（34）o权威边界路由器选项（35）
The document registers two new ICMPv6 "type" numbers under the subregistry "ICMPv6 "type" Numbers":
本文件在子区域“ICMPv6”类型“编号”下登记了两个新的ICMPv6“类型”编号：
o Duplicate Address Request (157) o Duplicate Address Confirmation (158)
o 重复地址请求（157）o重复地址确认（158）
IANA has also created a new subregistry for the Status values of the Address Registration Option, under the ICMPv6 parameters registry.
IANA还在ICMPv6参数注册表下为地址注册选项的状态值创建了一个新的子域。
Address Registration Option Status Values registry:
地址注册选项状态值注册表：
o Possible values are 8-bit unsigned integers (0..255). o Registration procedure is "Standards Action" [RFC5226]. o Initial allocation is as indicated in Table 2:
o 可能的值是8位无符号整数（0..255）。o注册程序为“标准行动”[RFC5226]。o初始分配如表2所示：
+--------+--------------------------------------------+
| Status | Description |
+--------+--------------------------------------------+
| 0 | Success |
| 1 | Duplicate Address |
| 2 | Neighbor Cache Full |
| 3-255 | Allocated using Standards Action [RFC5226] |
+--------+--------------------------------------------+
+--------+--------------------------------------------+
| Status | Description |
+--------+--------------------------------------------+
| 0 | Success |
| 1 | Duplicate Address |
| 2 | Neighbor Cache Full |
| 3-255 | Allocated using Standards Action [RFC5226] |
+--------+--------------------------------------------+
Table 2
表2
There are two classes of ND extensions that interact with this specification in different ways.
有两类ND扩展以不同的方式与该规范交互。
One class encompasses extensions to the DAD mechanisms in [RFC4861] and [RFC4862]. An example of this is Optimistic DAD [RFC4429]. Such extensions do not apply when this specification is being used, since it uses ARO for DAD (which is neither optimistic nor pessimistic -- always one round trip to the router to check DAD).
一个类包含[RFC4861]和[RFC4862]中DAD机制的扩展。乐观型DAD[RFC4429]就是一个例子。当使用此规范时，此类扩展不适用，因为它使用ARO for DAD（这既不是乐观的，也不是悲观的——总是一次往返于路由器以检查DAD）。
All other (non-DAD) ND extensions, be they path selection types like default router preferences [RFC4191], configuration types like DNS configuration [RFC6106], or other types like Detecting Network Attachment [RFC6059], are completely orthogonal to this specification and will work as is.
所有其他（非DAD）ND扩展，无论是默认路由器首选项[RFC4191]之类的路径选择类型、DNS配置[RFC6106]之类的配置类型，还是检测网络连接[RFC6059]之类的其他类型，都与本规范完全正交，并将按原样工作。
This section discusses guidelines of new protocol features defined in this document. It also sets some expectations for implementation and deployment of these features. This section is informative in nature: it does not override the detailed specifications of the previous sections but summarizes them and presents them in a compact form, to be used as checklists. The checklists act as guidelines to indicate the possible importance of a feature in terms of a deployment as per information available as of the writing of the document. Note that in some cases the deployment is 'SHOULD' where the implementation is
本节讨论本文档中定义的新协议功能的指南。它还为这些特性的实现和部署设定了一些期望。本节本质上是信息性的：它不覆盖前面章节的详细规范，而是对其进行总结，并以紧凑的形式呈现，用作检查表。检查表作为指导原则，根据文档编写时可用的信息，指示功能在部署方面可能的重要性。请注意，在某些情况下，部署是“应该”的，而实现是“应该”的
a 'MUST'. This is due to the presence of substitutable features; the deployment may use alternative methods for those. Therefore, implementing a configuration knob is recommended for the substitutable features. The lists emphasize conciseness over completeness.
“必须”。这是由于存在可替代的特征；部署可能会使用其他方法来解决这些问题。因此，建议为可替代功能安装配置旋钮。这些清单强调简洁而不是完整。
+----------+-----------------------------------+--------+-----------+
| Section | Description | Deploy | Implement |
+----------+-----------------------------------+--------+-----------+
| 3.1 | Host-initiated RA | MUST | MUST |
| 3.2 | EUI-64-based IPv6 address | MUST | MUST |
| | 16-bit MAC-based address | MAY | SHOULD |
| | Other non-unique addresses | MAY | MAY |
| 3.3 | Host-initiated RS | MUST | MUST |
| | ABRO processing | SHOULD | MUST |
| 4.1 | Registration with ARO | MUST | MUST |
| 4.2, 5.4 | 6CO | SHOULD | SHOULD |
| 5.2 | Joining solicited-node multicast | N/A | N/A |
| | Joining all-nodes multicast | MUST | MUST |
| | Using link-layer indication for | MAY | MAY |
| | NUD | | |
| 5.5 | 6LoWPAN-ND NUD | MUST | MUST |
| 5.8.2 | Behavior on wakeup | SHOULD | SHOULD |
+----------+-----------------------------------+--------+-----------+
+----------+-----------------------------------+--------+-----------+
| Section | Description | Deploy | Implement |
+----------+-----------------------------------+--------+-----------+
| 3.1 | Host-initiated RA | MUST | MUST |
| 3.2 | EUI-64-based IPv6 address | MUST | MUST |
| | 16-bit MAC-based address | MAY | SHOULD |
| | Other non-unique addresses | MAY | MAY |
| 3.3 | Host-initiated RS | MUST | MUST |
| | ABRO processing | SHOULD | MUST |
| 4.1 | Registration with ARO | MUST | MUST |
| 4.2, 5.4 | 6CO | SHOULD | SHOULD |
| 5.2 | Joining solicited-node multicast | N/A | N/A |
| | Joining all-nodes multicast | MUST | MUST |
| | Using link-layer indication for | MAY | MAY |
| | NUD | | |
| 5.5 | 6LoWPAN-ND NUD | MUST | MUST |
| 5.8.2 | Behavior on wakeup | SHOULD | SHOULD |
+----------+-----------------------------------+--------+-----------+
Table 3: Guideline for 6LoWPAN-ND Features for Hosts
表3：主机6LoWPAN ND功能指南
+---------------+-------------------------+------------+------------+
| Section | Description | Deploy | Implement |
+---------------+-------------------------+------------+------------+
| 3.1 | Periodic RA | SHOULD NOT | SHOULD NOT |
| 3.2 | Address assignment | SHOULD | MUST |
| | during startup | | |
| 3.3 | Supporting EUI-64-based | MUST | MUST |
| | MAC hosts | | |
| | Supporting 16-bit MAC | MAY | SHOULD |
| | hosts | | |
| 3.4, 4.3, | ABRO processing/sending | SHOULD | MUST |
| 8.1.3, 8.1.4 | | | |
| 8.1 | Multihop prefix storing | SHOULD | MUST |
| | and redistribution | | |
| 3.5 | Tentative NCE | MUST | MUST |
| 8.2 | Multihop DAD | SHOULD | MUST |
| 4.1, 6.5, | ARO support | MUST | MUST |
| 6.5.1 - 6.5.5 | | | |
| 4.2 | 6CO | SHOULD | SHOULD |
| 6.3 | Process RS/ABRO | MUST | MUST |
+---------------+-------------------------+------------+------------+
+---------------+-------------------------+------------+------------+
| Section | Description | Deploy | Implement |
+---------------+-------------------------+------------+------------+
| 3.1 | Periodic RA | SHOULD NOT | SHOULD NOT |
| 3.2 | Address assignment | SHOULD | MUST |
| | during startup | | |
| 3.3 | Supporting EUI-64-based | MUST | MUST |
| | MAC hosts | | |
| | Supporting 16-bit MAC | MAY | SHOULD |
| | hosts | | |
| 3.4, 4.3, | ABRO processing/sending | SHOULD | MUST |
| 8.1.3, 8.1.4 | | | |
| 8.1 | Multihop prefix storing | SHOULD | MUST |
| | and redistribution | | |
| 3.5 | Tentative NCE | MUST | MUST |
| 8.2 | Multihop DAD | SHOULD | MUST |
| 4.1, 6.5, | ARO support | MUST | MUST |
| 6.5.1 - 6.5.5 | | | |
| 4.2 | 6CO | SHOULD | SHOULD |
| 6.3 | Process RS/ABRO | MUST | MUST |
+---------------+-------------------------+------------+------------+
Table 4: Guideline for 6LR Features in 6LoWPAN-ND
表4:6LoWPAN ND中6LR功能的指南
+--------------+--------------------------+------------+------------+
| Section | Description | Deploy | Implement |
+--------------+--------------------------+------------+------------+
| 3.1 | Periodic RA | SHOULD NOT | SHOULD NOT |
| 3.2 | Address autoconf on | MUST NOT | MUST NOT |
| | router interface | | |
| 3.3 | EUI-64 MAC support on | MUST | MUST |
| | 6LoWPAN interface | | |
| 8.1 - 8.1.1, | Multihop prefix | SHOULD | MUST |
| 8.1.5 | distribution | | |
| 8.2 | Multihop DAD | SHOULD | MUST |
+--------------+--------------------------+------------+------------+
+--------------+--------------------------+------------+------------+
| Section | Description | Deploy | Implement |
+--------------+--------------------------+------------+------------+
| 3.1 | Periodic RA | SHOULD NOT | SHOULD NOT |
| 3.2 | Address autoconf on | MUST NOT | MUST NOT |
| | router interface | | |
| 3.3 | EUI-64 MAC support on | MUST | MUST |
| | 6LoWPAN interface | | |
| 8.1 - 8.1.1, | Multihop prefix | SHOULD | MUST |
| 8.1.5 | distribution | | |
| 8.2 | Multihop DAD | SHOULD | MUST |
+--------------+--------------------------+------------+------------+
Table 5: Guideline for 6LBR Features in 6LoWPAN-ND
表5:6LoWPAN ND中6LBR功能的指南
The authors thank Pascal Thubert, Jonathan Hui, Richard Kelsey, Geoff Mulligan, Julien Abeille, Alexandru Petrescu, Peter Siklosi, Pieter De Mil, Fred Baker, Anthony Schoofs, Phil Roberts, Daniel Gavelle, Joseph Reddy, Robert Cragie, Mathilde Durvy, Colin O'Flynn, Dario Tedeschi, Esko Dijk, and Joakim Eriksson for useful discussions and comments that have helped shape and improve this document.
作者感谢Pascal Thubert、Jonathan Hui、Richard Kelsey、Geoff Mulligan、Julien Abeille、Alexandru Petrescu、Peter Siklosi、Pieter De Mil、Fred Baker、Anthony Schoofs、Phil Roberts、Daniel Gavelle、Joseph Reddy、Robert Cragie、Mathilde Durvy、Colin O'Flynn、Dario Tedeschi、Esko Dijk、，和Joakim Eriksson进行了有益的讨论和评论，这些讨论和评论有助于形成和改进本文件。
Additionally, the authors would like to recognize Pascal Thubert for contributing the original registration idea and for extensive contributions to earlier versions of the document, Jonathan Hui for original ideas on prefix/context distribution and extensive contributions to earlier versions of the document, Colin O'Flynn for useful "Error-to" suggestions (Section 6.5.2) and for contributions to the Examples section, Geoff Mulligan for suggesting the use of address registration as part of existing IPv6 ND messages, and Mathilde Durvy for helping to clarify router interaction.
此外，作者还想表彰Pascal Thubert对原始注册理念的贡献以及对早期版本文件的广泛贡献，Jonathan Hui对前缀/上下文分布的原创理念以及对早期版本文件的广泛贡献，Colin O'Flynn对有用的“错误到”建议（第6.5.2节）和对示例部分的贡献，Geoff Mulligan建议将地址注册作为现有IPv6 ND消息的一部分，Mathilde Durvy帮助澄清路由器交互。
[ETHERNET] "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", IEEE Std 802.3-2008, December 2008, <http://standards.ieee.org/getieee802/download/ 802.3-2008_section1.pdf>.
[以太网]“IEEE信息技术标准-系统间远程通信和信息交换-局域网和城域网-特定要求-第3部分：带冲突检测的载波侦听多址接入（CSMA/CD）接入方法和物理层规范”，IEEE Std 802.3-2008，2008年12月， <http://standards.ieee.org/getieee802/download/ 802.3-2008\u section1.pdf>。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999.
[RFC2491]Armitage，G.，Schulter，P.，Jork，M.，和G.Harter，“非广播多址（NBMA）网络上的IPv6”，RFC 2491，1999年1月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年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月。
[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月。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 49442007年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011.
[RFC6282]Hui，J.和P.Thubert，“基于IEEE 802.15.4的网络上IPv6数据报的压缩格式”，RFC 6282，2011年9月。
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64(TM)) Registration Authority", <http:// standards.ieee.org/regauth/oui/tutorials/EUI64.html>.
[EUI64]IEEE，“64位全局标识符（EUI-64（TM））注册机构指南”，<http://standards.IEEE.org/regauth/oui/tutorials/EUI64.html>。
[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月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[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月。
[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月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.
[RFC4429]Moore，N.，“IPv6的乐观重复地址检测（DAD）”，RFC4429，2006年4月。
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007.
[RFC4919]Kushalnagar，N.，黑山，G.，和C.Schumacher，“低功率无线个人区域网络（6LoWPANs）上的IPv6：概述，假设，问题陈述和目标”，RFC 4919，2007年8月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad Hoc Networks", RFC 5889, September 2010.
[RFC5889]Baccelli，E.和M.Townsley，“Ad Hoc网络中的IP寻址模型”，RFC 5889，2010年9月。
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010.
[RFC6059]Krishnan，S.和G.Daley，“IPv6中检测网络连接的简单程序”，RFC 60592010年11月。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
[RFC6106]Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，RFC 61062010年11月。
Authors' Addresses
作者地址
Zach Shelby (editor) Sensinode Konekuja 2 Oulu 90620 Finland
扎克·谢尔比（编辑）芬兰科内库亚2号传感器90620
Phone: +358407796297
EMail: zach@sensinode.com
Phone: +358407796297
EMail: zach@sensinode.com
Samita Chakrabarti Ericsson
Samita Chakrabarti Ericsson
EMail: samita.chakrabarti@ericsson.com
EMail: samita.chakrabarti@ericsson.com
Erik Nordmark Cisco Systems
埃里克诺德马克思科系统公司
EMail: nordmark@cisco.com
EMail: nordmark@cisco.com
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
卡斯滕·鲍曼大学不来梅邮政学院330440不来梅D-28359德国
Phone: +49-421-218-63921
EMail: cabo@tzi.org
Phone: +49-421-218-63921
EMail: cabo@tzi.org