Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 8505 Cisco
Updates: 6775 E. Nordmark
Category: Standards Track Zededa
ISSN: 2070-1721 S. Chakrabarti
Verizon
C. Perkins
Futurewei
November 2018
Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 8505 Cisco
Updates: 6775 E. Nordmark
Category: Standards Track Zededa
ISSN: 2070-1721 S. Chakrabarti
Verizon
C. Perkins
Futurewei
November 2018
Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
低功耗无线个人区域网（6LoWPAN）上IPv6邻居发现的注册扩展
Abstract
摘要
This specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low-power network.
本规范更新了RFC 6775——低功耗无线个人区域网（6LoWPAN）邻居发现规范——以阐明协议作为注册技术的作用，并简化6LoWPAN路由器中的注册操作，以及为不同网络拓扑提供注册能力和移动性检测的增强，包括在低功率网络中执行主机路由和/或代理邻居发现的路由注册器。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8505.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8505.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
2.1. Requirements Language ......................................4
2.2. Related Documents ..........................................4
2.3. Abbreviations ..............................................4
2.4. New Terms ..................................................6
3. Applicability of Address Registration Options ...................7
4. Extended Neighbor Discovery Options and Messages ................8
4.1. Extended Address Registration Option (EARO) ................8
4.2. Extended Duplicate Address Message Formats ................12
4.3. Extensions to the Capability Indication Option ............13
5. Updating RFC 6775 ..............................................14
5.1. Extending the Address Registration Option .................16
5.2. Transaction ID ............................................17
5.2.1. Comparing TID Values ...............................17
5.3. Registration Ownership Verifier (ROVR) ....................19
5.4. Extended Duplicate Address Messages .......................20
5.5. Registering the Target Address ............................20
5.6. Link-Local Addresses and Registration .....................21
5.7. Maintaining the Registration States .......................22
6. Backward Compatibility .........................................24
6.1. Signaling EARO Support ....................................25
6.2. RFC 6775-Only 6LN .........................................25
6.3. RFC 6775-Only 6LR .........................................25
6.4. RFC 6775-Only 6LBR ........................................26
7. Security Considerations ........................................26
8. Privacy Considerations .........................................28
1. Introduction ....................................................3
2. Terminology .....................................................4
2.1. Requirements Language ......................................4
2.2. Related Documents ..........................................4
2.3. Abbreviations ..............................................4
2.4. New Terms ..................................................6
3. Applicability of Address Registration Options ...................7
4. Extended Neighbor Discovery Options and Messages ................8
4.1. Extended Address Registration Option (EARO) ................8
4.2. Extended Duplicate Address Message Formats ................12
4.3. Extensions to the Capability Indication Option ............13
5. Updating RFC 6775 ..............................................14
5.1. Extending the Address Registration Option .................16
5.2. Transaction ID ............................................17
5.2.1. Comparing TID Values ...............................17
5.3. Registration Ownership Verifier (ROVR) ....................19
5.4. Extended Duplicate Address Messages .......................20
5.5. Registering the Target Address ............................20
5.6. Link-Local Addresses and Registration .....................21
5.7. Maintaining the Registration States .......................22
6. Backward Compatibility .........................................24
6.1. Signaling EARO Support ....................................25
6.2. RFC 6775-Only 6LN .........................................25
6.3. RFC 6775-Only 6LR .........................................25
6.4. RFC 6775-Only 6LBR ........................................26
7. Security Considerations ........................................26
8. Privacy Considerations .........................................28
9. IANA Considerations ............................................29
9.1. Address Registration Option Flags .........................29
9.2. Address Registration Option I-Field .......................29
9.3. ICMP Codes ................................................30
9.4. New ARO Status Values .....................................31
9.5. New 6LoWPAN Capability Bits ...............................32
10. References ....................................................32
10.1. Normative References .....................................32
10.2. Informative References ...................................34
Appendix A. Applicability and Fulfilled Requirements
(Not Normative) .......................................38
Appendix B. Requirements (Not Normative) ..........................39
B.1. Requirements Related to Mobility ...........................39
B.2. Requirements Related to Routing Protocols ..................40
B.3. Requirements Related to Various Low-Power Link Types .......41
B.4. Requirements Related to Proxy Operations ...................42
B.5. Requirements Related to Security ...........................42
B.6. Requirements Related to Scalability ........................44
B.7. Requirements Related to Operations and Management ..........44
B.8. Matching Requirements with Specifications ..................45
Acknowledgments ...................................................47
Authors' Addresses ................................................47
9. IANA Considerations ............................................29
9.1. Address Registration Option Flags .........................29
9.2. Address Registration Option I-Field .......................29
9.3. ICMP Codes ................................................30
9.4. New ARO Status Values .....................................31
9.5. New 6LoWPAN Capability Bits ...............................32
10. References ....................................................32
10.1. Normative References .....................................32
10.2. Informative References ...................................34
Appendix A. Applicability and Fulfilled Requirements
(Not Normative) .......................................38
Appendix B. Requirements (Not Normative) ..........................39
B.1. Requirements Related to Mobility ...........................39
B.2. Requirements Related to Routing Protocols ..................40
B.3. Requirements Related to Various Low-Power Link Types .......41
B.4. Requirements Related to Proxy Operations ...................42
B.5. Requirements Related to Security ...........................42
B.6. Requirements Related to Scalability ........................44
B.7. Requirements Related to Operations and Management ..........44
B.8. Matching Requirements with Specifications ..................45
Acknowledgments ...................................................47
Authors' Addresses ................................................47
IPv6 Low-Power and Lossy Networks (LLNs) support star and mesh topologies. For such networks, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775] (also referred to as "6LoWPAN Neighbor Discovery (ND)") defines a registration mechanism and a central IPv6 ND Registrar to ensure unique addresses. The 6LoWPAN ND mechanism reduces the dependency of the IPv6 ND protocol [RFC4861] [RFC4862] on network-layer multicast and link-layer broadcast operations.
IPv6低功耗和有损网络（LLN）支持星形和网状拓扑。对于此类网络，“低功率无线个人区域网络（6LoWPANs）上IPv6的邻居发现优化”[RFC6775]（也称为“6LoWPAN邻居发现（ND）”）定义了注册机制和中央IPv6 ND注册器，以确保地址的唯一性。6LoWPAN ND机制降低了IPv6 ND协议[RFC4861][RFC4862]对网络层多播和链路层广播操作的依赖性。
This specification updates 6LoWPAN ND [RFC6775] to simplify and generalize registration in 6LoWPAN Routers (6LRs). In particular, this specification modifies and extends the behavior and protocol elements of 6LoWPAN ND to enable the following actions:
本规范更新了6LoWPAN ND[RFC6775]，以简化和推广6LoWPAN路由器（6LR）中的注册。特别是，本规范修改和扩展了6LoWPAN ND的行为和协议元素，以启用以下操作：
o Determining the most recent location in the case of node mobility
o 在节点移动性的情况下确定最近的位置
o Simplifying the registration flow for Link-Local Addresses
o 简化链路本地地址的注册流程
o Support for a routing-unaware leaf node in a route-over network
o 支持网络路由中的路由无意识叶节点
o Proxy registration in a route-over network
o 网络路由中的代理注册
o Enabling verification for the registration, using the Registration Ownership Verifier (ROVR) (Section 5.3)
o 使用注册所有权验证器（ROVR）启用注册验证（第5.3节）
o Registration to an IPv6 ND proxy (e.g., a Routing Registrar)
o 注册到IPv6 ND代理（例如，路由注册器）
o Better support for privacy and temporary addresses
o 更好地支持隐私和临时地址
These features satisfy the requirements listed in Appendix B.
这些特性满足附录B中列出的要求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
In this document, readers will encounter terms and concepts that are discussed in the following documents:
在本文档中，读者将遇到以下文档中讨论的术语和概念：
o "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861]
o “IP版本6（IPv6）的邻居发现”[RFC4861]
o "IPv6 Stateless Address Autoconfiguration" [RFC4862]
o “IPv6无状态地址自动配置”[RFC4862]
o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919]
o “低功耗无线个人区域网络（6LoWPANs）上的IPv6：概述、假设、问题陈述和目标”[RFC4919]
o "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606]
o “通过低功率无线个人区域网（6LoWPAN）路由的IPv6问题陈述和要求”[RFC6606]
o "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775]
o “低功耗无线个人区域网络（6LoWPANs）上IPv6邻居发现优化”[RFC6775]
This document uses the following abbreviations:
本文件使用以下缩写：
6BBR: 6LoWPAN Backbone Router
6BBR:6LoWPAN骨干路由器
6CIO: Capability Indication Option
6CIO：能力指示选项
6LBR: 6LoWPAN Border Router
6LBR:6LoWPAN边界路由器
6LN: 6LoWPAN Node
6LN:6LoWPAN节点
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
6LoWPAN:IPv6低功耗无线个人局域网
6LR: 6LoWPAN Router
6LR:6LoWPAN路由器
ARO: Address Registration Option
地址注册选项
DAC: Duplicate Address Confirmation
重复地址确认
DAD: Duplicate Address Detection
重复地址检测
DAR: Duplicate Address Request
重复地址请求
DODAG: Destination-Oriented Directed Acyclic Graph
DODAG：面向目的的有向无环图
EARO: Extended Address Registration Option
扩展地址注册选项
EDA: Extended Duplicate Address
扩展重复地址
EDAC: Extended Duplicate Address Confirmation
EDAC：扩展重复地址确认
EDAR: Extended Duplicate Address Request
扩展重复地址请求
LLN: Low-Power and Lossy Network
LLN：低功耗有损网络
NA: Neighbor Advertisement
安娜：邻居的广告
NCE: Neighbor Cache Entry
NCE：邻居缓存条目
ND: Neighbor Discovery
邻居发现
NS: Neighbor Solicitation
NS：邻居邀请
RA: Router Advertisement
路由器广告
ROVR: Registration Ownership Verifier (pronounced "rover")
ROVR：注册所有权验证人（发音为“rover”）
RPL: IPv6 Routing Protocol for LLNs (pronounced "ripple") [RFC6550]
RPL:LLN的IPv6路由协议（读作“ripple”）[RFC6550]
RS: Router Solicitation
RS：路由器请求
TID: Transaction ID (a sequence counter in the EARO)
TID：事务ID（EARO中的序列计数器）
Backbone Link: An IPv6 transit link that interconnects two or more Backbone Routers.
主干链路：连接两个或多个主干路由器的IPv6传输链路。
Binding: The association between an IP address, a Media Access Control (MAC) address, and other information about the node that owns the IP address.
绑定：IP地址、媒体访问控制（MAC）地址和有关拥有该IP地址的节点的其他信息之间的关联。
Registration: The process by which a 6LN registers an IPv6 Address with a 6LR in order to establish connectivity to the LLN.
注册：6LN向6LR注册IPv6地址以建立与LLN的连接的过程。
Registered Node: The 6LN for which the registration is performed, according to the fields in the EARO.
注册节点：根据EARO中的字段执行注册的6LN。
Registering Node: The node that performs the registration. Either the Registered Node or a proxy.
注册节点：执行注册的节点。注册的节点或代理。
IPv6 ND Registrar: A node that can process a registration in either NS(EARO) or EDAR messages and consequently respond with an NA or EDAC message containing the EARO and appropriate status for the registration.
IPv6 ND注册器：可以在NS（EARO）或EDAR消息中处理注册的节点，并因此使用包含EARO和注册的适当状态的NA或EDAC消息进行响应。
Registered Address: An address registered for the Registered Node.
注册地址：为注册节点注册的地址。
RFC 6775-only: An implementation, a type of node, or a message that behaves only as specified by [RFC6775], as opposed to the behavior specified in this document.
仅限RFC 6775：一种实现、一种节点类型或一条消息，其行为仅符合[RFC6775]的规定，与本文档中规定的行为相反。
Route-over network: A network for which connectivity is provided at the IP layer.
网络路由：在IP层提供连接的网络。
Routing Registrar: An IPv6 ND Registrar that also provides reachability services for the Registered Address, including DAD and proxy NA.
路由注册器：IPv6 ND注册器，还为注册地址（包括DAD和代理NA）提供可达性服务。
Backbone Router (6BBR): A Routing Registrar that proxies the 6LoWPAN ND operations specified in this document to ensure that multiple LLNs federated by a Backbone Link operate as a single IPv6 subnetwork.
主干路由器（6BBR）：代理本文档中指定的6LoWPAN ND操作的路由注册器，以确保由主干链路联合的多个LLN作为单个IPv6子网运行。
updated: A 6LN, 6LR, or 6LBR that supports this specification, in contrast to an RFC 6775-only device.
更新：与仅限RFC 6775的设备相比，支持此规格的6LN、6LR或6LBR。
The ARO as described in [RFC6775] facilitates DAD for hosts and populates NCEs [RFC4861] in the routers. This reduces the reliance on multicast operations, which are often as intrusive as broadcast, in IPv6 ND operations (see [Multicast-over-IEEE802-Wireless]).
[RFC6775]中所述的ARO有助于主机的DAD，并在路由器中填充[RFC4861]。这减少了在IPv6 ND操作中对多播操作的依赖，多播操作通常与广播一样具有侵入性（请参见[multicast-over-IEEE802-Wireless]）。
This document specifies new status codes for registrations rejected by a 6LR or 6LBR for reasons other than address duplication. Examples include:
本文档为6LR或6LBR因地址重复以外的原因拒绝的注册指定了新的状态代码。例子包括：
o the router running out of space.
o 路由器空间不足。
o a registration bearing a stale sequence number. This could happen if the host moves after the registration was placed.
o 带有过时序列号的登记。如果主机在注册后移动，则可能发生这种情况。
o a host misbehaving and attempting to register an invalid address, such as the unspecified address as defined in [RFC4291].
o 主机行为不正常，试图注册无效地址，如[RFC4291]中定义的未指定地址。
o a host using an address that is not topologically correct on that link.
o 在该链路上使用拓扑不正确地址的主机。
In such cases, the host will receive an error that will help diagnose the issue; the host may retry -- possibly with a different address or possibly registering to a different router -- depending on the returned error. The ability to return errors to address registrations is not intended to be used to restrict the ability of hosts to form and use multiple addresses. Each host may form and register a number of addresses for enhanced privacy, using mechanisms such as those described in [RFC4941] ("Privacy Extensions for Stateless Address Autoconfiguration in IPv6"), e.g., Stateless Address Autoconfiguration (SLAAC), and SHOULD conform to [RFC7934] ("Host Address Availability Recommendations").
在这种情况下，主机将收到一个有助于诊断问题的错误；根据返回的错误，主机可能会重试（可能使用不同的地址，也可能注册到不同的路由器）。向地址注册返回错误的能力并不是用来限制主机形成和使用多个地址的能力。每个主机可以使用[RFC4941]（“IPv6中无状态地址自动配置的隐私扩展”）中所述的机制（例如，无状态地址自动配置（SLAAC））形成并注册多个地址以增强隐私，并且应符合[RFC7934]（“主机地址可用性建议”）。
As indicated in IPv6 ND [RFC4861], a router needs enough storage to hold NCEs for all directly connected addresses to which it is currently forwarding packets (unused entries may be flushed). In contrast, a router serving the address-registration mechanism needs enough storage to hold NCEs for all the addresses that may be registered to it, regardless of whether or not they are actively communicating. The number of registrations supported by a 6LR or 6LBR MUST be clearly documented by the vendor, and the dynamic use of associated resources SHOULD be made available to the network operator, e.g., to a management console. Network administrators need to ensure that 6LRs/6LBRs in their network support the number and types of devices that can register to them, based on the number of IPv6 Addresses that those devices require, as well as their address renewal rate and behavior.
如IPv6 ND[RFC4861]中所述，路由器需要足够的存储空间来保存其当前转发数据包的所有直接连接地址的NCE（未使用的条目可能会被刷新）。相反，为地址注册机制提供服务的路由器需要足够的存储空间来保存可能注册到它的所有地址的NCE，而不管它们是否正在进行主动通信。供应商必须清楚记录6LR或6LBR支持的注册数量，并向网络运营商提供相关资源的动态使用，例如管理控制台。网络管理员需要确保其网络中的6LRs/6LBR支持可以向其注册的设备的数量和类型，这取决于这些设备所需的IPv6地址数量，以及它们的地址更新率和行为。
This specification does not introduce any new options; it modifies existing options and updates the associated behaviors.
本规范未引入任何新选项；它修改现有选项并更新关联的行为。
The ARO is defined in Section 4.1 of [RFC6775].
[RFC6775]第4.1节对ARO进行了定义。
This specification introduces the EARO; the EARO is based on the ARO for use in NS and NA messages. The EARO includes a sequence counter called the Transaction ID (TID), which is used to determine the latest location of a registering mobile device. A new T flag indicates that the presence of the TID field is populated and that the option is an EARO. A 6LN requests routing or proxy services from a 6LR using a new R flag in the EARO.
本规范介绍了EARO；EARO基于ARO，用于NS和NA消息。EARO包括一个称为事务ID（TID）的序列计数器，用于确定注册移动设备的最新位置。新的T标志表示已填充TID字段，且选项为EARO。6LN使用EARO中的新R标志从6LR请求路由或代理服务。
The EUI-64 field is redefined and renamed "ROVR field" in order to carry different types of information, e.g., cryptographic information of variable size (see Section 5.3). A larger ROVR size MAY be used if and only if backward compatibility is not an issue in the particular LLN. The length of the ROVR field, expressed in units of 8 bytes, is the Length value of the option minus 1. A larger ROVR size MAY be used if and only if backward compatibility is not an issue in the particular LLN.
EUI-64字段被重新定义并重命名为“ROVR字段”，以承载不同类型的信息，例如可变大小的加密信息（见第5.3节）。如果且仅当向后兼容性在特定LLN中不是问题时，可以使用更大的ROVR大小。ROVR字段的长度（以8字节为单位）是选项的长度值减去1。如果且仅当向后兼容性在特定LLN中不是问题时，可以使用更大的ROVR大小。
Section 5.1 discusses those changes in depth.
第5.1节深入讨论了这些变化。
The format of the EARO is shown in Figure 1:
EARO的格式如图1所示：
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 | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: EARO Format
图1:EARO格式
Option Fields:
选项字段：
Type: 33
类型：33
Length: 8-bit unsigned integer. The length of the option in units of 8 bytes.
长度：8位无符号整数。选项的长度，以8字节为单位。
Status: 8-bit unsigned integer. Indicates the status of a registration in the NA response. MUST be set to 0 in NS messages. See Table 1 below.
状态：8位无符号整数。指示NA响应中注册的状态。在NS消息中必须设置为0。见下表1。
Opaque: An octet opaque to ND. The 6LN MAY pass it transparently to another process. It MUST be set to 0 when not used.
不透明的：对ND不透明的八位组。6LN可以透明地将其传递给另一个进程。不使用时，必须将其设置为0。
Rsvd (Reserved): This field is unused. It MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
Rsvd（保留）：此字段未使用。发送方必须将其初始化为0，接收方必须将其忽略。
I: 2-bit integer. A value of 0 indicates that the Opaque field carries an abstract index that is used to decide in which routing topology the address is expected to be injected. In that case, the Opaque field is passed to a routing process with the indication that it carries topology information, and the value of 0 indicates default. All other values of "I" are reserved and MUST NOT be used.
I：2位整数。值为0表示不透明字段包含一个抽象索引，该索引用于确定将在哪个路由拓扑中注入地址。在这种情况下，不透明字段被传递给路由进程，指示它携带拓扑信息，值0表示默认值。保留“I”的所有其他值，不得使用。
R: The Registering Node sets the R flag to request reachability services for the Registered Address from a Routing Registrar.
R：注册节点设置R标志，以从路由注册器请求注册地址的可达性服务。
T: 1-bit flag. Set if the next octet is used as a TID.
T：1位标志。设置下一个八位字节是否用作TID。
TID: 1-byte unsigned integer. A Transaction ID that is maintained by the node and incremented with each transaction of one or more registrations performed at the same time to one or more 6LRs. This field MUST be ignored if the T flag is not set.
TID：1字节无符号整数。由节点维护的一种事务ID，随着同时执行的一个或多个注册的每个事务的增加，该事务ID增加到一个或多个6LR。如果未设置T标志，则必须忽略此字段。
Registration Lifetime: 16-bit integer, expressed in minutes. A value of 0 indicates that the registration has ended and that the associated state MUST be removed.
注册生存期：16位整数，以分钟表示。值0表示注册已结束，必须删除关联状态。
Registration Ownership Verifier (ROVR): Enables the correlation between multiple attempts to register the same IPv6 Address. The ROVR size MUST be 64 bits when backward compatibility is needed; otherwise, the size MAY be 128, 192, or 256 bits.
注册所有权验证器（ROVR）：启用注册同一IPv6地址的多次尝试之间的关联。当需要向后兼容时，ROVR大小必须为64位；否则，大小可以是128、192或256位。
+-------+-----------------------------------------------------------+
| Value | Description |
+-------+-----------------------------------------------------------+
| 0-2 | As defined in [RFC6775]. Note: A Status value of 1 |
| | ("Duplicate Address") applies to the Registered Address. |
| | If the Source Address conflicts with an existing |
| | registration, "Duplicate Source Address" MUST be used. |
| | |
| 3 | Moved: The registration failed because it is not the most |
| | recent. This Status indicates that the registration is |
| | rejected because another more recent registration was |
| | done, as indicated by the same ROVR and a more recent |
| | TID. One possible cause is a stale registration that has |
| | progressed slowly in the network and was passed by a more |
| | recent one. It could also indicate a ROVR collision. |
| | |
| 4 | Removed: The binding state was removed. This Status MAY |
| | be placed in an NA(EARO) message that is sent as the |
| | rejection of a proxy registration to an IPv6 ND |
| | Registrar, or in an asynchronous NA(EARO), at any time. |
| | |
| 5 | Validation Requested: The Registering Node is challenged |
| | for owning the Registered Address or for being an |
| | acceptable proxy for the registration. An IPv6 ND |
| | Registrar MAY place this Status in asynchronous DAC or NA |
| | messages. |
| | |
| 6 | Duplicate Source Address: The address used as the source |
| | of the NS(EARO) conflicts with an existing registration. |
| | |
| 7 | Invalid Source Address: The address used as the source of |
| | the NS(EARO) is not a Link-Local Address. |
| | |
| 8 | Registered Address Topologically Incorrect: The address |
| | being registered is not usable on this link. |
| | |
| 9 | 6LBR Registry Saturated: A new registration cannot be |
| | accepted because the 6LBR Registry is saturated. Note: |
| | This code is used by 6LBRs instead of Status 2 when |
| | responding to a Duplicate Address message exchange and is |
| | passed on to the Registering Node by the 6LR. |
| | |
| 10 | Validation Failed: The proof of ownership of the |
| | Registered Address is not correct. |
+-------+-----------------------------------------------------------+
+-------+-----------------------------------------------------------+
| Value | Description |
+-------+-----------------------------------------------------------+
| 0-2 | As defined in [RFC6775]. Note: A Status value of 1 |
| | ("Duplicate Address") applies to the Registered Address. |
| | If the Source Address conflicts with an existing |
| | registration, "Duplicate Source Address" MUST be used. |
| | |
| 3 | Moved: The registration failed because it is not the most |
| | recent. This Status indicates that the registration is |
| | rejected because another more recent registration was |
| | done, as indicated by the same ROVR and a more recent |
| | TID. One possible cause is a stale registration that has |
| | progressed slowly in the network and was passed by a more |
| | recent one. It could also indicate a ROVR collision. |
| | |
| 4 | Removed: The binding state was removed. This Status MAY |
| | be placed in an NA(EARO) message that is sent as the |
| | rejection of a proxy registration to an IPv6 ND |
| | Registrar, or in an asynchronous NA(EARO), at any time. |
| | |
| 5 | Validation Requested: The Registering Node is challenged |
| | for owning the Registered Address or for being an |
| | acceptable proxy for the registration. An IPv6 ND |
| | Registrar MAY place this Status in asynchronous DAC or NA |
| | messages. |
| | |
| 6 | Duplicate Source Address: The address used as the source |
| | of the NS(EARO) conflicts with an existing registration. |
| | |
| 7 | Invalid Source Address: The address used as the source of |
| | the NS(EARO) is not a Link-Local Address. |
| | |
| 8 | Registered Address Topologically Incorrect: The address |
| | being registered is not usable on this link. |
| | |
| 9 | 6LBR Registry Saturated: A new registration cannot be |
| | accepted because the 6LBR Registry is saturated. Note: |
| | This code is used by 6LBRs instead of Status 2 when |
| | responding to a Duplicate Address message exchange and is |
| | passed on to the Registering Node by the 6LR. |
| | |
| 10 | Validation Failed: The proof of ownership of the |
| | Registered Address is not correct. |
+-------+-----------------------------------------------------------+
Table 1: EARO Status Codes
表1:EARO状态代码
The DAR and DAC messages share a common base format as defined in Section 4.4 of [RFC6775]. Those messages enable information from the ARO to be transported over multiple hops. The DAR and DAC are extended as shown in Figure 2:
DAR和DAC消息共享[RFC6775]第4.4节中定义的通用基本格式。这些消息使来自ARO的信息能够通过多个跃点传输。DAR和DAC的扩展如图2所示：
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 |CodePfx|CodeSfx| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 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 |CodePfx|CodeSfx| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Registered Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Extended Duplicate Address Message Format
图2：扩展的重复地址消息格式
Modified Message Fields:
修改的消息字段：
Code: The ICMP Code [RFC4443] for Duplicate Address messages is split into two 4-bit fields: the Code Prefix and the Code Suffix. The Code Prefix MUST be set to 0 by the sender and MUST be ignored by the receiver. A non-null value of the Code Suffix indicates support for this specification. It MUST be set to 1 when operating in a backward-compatible mode, indicating a ROVR size of 64 bits. It MAY be 2, 3, or 4, denoting a ROVR size of 128, 192, or 256 bits, respectively.
代码：重复地址消息的ICMP代码[RFC4443]分为两个4位字段：代码前缀和代码后缀。发送方必须将代码前缀设置为0，接收方必须忽略该前缀。代码后缀的非空值表示支持此规范。在向后兼容模式下运行时，必须将其设置为1，表示ROVR大小为64位。它可以是2、3或4，分别表示128、192或256位的ROVR大小。
TID: 1-byte integer. Same definition and processing as the TID in the EARO as defined in Section 4.1. This field MUST be ignored if the ICMP Code is null.
TID：1字节整数。与第4.1节中定义的EARO中的TID定义和处理相同。如果ICMP代码为空，则必须忽略此字段。
Registration Ownership Verifier (ROVR): The size of the ROVR is known from the ICMP Code Suffix. This field has the same definition and processing as the ROVR in the EARO as defined in Section 4.1.
注册所有权验证器（ROVR）：ROVR的大小由ICMP代码后缀可知。该字段的定义和处理与第4.1节中定义的EARO中的ROVR相同。
This specification defines five new capability bits for use in the 6CIO as defined by [RFC7400] ("6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"), for use in IPv6 ND messages. (The G flag is defined in Section 3.3 of [RFC7400].)
本规范定义了在[RFC7400]中定义的6CIO中使用的五个新功能位（“6LoWPAN GHC：低功耗无线个人区域网络（6LoWPANs）上IPv6的通用报头压缩”），用于IPv6 ND消息。（G标志的定义见[RFC7400]第3.3节。）
The D flag indicates that the 6LBR supports EDAR and EDAC messages. A 6LR that learns the D flag from advertisements can then exchange EDAR and EDAC messages with the 6LBR, and it also sets the D flag as well as the L flag in the 6CIO in its own advertisements. In this way, 6LNs will be able to prefer registration with a 6LR that can make use of new 6LBR features.
D标志表示6LBR支持EDAR和EDAC信息。从广告中学习D标志的6LR可以与6LBR交换EDAR和EDAC信息，它还可以在自己的广告中设置6CIO中的D标志和L标志。通过这种方式，6LNs将能够更倾向于使用6LR注册，该6LR可以利用新的6LBR功能。
The new L, B, and P flags indicate whether a router is capable of acting as a 6LR, 6LBR, or Routing Registrar (e.g., 6BBR) (or some combination thereof), respectively. These flags are not mutually exclusive; an updated node can advertise multiple collocated functions.
新的L、B和P标志分别指示路由器是否能够充当6LR、6LBR或路由注册器（例如6BBR）（或其组合）。这些旗帜并不相互排斥；更新的节点可以公布多个并置函数。
The E flag indicates that the EARO can be used in a registration. A 6LR that supports this specification MUST set the E flag.
E标志表示可以在注册中使用EARO。支持此规格的6LR必须设置E标志。
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 = 1 | Reserved |D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 1 | Reserved |D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: New Capability Bits in the 6CIO
图3:6CIO中的新功能位
Option Fields:
选项字段：
Type: 36
类型：36
D: The 6LBR supports EDAR and EDAC messages.
D:6LBR支持EDAR和EDAC信息。
L: The node is a 6LR.
L:节点是一个6LR。
B: The node is a 6LBR.
B:节点是6LBR。
P: The node is a Routing Registrar.
P：节点是一个路由注册器。
E: The node is an IPv6 ND Registrar; i.e., it supports registrations based on the EARO.
E：该节点是IPv6 ND注册器；i、 例如，它支持基于EARO的注册。
The EARO (see Section 4.1) updates the ARO used within NS and NA messages between a 6LN and a 6LR. The update enables a registration to a Routing Registrar in order to obtain additional services, such as return routability to the Registered Address by such means as routing and/or proxy ND, as illustrated in Figure 4.
EARO（参见第4.1节）更新6LN和6LR之间NS和NA消息中使用的ARO。更新允许向路由注册器注册，以获得附加服务，例如通过路由和/或代理ND等方式将可路由性返回到注册地址，如图4所示。
Routing
6LN Registrar
| |
| NS(EARO) |
|--------------->|
| |
| | Inject/maintain
| | host route or
| | IPv6 ND proxy state
| | <----------------->
| NA(EARO) |
|<---------------|
| |
Routing
6LN Registrar
| |
| NS(EARO) |
|--------------->|
| |
| | Inject/maintain
| | host route or
| | IPv6 ND proxy state
| | <----------------->
| NA(EARO) |
|<---------------|
| |
Figure 4: (Re-)Registration Flow
图4：（重新）注册流程
Similarly, the EDAR and EDAC update the DAR and DAC messages so as to transport the new information between 6LRs and 6LBRs across an LLN mesh. The extensions to the ARO are the DAR and the DAC, as used in the Duplicate Address messages. They convey the additional information all the way to the 6LBR.
类似地，EDAR和EDAC更新DAR和DAC消息，以便通过LLN网格在6LRs和6LBR之间传输新信息。ARO的扩展是DAR和DAC，用于重复地址消息。它们将附加信息一直传送到6LBR。
In turn, the 6LBR may proxy the registration to obtain reachability services from a Routing Registrar such as a 6BBR, as illustrated in Figure 5. This specification avoids the Duplicate Address message flow for Link-Local Addresses in a route-over [RFC6606] topology (see Section 5.6).
反过来，6LBR可以代理注册以从路由注册器（如6BBR）获得可达性服务，如图5所示。本规范避免了[RFC6606]拓扑上路由中链路本地地址的重复地址消息流（见第5.6节）。
Routing
6LN 6LR 6LBR Registrar
| | | |
|<Link-local>| <Routed> |<Link-local>|
| | | |
| NS(EARO) | | |
|----------->| | |
| | Extended DAR | |
| |------------->| |
| | | proxy |
| | | NS(EARO) |
| | |----------->|
| | | | Inject/maintain
| | | | host route or
| | | | IPv6 ND proxy state
| | | | <----------------->
| | | proxy |
| | | NA(EARO) |
| | Extended DAC |<-----------|
| |<-------------| |
| NA(EARO) | | |
|<-----------| | |
| | | |
Routing
6LN 6LR 6LBR Registrar
| | | |
|<Link-local>| <Routed> |<Link-local>|
| | | |
| NS(EARO) | | |
|----------->| | |
| | Extended DAR | |
| |------------->| |
| | | proxy |
| | | NS(EARO) |
| | |----------->|
| | | | Inject/maintain
| | | | host route or
| | | | IPv6 ND proxy state
| | | | <----------------->
| | | proxy |
| | | NA(EARO) |
| | Extended DAC |<-----------|
| |<-------------| |
| NA(EARO) | | |
|<-----------| | |
| | | |
Figure 5: (Re-)Registration Flow
图5：（重新）注册流程
This specification allows multiple registrations, including registrations for privacy and temporary addresses, and provides a mechanism to help clean up stale registration state as soon as possible, e.g., after a movement (see Section 7).
本规范允许多个注册，包括隐私和临时地址的注册，并提供了一种机制来帮助尽快清理过时的注册状态，例如在移动之后（参见第7节）。
Section 5 of [RFC6775] specifies how a 6LN bootstraps an interface and locates available 6LRs. A Registering Node SHOULD register to a 6LR that supports this specification if one is found, as discussed in Section 6.1, instead of registering to an RFC 6775-only 6LR; otherwise, the Registering Node operates in a backward-compatible fashion when attaching to an RFC 6775-only 6LR.
[RFC6775]的第5节规定了6LN如何引导接口并定位可用的6LR。如第6.1节所述，注册节点应注册到支持本规范的6LR，而不是仅注册到RFC 6775 6LR；否则，当仅连接到RFC 6775 6LR时，注册节点以向后兼容的方式操作。
The EARO updates the ARO and is backward compatible with the ARO if and only if the Length value of the option is set to 2. The format of the EARO is presented in Section 4.1. More details on backward compatibility can be found in Section 6.
当且仅当选项的长度值设置为2时，EARO更新ARO并与ARO向后兼容。EARO的格式见第4.1节。有关向后兼容性的更多详细信息，请参见第6节。
The NS message and the ARO are modified as follows:
NS消息和ARO修改如下：
o The Target Address field in the NS containing the EARO is now the field that indicates the address that is being registered, as opposed to the Source Address field in the NS as specified in [RFC6775] (see Section 5.5). This change enables a 6LBR to send a proxy registration for a 6LN's address to a Routing Registrar and in most cases also avoids the use of an address as the Source Address before it is registered.
o 包含EARO的NS中的目标地址字段现在是指示正在注册的地址的字段，而不是[RFC6775]中指定的NS中的源地址字段（参见第5.5节）。此更改使6LBR能够向路由注册器发送6LN地址的代理注册，并且在大多数情况下，也避免了在注册前将地址用作源地址。
o The EUI-64 field in the ARO is renamed "Registration Ownership Verifier (ROVR)" and is not required to be derived from a MAC address (see Section 5.3).
o ARO中的EUI-64字段更名为“注册所有权验证器（ROVR）”，不需要从MAC地址派生（见第5.3节）。
o The option's Length value MAY be different than 2 and take a value between 3 and 5, in which case the EARO is not backward compatible with an ARO. The increase in size corresponds to a larger ROVR field, so the size of the ROVR is inferred from the option's Length value.
o 该选项的长度值可能不同于2，取值范围为3到5，在这种情况下，EARO与ARO不向后兼容。大小的增加对应于更大的ROVR字段，因此ROVR的大小是从选项的长度值推断出来的。
o A new Opaque field is introduced to carry opaque information in cases where the registration is relayed to another process, e.g., to be advertised by a routing protocol. A new "I" field provides a type for the opaque information and indicates the other process to which the 6LN passes the opaque value. A value of 0 for the "I" field indicates topological information to be passed to a routing process if the registration is redistributed. In that case, a value of 0 for the Opaque field (1) is backward compatible with the reserved fields that are overloaded and (2) indicates that the default topology is to be used.
o 引入了一个新的不透明字段，以便在注册被中继到另一个进程（例如，通过路由协议进行公告）的情况下携带不透明信息。新的“I”字段为不透明信息提供了一种类型，并指示6LN将不透明值传递到的其他进程。“I”字段的值为0表示如果重新分发注册，将向路由进程传递拓扑信息。在这种情况下，不透明字段（1）的值0与重载的保留字段向后兼容，（2）表示将使用默认拓扑。
o This document specifies a new flag in the EARO: the R flag. If the R flag is set, the Registering Node requests that the 6LR ensure reachability for the Registered Address, e.g., by means of routing or proxy ND. Conversely, when it is not set, the R flag indicates that the Registering Node is a router and that it will advertise reachability to the Registered Address via a routing protocol (such as RPL [RFC6550]).
o 本文档在EARO中指定了一个新标志：R标志。如果设置了R标志，则注册节点请求6LR确保注册地址的可达性，例如通过路由或代理ND。相反，当未设置时，R标志指示注册节点是路由器，并且它将通过路由协议（例如RPL[RFC6550]）向注册地址通告可达性。
o A node that supports this specification MUST provide a TID field in the EARO and set the T flag to indicate the presence of the TID (see Section 5.2).
o 支持本规范的节点必须在EARO中提供TID字段，并设置T标志以指示TID的存在（见第5.2节）。
o Finally, this specification introduces new status codes to help diagnose the cause of a registration failure (see Table 1).
o 最后，本规范引入了新的状态代码，以帮助诊断注册失败的原因（参见表1）。
When registering, a 6LN that acts only as a host MUST set the R flag to indicate that it is not a router and that it will not handle its own reachability. A 6LR that manages its reachability SHOULD NOT set the R flag; if it does, routes towards this router may be installed on its behalf and may interfere with those it advertises.
注册时，仅作为主机的6LN必须设置R标志，以表明它不是路由器，并且不会处理自身的可达性。管理其可达性的6LR不应设置R标志；如果它这样做，则可能会代表它安装指向此路由器的路由，并且可能会干扰它所宣传的路由。
The TID is a sequence number that is incremented by the 6LN with each re-registration to a 6LR. The TID is used to determine the recency of the registration request. The network uses the most recent TID to determine the most recent known location(s) of a moving 6LN. When a Registered Node is registered with multiple 6LRs in parallel, the same TID MUST be used. This enables the 6LBRs and/or Routing Registrars to determine whether the registrations are identical and to distinguish that situation from a movement (for example, see Section 5.7 and Appendix A).
TID是一个序列号，每次重新注册到6LR时，该序列号将按6LN递增。TID用于确定注册请求的最新情况。网络使用最近的TID确定移动6LN的最近已知位置。当一个已注册节点与多个6LR并行注册时，必须使用相同的TID。这使6LBRs和/或路由登记器能够确定登记是否相同，并将该情况与移动区分开来（例如，参见第5.7节和附录a）。
The operation of the TID is fully compatible with that of the RPL Path Sequence counter as described in Section 7.2 of [RFC6550] ("RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks").
TID的操作与[RFC6550]第7.2节所述的RPL路径序列计数器的操作完全兼容（“RPL：低功耗和有损网络的IPv6路由协议”）。
A TID is deemed to be more recent than another when its value is greater as determined by the operations detailed in this section.
根据本节详述的操作确定，如果TID的价值大于其他TID，则认为TID比其他TID更为近期。
The TID range is subdivided in a "lollipop" fashion [Perlman83], where the values from 128 and greater are used as a linear sequence to indicate a restart and bootstrap the counter, and the values less than or equal to 127 are used as a circular sequence number space of size 128 as mentioned in [RFC1982]. Consideration is given to the mode of operation when transitioning from the linear region to the circular region. Finally, when operating in the circular region, if sequence numbers are determined to be too far apart, then they are not comparable, as detailed below.
TID范围以“棒棒糖”方式细分[Perlman83]，其中128及以上的值用作线性序列，以指示计数器的重启和引导，小于或等于127的值用作[RFC1982]中提到的大小为128的循环序列号空间。考虑从线性区域过渡到圆形区域时的操作模式。最后，当在圆形区域中操作时，如果序列号被确定为相距太远，则它们是不可比较的，如下所述。
A window of comparison, SEQUENCE_WINDOW = 16, is configured based on a value of 2^N, where N is defined to be 4 in this specification.
比较窗口SEQUENCE_window=16基于2^N的值进行配置，其中N在本规范中定义为4。
For a given sequence counter,
对于给定的序列计数器，
1. Prior to use, the sequence counter SHOULD be initialized to an implementation-defined value of 128 or greater. A recommended value is 240 (256 - SEQUENCE_WINDOW).
1. 使用前，序列计数器应初始化为128或更大的实现定义值。建议值为240（256-序列_窗口）。
2. When a sequence counter increment would cause the sequence counter to increment beyond its maximum value, the sequence counter MUST wrap back to 0. When incrementing a sequence counter greater than or equal to 128, the maximum value is 255. When incrementing a sequence counter less than 128, the maximum value is 127.
2. 当序列计数器的增量会导致序列计数器的增量超过其最大值时，序列计数器必须返回到0。当递增大于或等于128的序列计数器时，最大值为255。当序列计数器的增量小于128时，最大值为127。
3. When comparing two sequence counters, the following rules MUST be applied:
3. 比较两个序列计数器时，必须应用以下规则：
1. When a first sequence counter A is in the interval [128-255] and a second sequence counter B is in the interval [0-127]:
1. 当第一个序列计数器a在区间[128-255]内，第二个序列计数器B在区间[0-127]内时：
1. If (256 + B - A) is less than or equal to SEQUENCE_WINDOW, then B is greater than A, A is less than B, and the two are not equal.
1. 如果（256+B-A）小于或等于序列_窗口，则B大于A，A小于B，且两者不相等。
2. If (256 + B - A) is greater than SEQUENCE_WINDOW, then A is greater than B, B is less than A, and the two are not equal.
2. 如果（256+B-A）大于序列_窗口，则A大于B，B小于A，且两者不相等。
For example, if A is 240 and B is 5, then (256 + 5 - 240) is 21. 21 is greater than SEQUENCE_WINDOW (16); thus, 240 is greater than 5. As another example, if A is 250 and B is 5, then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW (16); thus, 250 is less than 5.
例如，如果A是240，B是5，那么（256+5-240）是21。21大于序列_窗口（16）；因此，240大于5。作为另一个例子，如果A是250，B是5，那么（256+5-250）是11。11小于序列_窗口（16）；因此，250小于5。
2. In the case where both sequence counters to be compared are less than or equal to 127, and in the case where both sequence counters to be compared are greater than or equal to 128:
2. 在两个要比较的序列计数器小于或等于127的情况下，以及在两个要比较的序列计数器大于或等于128的情况下：
1. If the absolute magnitude of difference between the two sequence counters is less than or equal to SEQUENCE_WINDOW, then a comparison as described in [RFC1982] is used to determine the relationships "greater than", "less than", and "equal".
1. 如果两个序列计数器之间差值的绝对大小小于或等于序列_窗口，则使用[RFC1982]中所述的比较来确定关系“大于”、“小于”和“等于”。
2. If the absolute magnitude of difference of the two sequence counters is greater than SEQUENCE_WINDOW, then a desynchronization has occurred and the two sequence numbers are not comparable.
2. 如果两个序列计数器的差值的绝对大小大于sequence_WINDOW，则发生了去同步，并且两个序列号不可比较。
4. If two sequence numbers are determined to be not comparable, i.e., the results of the comparison are not defined, then a node should give precedence to the sequence number that was most recently incremented. Failing this, the node should select the sequence number in order to minimize the resulting changes to its own state.
4. 如果确定两个序列号不可比较，即未定义比较结果，则节点应优先于最近递增的序列号。否则，节点应选择序列号，以尽量减少对其自身状态的更改。
The ROVR field replaces the EUI-64 field of the ARO defined in [RFC6775]. It is associated in the 6LR and the 6LBR with the registration state. The ROVR can be a unique ID of the Registering Node, such as the EUI-64 address of an interface. This can also be a token obtained with cryptographic methods that can be used in additional protocol exchanges to associate a cryptographic identity (key) with this registration to ensure that only the owner can modify it later, if the proof of ownership of the ROVR can be obtained. The scope of a ROVR is the registration of a particular IPv6 Address, and it MUST NOT be used to correlate registrations of different addresses.
ROVR字段替换[RFC6775]中定义的ARO的EUI-64字段。它在6LR和6LBR中与注册状态相关联。ROVR可以是注册节点的唯一ID，例如接口的EUI-64地址。这也可以是通过加密方法获得的令牌，可在附加协议交换中使用，以将加密身份（密钥）与此注册关联，以确保只有所有者可以在以后修改它（如果可以获得ROVR的所有权证明）。ROVR的范围是特定IPv6地址的注册，不得用于关联不同地址的注册。
The ROVR can be of different types; the type is signaled in the message that carries the new type. For instance, the type can be a cryptographic string and can be used to prove the ownership of the registration as specified in [AP-ND] ("Address Protected Neighbor Discovery for Low-power and Lossy Networks"). In order to support the flows related to the proof of ownership, this specification introduces new status codes "Validation Requested" and "Validation Failed" in the EARO.
ROVR可以是不同类型的；该类型在携带新类型的消息中发出信号。例如，该类型可以是加密字符串，并可用于证明[AP-ND]（“低功耗和有损网络的地址保护邻居发现”）中指定的注册所有权。为了支持与所有权证明相关的流程，本规范在EARO中引入了新的状态代码“请求验证”和“验证失败”。
Note regarding ROVR collisions: Different techniques for forming the ROVR will operate in different namespaces. [RFC6775] specifies the use of EUI-64 addresses. [AP-ND] specifies the generation of cryptographic tokens. While collisions are not expected in the EUI-64 namespace only, they may happen if [AP-ND] is implemented by at least one of the nodes. An implementation that understands the namespace MUST consider that ROVRs from different namespaces are different even if they have the same value. An RFC 6775-only 6LBR or 6LR will confuse the namespaces; this slightly increases the risk of a ROVR collision. A ROVR collision has no effect if the two Registering Nodes register different addresses, since the ROVR is only significant within the context of one registration. A ROVR is not expected to be unique to one registration, as this specification allows a node to use the same ROVR to register multiple IPv6 Addresses. This is why the ROVR MUST NOT be used as a key to identify the Registering Node or as an index to the registration. It is only used as a match to ensure that the node that updates a registration for an IPv6 Address is the node that made the original
关于ROVR冲突的注意：形成ROVR的不同技术将在不同的名称空间中运行。[RFC6775]指定EUI-64地址的使用。[AP-ND]指定加密令牌的生成。虽然仅在EUI-64命名空间中不需要冲突，但如果[AP-ND]由至少一个节点实现，则可能会发生冲突。理解命名空间的实现必须考虑来自不同命名空间的ROVRs，即使它们具有相同的值也是不同的。RFC 6775仅6LBR或6LR会混淆名称空间；这略微增加了ROVR碰撞的风险。如果两个注册节点注册不同的地址，则ROVR冲突无效，因为ROVR仅在一个注册的上下文中有效。ROVR对于一次注册不应是唯一的，因为此规范允许节点使用同一ROVR注册多个IPv6地址。这就是为什么ROVR不能用作标识注册节点的密钥或注册索引的原因。它仅用作匹配，以确保更新IPv6地址注册的节点是生成原始地址的节点
registration for that IPv6 Address. Also, when the ROVR is not an EUI-64 address, then it MUST NOT be used as the Interface Identifier of the Registered Address. This way, a registration that uses that ROVR will not collide with that of an IPv6 Address derived from EUI-64 and using the EUI-64 as the ROVR per [RFC6775].
注册该IPv6地址。此外，如果ROVR不是EUI-64地址，则不得将其用作注册地址的接口标识符。这样，使用该ROVR的注册将不会与根据[RFC6775]从EUI-64派生并使用EUI-64作为ROVR的IPv6地址的注册冲突。
The Registering Node SHOULD store the ROVR, or enough information to regenerate it, in persistent memory. If this is not done and an event such as a reboot causes a loss of state, re-registering the same address could be impossible until (1) the 6LRs and the 6LBR time out the previous registration or (2) a management action clears the relevant state in the network.
注册节点应在持久内存中存储ROVR或足够的信息以重新生成ROVR。如果不这样做，并且诸如重新启动之类的事件会导致状态丢失，则在（1）6LRs和6LBR在先前的注册中超时或（2）管理操作清除网络中的相关状态之前，可能无法重新注册相同的地址。
In order to map the new EARO content in the EDA messages, a new TID field is added to the EDAR and EDAC messages as a replacement for the Reserved field, and a non-null value of the ICMP Code indicates support for this specification. The format of the EDAR and EDAC messages is presented in Section 4.2.
为了在EDA消息中映射新的EARO内容，在EDAR和EDAC消息中添加了一个新的TID字段作为保留字段的替换，ICMP代码的非空值表示支持此规范。EDAR和EDAC信息的格式见第4.2节。
As with the EARO, the EDA messages are backward compatible with the RFC 6775-only versions, as long as the ROVR field is 64 bits long. Remarks concerning backward compatibility for the protocol between the 6LN and the 6LR apply similarly between a 6LR and a 6LBR.
与EARO一样，只要ROVR字段长度为64位，EDA消息与仅RFC 6775版本向后兼容。关于6LN和6LR之间协议向后兼容性的备注同样适用于6LR和6LBR。
An NS message with an EARO is a registration if and only if it also carries an SLLA Option ("SLLAO") [RFC6775] ("SLLA" stands for "Source Link-Layer Address"). The EARO can also be used in NS and NA messages between Routing Registrars to determine the distributed registration state; in that case, it does not carry the SLLA Option and is not confused with a registration.
带有EARO的NS消息是注册，当且仅当它还带有SLLA选项（“SLLAO”）[RFC6775]（“SLLA”代表“源链路层地址”）。EARO还可用于路由注册器之间的NS和NA消息中，以确定分布式注册状态；在这种情况下，它不带有SLLA选项，也不会与注册混淆。
The Registering Node is the node that performs the registration to the Routing Registrar. As also described in [RFC6775], it may be the Registered Node as well, in which case it registers one of its own addresses and indicates its own MAC address as the SLLA in the NS(EARO).
注册节点是向路由注册器执行注册的节点。如[RFC6775]中所述，它也可以是注册的节点，在这种情况下，它注册自己的一个地址，并将自己的MAC地址指示为NS（EARO）中的SLLA。
This specification adds the capability to proxy the registration operation on behalf of a Registered Node that is reachable over an LLN mesh. In that case, if the Registered Node is reachable from the Routing Registrar via a mesh-under configuration, the Registering Node indicates the MAC address of the Registered Node as the SLLA in the NS(EARO). If the Registered Node is reachable over a route-over configuration from the Registering Node, the SLLA in the NS(ARO) is
此规范添加了代表可通过LLN网格访问的已注册节点代理注册操作的功能。在这种情况下，如果注册节点可通过配置中的网状网从路由注册器到达，则注册节点将注册节点的MAC地址指示为NS（EARO）中的SLLA。如果注册的节点可以通过来自注册节点的路由覆盖配置访问，则NS（ARO）中的SLLA是可访问的
that of the Registering Node. This enables the Registering Node to attract the packets from the Routing Registrar and route them over the LLN to the Registered Node.
注册节点的名称。这使得注册节点能够吸引来自路由注册器的包，并通过LLN将它们路由到注册节点。
In order to enable the latter operation, this specification changes the behavior of the 6LN and the 6LR so that the Registered Address is found in the Target Address field of the NS and NA messages as opposed to the Source Address field. With this convention, a TLLA Option (Target Link-Layer Address Option, or "TLLAO") indicates the link-layer address of the 6LN that owns the address.
为了启用后一种操作，本规范更改6LN和6LR的行为，以便在NS和NA消息的目标地址字段中找到注册地址，而不是在源地址字段中。根据此约定，TLLA选项（目标链路层地址选项，或“TLLAO”）表示拥有该地址的6LN的链路层地址。
A Registering Node (e.g., a 6LBR also acting as a RPL root) that advertises reachability for the 6LN MUST place its own link-layer address in the SLLA Option of the registration NS(EARO) message. This maintains compatibility with RFC 6775-only 6LoWPAN ND.
播发6LN可达性的注册节点（例如，也充当RPL根的6LBR）必须在注册NS（EARO）消息的SLLA选项中放置自己的链路层地址。这仅与RFC 6775 6LoWPAN ND保持兼容。
LLN nodes are often not wired and may move. There is no guarantee that a Link-Local Address will remain unique among a huge and potentially variable set of neighboring nodes.
LLN节点通常未连接，可能会移动。无法保证链路本地地址在庞大且可能可变的相邻节点集中保持唯一。
Compared to [RFC6775], this specification only requires that a Link-Local Address be unique from the perspective of the two nodes that use it to communicate (e.g., the 6LN and the 6LR in an NS/NA exchange). This simplifies the DAD process in a route-over topology for Link-Local Addresses by avoiding an exchange of EDA messages between the 6LR and a 6LBR for those addresses.
与[RFC6775]相比，本规范仅要求从使用链路本地地址进行通信的两个节点（例如，NS/NA交换中的6LN和6LR）的角度来看，链路本地地址是唯一的。这通过避免6LR和6LBR之间交换用于链路本地地址的EDA消息，简化了链路本地地址的路由拓扑中的DAD过程。
An exchange between two nodes using Link-Local Addresses implies that they are reachable over one hop. A node MUST register a Link-Local Address to a 6LR in order to obtain further reachability by way of that 6LR and, in particular, to use the Link-Local Address as the Source Address to register other addresses, e.g., global addresses.
使用链路本地地址的两个节点之间的交换意味着它们可以通过一个跃点到达。节点必须注册到6LR的链路本地地址，以便通过该6LR获得进一步的可达性，尤其是使用链路本地地址作为源地址来注册其他地址，例如全局地址。
If there is no collision with a previously registered address, then the Link-Local Address is unique from the standpoint of this 6LR and the registration is not a duplicate. Two different 6LRs might claim the same Link-Local Address but different link-layer addresses. In that case, a 6LN MUST only interact with at most one of the 6LRs.
如果与先前注册的地址没有冲突，则从该6LR的角度来看，链路本地地址是唯一的，并且注册不是重复的。两个不同的6LR可能声明相同的链路本地地址，但不同的链路层地址。在这种情况下，6LN最多只能与一个6LR交互。
The exchange of EDAR and EDAC messages between the 6LR and a 6LBR, which ensures that an address is unique across the domain covered by the 6LBR, does not need to take place for Link-Local Addresses.
6LR和6LBR之间的EDAR和EDAC消息交换可确保地址在6LBR覆盖的域中是唯一的，而链路本地地址无需进行交换。
When sending an NS(EARO) to a 6LR, a 6LN MUST use a Link-Local Address as the Source Address of the registration, whatever the type of IPv6 Address that is being registered. That Link-Local Address MUST be either an address that is already registered to the 6LR or the address that is being registered.
当向6LR发送NS（EARO）时，6LN必须使用链路本地地址作为注册的源地址，无论注册的IPv6地址类型如何。该链路本地地址必须是已注册到6LR的地址或正在注册的地址。
When a 6LN starts up, it typically multicasts an RS and receives one or more unicast RA messages from 6LRs. If the 6LR can process EARO messages, then it places a 6CIO in its RA message with the E flag set as required in Section 6.1.
当6LN启动时，它通常多播RS并从6LRs接收一个或多个单播RA消息。如果6LR可以处理EARO消息，则它会在其RA消息中放置一个6CIO，并按照第6.1节的要求设置E标志。
When a Registering Node does not have an already-registered address, it MUST register a Link-Local Address, using it as both the Source Address and the Target Address of an NS(EARO) message. In that case, it is RECOMMENDED to use an address for which DAD is not required (see [RFC6775]), e.g., derived from a globally unique EUI-64 address; using the SLLA Option in the NS is consistent with existing ND specifications such as [RFC4429] ("Optimistic Duplicate Address Detection (DAD) for IPv6"). The 6LN MAY then use that address to register one or more other addresses.
当注册节点没有已注册的地址时，它必须注册链路本地地址，将其用作NS（EARO）消息的源地址和目标地址。在这种情况下，建议使用不需要DAD的地址（参见[RFC6775]），例如，从全局唯一的EUI-64地址派生；在NS中使用SLLA选项符合现有的ND规范，如[RFC4429]（“IPv6的乐观重复地址检测（DAD））。然后，6LN可以使用该地址注册一个或多个其他地址。
A 6LR that supports this specification replies with an NA(EARO), setting the appropriate status. Since there is no exchange of EDAR or EDAC messages for Link-Local Addresses, the 6LR may answer immediately to the registration of a Link-Local Address, based solely on its existing state and the SLLA Option that is placed in the NS(EARO) message as required in [RFC6775].
支持此规范的6LR以NA（EARO）回复，并设置适当的状态。由于链路本地地址不存在EDAR或EDAC消息交换，6LR可根据其现有状态和[RFC6775]中要求的NS（EARO）消息中的SLLA选项，立即响应链路本地地址的注册。
A node registers its IPv6 Global Unicast Addresses (GUAs) to a 6LR in order to establish global reachability for these addresses via that 6LR. When registering with an updated 6LR, a Registering Node does not use a GUA as the Source Address, in contrast to a node that complies with [RFC6775]. For non-Link-Local Addresses, the exchange of EDAR and EDAC messages MUST conform to [RFC6775], but the extended formats described in this specification for the DAR and the DAC are used to relay the extended information in the case of an EARO.
节点将其IPv6全局单播地址（GUA）注册到6LR，以便通过该6LR建立这些地址的全局可达性。当向更新的6LR注册时，注册节点不使用GUA作为源地址，这与符合[RFC6775]的节点不同。对于非链路本地地址，EDAR和EDAC消息的交换必须符合[RFC6775]，但本规范中描述的DAR和DAC扩展格式用于在EARO情况下中继扩展信息。
This section discusses protocol actions that involve the Registering Node, the 6LR, and the 6LBR. It must be noted that the portion that deals with a 6LBR only applies to those addresses that are registered to it; as discussed in Section 5.6, this is not the case for Link-Local Addresses. The registration state includes all data that is stored in the router relative to that registration, in particular, but not limited to, an NCE. 6LBRs and Routing Registrars may store additional registration information and use synchronization protocols that are out of scope for this document.
本节讨论涉及注册节点、6LR和6LBR的协议操作。必须注意的是，涉及6LBR的部分仅适用于向其注册的地址；如第5.6节所述，链路本地地址并非如此。注册状态包括存储在路由器中的与该注册相关的所有数据，特别是但不限于NCE。6LBRs和路由注册器可能存储额外的注册信息，并使用本文档范围之外的同步协议。
A 6LR cannot accept a new registration when its registration storage space is exhausted. In that situation, the EARO is returned in an NA message with a status code of "Neighbor Cache Full" (Status 2; see [RFC6775] and Table 1), and the Registering Node may attempt to register to another 6LR.
当6LR的注册存储空间耗尽时，6LR无法接受新的注册。在这种情况下，在NA消息中返回EARO，状态代码为“邻居缓存已满”（状态2；请参阅[RFC6775]和表1），注册节点可能会尝试注册到另一个6LR。
If the registry in the 6LBR is full, then the 6LBR cannot decide whether a registration for a new address is a duplicate. In that case, the 6LBR replies to an EDAR message with an EDAC message that carries a new status code indicating "6LBR Registry Saturated" (Table 1). Note: This code is used by 6LBRs instead of "Neighbor Cache Full" when responding to a Duplicate Address message exchange and is passed on to the Registering Node by the 6LR. There is no point in the node retrying this registration via another 6LR, since the problem is network-wide. The node may abandon that address, de-register other addresses first to make room, or keep the address "tentative" [RFC4861] and retry later.
如果6LBR中的注册表已满，则6LBR无法确定新地址的注册是否重复。在这种情况下，6LBR使用EDAC消息回复EDAR消息，该消息携带一个新的状态代码，指示“6LBR注册表饱和”（表1）。注意：6LBRs在响应重复地址消息交换时使用此代码，而不是“邻居缓存已满”，并由6LR传递给注册节点。节点通过另一个6LR重试此注册没有意义，因为问题是网络范围内的。节点可以放弃该地址，首先取消注册其他地址以腾出空间，或者保留地址“暂定”[RFC4861]，然后重试。
A node renews an existing registration by sending a new NS(EARO) message for the Registered Address, and the 6LR MUST report the new registration to the 6LBR.
节点通过发送注册地址的新NS（EARO）消息来更新现有注册，6LR必须向6LBR报告新注册。
A node that ceases to use an address SHOULD attempt to de-register that address from all the 6LRs to which it has registered the address. This is achieved using an NS(EARO) message with a Registration Lifetime of 0. If this is not done, the associated state will remain in the network until the current Registration Lifetime expires; this may lead to a situation where the 6LR resources become saturated, even if they were correctly planned to start with. The 6LR may then take defensive measures that may prevent this node or some other nodes from owning as many addresses as they request (see Section 7).
停止使用地址的节点应尝试从其已注册地址的所有6LR中注销该地址。这是使用注册生存期为0的NS（EARO）消息实现的。如果不这样做，关联状态将保留在网络中，直到当前注册生存期到期；这可能会导致6LR资源饱和的情况，即使他们正确地计划开始。然后，6LR可采取防御措施，防止该节点或某些其他节点拥有其请求的尽可能多的地址（参见第7节）。
A node that moves away from a particular 6LR SHOULD attempt to de-register all of its addresses registered to that 6LR and register to a new 6LR with an incremented TID. When/if the node appears elsewhere, an asynchronous NA(EARO) or EDAC message with a status code of "Moved" SHOULD be used to clean up the state in the previous location. The "Moved" status can be used by a Routing Registrar in an NA(EARO) message to indicate that the ownership of the proxy state was transferred to another Routing Registrar due to movement of the device. If the receiver of the message has registration state corresponding to the related address, it SHOULD propagate the status down the forwarding path to the Registered Node (e.g., reversing an existing RPL [RFC6550] path as prescribed in [Efficient-NPDAO]). Whether it could do so or not, the receiver MUST clean up said state.
离开特定6LR的节点应尝试注销其注册到该6LR的所有地址，并使用递增的TID注册到新的6LR。当/如果节点出现在其他位置，则应使用状态代码为“已移动”的异步NA（EARO）或EDAC消息清除前一位置的状态。“移动”状态可由NA（EARO）消息中的路由注册器使用，以指示代理状态的所有权由于设备的移动而转移到另一个路由注册器。如果消息的接收者具有对应于相关地址的注册状态，则其应将状态沿着转发路径传播到注册节点（例如，按照[NPDAO]中的规定反转现有RPL[RFC6550]路径）。无论它是否可以这样做，接收者必须清理所述状态。
Upon receiving an NS(EARO) message with a Registration Lifetime of 0 and determining that this EARO is the most recent for a given NCE (see Section 5.2), a 6LR cleans up its NCE. If the address was registered to the 6LBR, then the 6LR MUST report to the 6LBR, through a Duplicate Address exchange with the 6LBR, indicating the null Registration Lifetime and the latest TID that this 6LR is aware of.
当接收到注册生存期为0的NS（EARO）消息并确定该EARO是给定NCE的最新消息时（参见第5.2节），6LR将清除其NCE。如果该地址已注册到6LBR，则6LR必须通过与6LBR的重复地址交换向6LBR报告，指示空注册寿命和该6LR知道的最新TID。
Upon receiving the EDAR message, the 6LBR determines if this is the most recent TID it has received for that particular registry entry. If so, then the EDAR is answered with an EDAC message bearing a status code of 0 ("Success") [RFC6775], and the entry is scheduled to be removed. Otherwise, a status code of "Moved" is returned instead, and the existing entry is maintained.
收到EDAR消息后，6LBR确定这是否是该特定注册表项最近收到的TID。如果是这样，则EDAR将通过带有状态代码0（“成功”）[RFC6775]的EDAC消息进行应答，并计划删除该条目。否则，将返回状态代码“Moved”，并保留现有条目。
When an address is scheduled to be removed, the 6LBR SHOULD keep its NCE in a DELAY state [RFC4861] for a configurable period of time, so as to prevent a scenario where (1) a mobile node that de-registered from one 6LR did not yet register to a new one or (2) the new registration did not yet reach the 6LBR due to propagation delays in the network. Once the DELAY time has passed, the 6LBR silently removes its entry.
当计划删除地址时，6LBR应在可配置的时间段内将其NCE保持在延迟状态[RFC4861]，以防止出现以下情况：（1）从一个6LR注销的移动节点尚未注册到新的6LR或（2）由于网络中的传播延迟，新注册尚未到达6LBR。一旦延迟时间过去，6LBR会自动删除其条目。
This specification changes the behavior of the peers in a registration flow. To enable backward compatibility, a 6LN that registers to a 6LR that is not known to support this specification MUST behave in a manner that is backward compatible with [RFC6775]. Conversely, if the 6LR is found to support this specification, then the 6LN MUST conform to this specification when communicating with that 6LR.
此规范更改注册流中对等方的行为。为了实现向后兼容，注册到不支持本规范的6LR的6LN必须以与[RFC6775]向后兼容的方式运行。相反，如果发现6LR支持本规范，则6LN在与该6LR通信时必须符合本规范。
A 6LN that supports this specification MUST always use an EARO as a replacement for an ARO in its registration to a router. This behavior is backward compatible, since the T flag and TID field occupy fields that are reserved in [RFC6775] and are thus ignored by an RFC 6775-only router. A router that supports this specification MUST answer an NS(ARO) and an NS(EARO) with an NA(EARO). A router that does not support this specification will consider the ROVR as an EUI-64 address and treat it the same; this scenario has no consequence if the Registered Addresses are different.
支持此规范的6LN在向路由器注册时必须始终使用EARO替代ARO。此行为是向后兼容的，因为T标志和TID字段占用[RFC6775]中保留的字段，因此被仅RFC 6775路由器忽略。支持此规范的路由器必须用NA（EARO）应答NS（ARO）和NS（EARO）。不支持此规范的路由器将考虑ROVR作为EUI 64地址，并将其视为相同；如果注册地址不同，则此场景没有任何后果。
[RFC7400] specifies the 6CIO, which indicates a node's capabilities to the node's peers. The 6CIO MUST be present in both RS and RA messages, unless the 6CIO information was already shared in recent exchanges or pre-configured in all nodes in a network. In any case, a 6CIO MUST be placed in an RA message that is sent in response to an RS with a 6CIO.
[RFC7400]指定6CIO，它向节点的对等方指示节点的能力。除非6CIO信息已在最近的交换中共享或在网络中的所有节点中预先配置，否则6CIO必须同时出现在RS和RA消息中。在任何情况下，必须将6CIO放在RA消息中，该消息通过6CIO发送给RS。
Section 4.3 defines a new flag for the 6CIO to signal EARO support by the issuer of the message. New flags are also added to the 6CIO to signal the sender's capability to act as a 6LR, 6LBR, and Routing Registrar (see Section 4.3).
第4.3节为6CIO定义了一个新标志，以表示消息发布者对EARO的支持。6CIO中还添加了新标志，以表明发送方作为6LR、6LBR和路由注册器的能力（参见第4.3节）。
Section 4.3 also defines a new flag that indicates the support of EDAR and EDAC messages by the 6LBR. This flag is valid in RA messages but not in RS messages. More information on the 6LBR is found in a separate Authoritative Border Router Option (ABRO). The ABRO is placed in RA messages as prescribed by [RFC6775]; in particular, it MUST be placed in an RA message that is sent in response to an RS with a 6CIO indicating the capability to act as a 6LR, since the RA propagates information between routers.
第4.3节还定义了一个新标志，表示6LBR支持EDAR和EDAC信息。此标志在RA消息中有效，但在RS消息中无效。有关6LBR的更多信息，请参见单独的权威边界路由器选项（ABRO）。ABRO按照[RFC6775]的规定放置在RA消息中；特别是，由于RA在路由器之间传播信息，因此必须将其放置在RA消息中，该消息是响应RS发送的，带有6CIO，指示作为6LR的能力。
An RFC 6775-only 6LN will use the Registered Address as the Source Address of the NS message and will not use an EARO. An updated 6LR MUST accept that registration if it is valid per [RFC6775], and it MUST manage the binding cache accordingly. The updated 6LR MUST then use the RFC 6775-only DAR and DAC messages as specified in [RFC6775] to indicate to the 6LBR that the TID is not present in the messages.
仅限RFC 6775 6LN将使用注册地址作为NS消息的源地址，而不使用EARO。如果更新的6LR根据[RFC6775]有效，则必须接受该注册，并且必须相应地管理绑定缓存。然后，更新的6LR必须使用[RFC6775]中规定的RFC 6775仅限DAR和DAC消息，以向6LBR指示消息中不存在TID。
The main difference from [RFC6775] is that the exchange of DAR and DAC messages for the purpose of DAD is avoided for Link-Local Addresses. In any case, the 6LR MUST use an EARO in the reply and can use any of the status codes defined in this specification.
与[RFC6775]的主要区别在于，对于链路本地地址，避免了为DAD目的而交换DAR和DAC消息。在任何情况下，6LR必须在回复中使用EARO，并且可以使用本规范中定义的任何状态代码。
An updated 6LN discovers the capabilities of the 6LR in the 6CIO in RA messages from that 6LR; if the 6CIO was not present in the RA, then the 6LR is assumed to be RFC 6775-only.
更新的6LN在来自该6LR的RA消息中的6CIO中发现6LR的能力；如果RA中不存在6CIO，则假定6LR仅为RFC 6775。
An updated 6LN MUST use an EARO in the request, regardless of the type of 6LR -- RFC 6775-only or updated; this implies that the T flag is set. It MUST use a ROVR of 64 bits if the 6LR is RFC 6775-only.
更新后的6LN必须在请求中使用EARO，无论6LR的类型是RFC 6775 only还是updated；这意味着设置了T标志。如果6LR仅为RFC 6775，则必须使用64位ROVR。
If an updated 6LN moves from an updated 6LR to an RFC 6775-only 6LR, the RFC 6775-only 6LR will send an RFC 6775-only DAR message, which cannot be compared with an updated one for recency. Allowing RFC 6775-only DAR messages to update a state established by the updated protocol in the 6LBR would be an attack vector; therefore, this cannot be the default behavior. But if RFC 6775-only and updated 6LRs coexist temporarily in a network, then it makes sense for an administrator to install a policy that allows this behavior, using some method that is out of scope for this document.
如果更新的6LN从更新的6LR移动到仅限RFC 6775的6LR，则仅限RFC 6775的6LR将发送仅限RFC 6775的DAR消息，该消息无法与更新的最近性消息进行比较。允许RFC 6775仅DAR消息更新由6LBR中更新的协议建立的状态将是攻击向量；因此，这不能是默认行为。但是，如果仅RFC 6775和更新的6LR在网络中暂时共存，则管理员可以安装允许此行为的策略，使用本文档不适用的方法。
With this specification, the Duplicate Address messages are extended to transport the EARO information. As with the NS/NA exchange, an updated 6LBR MUST always use the EDAR and EDAC messages.
根据此规范，复制地址消息被扩展以传输EARO信息。与NS/NA交换一样，更新的6LBR必须始终使用EDAR和EDAC消息。
Note that an RFC 6775-only 6LBR will accept and process an EDAR message as if it were an RFC 6775-only DAR, as long as the ROVR is 64 bits long. An updated 6LR discovers the capabilities of the 6LBR in the 6CIO in RA messages from the 6LR; if the 6CIO was not present in any RA, then the 6LBR is assumed to be RFC 6775-only.
请注意，只要ROVR长度为64位，RFC 6775 only 6LBR将接受和处理EDAR消息，就像它是RFC 6775 only DAR一样。更新的6LR在来自6LR的RA消息中的6CIO中发现6LBR的能力；如果6CIO不存在于任何RA中，则假定6LBR仅为RFC 6775。
If the 6LBR is RFC 6775-only, the 6LR MUST use only the 64 leftmost bits of the ROVR and place the result in the EDAR message to maintain compatibility. This way, the support of DAD is preserved.
如果6LBR仅为RFC 6775，则6LR必须仅使用ROVR最左边的64位，并将结果放入EDAR消息中以保持兼容性。这样，爸爸的支持就得以保留。
This specification extends [RFC6775], and the Security Considerations section of that document also applies to this document. In particular, the link layer SHOULD be sufficiently protected to prevent rogue access.
本规范扩展了[RFC6775]，该文件的安全注意事项部分也适用于本文件。特别是，链路层应得到充分保护，以防止恶意访问。
[RFC6775] does not protect the content of its messages and expects lower-layer encryption to defeat potential attacks. This specification requires the LLN MAC layer to provide secure unicast to/from a Routing Registrar and secure broadcast or multicast from the Routing Registrar in a way that prevents tampering with or replaying the ND messages.
[RFC6775]不保护其消息的内容，并期望较低层的加密能够击败潜在的攻击。本规范要求LLN MAC层以防止篡改或重播ND消息的方式向路由注册器提供安全的单播，并从路由注册器提供安全的广播或多播。
This specification recommends using privacy techniques (see Section 8) and protecting against address theft via methods that are outside the scope of this document. As an example, [AP-ND] guarantees the ownership of the Registered Address using a cryptographic ROVR.
本规范建议使用隐私技术（见第8节），并通过本文件范围之外的方法防止地址被盗。例如，[AP-ND]使用加密ROVR保证注册地址的所有权。
The registration mechanism may be used by a rogue node to attack the 6LR or 6LBR with a denial-of-service attack against the registry. It may also happen that the registry of a 6LR or 6LBR is saturated and cannot take any more registrations; this scenario effectively denies the requesting node the capability to use a new address. In order to alleviate those concerns, (1) Section 5.2 provides a sequence counter that keeps incrementing to detect and clean up stale registration information and that contributes to defeat replay attacks and (2) Section 5.7 provides a number of recommendations that ensure that a stale registration is removed as soon as possible from the 6LR and 6LBR.
恶意节点可使用注册机制通过对注册表的拒绝服务攻击来攻击6LR或6LBR。6LR或6LBR的注册也可能饱和，无法再进行任何注册；该场景有效地拒绝了请求节点使用新地址的能力。为了缓解这些问题，（1）第5.2节提供了一个序列计数器，该计数器不断递增，以检测和清除过时的注册信息，并有助于击败重播攻击；（2）第5.7节提供了一些建议，以确保尽快从6LR和6LBR中删除过时的注册。
In particular, this specification recommends that:
本规范特别建议：
o A node that ceases to use an address SHOULD attempt to de-register that address from all the 6LRs to which it is registered.
o 停止使用地址的节点应尝试从其注册的所有6LR中注销该地址。
o The registration lifetimes SHOULD be individually configurable for each address or group of addresses. A node SHOULD be configured for each address (or address category) with a Registration Lifetime that reflects the expectation of how long it will use the address with the 6LR to which the address is registered. In particular, use cases that involve mobility or rapid address changes SHOULD use lifetimes that are the same order of magnitude as the duration of the expectation of presence but that are still longer.
o 每个地址或地址组的注册生存期都应该是可单独配置的。应该为每个地址（或地址类别）配置一个节点，该节点的注册生存期反映了它将使用地址注册到的6LR的预期时间。特别是，涉及移动性或快速地址更改的用例应该使用与预期存在时间相同数量级但更长的生命周期。
o The router (6LR or 6LBR) SHOULD be configurable so as to limit the number of addresses that can be registered by a single node, but as a protective measure only. In any case, a router MUST be able to keep a minimum number of addresses per node. That minimum depends on the type of device and ranges between 3 for a very constrained LLN and 10 for a larger device. A node may be identified by its MAC address, as long as it is not obfuscated by privacy measures. A stronger identification (e.g., by security credentials) is RECOMMENDED. When the maximum is reached, the router SHOULD use a Least Recently Used (LRU) algorithm to clean up the addresses, keeping at least one Link-Local Address. The router SHOULD attempt to keep one or more stable addresses if stability can be determined, e.g., because they are used over a much longer time span than other (privacy, shorter-lived) addresses.
o 路由器（6LR或6LBR）应可配置，以限制单个节点可注册的地址数量，但仅作为保护措施。在任何情况下，路由器必须能够保持每个节点的最小地址数。该最小值取决于设备的类型，对于非常受限的LLN为3，对于较大的设备为10。一个节点可以通过它的MAC地址来识别，只要它没有被隐私措施混淆。建议使用更强的标识（例如，通过安全凭据）。当达到最大值时，路由器应使用最近最少使用（LRU）算法清理地址，至少保留一个链路本地地址。如果可以确定稳定性，路由器应尝试保持一个或多个稳定地址，例如，因为它们的使用时间跨度比其他（隐私、寿命较短）地址长得多。
o In order to avoid denial of registration due to a lack of resources, administrators should take great care to deploy adequate numbers of 6LRs to cover the needs of the nodes in their range, so as to avoid a situation of starving nodes. It is expected that the 6LBR that serves an LLN is a more capable node
o 为了避免由于缺乏资源而导致注册被拒绝，管理员应该非常小心地部署足够数量的6LR，以满足其范围内节点的需求，从而避免出现节点饥饿的情况。预计为LLN提供服务的6LBR是一个功能更强的节点
than the average 6LR, but in a network condition where it may become saturated, a particular LLN should distribute the 6LBR functionality -- for instance, by leveraging a high-speed Backbone Link and Routing Registrars to aggregate multiple LLNs into a larger subnet.
超过平均6LR，但在可能饱和的网络条件下，特定LLN应分配6LBR功能——例如，利用高速主干链路和路由注册器将多个LLN聚合到一个更大的子网中。
The LLN nodes depend on a 6LBR and may use the services of a Routing Registrar for their operation. A trust model MUST be put in place to ensure that only authorized devices are acting in these roles, so as to avoid threats such as black-holing or bombing attack whereby an impersonated 6LBR would destroy state in the network by using the "Removed" status code. At a minimum, this trust model could be based on Layer 2 access control or could provide role validation as well (see Req-5.1 in Appendix B.5).
LLN节点依赖于6LBR，可以使用路由注册器的服务进行操作。必须建立一个信任模型，以确保只有授权的设备才能扮演这些角色，从而避免诸如黑洞或爆炸攻击之类的威胁，即模拟的6LBR将使用“已删除”状态代码破坏网络中的状态。至少，该信任模型可以基于第2层访问控制，也可以提供角色验证（见附录B.5中的Req-5.1）。
As indicated in Section 3, this protocol does not limit the number of IPv6 Addresses that each device can form. However, to mitigate denial-of-service attacks, it can be useful as a protective measure to have a limit that is high enough not to interfere with the normal behavior of devices in the network. A host should be able to form and register any address that is topologically correct in the subnet(s) advertised by the 6LR/6LBR.
如第3节所述，该协议不限制每个设备可以形成的IPv6地址数量。但是，为了减轻拒绝服务攻击，可以将限制设置为足够高而不干扰网络中设备的正常行为，作为一种保护措施。主机应能够在6LR/6LBR播发的子网中形成并注册任何拓扑正确的地址。
This specification does not mandate any particular way for forming IPv6 Addresses, but it discourages using EUI-64 for forming the Interface Identifier in the Link-Local Address because this method prevents the usage of Secure Neighbor Discovery (SEND) [RFC3971], Cryptographically Generated Addresses (CGAs) [RFC3972], and other address privacy techniques.
本规范未规定形成IPv6地址的任何特定方式，但不鼓励使用EUI-64在链路本地地址中形成接口标识符，因为此方法防止使用安全邻居发现（SEND）[RFC3971]，加密生成地址（CGA）[RFC3972]，和其他地址隐私技术。
[RFC8065] ("Privacy Considerations for IPv6 Adaptation-Layer Mechanisms") explains why privacy is important and how to form privacy-aware addresses. All implementations and deployments must consider the option of privacy addresses in their own environments.
[RFC8065]（“IPv6适配层机制的隐私注意事项”）解释了隐私的重要性以及如何形成隐私感知地址。所有的实现和部署都必须考虑在它们自己的环境中的隐私地址的选择。
The IPv6 Address of the 6LN in the IPv6 header can be compressed statelessly when the Interface Identifier in the IPv6 Address can be derived from the lower-layer address. When it is not critical to benefit from that compression, e.g., the address can be compressed statefully, or it is rarely used and/or it is used only over one hop, privacy concerns should be considered. In particular, new implementations should follow [RFC8064] ("Recommendation on Stable IPv6 Interface Identifiers"). [RFC8064] recommends the mechanism specified in [RFC7217] ("A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)") for generating Interface Identifiers to be used in SLAAC.
当IPv6地址中的接口标识符可以从较低层地址派生时，IPv6报头中6LN的IPv6地址可以无状态压缩。如果从该压缩中获益并不重要，例如，地址可以有状态压缩，或者很少使用和/或仅在一个跃点上使用，则应考虑隐私问题。特别是，新的实现应该遵循[RFC8064]（“关于稳定IPv6接口标识符的建议”）。[RFC8064]建议使用[RFC7217]（“使用IPv6无状态地址自动配置（SLAAC）生成语义不透明接口标识符的方法”）中指定的机制来生成要在SLAAC中使用的接口标识符。
IANA has made a number of changes under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry, as follows.
IANA在“Internet控制消息协议版本6（ICMPv6）参数”注册表下进行了如下更改。
IANA has created a new subregistry for "Address Registration Option Flags" under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry. (See [RFC4443] for information regarding ICMPv6.)
IANA在“Internet控制消息协议版本6（ICMPv6）参数”注册表下为“地址注册选项标志”创建了一个新的子区域。（有关ICMPv6的信息，请参见[RFC4443]）
This specification defines eight positions -- bit 0 to bit 7 -- and assigns bit 6 for the R flag and bit 7 for the T flag (see Section 4.1). The registration procedure is "IETF Review" or "IESG Approval" (see [RFC8126]).
本规范定义了八个位置——位0到位7——并为R标志分配位6，为T标志分配位7（见第4.1节）。注册程序为“IETF审查”或“IESG批准”（见[RFC8126]）。
The initial contents of the registry are shown in Table 2.
注册表的初始内容如表2所示。
+-------------+--------------+------------+
| ARO Status | Description | Reference |
+-------------+--------------+------------+
| 0-5 | Unassigned | |
| | | |
| 6 | R Flag | RFC 8505 |
| | | |
| 7 | T Flag | RFC 8505 |
+-------------+--------------+------------+
+-------------+--------------+------------+
| ARO Status | Description | Reference |
+-------------+--------------+------------+
| 0-5 | Unassigned | |
| | | |
| 6 | R Flag | RFC 8505 |
| | | |
| 7 | T Flag | RFC 8505 |
+-------------+--------------+------------+
Table 2: New Address Registration Option Flags
表2：新地址注册选项标志
IANA has created a new subregistry for "Address Registration Option I-Field" under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry.
IANA已在“互联网控制消息协议版本6（ICMPv6）参数”注册表下为“地址注册选项I-Field”创建了一个新的子域。
This specification defines four integer values from 0 to 3 and assigns value 0 to "Abstract Index for Topology Selection" (see Section 4.1). The registration procedure is "IETF Review" or "IESG Approval" [RFC8126].
本规范定义了从0到3的四个整数值，并将值0分配给“拓扑选择的抽象索引”（见第4.1节）。注册程序为“IETF审查”或“IESG批准”[RFC8126]。
The initial contents of the registry are shown in Table 3.
登记册的初始内容如表3所示。
+--------+---------------------------------------+------------+
| Value | Meaning | Reference |
+--------+---------------------------------------+------------+
| 0 | Abstract Index for Topology Selection | RFC 8505 |
| | | |
| 1-3 | Unassigned | |
+--------+---------------------------------------+------------+
+--------+---------------------------------------+------------+
| Value | Meaning | Reference |
+--------+---------------------------------------+------------+
| 0 | Abstract Index for Topology Selection | RFC 8505 |
| | | |
| 1-3 | Unassigned | |
+--------+---------------------------------------+------------+
Table 3: New Subregistry for the EARO I-Field
表3:EARO I-Field的新分区
IANA has created two new subregistries of the 'ICMPv6 "Code" Fields' registry, which itself is a subregistry of ICMPv6 codes in the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry.
IANA已创建了“ICMPv6”代码“字段”注册表的两个新子域，该注册表本身是“Internet控制消息协议版本6（ICMPv6）参数”注册表中ICMPv6代码的子域。
The new subregistries relate to ICMP Types 157 (Duplicate Address Request) (shown in Table 4) and 158 (Duplicate Address Confirmation) (shown in Table 5), respectively. For those two ICMP types, the ICMP Code field is split into two subfields: the Code Prefix and the Code Suffix. The new subregistries relate to the Code Suffix portion of the ICMP Code. The range of the Code Suffix is 0-15 in all cases. The registration procedure is "IETF Review" or "IESG Approval" [RFC8126] for both subregistries.
新的分区域分别涉及ICMP类型157（重复地址请求）（见表4）和158（重复地址确认）（见表5）。对于这两种ICMP类型，ICMP代码字段分为两个子字段：代码前缀和代码后缀。新的分区域与ICMP代码的代码后缀部分有关。在所有情况下，代码后缀的范围都是0-15。两个分区域的注册程序均为“IETF审查”或“IESG批准”[RFC8126]。
The initial contents of these subregistries are as follows:
这些分区域的初步内容如下：
+--------------+--------------------------------------+------------+
| Code Suffix | Meaning | Reference |
+--------------+--------------------------------------+------------+
| 0 | DAR message | RFC 6775 |
| | | |
| 1 | EDAR message with 64-bit ROVR field | RFC 8505 |
| | | |
| 2 | EDAR message with 128-bit ROVR field | RFC 8505 |
| | | |
| 3 | EDAR message with 192-bit ROVR field | RFC 8505 |
| | | |
| 4 | EDAR message with 256-bit ROVR field | RFC 8505 |
| | | |
| 5-15 | Unassigned | |
+--------------+--------------------------------------+------------+
+--------------+--------------------------------------+------------+
| Code Suffix | Meaning | Reference |
+--------------+--------------------------------------+------------+
| 0 | DAR message | RFC 6775 |
| | | |
| 1 | EDAR message with 64-bit ROVR field | RFC 8505 |
| | | |
| 2 | EDAR message with 128-bit ROVR field | RFC 8505 |
| | | |
| 3 | EDAR message with 192-bit ROVR field | RFC 8505 |
| | | |
| 4 | EDAR message with 256-bit ROVR field | RFC 8505 |
| | | |
| 5-15 | Unassigned | |
+--------------+--------------------------------------+------------+
Table 4: Code Suffixes for ICMP Type 157 DAR Message
表4:ICMP类型157 DAR报文的代码后缀
+--------------+--------------------------------------+------------+
| Code Suffix | Meaning | Reference |
+--------------+--------------------------------------+------------+
| 0 | DAC message | RFC 6775 |
| | | |
| 1 | EDAC message with 64-bit ROVR field | RFC 8505 |
| | | |
| 2 | EDAC message with 128-bit ROVR field | RFC 8505 |
| | | |
| 3 | EDAC message with 192-bit ROVR field | RFC 8505 |
| | | |
| 4 | EDAC message with 256-bit ROVR field | RFC 8505 |
| | | |
| 5-15 | Unassigned | |
+--------------+--------------------------------------+------------+
+--------------+--------------------------------------+------------+
| Code Suffix | Meaning | Reference |
+--------------+--------------------------------------+------------+
| 0 | DAC message | RFC 6775 |
| | | |
| 1 | EDAC message with 64-bit ROVR field | RFC 8505 |
| | | |
| 2 | EDAC message with 128-bit ROVR field | RFC 8505 |
| | | |
| 3 | EDAC message with 192-bit ROVR field | RFC 8505 |
| | | |
| 4 | EDAC message with 256-bit ROVR field | RFC 8505 |
| | | |
| 5-15 | Unassigned | |
+--------------+--------------------------------------+------------+
Table 5: Code Suffixes for ICMP Type 158 DAC Message
表5:ICMP 158型DAC报文的代码后缀
IANA has made additions to the "Address Registration Option Status Values" subregistry, as follows:
IANA对“地址注册选项状态值”子区域进行了如下补充：
+-------+--------------------------------------------+------------+
| Value | Description | Reference |
+-------+--------------------------------------------+------------+
| 3 | Moved | RFC 8505 |
| | | |
| 4 | Removed | RFC 8505 |
| | | |
| 5 | Validation Requested | RFC 8505 |
| | | |
| 6 | Duplicate Source Address | RFC 8505 |
| | | |
| 7 | Invalid Source Address | RFC 8505 |
| | | |
| 8 | Registered Address Topologically Incorrect | RFC 8505 |
| | | |
| 9 | 6LBR Registry Saturated | RFC 8505 |
| | | |
| 10 | Validation Failed | RFC 8505 |
+-------+--------------------------------------------+------------+
+-------+--------------------------------------------+------------+
| Value | Description | Reference |
+-------+--------------------------------------------+------------+
| 3 | Moved | RFC 8505 |
| | | |
| 4 | Removed | RFC 8505 |
| | | |
| 5 | Validation Requested | RFC 8505 |
| | | |
| 6 | Duplicate Source Address | RFC 8505 |
| | | |
| 7 | Invalid Source Address | RFC 8505 |
| | | |
| 8 | Registered Address Topologically Incorrect | RFC 8505 |
| | | |
| 9 | 6LBR Registry Saturated | RFC 8505 |
| | | |
| 10 | Validation Failed | RFC 8505 |
+-------+--------------------------------------------+------------+
Table 6: New ARO Status Values
表6：新的ARO状态值
IANA has made additions to the "6LoWPAN Capability Bits" subregistry, as follows:
IANA对“6LoWPAN能力Bits”子区域进行了如下补充：
+------+---------------------------+------------+
| Bit | Description | Reference |
+------+---------------------------+------------+
| 10 | EDA Support (D bit) | RFC 8505 |
| | | |
| 11 | 6LR capable (L bit) | RFC 8505 |
| | | |
| 12 | 6LBR capable (B bit) | RFC 8505 |
| | | |
| 13 | Routing Registrar (P bit) | RFC 8505 |
| | | |
| 14 | EARO support (E bit) | RFC 8505 |
+------+---------------------------+------------+
+------+---------------------------+------------+
| Bit | Description | Reference |
+------+---------------------------+------------+
| 10 | EDA Support (D bit) | RFC 8505 |
| | | |
| 11 | 6LR capable (L bit) | RFC 8505 |
| | | |
| 12 | 6LBR capable (B bit) | RFC 8505 |
| | | |
| 13 | Routing Registrar (P bit) | RFC 8505 |
| | | |
| 14 | EARO support (E bit) | RFC 8505 |
+------+---------------------------+------------+
Table 7: New 6LoWPAN Capability Bits
表7：新的6LoWPAN功能位
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<https://www.rfc-editor.org/info/rfc4291>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，Ed.“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，STD 89，RFC 4443，DOI 10.17487/RFC4443，2006年3月<https://www.rfc-editor.org/info/rfc4443>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<https://www.rfc-editor.org/info/rfc4862>.
[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, DOI 10.17487/RFC4919, August 2007, <https://www.rfc-editor.org/info/rfc4919>.
[RFC4919]Kushalnagar，N.，黑山，G.和C.Schumacher，“低功率无线个人区域网络（6LoWPANs）上的IPv6：概述，假设，问题陈述和目标”，RFC 4919，DOI 10.17487/RFC4919，2007年8月<https://www.rfc-editor.org/info/rfc4919>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.
[RFC6282]Hui，J.，Ed.和P.Thubert，“基于IEEE 802.15.4的网络上IPv6数据报的压缩格式”，RFC 6282，DOI 10.17487/RFC6282，2011年9月<https://www.rfc-editor.org/info/rfc6282>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing", RFC 6606, DOI 10.17487/RFC6606, May 2012, <https://www.rfc-editor.org/info/rfc6606>.
[RFC6606]Kim，E.，Kaspar，D.，Gomez，C.，和C.Bormann，“通过低功率无线个人区域网络（6LoWPAN）路由的IPv6问题陈述和要求”，RFC 6606，DOI 10.17487/RFC6606，2012年5月<https://www.rfc-editor.org/info/rfc6606>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.
[RFC6775]Shelby，Z.，Ed.，Chakrabarti，S.，Nordmark，E.，和C.Bormann，“低功率无线个人区域网络（6LoWPANs）上IPv6邻居发现优化”，RFC 6775，DOI 10.17487/RFC67752012年11月<https://www.rfc-editor.org/info/rfc6775>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 2014, <https://www.rfc-editor.org/info/rfc7400>.
[RFC7400]Bormann，C.，“6LoWPAN GHC：低功率无线个人区域网络（6LoWPANs）上IPv6的通用报头压缩”，RFC 7400，DOI 10.17487/RFC7400，2014年11月<https://www.rfc-editor.org/info/rfc7400>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[Alternative-Ellip-Curve-Reps] Struik, R., "Alternative Elliptic Curve Representations", Work in Progress, draft-struik-lwip-curve-representations-00, October 2017.
[Alternative Ellip Curve Reps]Struik，R.，“备选椭圆曲线表示法”，正在进行的工作，draft-Struik-lwip-Curve-Representations-00，2017年10月。
[AP-ND] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, "Address Protected Neighbor Discovery for Low-power and Lossy Networks", Work in Progress, draft-ietf-6lo-ap-nd-08, October 2018.
[AP-ND]Thubert，P.，Ed.，Sarikaya，B.，Sethi，M.，和R.Struik，“低功率和有损网络的地址保护邻居发现”，正在进行的工作，草案-ietf-6lo-AP-ND-082018年10月。
[Arch-for-6TiSCH] Thubert, P., Ed., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, draft-ietf-6tisch-architecture-17, November 2018.
[Arch-for-6TiSCH]Thubert，P.，Ed.“基于IEEE 802.15.4的TSCH模式的IPv6架构”，正在进行的工作，草案-ietf-6TiSCH-Architecture-17，2018年11月。
[Efficient-NPDAO] Jadhav, R., Ed., Thubert, P., Sahoo, R., and Z. Cao, "Efficient Route Invalidation", Work in Progress, draft-ietf-roll-efficient-npdao-09, October 2018.
[Efficient NPDAO]Jadhav，R.，Ed.，Thubert，P.，Sahoo，R.，和Z.Cao，“有效路线失效”，在建工程，草案-ietf-roll-Efficient-NPDAO-09，2018年10月。
[IEEE-802-15-4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Standard 802.15.4, DOI 10.1109/IEEESTD.2016.7460875, <https://ieeexplore.ieee.org/document/7460875/>.
[IEEE-802-15-4]IEEE，“低速无线网络的IEEE标准”，IEEE标准802.15.4，DOI 10.1109/IEEESTD.2016.7460875<https://ieeexplore.ieee.org/document/7460875/>.
[IPv6-Backbone-Router] Thubert, P., Ed. and C. Perkins, "IPv6 Backbone Router", Work in Progress, draft-ietf-6lo-backbone-router-08, October 2018.
[IPv6主干路由器]Thubert，P.，Ed.和C.Perkins，“IPv6主干路由器”，正在进行的工作，草稿-ietf-6lo-Backbone-Router-082018年10月。
[IPv6-over-802.11ah] Del Carpio Vega, L., Robles, M., and R. Morabito, "IPv6 over 802.11ah", Work in Progress, draft-delcarpio-6lo-wlanah-01, October 2015.
[IPv6-over-802.11ah]Del Carpio Vega，L.，Robles，M.，和R.Morabito，“IPv6 over 802.11ah”，正在进行的工作，草稿-delcarpio-6lo-wlanah-012015年10月。
[IPv6-over-NFC] Choi, Y., Ed., Hong, Y-G., Youn, J-S., Kim, D-K., and J-H. Choi, "Transmission of IPv6 Packets over Near Field Communication", Work in Progress, draft-ietf-6lo-nfc-12, November 2018.
[IPv6 over NFC]Choi，Y.，Ed.，Hong，Y-G.，Youn，J-S.，Kim，D-K.，和J-H.Choi，“通过近场通信传输IPv6数据包”，正在进行的工作，草案-ietf-6lo-NFC-12，2018年11月。
[IPv6-over-PLC] Hou, J., Liu, B., Hong, Y-G., Tang, X., and C. Perkins, "Transmission of IPv6 Packets over PLC Networks", Work in Progress, draft-hou-6lo-plc-05, October 2018.
[IPv6 over PLC]Hou，J.，Liu，B.，Hong，Y-G.，Tang，X.，和C.Perkins，“通过PLC网络传输IPv6数据包”，正在进行的工作，草稿-Hou-6lo-PLC-05，2018年10月。
[Multicast-over-IEEE802-Wireless] Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", Work in Progress, draft-ietf-mboned-ieee802-mcast-problems-03, October 2018.
[Multicast-over-IEEE802-Wireless]加州帕金斯、M.麦克布莱德、D.斯坦利、W.库马里和JC。Zuniga，“IEEE 802无线媒体上的多播注意事项”，正在进行的工作，草稿-ietf-mboned-ieee802-mcast-problems-032018年10月。
[ND-Optimizations] Chakrabarti, S., Nordmark, E., Thubert, P., and M. Wasserman, "IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks", Work in Progress, draft-chakrabarti-nordmark-6man-efficient-nd-07, February 2015.
[ND优化]Chakrabarti，S.，Nordmark，E.，Thubert，P.，和M.Wasserman，“有线和无线网络IPv6邻居发现优化”，正在进行的工作，草稿-Chakrabarti-Nordmark-6man-efficient-ND-072015年2月。
[Perlman83] Perlman, R., "Fault-Tolerant Broadcast of Routing Information", North-Holland Computer Networks 7: pp. 395-405, DOI 10.1016/0376-5075(83)90034-X, 1983, <http://www.cs.illinois.edu/~pbg/courses/cs598fa09/ readings/p83.pdf>.
[Perlman 83]Perlman，R.，“路由信息的容错广播”，北荷兰计算机网络7:395-405页，DOI 10.1016/0376-5075（83）90034-X，1983年<http://www.cs.illinois.edu/~pbg/courses/cs598fa09/readings/p83.pdf>。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, <https://www.rfc-editor.org/info/rfc1958>.
[RFC1958]Carpenter，B.，Ed.，“互联网的架构原则”，RFC 1958，DOI 10.17487/RFC19581996年6月<https://www.rfc-editor.org/info/rfc1958>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.
[RFC1982]Elz，R.和R.Bush，“序列号算术”，RFC 1982，DOI 10.17487/RFC1982，1996年8月<https://www.rfc-editor.org/info/rfc1982>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003, <https://www.rfc-editor.org/info/rfc3610>.
[RFC3610]Whiting，D.，Housley，R.，和N.Ferguson，“CBC-MAC（CCM）计数器”，RFC 3610，DOI 10.17487/RFC3610，2003年9月<https://www.rfc-editor.org/info/rfc3610>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.
[RFC3810]Vida，R.，Ed.和L.Costa，Ed.，“IPv6的多播侦听器发现版本2（MLDv2）”，RFC 3810，DOI 10.17487/RFC3810，2004年6月<https://www.rfc-editor.org/info/rfc3810>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 3971，DOI 10.17487/RFC3971，2005年3月<https://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, <https://www.rfc-editor.org/info/rfc3972>.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 3972，DOI 10.17487/RFC3972，2005年3月<https://www.rfc-editor.org/info/rfc3972>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, <https://www.rfc-editor.org/info/rfc4429>.
[RFC4429]Moore，N.，“IPv6的乐观重复地址检测（DAD）”，RFC 4429，DOI 10.17487/RFC4429，2006年4月<https://www.rfc-editor.org/info/rfc4429>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 4941，DOI 10.17487/RFC49411907年9月<https://www.rfc-editor.org/info/rfc4941>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.
[RFC6550]温特，T.，Ed.，Thubert，P.，Ed.，Brandt，A.，Hui，J.，Kelsey，R.，Levis，P.，Pister，K.，Struik，R.，Vasseur，JP.，和R.Alexander，“RPL:低功耗和有损网络的IPv6路由协议”，RFC 6550，DOI 10.17487/RFC6550，2012年3月<https://www.rfc-editor.org/info/rfc6550>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <https://www.rfc-editor.org/info/rfc7217>.
[RFC7217]Gont，F.“使用IPv6无状态地址自动配置（SLAAC）生成语义不透明接口标识符的方法”，RFC 7217，DOI 10.17487/RFC72172014年4月<https://www.rfc-editor.org/info/rfc7217>.
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/RFC7428, February 2015, <https://www.rfc-editor.org/info/rfc7428>.
[RFC7428]Brandt，A.和J.Buron，“通过ITU-T G.9959网络传输IPv6数据包”，RFC 7428，DOI 10.17487/RFC7428，2015年2月<https://www.rfc-editor.org/info/rfc7428>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, <https://www.rfc-editor.org/info/rfc7668>.
[RFC7668]Nieminen，J.，Savolainen，T.，Isomaki，M.，Patil，B.，Shelby，Z.，和C.Gomez，“蓝牙（R）低能量IPv6”，RFC 7668，DOI 10.17487/RFC7668，2015年10月<https://www.rfc-editor.org/info/rfc7668>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016, <https://www.rfc-editor.org/info/rfc7934>.
[RFC7934]Coletti，L.，Cerf，V.，Cheshire，S.，和D.Schinazi，“主机地址可用性建议”，BCP 204，RFC 7934，DOI 10.17487/RFC79342016年7月<https://www.rfc-editor.org/info/rfc7934>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, <https://www.rfc-editor.org/info/rfc8064>.
[RFC8064]Gont，F.，Cooper，A.，Thaler，D.，和W.Liu，“关于稳定IPv6接口标识符的建议”，RFC 8064，DOI 10.17487/RFC8064，2017年2月<https://www.rfc-editor.org/info/rfc8064>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[RFC8065]Thaler，D.，“IPv6适配层机制的隐私考虑”，RFC 8065，DOI 10.17487/RFC8065，2017年2月<https://www.rfc-editor.org/info/rfc8065>.
[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, M., and D. Barthel, "Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 2017, <https://www.rfc-editor.org/info/rfc8105>.
[RFC8105]Mariager，P.，Petersen，J.，Ed.，Shelby，Z.，Van de Logt，M.，和D.Barthel，“通过数字增强无绳通信（DECT）超低能（ULE）传输IPv6数据包”，RFC 8105，DOI 10.17487/RFC8105，2017年5月<https://www.rfc-editor.org/info/rfc8105>.
[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. Donaldson, "Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, May 2017, <https://www.rfc-editor.org/info/rfc8163>.
[RFC8163]Lynn，K.，Ed.，Martocci，J.，Neilson，C.，和S.Donaldson，“通过主从/令牌传递（MS/TP）网络传输IPv6”，RFC 8163，DOI 10.17487/RFC8163，2017年5月<https://www.rfc-editor.org/info/rfc8163>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>.
[RFC8279]Wijnands，IJ.，Ed.，Rosen，E.，Ed.，Dolganow，A.，Przygienda，T.，和S.Aldrin，“使用位索引显式复制（BIER）的多播”，RFC 8279，DOI 10.17487/RFC8279，2017年11月<https://www.rfc-editor.org/info/rfc8279>.
[Routing-for-RPL-Leaves] Thubert, P., Ed., "Routing for RPL Leaves", Work in Progress, draft-thubert-roll-unaware-leaves-05, May 2018.
【RPL叶路由】Thubert，P.，Ed.，“RPL叶路由”，正在进行的工作，草稿-Thubert-roll-Unknowledge-Leaves-052018年5月。
Appendix A. Applicability and Fulfilled Requirements (Not Normative)
附录A.适用性和满足的要求（非规范性）
This specification extends 6LoWPAN ND to provide a sequence number to the registration and fulfills the requirements expressed in Appendix B.1 by enabling the mobility of devices from one LLN to the next. A full specification for enabling mobility based on the use of the EARO and the registration procedures defined in this document can be found in subsequent work [IPv6-Backbone-Router] ("IPv6 Backbone Router"). The 6BBR is an example of a Routing Registrar that acts as an IPv6 ND proxy over a Backbone Link that federates multiple LLNs as well as the Backbone Link itself into a single IPv6 subnet. The expected registration flow in that case is illustrated in Figure 6, noting that any combination of 6LR, 6LBR, and 6BBR may be collocated.
本规范扩展了6LoWPAN ND，为注册提供了序列号，并通过实现设备从一个LLN到下一个LLN的移动性，满足附录B.1中所述的要求。在后续工作[IPv6主干路由器]（“IPv6主干路由器”）中可以找到基于EARO的使用和本文档中定义的注册程序实现移动性的完整规范。6BBR是路由注册器的一个示例，它在主干链路上充当IPv6 ND代理，该主干链路将多个LLN以及主干链路本身联合到单个IPv6子网中。这种情况下的预期注册流程如图6所示，注意6LR、6LBR和6BBR的任何组合都可以并置。
6LN 6LR 6LBR 6BBR
| | | |
| NS(EARO) | | |
|--------------->| | |
| | Extended DAR | |
| |-------------->| |
| | | |
| | | proxy NS(EARO) |
| | |--------------->|
| | | | NS(DAD)
| | | | ------>
| | | | <wait>
| | | |
| | | proxy NA(EARO) |
| | |<---------------|
| | Extended DAC | |
| |<--------------| |
| NA(EARO) | | |
|<---------------| | |
| | | |
6LN 6LR 6LBR 6BBR
| | | |
| NS(EARO) | | |
|--------------->| | |
| | Extended DAR | |
| |-------------->| |
| | | |
| | | proxy NS(EARO) |
| | |--------------->|
| | | | NS(DAD)
| | | | ------>
| | | | <wait>
| | | |
| | | proxy NA(EARO) |
| | |<---------------|
| | Extended DAC | |
| |<--------------| |
| NA(EARO) | | |
|<---------------| | |
| | | |
Figure 6: (Re-)Registration Flow
图6：（重新）注册流程
[Arch-for-6TiSCH] ("An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4") describes how a 6LoWPAN ND host using the Time-Slotted Channel Hopping (TSCH) mode of IEEE Std. 802.15.4 [IEEE-802-15-4] can connect to the Internet via a RPL mesh network. Doing so requires additions to the 6LoWPAN ND protocol to support mobility and reachability in a secure and manageable network environment. This document specifies those new operations and fulfills the requirements listed in Appendix B.2.
[Arch-for-6TiSCH]（“基于IEEE 802.15.4的TSCH模式的IPv6架构”）描述了使用IEEE标准802.15.4[IEEE-802-15-4]的时隙信道跳频（TSCH）模式的6LoWPAN ND主机如何通过RPL网状网络连接到Internet。这样做需要添加到6LoWPAN ND协议中，以支持在安全和可管理的网络环境中的移动性和可达性。本文件规定了这些新操作，并满足附录B.2中列出的要求。
The term "LLN" is used loosely in this document and is intended to cover multiple types of WLANs and WPANs, including Low-Power IEEE Std. 802.11 networking, Bluetooth low energy, IEEE Std. 802.11ah, and IEEE Std. 802.15.4 wireless meshes, so as to address the requirements discussed in Appendix B.3.
术语“LLN”在本文件中使用松散，旨在涵盖多种类型的WLAN和WPAN，包括低功耗IEEE标准802.11网络、蓝牙低能耗、IEEE标准802.11ah和IEEE标准802.15.4无线网格，以满足附录B.3中讨论的要求。
This specification can be used by any wireless node to register its IPv6 Addresses with a Routing Registrar and to obtain routing services such as proxy ND operations over a Backbone Link. This satisfies the requirements expressed in Appendix B.4.
任何无线节点都可以使用此规范向路由注册器注册其IPv6地址，并通过主干链路获得路由服务，如代理ND操作。这符合附录B.4中规定的要求。
This specification is extended by [AP-ND] to provide a solution to some of the security-related requirements expressed in Appendix B.5.
[AP-ND]扩展了本规范，为附录B.5中所述的一些安全相关要求提供了解决方案。
[ND-Optimizations] ("IPv6 Neighbor Discovery Optimizations for Wired
and Wireless Networks") suggests that 6LoWPAN ND [RFC6775] can be
extended to other types of links (beyond IEEE Std. 802.15.4) for
which it was defined. The registration technique is beneficial when
the link-layer technique used to carry IPv6 multicast packets is not
sufficiently efficient in terms of delivery ratio or energy
consumption in the end devices -- in particular, to enable
energy-constrained sleeping nodes. The value of such an extension is
especially apparent in the case of mobile wireless nodes, to reduce
the multicast operations that are related to IPv6 ND [RFC4861]
[RFC4862] and affect the operation of the wireless medium
[Multicast-over-IEEE802-Wireless]. This fulfills the scalability
requirements listed in Appendix B.6.
[ND-Optimizations] ("IPv6 Neighbor Discovery Optimizations for Wired
and Wireless Networks") suggests that 6LoWPAN ND [RFC6775] can be
extended to other types of links (beyond IEEE Std. 802.15.4) for
which it was defined. The registration technique is beneficial when
the link-layer technique used to carry IPv6 multicast packets is not
sufficiently efficient in terms of delivery ratio or energy
consumption in the end devices -- in particular, to enable
energy-constrained sleeping nodes. The value of such an extension is
especially apparent in the case of mobile wireless nodes, to reduce
the multicast operations that are related to IPv6 ND [RFC4861]
[RFC4862] and affect the operation of the wireless medium
[Multicast-over-IEEE802-Wireless]. This fulfills the scalability
requirements listed in Appendix B.6.
Appendix B. Requirements (Not Normative)
附录B.要求（非规范性）
This appendix lists requirements that were discussed by the 6lo Working Group for an update to 6LoWPAN ND. How those requirements are matched with existing specifications at the time of this writing is shown in Appendix B.8.
本附录列出了6lo工作组讨论的6LoWPAN ND更新要求。在撰写本文时，这些要求如何与现有规范相匹配，见附录B.8。
Due to the unstable nature of LLN links, even in an LLN of immobile nodes, a 6LN may change its point of attachment from, say, 6LR-a to 6LR-b but may not be able to notify 6LR-a. Consequently, 6LR-a may still attract traffic that it cannot deliver any more. When links to a 6LR change state, there is thus a need to identify stale states in a 6LR and restore reachability in a timely fashion, e.g., by using some type of signaling upon detection of the movement or using a keep-alive mechanism with a period that is consistent with the needs of the application.
由于LLN链路的不稳定性，即使在固定节点的LLN中，6LN也可能将其连接点从（例如）6LR-a更改为6LR-b，但可能无法通知6LR-a。因此，6LR-a仍可能吸引无法提供的流量。当链接到6LR更改状态时，因此需要识别6LR中的陈旧状态并及时恢复可达性，例如，通过在检测到移动时使用某种类型的信令或使用与应用程序需求一致的保持活动机制。
Req-1.1: Upon a change of point of attachment, connectivity via a new 6LR MUST be restored in a timely fashion without the need to de-register from the previous 6LR.
Req-1.1：当连接点发生变化时，必须及时恢复通过新6LR的连接，而无需从以前的6LR注销。
Req-1.2: For that purpose, the protocol MUST enable differentiating between multiple registrations from one 6LN and registrations from different 6LNs claiming the same address.
Req-1.2：为此，协议必须能够区分来自一个6LN的多个注册和来自声称相同地址的不同6LN的注册。
Req-1.3: Stale states MUST be cleaned up in 6LRs.
Req-1.3：必须在6LRs中清除陈旧状态。
Req-1.4: A 6LN SHOULD also be able to register its address concurrently to multiple 6LRs.
Req-1.4:6LN还应能够同时向多个6LR注册其地址。
The point of attachment of a 6LN may be a 6LR in an LLN mesh. IPv6 routing in an LLN can be based on RPL, which is the routing protocol that was defined by the IETF for this particular purpose. Other routing protocols are also considered by Standards Development Organizations (SDOs) on the basis of the expected network characteristics. It is required that a 6LN attached via ND to a 6LR indicate whether or not it (1) participates in the selected routing protocol to obtain reachability via the 6LR or (2) expects the 6LR to manage its reachability.
6LN的连接点可以是LLN网格中的6LR。LLN中的IPv6路由可以基于RPL，RPL是IETF为此目的定义的路由协议。标准开发组织（SDO）也会根据预期的网络特性考虑其他路由协议。要求通过ND连接到6LR的6LN指示其（1）是否参与所选路由协议以通过6LR获得可达性，或（2）是否期望6LR管理其可达性。
The specified updates enable other specifications to define new services such as Source Address Validation Improvement (SAVI) (via [AP-ND]), participation as an unaware leaf to a routing protocol (such as the protocol described in [RFC6550] (RPL)) (via [Routing-for-RPL-Leaves]), and registration to Backbone Routers performing proxy ND in an LLN (via [IPv6-Backbone-Router]).
指定的更新使得其他规范能够定义新的服务，例如源地址验证改进（SAVI）（通过[AP-ND]）、作为路由协议（例如[RFC6550]（RPL）中描述的协议）的不知情叶参与（通过[routing for RPL Leaves]）、以及注册到在LLN中执行代理ND的主干路由器（通过[IPv6骨干路由器]）。
Beyond the 6LBR unicast address registered by ND, other addresses, including multicast addresses, are needed as well. For example, a routing protocol often uses a multicast address to register changes to established paths. ND needs to register such a multicast address to enable routing concurrently with discovery.
除了ND注册的6LBR单播地址之外，还需要其他地址，包括多播地址。例如，路由协议通常使用多播地址来注册对已建立路径的更改。ND需要注册这样的多播地址，以便在发现的同时启用路由。
Multicast is needed for groups. Groups may be formed by device type (e.g., routers, street lamps), location (geography, RPL subtree), or both.
组需要多播。组可以由设备类型（例如路由器、路灯）、位置（地理、RPL子树）或两者组成。
The Bit Index Explicit Replication (BIER) architecture [RFC8279] proposes an optimized technique to enable multicast in an LLN with a very limited requirement for routing state in the nodes.
位索引显式复制（BIER）体系结构[RFC8279]提出了一种优化技术，可以在LLN中启用多播，而对节点中的路由状态的要求非常有限。
Related requirements are as follows:
相关要求如下：
Req-2.1: The ND registration method SHOULD be extended so that the 6LR is instructed whether to advertise the address of a 6LN over the selected routing protocol and obtain reachability to that address using the selected routing protocol.
Req-2.1：应扩展ND注册方法，以便指示6LR是否通过所选路由协议公布6LN的地址，并使用所选路由协议获得该地址的可达性。
Req-2.2: Considering RPL, the ARO that is used in the ND registration SHOULD be extended to carry enough information to generate a DAO message as specified in Section 6.4 of [RFC6550] -- in particular, the capability to compute a Path Sequence and, as an option, a RPLInstanceID.
Req-2.2：考虑到RPL，ND注册中使用的ARO应扩展，以携带足够的信息，以生成[RFC6550]第6.4节中规定的DAO消息——特别是计算路径序列和RPLInstanceID（可选）的能力。
Req-2.3: Multicast operations SHOULD be supported and optimized -- for instance, using BIER or the Multicast Protocol for Low-Power and Lossy Networks (MPL). Whether ND is appropriate for the registration to the Routing Registrar is to be defined, considering the additional burden of supporting Multicast Listener Discovery Version 2 (MLDv2) for IPv6 [RFC3810].
Req-2.3：应支持并优化多播操作——例如，使用BIER或低功耗有损网络（MPL）的多播协议。考虑到支持IPv6多播侦听器发现版本2（MLDv2）[RFC3810]的额外负担，需要定义ND是否适合注册到路由注册器。
6LoWPAN ND [RFC6775] was defined with a focus on IEEE Std.802.15.4 and, in particular, the capability to derive a unique identifier from a globally unique EUI-64 address. At this point, the 6lo Working Group is extending the 6LoWPAN Header Compression (HC) technique [RFC6282] to other link types, including ITU-T G.9959 [RFC7428], Master-Slave/Token-Passing [RFC8163], Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy [RFC8105], Near Field Communication [IPv6-over-NFC], and IEEE Std. 802.11ah [IPv6-over-802.11ah], as well as Bluetooth low energy [RFC7668] and Power Line Communication (PLC) Networks [IPv6-over-PLC].
6LoWPAN ND[RFC6775]的定义侧重于IEEE标准802.15.4，尤其是从全局唯一EUI-64地址派生唯一标识符的能力。此时，6lo工作组正在将6LoWPAN报头压缩（HC）技术[RFC6282]扩展到其他链路类型，包括ITU-T G.9959[RFC7428]、主从/令牌传递[RFC8163]、数字增强无绳通信（DECT）超低能量[RFC8105]、近场通信[IPv6 over NFC]和IEEE标准802.11ah[IPv6-over-802.11ah]，以及蓝牙低能耗[RFC7668]和电力线通信（PLC）网络[IPv6 over PLC]。
Related requirements are as follows:
相关要求如下：
Req-3.1: The support of the registration mechanism SHOULD be extended to more LLN links than IEEE Std.802.15.4, matching at least the LLN links for which an "IPv6 over foo" specification exists, as well as low-power Wi-Fi.
Req-3.1：注册机制的支持应扩展到比IEEE Std.802.15.4更多的LLN链路，至少匹配存在“IPv6 over foo”规范的LLN链路以及低功耗Wi-Fi。
Req-3.2: As part of this extension, a mechanism to compute a unique identifier should be provided, with the capability to form a Link-Local Address that SHOULD be unique at least within the LLN connected to a 6LBR discovered by ND in each node within the LLN.
Req-3.2：作为该扩展的一部分，应提供一种计算唯一标识符的机制，该机制能够形成一个链路本地地址，该地址至少在连接到由ND在LLN内的每个节点中发现的6LBR的LLN内是唯一的。
Req-3.3: The ARO used in the ND registration SHOULD be extended to carry the relevant forms of the unique identifier.
Req-3.3：ND注册中使用的ARO应扩展，以携带唯一标识符的相关形式。
Req-3.4: ND should specify the formation of a site-local address that follows the security recommendations in [RFC7217].
Req-3.4:ND应规定按照[RFC7217]中的安全建议形成站点本地地址。
Duty-cycled devices may not be awake to answer a lookup from a node that uses IPv6 ND and may need a proxy. Additionally, the duty-cycled device may rely on the 6LBR to perform registration to the Routing Registrar.
占空比循环的设备可能无法唤醒，无法应答来自使用IPv6 ND的节点的查找，并且可能需要代理。此外，占空比循环设备可依赖6LBR向路由注册器执行注册。
The ND registration method SHOULD defend the addresses of duty-cycled devices that are sleeping most of the time and incapable of defending their own addresses.
ND注册方法应该保护占空比设备的地址，这些设备大部分时间处于睡眠状态，无法保护自己的地址。
Related requirements are as follows:
相关要求如下：
Req-4.1: The registration mechanism SHOULD enable a third party to proxy-register an address on behalf of a 6LN that may be sleeping or located deeper in an LLN mesh.
Req-4.1：注册机制应允许第三方代表6LN代理注册地址，该6LN可能处于休眠状态或位于LLN网状结构的较深位置。
Req-4.2: The registration mechanism SHOULD be applicable to a duty-cycled device regardless of the link type and SHOULD enable a Routing Registrar to operate as a proxy to defend the Registered Addresses on its behalf.
Req-4.2：无论链路类型如何，注册机制应适用于占空比设备，并应使路由注册器能够作为代理代表其维护注册地址。
Req-4.3: The registration mechanism SHOULD enable long sleep durations, on the order of multiple days to a month.
Req-4.3：注册机制应允许长睡眠时间，从几天到一个月不等。
In order to guarantee the operations of the 6LoWPAN ND flows, spoofing the roles of the 6LR, 6LBR, and Routing Registrar should be avoided. Once a node successfully registers an address, 6LoWPAN ND should provide energy-efficient means for the 6LBR to protect that ownership even when the node that registered the address is sleeping.
为了保证6LoWPAN ND流的操作，应避免欺骗6LR、6LBR和路由注册器的角色。一旦一个节点成功注册了一个地址，6LoWPAN ND应该为6LBR提供节能的方法来保护该所有权，即使注册地址的节点正在睡眠。
In particular, the 6LR and the 6LBR should then be able to verify whether a subsequent registration for a given address comes from the original node.
特别是，6LR和6LBR应能够验证给定地址的后续注册是否来自原始节点。
In an LLN, it makes sense to base security on Layer 2 security. During bootstrap of the LLN, nodes join the network after authorization by a Joining Assistant (JA) or a Commissioning Tool (CT). After joining, nodes communicate with each other via secured links. The keys for Layer 2 security are distributed by the JA/CT.
在LLN中，将安全性建立在第2层安全性的基础上是有意义的。在LLN引导过程中，节点通过加入助手（JA）或调试工具（CT）授权后加入网络。加入后，节点通过安全链路相互通信。第2层安全的密钥由JA/CT分发。
The JA/CT can be part of the LLN or be outside the LLN. In both cases, the ability to route packets between the JA/CT and the joining node is needed.
JA/CT可以是LLN的一部分，也可以在LLN之外。在这两种情况下，都需要在JA/CT和加入节点之间路由数据包的能力。
Related requirements are as follows:
相关要求如下：
Req-5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for the 6LR, 6LBR, and Routing Registrar to authenticate and authorize one another for their respective roles, as well as with the 6LN for the role of 6LR.
Req-5.1:6LoWPAN ND安全机制应为6LR、6LBR和路由注册器提供一种机制，以相互验证和授权各自的角色，并为6LR角色提供6LN。
Req-5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for the 6LR and the 6LBR to validate new registrations of authorized nodes. Joining of unauthorized nodes MUST be prevented.
Req-5.2:6LoWPAN ND安全机制应为6LR和6LBR提供一种机制，以验证授权节点的新注册。必须防止加入未经授权的节点。
Req-5.3: The use of 6LoWPAN ND security mechanisms SHOULD NOT result in large packet sizes. In particular, the NS, NA, DAR, and DAC messages for a re-registration flow SHOULD NOT exceed 80 octets so as to fit in a secured IEEE Std.802.15.4 [IEEE-802-15-4] frame.
Req-5.3：使用6LoWPAN ND安全机制不应导致大数据包大小。特别地，用于重新注册流的NS、NA、DAR和DAC消息不应超过80个八位字节，以便适合于安全的IEEE Std.802.15.4[IEEE-802-15-4]帧。
Req-5.4: Recurrent 6LoWPAN ND security operations MUST NOT be computationally intensive on the 6LN's CPU. When calculation of a key hash is employed, a mechanism lighter than SHA-1 SHOULD be used.
Req-5.4:6LoWPAN ND安全操作在6LN的CPU上不能是计算密集型的。当使用密钥散列计算时，应使用比SHA-1轻的机制。
Req-5.5: The number of keys that the 6LN needs to manipulate SHOULD be minimized.
Req-5.5：应尽量减少6LN需要操纵的钥匙数量。
Req-5.6: 6LoWPAN ND security mechanisms SHOULD enable (1) the variation of CCM ("Counter with CBC-MAC") [RFC3610] called "CCM*" for use at both Layer 2 and Layer 3 and (2) the reuse of a security code that has to be present on the device for upper-layer security (e.g., TLS). Algorithm agility and support for large keys (e.g., 256-bit key sizes) are also desirable.
Req-5.6:6LoWPAN ND安全机制应允许（1）称为“CCM*”的CCM（“带CBC-MAC的计数器”）[RFC3610]的变化在第2层和第3层使用；（2）重用必须存在于设备上的安全代码以实现上层安全（例如TLS）。算法灵活性和对大密钥（例如256位密钥大小）的支持也是可取的。
Req-5.7: Public key and signature sizes SHOULD be minimized while maintaining adequate confidentiality and data origin authentication for multiple types of applications with various degrees of criticality.
Req-5.7：应尽量减少公钥和签名的大小，同时为具有不同关键程度的多种类型的应用程序保持足够的机密性和数据源身份验证。
Req-5.8: Routing of packets should continue when links pass from the unsecured state to the secured state.
Req-5.8：当链路从非安全状态转移到安全状态时，数据包的路由应继续。
Req-5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for the 6LR and the 6LBR to validate whether a new registration for a given address corresponds to the same 6LN that registered it initially and, if not, determine the rightful owner and deny or clean up the registration if it is a duplicate.
Req-5.9:6LoWPAN ND安全机制应为6LR和6LBR提供一种机制，以验证给定地址的新注册是否与最初注册的6LN相同，如果不一致，则确定合法所有者，并拒绝或清除重复注册。
Use cases from Automatic Meter Reading (AMR) (collection-tree operations) and Advanced Metering Infrastructure (AMI) (bidirectional communication to the meters) indicate the need for a large number of LLN nodes pertaining to a single RPL DODAG (e.g., 5000) and connected to the 6LBR over a large number of LLN hops (e.g., 15).
来自自动抄表（AMR）（收集树操作）和高级计量基础设施（AMI）（与仪表的双向通信）的用例表明，需要大量与单个RPL DODAG（例如5000）相关的LLN节点，并通过大量LLN跃点（例如15）连接到6LBR。
Related requirements are as follows:
相关要求如下：
Req-6.1: The registration mechanism SHOULD enable a single 6LBR to register multiple thousands of devices.
Req-6.1：注册机制应允许单个6LBR注册数千个设备。
Req-6.2: The timing of the registration operation should allow for long latency, such as that found in LLNs with ten or more hops.
Req-6.2：注册操作的计时应允许较长的延迟，例如在具有十个或更多跳数的LLN中发现的延迟。
Guideline 3.8 in Section 3 of [RFC1958] ("Architectural Principles of the Internet") recommends the following: "Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually." This is especially true in LLNs where the number of devices may be large and manual configuration is infeasible. Capabilities for dynamic configuration of LLN devices can also be constrained by network and power limitations.
[RFC1958]（“互联网架构原则”）第3节中的准则3.8建议：“尽可能避免选项和参数。任何选项和参数都应动态配置或协商，而不是手动配置。”这在LLN中尤其如此，在LLN中，设备数量可能很大，手动配置不可行。LLN设备的动态配置能力也可能受到网络和电源限制的限制。
A network administrator should be able to validate that the network is operating within capacity and that, in particular, a 6LBR does not get overloaded with an excessive amount of registrations, so the administrator can take actions such as adding a Backbone Link with additional 6LBRs and Routing Registrars to the network.
网络管理员应能够验证网络是否在容量范围内运行，尤其是6LBR不会因过多的注册而过载，因此管理员可以采取措施，例如向网络添加带有额外6LBR和路由注册器的主干链路。
Related requirements are as follows:
相关要求如下：
Req-7.1: A management model SHOULD be provided that enables access to the 6LBR, monitors its usage vs. capacity, and sends alerts in the case of congestion. It is recommended that the 6LBR be reachable over a non-LLN link.
Req-7.1：应提供一个管理模型，允许访问6LBR，监控其使用情况与容量，并在发生拥塞时发送警报。建议通过非LLN链路访问6LBR。
Req-7.2: A management model SHOULD be provided that enables access to the 6LR and its capacity to host additional NCEs. This management model SHOULD avoid polling individual 6LRs in a way that could disrupt the operation of the LLN.
Req-7.2：应提供能够访问6LR及其承载额外NCE的能力的管理模型。这种管理模式应避免以可能中断LLN运行的方式轮询单个6LR。
Req-7.3: Information on successful and failed registrations SHOULD be provided, including information such as the ROVR of the 6LN, the Registered Address, the address of the 6LR, and the duration of the registration flow.
Req-7.3：应提供成功注册和失败注册的信息，包括6LN的ROVR、注册地址、6LR地址以及注册流程的持续时间等信息。
Req-7.4: In the case of a failed registration, information on the failure, including the identification of the node that rejected the registration and the status in the EARO, SHOULD be provided.
Req-7.4：如果注册失败，应提供失败信息，包括拒绝注册的节点标识和EARO中的状态。
+-------------+--------------------------------+
| Requirement | Document |
+-------------+--------------------------------+
| Req-1.1 | [IPv6-Backbone-Router] |
| | |
| Req-1.2 | [RFC6775] |
| | |
| Req-1.3 | [RFC6775] |
| | |
| Req-1.4 | RFC 8505 |
| | |
| Req-2.1 | RFC 8505 |
| | |
| Req-2.2 | RFC 8505 |
| | |
| Req-2.3 | |
| | |
| Req-3.1 | Technology Dependent |
| | |
| Req-3.2 | Technology Dependent |
| | |
| Req-3.3 | Technology Dependent |
| | |
| Req-3.4 | Technology Dependent |
+-------------+--------------------------------+
| Requirement | Document |
+-------------+--------------------------------+
| Req-1.1 | [IPv6-Backbone-Router] |
| | |
| Req-1.2 | [RFC6775] |
| | |
| Req-1.3 | [RFC6775] |
| | |
| Req-1.4 | RFC 8505 |
| | |
| Req-2.1 | RFC 8505 |
| | |
| Req-2.2 | RFC 8505 |
| | |
| Req-2.3 | |
| | |
| Req-3.1 | Technology Dependent |
| | |
| Req-3.2 | Technology Dependent |
| | |
| Req-3.3 | Technology Dependent |
| | |
| Req-3.4 | Technology Dependent |
| | |
| Req-4.1 | RFC 8505 |
| | |
| Req-4.2 | RFC 8505 |
| | |
| Req-4.3 | [RFC6775] |
| | |
| Req-5.1 | |
| | |
| Req-5.2 | [AP-ND] |
| | |
| Req-5.3 | |
| | |
| Req-5.4 | |
| | |
| Req-5.5 | [AP-ND] |
| | |
| Req-5.6 | [Alternative-Ellip-Curve-Reps] |
| | |
| Req-5.7 | [AP-ND] |
| | |
| Req-5.8 | |
| | |
| Req-5.9 | [AP-ND] |
| | |
| Req-6.1 | RFC 8505 |
| | |
| Req-6.2 | RFC 8505 |
| | |
| Req-7.1 | |
| | |
| Req-7.2 | |
| | |
| Req-7.3 | |
| | |
| Req-7.4 | |
+-------------+--------------------------------+
| | |
| Req-4.1 | RFC 8505 |
| | |
| Req-4.2 | RFC 8505 |
| | |
| Req-4.3 | [RFC6775] |
| | |
| Req-5.1 | |
| | |
| Req-5.2 | [AP-ND] |
| | |
| Req-5.3 | |
| | |
| Req-5.4 | |
| | |
| Req-5.5 | [AP-ND] |
| | |
| Req-5.6 | [Alternative-Ellip-Curve-Reps] |
| | |
| Req-5.7 | [AP-ND] |
| | |
| Req-5.8 | |
| | |
| Req-5.9 | [AP-ND] |
| | |
| Req-6.1 | RFC 8505 |
| | |
| Req-6.2 | RFC 8505 |
| | |
| Req-7.1 | |
| | |
| Req-7.2 | |
| | |
| Req-7.3 | |
| | |
| Req-7.4 | |
+-------------+--------------------------------+
Table 8: Documents That Address Requirements
表8：满足要求的文件
Acknowledgments
致谢
Kudos to Eric Levy-Abegnoli, who designed the "First-Hop Security" infrastructure upon which the first Backbone Router was implemented. Many thanks to Sedat Gormus, Rahul Jadhav, Tim Chown, Juergen Schoenwaelder, Chris Lonvick, Dave Thaler, Adrian Farrel, Peter Yee, Warren Kumari, Benjamin Kaduk, Mirja Kuehlewind, Ben Campbell, Eric Rescorla, and Lorenzo Colitti for their various contributions and reviews. Also, many thanks to Thomas Watteyne for the world's first implementation of a 6LN that was instrumental to the early tests of the 6LR, 6LBR, and Backbone Router.
Eric Levy Abegnoli设计了“第一跳安全”基础设施，第一个主干路由器就是在这个基础设施上实现的。非常感谢镇静戈尔姆斯、拉胡尔·贾达夫、蒂姆·乔恩、尤尔根·舍恩瓦埃尔德、克里斯·朗维克、戴夫·泰勒、阿德里安·法雷尔、彼得·耶伊、沃伦·库马里、本杰明·卡杜克、米尔贾·库勒温德、本·坎贝尔、埃里克·雷斯科拉和洛伦佐·科利蒂的各种贡献和评论。此外，非常感谢Thomas Watteyne在世界上首次实现了6LN，这有助于6LR、6LBR和主干路由器的早期测试。
Authors' Addresses
作者地址
Pascal Thubert (editor) Cisco Systems, Inc. Building D (Regus) 45 Allee des Ormes Mougins - Sophia Antipolis France
Pascal Thubert（编辑）思科系统公司D栋（Regus）45 Allee des Ormes Mougins-索菲亚安提波利斯法国
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Erik Nordmark Zededa Santa Clara, CA United States of America
Erik Nordmark Zededa Santa Clara，加利福尼亚州，美利坚合众国
Email: nordmark@sonic.net
Email: nordmark@sonic.net
Samita Chakrabarti Verizon San Jose, CA United States of America
Samita Chakrabarti Verizon San Jose，加利福尼亚州，美利坚合众国
Email: samitac.ietf@gmail.com
Email: samitac.ietf@gmail.com
Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara, CA 95050 United States of America
Charles E.Perkins Futurewi 2330美国加利福尼亚州圣克拉拉中央高速公路95050号
Email: charliep@computer.org
Email: charliep@computer.org