Network Working Group J. Arkko, Ed.
Request for Comments: 3971 Ericsson
Category: Standards Track J. Kempf
DoCoMo Communications Labs USA
B. Zill
Microsoft
P. Nikander
Ericsson
March 2005
Network Working Group J. Arkko, Ed.
Request for Comments: 3971 Ericsson
Category: Standards Track J. Kempf
DoCoMo Communications Labs USA
B. Zill
Microsoft
P. Nikander
Ericsson
March 2005
SEcure Neighbor Discovery (SEND)
安全邻居发现（发送）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec.
IPv6节点使用邻居发现协议（NDP）来发现链路上的其他节点，确定其链路层地址以查找路由器，并维护有关到活动邻居的路径的可达性信息。如果不安全，NDP容易受到各种攻击。本文件规定了NDP的安全机制。与原始NDP规范中的机制不同，这些机制不使用IPsec。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Neighbor and Router Discovery Overview. . . . . . . . . . . . 6
4. Secure Neighbor Discovery Overview. . . . . . . . . . . . . . 8
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . . 9
5.1. CGA Option. . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Processing Rules for Senders. . . . . . . . . . 11
5.1.2. Processing Rules for Receivers. . . . . . . . . 12
5.1.3. Configuration . . . . . . . . . . . . . . . . . 13
5.2. RSA Signature Option. . . . . . . . . . . . . . . . . . 14
5.2.1. Processing Rules for Senders. . . . . . . . . . 16
5.2.2. Processing Rules for Receivers. . . . . . . . . 16
5.2.3. Configuration . . . . . . . . . . . . . . . . . 17
5.2.4. Performance Considerations. . . . . . . . . . . 18
5.3. Timestamp and Nonce Options . . . . . . . . . . . . . . 19
5.3.1. Timestamp Option. . . . . . . . . . . . . . . . 19
5.3.2. Nonce Option. . . . . . . . . . . . . . . . . . 20
5.3.3. Processing Rules for Senders. . . . . . . . . . 21
5.3.4. Processing Rules for Receivers. . . . . . . . . 21
6. Authorization Delegation Discovery. . . . . . . . . . . . . . 24
6.1. Authorization Model . . . . . . . . . . . . . . . . . . 24
6.2. Deployment Model. . . . . . . . . . . . . . . . . . . . 25
6.3. Certificate Format. . . . . . . . . . . . . . . . . . . 26
6.3.1. Router Authorization Certificate Profile. . . . 26
6.3.2. Suitability of Standard Identity Certificates . 29
6.4. Certificate Transport . . . . . . . . . . . . . . . . . 29
6.4.1. Certification Path Solicitation Message Format. 30
6.4.2. Certification Path Advertisement Message Format 32
6.4.3. Trust Anchor Option . . . . . . . . . . . . . . 34
6.4.4. Certificate Option. . . . . . . . . . . . . . . 36
6.4.5. Processing Rules for Routers. . . . . . . . . . 37
6.4.6. Processing Rules for Hosts. . . . . . . . . . . 38
6.5. Configuration . . . . . . . . . . . . . . . . . . . . . 39
7. Addressing. . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. CGAs. . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.2. Redirect Addresses. . . . . . . . . . . . . . . . . . . 40
7.3. Advertised Subnet Prefixes. . . . . . . . . . . . . . . 40
7.4. Limitations . . . . . . . . . . . . . . . . . . . . . . 41
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9.1. Threats to the Local Link Not Covered by SEND . . . . . 44
9.2. How SEND Counters Threats to NDP. . . . . . . . . . . . 45
9.2.1. Neighbor Solicitation/Advertisement Spoofing. . 45
9.2.2. Neighbor Unreachability Detection Failure . . . 46
9.2.3. Duplicate Address Detection DoS Attack. . . . . 46
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Neighbor and Router Discovery Overview. . . . . . . . . . . . 6
4. Secure Neighbor Discovery Overview. . . . . . . . . . . . . . 8
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . . 9
5.1. CGA Option. . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Processing Rules for Senders. . . . . . . . . . 11
5.1.2. Processing Rules for Receivers. . . . . . . . . 12
5.1.3. Configuration . . . . . . . . . . . . . . . . . 13
5.2. RSA Signature Option. . . . . . . . . . . . . . . . . . 14
5.2.1. Processing Rules for Senders. . . . . . . . . . 16
5.2.2. Processing Rules for Receivers. . . . . . . . . 16
5.2.3. Configuration . . . . . . . . . . . . . . . . . 17
5.2.4. Performance Considerations. . . . . . . . . . . 18
5.3. Timestamp and Nonce Options . . . . . . . . . . . . . . 19
5.3.1. Timestamp Option. . . . . . . . . . . . . . . . 19
5.3.2. Nonce Option. . . . . . . . . . . . . . . . . . 20
5.3.3. Processing Rules for Senders. . . . . . . . . . 21
5.3.4. Processing Rules for Receivers. . . . . . . . . 21
6. Authorization Delegation Discovery. . . . . . . . . . . . . . 24
6.1. Authorization Model . . . . . . . . . . . . . . . . . . 24
6.2. Deployment Model. . . . . . . . . . . . . . . . . . . . 25
6.3. Certificate Format. . . . . . . . . . . . . . . . . . . 26
6.3.1. Router Authorization Certificate Profile. . . . 26
6.3.2. Suitability of Standard Identity Certificates . 29
6.4. Certificate Transport . . . . . . . . . . . . . . . . . 29
6.4.1. Certification Path Solicitation Message Format. 30
6.4.2. Certification Path Advertisement Message Format 32
6.4.3. Trust Anchor Option . . . . . . . . . . . . . . 34
6.4.4. Certificate Option. . . . . . . . . . . . . . . 36
6.4.5. Processing Rules for Routers. . . . . . . . . . 37
6.4.6. Processing Rules for Hosts. . . . . . . . . . . 38
6.5. Configuration . . . . . . . . . . . . . . . . . . . . . 39
7. Addressing. . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. CGAs. . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.2. Redirect Addresses. . . . . . . . . . . . . . . . . . . 40
7.3. Advertised Subnet Prefixes. . . . . . . . . . . . . . . 40
7.4. Limitations . . . . . . . . . . . . . . . . . . . . . . 41
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9.1. Threats to the Local Link Not Covered by SEND . . . . . 44
9.2. How SEND Counters Threats to NDP. . . . . . . . . . . . 45
9.2.1. Neighbor Solicitation/Advertisement Spoofing. . 45
9.2.2. Neighbor Unreachability Detection Failure . . . 46
9.2.3. Duplicate Address Detection DoS Attack. . . . . 46
9.2.4. Router Solicitation and Advertisement Attacks . 46
9.2.5. Replay Attacks. . . . . . . . . . . . . . . . . 47
9.2.6. Neighbor Discovery DoS Attack . . . . . . . . . 48
9.3. Attacks against SEND Itself . . . . . . . . . . . . . . 48
10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . . 49
10.1. Constants . . . . . . . . . . . . . . . . . . . . . . . 49
10.2. Variables . . . . . . . . . . . . . . . . . . . . . . . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 50
12.1. Normative References. . . . . . . . . . . . . . . . . . 50
12.2. Informative References. . . . . . . . . . . . . . . . . 51
Appendices. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A. Contributors and Acknowledgments. . . . . . . . . . . . 53
B. Cache Management. . . . . . . . . . . . . . . . . . . . 53
C. Message Size When Carrying Certificates . . . . . . . . 54
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statements . . . . . . . . . . . . . . . . . . . . 56
9.2.4. Router Solicitation and Advertisement Attacks . 46
9.2.5. Replay Attacks. . . . . . . . . . . . . . . . . 47
9.2.6. Neighbor Discovery DoS Attack . . . . . . . . . 48
9.3. Attacks against SEND Itself . . . . . . . . . . . . . . 48
10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . . 49
10.1. Constants . . . . . . . . . . . . . . . . . . . . . . . 49
10.2. Variables . . . . . . . . . . . . . . . . . . . . . . . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 50
12.1. Normative References. . . . . . . . . . . . . . . . . . 50
12.2. Informative References. . . . . . . . . . . . . . . . . 51
Appendices. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A. Contributors and Acknowledgments. . . . . . . . . . . . 53
B. Cache Management. . . . . . . . . . . . . . . . . . . . 53
C. Message Size When Carrying Certificates . . . . . . . . 54
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statements . . . . . . . . . . . . . . . . . . . . 56
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [4] and 2462 [5]. Nodes on the same link use NDP to discover each other's presence and link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. NDP is used by both hosts and routers. Its functions include Neighbor Discovery (ND), Router Discovery (RD), Address Autoconfiguration, Address Resolution, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Redirection.
IPv6在RFCs 2461[4]和2462[5]中定义了邻居发现协议（NDP）。同一链路上的节点使用NDP来发现彼此的存在和链路层地址，查找路由器，并维护有关到活动邻居的路径的可达性信息。主机和路由器都使用NDP。它的功能包括邻居发现（ND）、路由器发现（RD）、地址自动配置、地址解析、邻居不可达性检测（NUD）、重复地址检测（DAD）和重定向。
The original NDP specifications called for the use of IPsec to protect NDP messages. However, the RFCs do not give detailed instructions for using IPsec to do this. In this particular application, IPsec can only be used with a manual configuration of security associations, due to bootstrapping problems in using IKE [19, 15]. Furthermore, the number of manually configured security associations needed for protecting NDP can be very large [20], making that approach impractical for most purposes.
最初的NDP规范要求使用IPsec来保护NDP消息。但是，RFC没有给出使用IPsec执行此操作的详细说明。在这个特定的应用程序中，IPsec只能与安全关联的手动配置一起使用，因为在使用IKE时存在引导问题[19,15]。此外，保护NDP所需的手动配置安全关联的数量可能非常大[20]，这使得该方法在大多数情况下都不切实际。
The SEND protocol is designed to counter the threats to NDP. These threats are described in detail in [22]. SEND is applicable in environments where physical security on the link is not assured (such as over wireless) and attacks on NDP are a concern.
发送协议旨在对抗NDP面临的威胁。[22]中详细描述了这些威胁。SEND适用于链路上的物理安全无法保证（如通过无线）且NDP受到攻击的环境。
This document is organized as follows. Sections 2 and 3 define some terminology and present a brief review of NDP, respectively. Section 4 describes the overall approach to securing NDP. This approach involves the use of new NDP options to carry public key - based signatures. A zero-configuration mechanism is used for showing
本文件的组织结构如下。第2节和第3节定义了一些术语，并分别简要回顾了NDP。第4节描述了保护NDP的总体方法。这种方法包括使用新的NDP选项来携带基于公钥的签名。零配置机制用于显示
address ownership on individual nodes; routers are certified by a trust anchor [7]. The formats, procedures, and cryptographic mechanisms for the zero-configuration mechanism are described in a related specification [11].
单个节点上的地址所有权；路由器由信任锚进行认证[7]。零配置机制的格式、过程和加密机制在相关规范中进行了描述[11]。
The required new NDP options are discussed in Section 5. Section 6 describes the mechanism for distributing certification paths to establish an authorization delegation chain to a trust anchor.
第5节讨论了所需的新NDP选项。第6节描述了分发证书路径以建立到信任锚的授权委托链的机制。
Finally, Section 8 discusses the co-existence of secured and unsecured NDP on the same link, and Section 9 discusses security considerations for SEcure Neighbor Discovery (SEND).
最后，第8节讨论了同一链路上安全NDP和非安全NDP的共存，第9节讨论了安全邻居发现（SEND）的安全注意事项。
The use of identity certificates provisioned on end hosts for authorizing address use is out of the scope for this document, as is the security of NDP when the entity defending an address is not the same as the entity claiming that address (also known as "proxy ND"). These are extensions of SEND that may be treated in separate documents, should the need arise.
当捍卫地址的实体与声称该地址的实体（也称为“代理ND”）不同时，使用终端主机上提供的身份证书授权地址使用不在本文档的范围内，NDP的安全性也不在本文档的范围内。这些是SEND的扩展，如果需要，可以在单独的文档中处理。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" are to be interpreted as described in [2].
在本文件中，使用了几个词来表示规范的要求。这些词通常大写。关键词“必须”、“不得”、“应该”、“不应该”、“建议”和“可能”的解释如[2]所述。
Authorization Delegation Discovery (ADD)
授权委托发现（ADD）
A process through which SEND nodes can acquire a certification path from a peer node to a trust anchor.
一种过程，通过该过程，发送节点可以获取从对等节点到信任锚点的认证路径。
Certificate Revocation List (CRL)
证书吊销列表（CRL）
In one method of certificate revocation, an authority periodically issues a signed data structure called the Certificate Revocation List. This is a time-stamped list identifying revoked certificates, signed by the issuer, and made freely available in a public repository.
在证书撤销的一种方法中，授权机构定期发布称为证书撤销列表的签名数据结构。这是一个带有时间戳的列表，标识已吊销的证书，由颁发者签名，并在公共存储库中免费提供。
Certification Path Advertisement (CPA)
认证路径公告（CPA）
The advertisement message used in the ADD process.
添加过程中使用的播发消息。
Certification Path Solicitation (CPS)
认证路径请求（CPS）
The solicitation message used in the ADD process.
添加过程中使用的请求消息。
Cryptographically Generated Address (CGA)
加密生成地址（CGA）
A technique [11] whereby an IPv6 address of a node is cryptographically generated by using a one-way hash function from the node's public key and some other parameters.
一种技术[11]，通过使用来自节点公钥和一些其他参数的单向散列函数以加密方式生成节点的IPv6地址。
Distinguished Encoding Rules (DER)
区分编码规则（DER）
An encoding scheme for data values, defined in [12].
[12]中定义的数据值编码方案。
Duplicate Address Detection (DAD)
重复地址检测（DAD）
A mechanism assuring that two IPv6 nodes on the same link are not using the same address.
确保同一链路上的两个IPv6节点不使用相同地址的机制。
Fully Qualified Domain Name (FQDN)
完全限定域名（FQDN）
A fully qualified domain name consists of a host and domain name, including the top-level domain.
完全限定域名由主机和域名（包括顶级域）组成。
Internationalized Domain Name (IDN)
国际化域名（IDN）
Internationalized Domain Names can be used to represent domain names that contain characters outside the ASCII set. See RFC 3490 [9].
国际化域名可用于表示包含ASCII集以外字符的域名。参见RFC 3490[9]。
Neighbor Discovery (ND)
邻居发现（ND）
The Neighbor Discovery function of the Neighbor Discovery Protocol (NDP). NDP contains functions besides ND.
邻居发现协议（NDP）的邻居发现功能。NDP包含除ND之外的函数。
Neighbor Discovery Protocol (NDP)
邻居发现协议（NDP）
The IPv6 Neighbor Discovery Protocol [7, 8].
IPv6邻居发现协议[7,8]。
The Neighbor Discovery Protocol is a part of ICMPv6 [6].
邻居发现协议是ICMPv6[6]的一部分。
Neighbor Unreachability Detection (NUD)
邻居不可达性检测（NUD）
A mechanism used for tracking the reachability of neighbors.
一种用于跟踪邻居可达性的机制。
Non-SEND node
非发送节点
An IPv6 node that does not implement this specification but uses only the Neighbor Discovery protocol defined in RFCs 2461 and 2462, as updated, without security.
未实现此规范但仅使用RFCs 2461和2462中定义的邻居发现协议（更新后）的IPv6节点，没有安全性。
Nonce
暂时
An unpredictable random or pseudo-random number generated by a node and used exactly once. In SEND, nonces are used to assure that a particular advertisement is linked to the solicitation that triggered it.
一个节点生成的不可预测的随机数或伪随机数，只使用一次。在SEND中，nonce用于确保特定广告与触发该广告的邀约相链接。
Router Authorization Certificate
路由器授权证书
An X.509v3 [7] public key certificate using the profile specified in Section 6.3.1.
使用第6.3.1节中指定的配置文件的X.509v3[7]公钥证书。
SEND node
发送节点
An IPv6 node that implements this specification.
实现此规范的IPv6节点。
Router Discovery (RD)
路由器发现（RD）
Router Discovery allows the hosts to discover what routers exist on the link, and what subnet prefixes are available. Router Discovery is a part of the Neighbor Discovery Protocol.
路由器发现允许主机发现链路上存在哪些路由器，以及哪些子网前缀可用。路由器发现是邻居发现协议的一部分。
Trust Anchor
信任锚
Hosts are configured with a set of trust anchors to protect Router Discovery. A trust anchor is an entity that the host trusts to authorize routers to act as routers. A trust anchor configuration consists of a public key and some associated parameters (see Section 6.5 for a detailed explanation of these parameters).
主机配置了一组信任锚，以保护路由器发现。信任锚是主机信任的实体，用于授权路由器充当路由器。信任锚配置由公钥和一些相关参数组成（有关这些参数的详细说明，请参见第6.5节）。
The Neighbor Discovery Protocol has several functions. Many of these are overloaded on a few central message types, such as the ICMPv6 Neighbor Advertisement message. In this section, we review some of these tasks and their effects in order to better understand how the messages should be treated. This section is not normative, and if this section and the original Neighbor Discovery RFCs are in conflict, the original RFCs, as updated, take precedence.
邻居发现协议有几个功能。其中许多消息在一些中心消息类型上过载，例如ICMPv6邻居公告消息。在本节中，我们将回顾其中一些任务及其影响，以便更好地理解应该如何处理这些消息。本节不规范，如果本节与原始邻居发现RFC冲突，则以更新后的原始RFC为准。
The main functions of NDP are as follows:
NDP的主要功能如下：
o The Router Discovery function allows IPv6 hosts to discover the local routers on an attached link. Router Discovery is described in Section 6 of RFC 2461 [4]. The main purpose of Router Discovery is to find neighboring routers willing to forward packets on behalf of hosts. Subnet prefix discovery involves determining which destinations are directly on a link; this information is necessary in order to know whether a packet should be sent to a router or directly to the destination node.
o 路由器发现功能允许IPv6主机发现连接链路上的本地路由器。RFC 2461[4]第6节描述了路由器发现。路由器发现的主要目的是找到愿意代表主机转发数据包的相邻路由器。子网前缀发现涉及确定哪些目的地直接位于链路上；为了知道数据包是应该发送到路由器还是直接发送到目的地节点，这个信息是必需的。
o The Redirect function is used for automatically redirecting a host to a better first-hop router, or to inform hosts that a destination is in fact a neighbor (i.e., on-link). Redirect is specified in Section 8 of RFC 2461 [4].
o 重定向功能用于自动将主机重定向到更好的第一跳路由器，或通知主机目的地实际上是邻居（即，在链路上）。RFC 2461[4]第8节规定了重定向。
o Address Autoconfiguration is used for automatically assigning addresses to a host [5]. This allows hosts to operate without explicit configuration related to IP connectivity. The default autoconfiguration mechanism is stateless. To create IP addresses, hosts use any prefix information delivered to them during Router Discovery and then test the newly formed addresses for uniqueness. A stateful mechanism, DHCPv6 [18], provides additional autoconfiguration features.
o 地址自动配置用于自动将地址分配给主机[5]。这允许主机在没有与IP连接相关的显式配置的情况下运行。默认的自动配置机制是无状态的。为了创建IP地址，主机使用路由器发现期间传递给它们的任何前缀信息，然后测试新形成的地址的唯一性。有状态机制DHCPv6[18]提供了额外的自动配置功能。
o Duplicate Address Detection (DAD) is used for preventing address collisions [5]: for instance, during Address Autoconfiguration. A node that intends to assign a new address to one of its interfaces first runs the DAD procedure to verify that no other node is using the same address. As the rules forbid the use of an address until it has been found unique, no higher layer traffic is possible until this procedure has been completed. Thus, preventing attacks against DAD can help ensure the availability of communications for the node in question.
o 重复地址检测（DAD）用于防止地址冲突[5]：例如，在地址自动配置期间。打算为其接口之一分配新地址的节点首先运行DAD过程，以验证没有其他节点使用相同的地址。由于规则禁止在发现地址唯一之前使用该地址，因此在该过程完成之前，不可能进行更高层的通信。因此，防止对DAD的攻击有助于确保相关节点的通信可用性。
o The Address Resolution function allows a node on the link to resolve another node's IPv6 address to the corresponding link-layer address. Address Resolution is defined in Section 7.2 of RFC 2461 [4], and it is used for hosts and routers alike. Again, no higher level traffic can proceed until the sender knows the link layer address of the destination node or the next hop router. Note that the source link layer address on link layer frames is not checked against the information learned through Address Resolution. This allows for an easier addition of network elements such as bridges and proxies and eases the stack implementation requirements, as less information has to be passed from layer to layer.
o 地址解析功能允许链路上的节点将另一节点的IPv6地址解析为相应的链路层地址。地址解析在RFC 2461[4]第7.2节中定义，它同样用于主机和路由器。同样，在发送方知道目标节点或下一跳路由器的链路层地址之前，无法进行更高级别的通信。请注意，链路层帧上的源链路层地址未根据通过地址解析获得的信息进行检查。这允许更容易地添加网桥和代理等网络元素，并简化了堆栈实现要求，因为从一层到另一层传递的信息更少。
o Neighbor Unreachability Detection (NUD) is used for tracking the reachability of neighboring nodes, both hosts and routers. NUD is defined in Section 7.3 of RFC 2461 [4]. NUD is security sensitive, because an attacker could claim that reachability exists when in fact it does not.
o 邻居不可达性检测（NUD）用于跟踪相邻节点（主机和路由器）的可达性。第24C.4节[NUD]中定义了。NUD是安全敏感的，因为攻击者可以声称可达性存在，而事实上它不存在。
The NDP messages follow the ICMPv6 message format. All NDP functions are realized by using the Router Solicitation (RS), Router Advertisement (RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA), and Redirect messages. An actual NDP message includes an NDP message header, consisting of an ICMPv6 header and ND message-specific data, and zero or more NDP options. The NDP message options are formatted in the Type-Length-Value format.
NDP消息遵循ICMPv6消息格式。所有NDP功能都是通过使用路由器请求（RS）、路由器公告（RA）、邻居请求（NS）、邻居公告（NA）和重定向消息来实现的。实际的NDP消息包括NDP消息头（由ICMPv6头和ND消息特定数据组成）以及零个或多个NDP选项。NDP消息选项的格式为类型长度值格式。
<------------NDP Message---------------->
*-------------------------------------------------------------*
| IPv6 Header | ICMPv6 | ND Message- | ND Message |
| Next Header = 58 | Header | specific | Options |
| (ICMPv6) | | data | |
*-------------------------------------------------------------*
<--NDP Message header-->
<------------NDP Message---------------->
*-------------------------------------------------------------*
| IPv6 Header | ICMPv6 | ND Message- | ND Message |
| Next Header = 58 | Header | specific | Options |
| (ICMPv6) | | data | |
*-------------------------------------------------------------*
<--NDP Message header-->
To secure the various functions in NDP, a set of new Neighbor Discovery options is introduced. They are used to protect NDP messages. This specification introduces these options, an authorization delegation discovery process, an address ownership proof mechanism, and requirements for the use of these components in NDP.
为了保护NDP中的各种功能，引入了一组新的邻居发现选项。它们用于保护NDP消息。本规范介绍了这些选项、授权委托发现过程、地址所有权证明机制以及在NDP中使用这些组件的要求。
The components of the solution specified in this document are as follows:
本文件中规定的溶液成分如下：
o Certification paths, anchored on trusted parties, are expected to certify the authority of routers. A host must be configured with a trust anchor to which the router has a certification path before the host can adopt the router as its default router. Certification Path Solicitation and Advertisement messages are used to discover a certification path to the trust anchor without requiring the actual Router Discovery messages to carry lengthy certification paths. The receipt of a protected Router Advertisement message for which no certification path is available triggers the authorization delegation discovery process.
o 锚定在受信任方上的认证路径有望认证路由器的权限。主机必须配置路由器具有认证路径的信任锚，然后主机才能将路由器用作其默认路由器。认证路径请求和公告消息用于发现到信任锚的认证路径，而不需要实际的路由器发现消息携带冗长的认证路径。接收到没有可用认证路径的受保护路由器公告消息将触发授权委托发现过程。
o Cryptographically Generated Addresses are used to make sure that the sender of a Neighbor Discovery message is the "owner" of the claimed address. A public-private key pair is generated by all nodes before they can claim an address. A new NDP option, the CGA option, is used to carry the public key and associated parameters.
o 加密生成的地址用于确保邻居发现消息的发送方是所声明地址的“所有者”。所有节点在可以声明地址之前都会生成一个公私密钥对。新的NDP选项CGA选项用于携带公钥和相关参数。
This specification also allows a node to use non-CGAs with certificates that authorize their use. However, the details of such use are beyond the scope of this specification and are left for future work.
该规范还允许节点将非CGA与授权其使用的证书一起使用。但是，此类使用的详细信息超出了本规范的范围，留待将来的工作。
o A new NDP option, the RSA Signature option, is used to protect all messages relating to Neighbor and Router discovery.
o 新的NDP选项RSA签名选项用于保护与邻居和路由器发现相关的所有消息。
Public key signatures protect the integrity of the messages and authenticate the identity of their sender. The authority of a public key is established either with the authorization delegation process, by using certificates, or through the address ownership proof mechanism, by using CGAs, or with both, depending on configuration and the type of the message protected.
公钥签名保护消息的完整性并验证其发送者的身份。公钥的权限可以通过授权委托过程（通过使用证书）或通过地址所有权证明机制（通过使用CGA）建立，也可以通过两者建立，具体取决于受保护消息的配置和类型。
Note: RSA is mandated because having multiple signature algorithms would break compatibility between implementations or increase implementation complexity by forcing the implementation of multiple algorithms and the mechanism to select among them. A second signature algorithm is only necessary as a recovery mechanism, in case a flaw is found in RSA. If this happens, a stronger signature algorithm can be selected, and SEND can be revised. The relationship between the new algorithm and the RSA-based SEND described in this document would be similar to that between the RSA-based SEND and Neighbor Discovery without SEND. Information signed with the stronger algorithm has precedence over that signed with RSA, in the same way that RSA-signed information now takes precedence over unsigned information. Implementations of the current and revised specs would still be compatible.
注意：RSA是强制性的，因为拥有多个签名算法会破坏实现之间的兼容性，或者通过强制实现多个算法和机制在其中进行选择而增加实现的复杂性。第二个签名算法仅作为恢复机制是必要的，以防在RSA中发现漏洞。如果发生这种情况，可以选择更强的签名算法，并修改SEND。本文中描述的新算法与基于RSA的SEND之间的关系类似于基于RSA的SEND与无SEND的邻居发现之间的关系。使用更强算法签名的信息优先于使用RSA签名的信息，这与RSA签名的信息现在优先于未签名的信息的方式相同。当前规范和修订规范的实现仍然是兼容的。
o In order to prevent replay attacks, two new Neighbor Discovery options, Timestamp and Nonce, are introduced. Given that Neighbor and Router Discovery messages are in some cases sent to multicast addresses, the Timestamp option offers replay protection without any previously established state or sequence numbers. When the messages are used in solicitation-advertisement pairs, they are protected with the Nonce option.
o 为了防止重播攻击，引入了两个新的邻居发现选项，Timestamp和Nonce。鉴于邻居和路由器发现消息在某些情况下发送到多播地址，时间戳选项提供重播保护，而无需任何先前建立的状态或序列号。在请求广告对中使用消息时，它们将使用Nonce选项进行保护。
The options described in this section MUST be supported.
必须支持本节中描述的选项。
The CGA option allows the verification of the sender's CGA. The format of the CGA option is described as follows:
CGA选项允许验证发送方的CGA。CGA选项的格式描述如下：
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 | Pad Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. CGA Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Pad Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. CGA Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
11
11
Length
长
The length of the option (including the Type, Length, Pad Length, Reserved, CGA Parameters, and Padding fields) in units of 8 octets.
选项的长度（包括类型、长度、填充长度、保留、CGA参数和填充字段），以8个八位字节为单位。
Pad Length
衬垫长度
The number of padding octets beyond the end of the CGA Parameters field but within the length specified by the Length field. Padding octets MUST be set to zero by senders and ignored by receivers.
超出CGA参数字段末尾但在长度字段指定长度内的填充八位字节数。发送方必须将填充八位字节设置为零，接收方必须忽略。
Reserved
含蓄的
An 8-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留供将来使用的8位字段。发送方必须将该值初始化为零，接收方必须忽略该值。
CGA Parameters
CGA参数
A variable-length field containing the CGA Parameters data structure described in Section 4 of [11].
包含[11]第4节所述CGA参数数据结构的可变长度字段。
This specification requires that if both the CGA option and the RSA Signature option are present, then the public key found from the CGA Parameters field in the CGA option MUST be that referred by the Key Hash field in the RSA Signature option. Packets received with two different keys MUST be silently discarded. Note that a future extension may provide a mechanism allowing the owner of an address and the signer to be different parties.
本规范要求，如果同时存在CGA选项和RSA签名选项，则从CGA选项的CGA参数字段中找到的公钥必须是RSA签名选项中的密钥散列字段引用的公钥。必须以静默方式丢弃使用两个不同密钥接收的数据包。请注意，未来的扩展可能会提供一种机制，允许地址所有者和签名者成为不同的当事方。
Padding
衬料
A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field.
一个可变长度字段，使选项长度为8的倍数，包含焊盘长度字段中指定的八位字节数。
If the node has been configured to use SEND, the CGA option MUST be present in all Neighbor Solicitation and Advertisement messages and MUST be present in Router Solicitation messages unless they are sent with the unspecified source address. The CGA option MAY be present in other messages.
如果节点已配置为使用发送，则CGA选项必须出现在所有邻居请求和播发消息中，并且必须出现在路由器请求消息中，除非它们是使用未指定的源地址发送的。CGA选项可能出现在其他消息中。
A node sending a message using the CGA option MUST construct the message as follows:
使用CGA选项发送消息的节点必须按照以下方式构造消息：
The CGA Parameter field in the CGA option is filled according to the rules presented above and in [11]. The public key in the field is taken from the configuration used to generate the CGA, typically from a data structure associated with the source address. The address MUST be constructed as specified in Section 4 of [11]. Depending on the type of the message, this address appears in different places, as follows:
CGA选项中的CGA参数字段根据上文和[11]中给出的规则填充。字段中的公钥取自用于生成CGA的配置，通常来自与源地址关联的数据结构。地址必须按照[11]第4节的规定构造。根据邮件的类型，此地址显示在不同的位置，如下所示：
Redirect
重新使用
The address MUST be the source address of the message.
地址必须是邮件的源地址。
Neighbor Solicitation
邻居请求
The address MUST be the Target Address for solicitations sent for Duplicate Address Detection; otherwise it MUST be the source address of the message.
地址必须是为检测重复地址而发送的请求的目标地址；否则，它必须是消息的源地址。
Neighbor Advertisement
邻居广告
The address MUST be the source address of the message.
地址必须是邮件的源地址。
Router Solicitation
路由器请求
The address MUST be the source address of the message. Note that the CGA option is not used when the source address is the unspecified address.
地址必须是邮件的源地址。请注意，当源地址是未指定的地址时，不使用CGA选项。
Router Advertisement
路由器通告
The address MUST be the source address of the message.
地址必须是邮件的源地址。
Neighbor Solicitation and Advertisement messages without the CGA option MUST be treated as unsecured (i.e., processed in the same way as NDP messages sent by a non-SEND node). The processing of unsecured messages is specified in Section 8. Note that SEND nodes that do not attempt to interoperate with non-SEND nodes MAY simply discard the unsecured messages.
没有CGA选项的邻居请求和广告消息必须被视为不安全消息（即，以与非发送节点发送的NDP消息相同的方式处理）。第8节规定了不安全消息的处理。请注意，不尝试与非发送节点互操作的发送节点可能只会丢弃不安全的消息。
Router Solicitation messages without the CGA option MUST also be treated as unsecured, unless the source address of the message is the unspecified address.
没有CGA选项的路由器请求消息也必须被视为不安全消息，除非消息的源地址是未指定的地址。
Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages containing a CGA option MUST be checked as follows:
包含CGA选项的重定向、邻居请求、邻居播发、路由器请求和路由器播发消息必须进行如下检查：
If the interface has been configured to use CGA, the receiving node MUST verify the source address of the packet by using the algorithm described in Section 5 of [11]. The inputs to the algorithm are the claimed address, as defined in the previous section, and the CGA Parameters field.
如果接口已配置为使用CGA，则接收节点必须使用[11]第5节中描述的算法验证数据包的源地址。算法的输入是前一节中定义的声明地址和CGA参数字段。
If the CGA verification is successful, the recipient proceeds with a more time-consuming cryptographic check of the signature. Note that even if the CGA verification succeeds, no claims about the validity of the use can be made until the signature has been checked.
如果CGA验证成功，接收方将继续对签名进行更耗时的加密检查。请注意，即使CGA验证成功，在检查签名之前，也不能声明使用的有效性。
A receiver that does not support CGA or has not specified its use for a given interface can still verify packets by using trust anchors, even if a CGA is used on a packet. In such a case, the CGA property of the address is simply left unverified.
不支持CGA或未指定其用于给定接口的接收器仍然可以通过使用信任锚来验证数据包，即使数据包上使用了CGA。在这种情况下，地址的CGA属性只是未经验证。
All nodes that support the verification of the CGA option MUST record the following configuration information:
支持CGA选项验证的所有节点必须记录以下配置信息：
minbits
小碎块
The minimum acceptable key length for public keys used in the generation of CGAs. The default SHOULD be 1024 bits. Implementations MAY also set an upper limit for the amount of computation needed when verifying packets that use these security associations. The upper limit SHOULD be at least 2048 bits. Any implementation should follow prudent cryptographic practice in determining the appropriate key lengths.
用于生成CGA的公钥的最小可接受密钥长度。默认值应为1024位。实现还可以为验证使用这些安全关联的数据包时所需的计算量设置上限。上限应至少为2048位。在确定适当的密钥长度时，任何实现都应遵循谨慎的加密实践。
All nodes that support the sending of the CGA option MUST record the following configuration information:
支持发送CGA选项的所有节点必须记录以下配置信息：
CGA parameters
CGA参数
Any information required to construct CGAs, as described in [11].
如[11]所述，构造CGA所需的任何信息。
The RSA Signature option allows public key-based signatures to be attached to NDP messages. The format of the RSA Signature option is described in the following diagram:
RSA签名选项允许将基于公钥的签名附加到NDP消息。RSA签名选项的格式如下图所示：
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Hash |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Digital Signature .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Hash |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Digital Signature .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
12
12
Length
长
The length of the option (including the Type, Length, Reserved, Key Hash, Digital Signature, and Padding fields) in units of 8 octets.
选项的长度（包括类型、长度、保留、密钥散列、数字签名和填充字段），以8个八位字节为单位。
Reserved
含蓄的
A 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver.
保留供将来使用的16位字段。发送方必须将该值初始化为零，接收方必须忽略该值。
Key Hash
密钥散列
A 128-bit field containing the most significant (leftmost) 128 bits of a SHA-1 [14] hash of the public key used for constructing the signature. The SHA-1 hash is taken over the presentation used in the Public Key field of the CGA Parameters data structure carried in the CGA option. Its purpose is to associate the signature to a particular key known by the receiver. Such a key can either be stored in the certificate cache of the receiver or be received in the CGA option in the same message.
一个128位字段，包含用于构造签名的公钥SHA-1[14]散列的最高有效（最左边）128位。SHA-1散列将接管CGA选项中携带的CGA参数数据结构的公钥字段中使用的表示。其目的是将签名与接收方已知的特定密钥相关联。这样的密钥可以存储在接收方的证书缓存中，也可以在同一消息中的CGA选项中接收。
Digital Signature
数字签名
A variable-length field containing a PKCS#1 v1.5 signature, constructed by using the sender's private key over the following sequence of octets:
包含PKCS#1 v1.5签名的可变长度字段，通过在以下八位字节序列上使用发送方的私钥构造：
1. The 128-bit CGA Message Type tag [11] value for SEND, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been generated randomly by the editor of this specification.).
1. 发送的128位CGA消息类型标记[11]值，0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08。（标签值是由本规范的编辑器随机生成的。）。
2. The 128-bit Source Address field from the IP header.
2. IP标头中的128位源地址字段。
3. The 128-bit Destination Address field from the IP header.
3. IP标头中的128位目标地址字段。
4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the ICMP header.
4. ICMP标头中的8位类型、8位代码和16位校验和字段。
5. The NDP message header, starting from the octet after the ICMP Checksum field and continuing up to but not including NDP options.
5. NDP消息头，从ICMP校验和字段后的八位字节开始，一直到但不包括NDP选项。
6. All NDP options preceding the RSA Signature option.
6. RSA签名选项之前的所有NDP选项。
The signature value is computed with the RSASSA-PKCS1-v1_5 algorithm and SHA-1 hash, as defined in [13].
根据[13]中的定义，使用RSASSA-PKCS1-v1_5算法和SHA-1散列计算签名值。
This field starts after the Key Hash field. The length of the Digital Signature field is determined by the length of the RSA Signature option minus the length of the other fields (including the variable length Pad field).
此字段在密钥散列字段之后开始。数字签名字段的长度由RSA签名选项的长度减去其他字段的长度（包括可变长度Pad字段）确定。
Padding
衬料
This variable-length field contains padding, as many bytes long as remain after the end of the signature.
此可变长度字段包含填充，长度与签名结束后剩余的字节数相同。
If the node has been configured to use SEND, Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, and Redirect messages MUST contain the RSA Signature option. Router Solicitation messages not sent with the unspecified source address MUST contain the RSA Signature option.
如果节点已配置为使用发送、邻居请求、邻居播发、路由器播发和重定向消息，则必须包含RSA签名选项。未使用未指定源地址发送的路由器请求消息必须包含RSA签名选项。
A node sending a message with the RSA Signature option MUST construct the message as follows:
发送带有RSA签名选项的消息的节点必须按照以下方式构造消息：
o The message is constructed in its entirety, without the RSA Signature option.
o 消息是完整构造的，没有RSA签名选项。
o The RSA Signature option is added as the last option in the message.
o RSA签名选项将作为消息中的最后一个选项添加。
o The data to be signed is constructed as explained in Section 5.2, under the description of the Digital Signature field.
o 待签名的数据按照第5.2节的说明构造，在数字签名字段的描述下。
o The message, in the form defined above, is signed by using the configured private key, and the resulting PKCS#1 v1.5 signature is put in the Digital Signature field.
o 使用配置的私钥对上述形式的消息进行签名，生成的PKCS#1 v1.5签名放在数字签名字段中。
Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, and Redirect messages without the RSA Signature option MUST be treated as unsecured (i.e., processed in the same way as NDP messages sent by a non-SEND node). See Section 8.
没有RSA签名选项的邻居请求、邻居播发、路由器播发和重定向消息必须视为不安全消息（即，以与非发送节点发送的NDP消息相同的方式处理）。见第8节。
Router Solicitation messages without the RSA Signature option MUST also be treated as unsecured, unless the source address of the message is the unspecified address.
没有RSA签名选项的路由器请求消息也必须被视为不安全消息，除非消息的源地址是未指定的地址。
Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages containing an RSA Signature option MUST be checked as follows:
包含RSA签名选项的重定向、邻居请求、邻居播发、路由器请求和路由器播发消息必须按如下方式进行检查：
o The receiver MUST ignore any options that come after the first RSA Signature option. (The options are ignored for both signature verification and NDP processing purposes.)
o 接收方必须忽略第一个RSA签名选项之后的任何选项。（出于签名验证和NDP处理目的，忽略这些选项。）
o The Key Hash field MUST indicate the use of a known public key, either one learned from a preceding CGA option in the same message, or one known by other means.
o 密钥散列字段必须指示已知公钥的使用，该公钥可以是从同一消息中前面的CGA选项中学习到的，也可以是通过其他方式知道的。
o The Digital Signature field MUST have correct encoding and MUST not exceed the length of the RSA Signature option minus the Padding.
o 数字签名字段必须具有正确的编码，并且不得超过RSA签名选项减去填充的长度。
o The Digital Signature verification MUST show that the signature has been calculated as specified in the previous section.
o 数字签名验证必须表明签名已按照上一节的规定计算。
o If the use of a trust anchor has been configured, a valid certification path (see Section 6.3) between the receiver's trust anchor and the sender's public key MUST be known.
o 如果已配置使用信任锚，则必须知道接收方的信任锚和发送方的公钥之间的有效认证路径（见第6.3节）。
Note that the receiver may verify just the CGA property of a packet, even if, in addition to CGA, the sender has used a trust anchor.
注意，即使除了CGA之外，发送方还使用了信任锚，接收方也可以仅验证数据包的CGA属性。
Messages that do not pass all the above tests MUST be silently discarded if the host has been configured to accept only secured ND messages. The messages MAY be accepted if the host has been configured to accept both secured and unsecured messages but MUST be treated as an unsecured message. The receiver MAY also otherwise silently discard packets (e.g., as a response to an apparent CPU exhausting DoS attack).
如果主机已配置为仅接受安全ND消息，则未通过上述所有测试的消息必须以静默方式丢弃。如果主机已配置为同时接受安全和非安全消息，但必须将其视为非安全消息，则可以接受这些消息。接收器还可以以其他方式无声地丢弃分组（例如，作为对明显的CPU耗尽DoS攻击的响应）。
All nodes that support the reception of the RSA Signature options MUST allow the following information to be configured for each separate NDP message type:
支持接收RSA签名选项的所有节点必须允许为每个单独的NDP消息类型配置以下信息：
authorization method
授权方法
This parameter determines the method through which the authority of the sender is determined. It can have four values:
此参数确定确定发件人权限的方法。它可以有四个值：
trust anchor
信任锚
The authority of the sender is verified as described in Section 6.3. The sender may claim additional authorization through the use of CGAs, but this is neither required nor verified.
按照第6.3节所述验证发送方的权限。发送方可以通过使用CGA申请额外授权，但这既不是必需的，也不是经过验证的。
CGA
CGA
The CGA property of the sender's address is verified as described in [11]. The sender may claim additional authority through a trust anchor, but this is neither required nor verified.
如[11]所述，验证发送方地址的CGA属性。发送方可以通过信任锚请求额外的权限，但这既不是必需的，也不是经过验证的。
trust anchor and CGA
信任锚与CGA
Both the trust anchor and the CGA verification is required.
信任锚和CGA验证都是必需的。
trust anchor or CGA
信任锚或CGA
Either the trust anchor or the CGA verification is required.
需要信任锚或CGA验证。
anchor
锚
The allowed trust anchor(s), if the authorization method is not set to CGA.
如果授权方法未设置为CGA，则允许的信任锚。
All nodes that support sending RSA Signature options MUST record the following configuration information:
所有支持发送RSA签名选项的节点必须记录以下配置信息：
keypair
钥匙对
A public-private key pair. If authorization delegation is in use, a certification path from a trust anchor to this key pair must exist.
一种公私密钥对。如果正在使用授权委派，则必须存在从信任锚点到该密钥对的证书路径。
CGA flag
CGA标志
A flag that indicates whether CGA is used or not. This flag may be per interface or per node. (Note that in future extensions of the SEND protocol, this flag may also be per subnet prefix.)
指示是否使用CGA的标志。此标志可以是每个接口或每个节点。（请注意，在发送协议的未来扩展中，此标志也可能是每个子网前缀。）
The construction and verification of the RSA Signature option is computationally expensive. In the NDP context, however, hosts typically only have to perform a few signature operations as they enter a link, a few operations as they find a new on-link peer with which to communicate, or Neighbor Unreachability Detection with existing neighbors.
RSA签名选项的构造和验证在计算上非常昂贵。然而，在NDP上下文中，主机通常只需在进入链路时执行一些签名操作，在找到要与之通信的新的链路上对等方时执行一些操作，或者与现有邻居进行邻居不可达性检测。
Routers are required to perform a larger number of operations, particularly when the frequency of router advertisements is high due to mobility requirements. Still, the number of required signature operations is on the order of a few dozen per second, some of which can be precomputed as explained below. A large number of router solicitations may cause a higher demand for performing asymmetric operations, although the base NDP protocol limits the rate at which multicast responses to solicitations can be sent.
路由器需要执行更多的操作，特别是当由于移动性要求，路由器广告的频率很高时。尽管如此，所需签名操作的数量大约为每秒几十次，其中一些操作可以按照下面的说明进行预计算。大量路由器请求可能会导致对执行非对称操作的更高要求，尽管基本NDP协议限制了对请求的多播响应的发送速率。
Signatures can be precomputed for unsolicited (multicast) Neighbor and Router Advertisements if the timing of the future advertisements is known. Typically, solicited neighbor advertisements are sent to the unicast address from which the solicitation was sent. Given that the IPv6 header is covered by the signature, it is not possible to precompute solicited advertisements.
如果未来播发的时间已知，则可以为未经请求的（多播）邻居和路由器播发预计算签名。通常，请求的邻居播发被发送到发送请求的单播地址。鉴于签名覆盖了IPv6标头，因此无法预计算请求的广告。
The purpose of the Timestamp option is to make sure that unsolicited advertisements and redirects have not been replayed. The format of this option is described in the following:
时间戳选项的目的是确保未经请求的广告和重定向未被重播。该选项的格式如下所述：
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
13
13
Length
长
The length of the option (including the Type, Length, Reserved, and Timestamp fields) in units of 8 octets; i.e., 2.
以8个八位字节为单位的选项长度（包括类型、长度、保留字段和时间戳字段）；i、 e.，2。
Reserved
含蓄的
A 48-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留供将来使用的48位字段。发送方必须将该值初始化为零，接收方必须忽略该值。
Timestamp
时间戳
A 64-bit unsigned integer field containing a timestamp. The value indicates the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point format. In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/64K fractions of a second.
包含时间戳的64位无符号整数字段。该值表示自1970年1月1日00:00 UTC以来使用定点格式的秒数。在此格式中，整数秒数包含在字段的前48位中，其余16位表示1/64K秒分数的数量。
Implementation note: This format is compatible with the usual representation of time under UNIX, although the number of bits available for the integer and fraction parts may vary.
实现说明：此格式与UNIX下的时间表示形式兼容，尽管整数和小数部分的可用位数可能有所不同。
The purpose of the Nonce option is to make sure that an advertisement is a fresh response to a solicitation sent earlier by the node. The format of this option is described in the following:
Nonce选项的目的是确保广告是对节点先前发送的请求的新响应。该选项的格式如下所述：
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 | Nonce ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Nonce ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
14
14
Length
长
The length of the option (including the Type, Length, and Nonce fields) in units of 8 octets.
选项的长度（包括类型、长度和Nonce字段），以8个八位字节为单位。
Nonce
暂时
A field containing a random number selected by the sender of the solicitation message. The length of the random number MUST be at least 6 bytes. The length of the random number MUST be selected so that the length of the nonce option is a multiple of 8 octets.
包含由请求消息的发送方选择的随机数的字段。随机数的长度必须至少为6字节。必须选择随机数的长度，以便nonce选项的长度是8个八位字节的倍数。
If the node has been configured to use SEND, all solicitation messages MUST include a Nonce. When sending a solicitation, the sender MUST store the nonce internally so that it can recognize any replies containing that particular nonce.
如果节点已配置为使用发送，则所有请求消息必须包含Nonce。发送请求时，发送方必须在内部存储nonce，以便能够识别包含该特定nonce的任何回复。
If the node has been configured to use SEND, all advertisements sent in reply to a solicitation MUST include a Nonce, copied from the received solicitation. Note that routers may decide to send a multicast advertisement to all nodes instead of a response to a specific host. In such a case, the router MAY still include the nonce value for the host that triggered the multicast advertisement. (Omitting the nonce value may cause the host to ignore the router's advertisement, unless the clocks in these nodes are sufficiently synchronized so that timestamps function properly.)
如果节点已配置为使用发送，则响应请求而发送的所有播发必须包含从接收到的请求复制的Nonce。请注意，路由器可能决定向所有节点发送多播播发，而不是向特定主机发送响应。在这种情况下，路由器仍然可以包括触发多播播发的主机的nonce值。（忽略nonce值可能会导致主机忽略路由器的播发，除非这些节点中的时钟已充分同步，以便时间戳正常工作。）
If the node has been configured to use SEND, all solicitation, advertisement, and redirect messages MUST include a Timestamp. Senders SHOULD set the Timestamp field to the current time, according to their real time clocks.
如果节点已配置为使用发送，则所有请求、播发和重定向消息必须包含时间戳。发件人应根据其实时时钟将时间戳字段设置为当前时间。
The processing of the Nonce and Timestamp options depends on whether a packet is a solicited advertisement. A system may implement the distinction in various ways. Section 5.3.4.1 defines the processing rules for solicited advertisements. Section 5.3.4.2 defines the processing rules for all other messages.
Nonce和Timestamp选项的处理取决于数据包是否是请求的广告。一个系统可以以各种方式实现这种区别。第5.3.4.1节定义了征求广告的处理规则。第5.3.4.2节定义了所有其他消息的处理规则。
In addition, the following rules apply in all cases:
此外，以下规则适用于所有情况：
o Messages received without at least one of the Timestamp and Nonce options MUST be treated as unsecured (i.e., processed in the same way as NDP messages sent by a non-SEND node).
o 必须将接收到的没有至少一个时间戳和Nonce选项的消息视为不安全消息（即，以与非发送节点发送的NDP消息相同的方式处理）。
o Messages received with the RSA Signature option but without the Timestamp option MUST be silently discarded.
o 使用RSA签名选项但不使用时间戳选项接收的消息必须以静默方式丢弃。
o Solicitation messages received with the RSA Signature option but without the Nonce option MUST be silently discarded.
o 使用RSA签名选项但不使用Nonce选项接收的请求消息必须以静默方式丢弃。
o Advertisements sent to a unicast destination address with the RSA Signature option but without a Nonce option SHOULD be processed as unsolicited advertisements.
o 发送到具有RSA签名选项但没有Nonce选项的单播目标地址的播发应作为未经请求的播发处理。
o An implementation MAY use some mechanism such as a timestamp cache to strengthen resistance to replay attacks. When there is a very large number of nodes on the same link, or when a cache filling attack is in progress, it is possible that the cache holding the most recent timestamp per sender will become full. In this case, the node MUST remove some entries from the cache or refuse some new requested entries. The specific policy as to which entries are preferred over others is left as an implementation decision. However, typical policies may prefer existing entries to new ones, CGAs with a large Sec value to smaller Sec values, and so on. The issue is briefly discussed in Appendix B.
o 实现可以使用诸如时间戳缓存之类的机制来增强对重播攻击的抵抗力。当同一链路上有大量节点时，或者当缓存填充攻击正在进行时，每个发送方持有最新时间戳的缓存可能会变满。在这种情况下，节点必须从缓存中删除一些条目，或者拒绝一些新请求的条目。关于哪些条目优先于其他条目的具体策略留待实施决定。但是，典型的策略可能更喜欢现有条目而不是新条目，具有较大Sec值的CGA而不是较小Sec值的CGA，等等。附录B简要讨论了该问题。
o The receiver MUST be prepared to receive the Timestamp and Nonce options in any order, as per RFC 2461 [4], Section 9.
o 根据RFC 2461[4]第9节，接收器必须准备好以任何顺序接收时间戳和Nonce选项。
The receiver MUST verify that it has recently sent a matching solicitation, and that the received advertisement contains a copy of the Nonce sent in the solicitation.
接收方必须验证其最近发送了匹配的邀约，并且接收到的广告包含邀约中发送的Nonce的副本。
If the message contains a Nonce option but the Nonce value is not recognized, the message MUST be silently discarded.
如果消息包含Nonce选项，但无法识别Nonce值，则必须以静默方式丢弃该消息。
Otherwise, if the message does not contain a Nonce option, it MAY be considered an unsolicited advertisement and processed according to Section 5.3.4.2.
否则，如果消息不包含Nonce选项，则可将其视为未经请求的广告，并根据第5.3.4.2节进行处理。
If the message is accepted, the receiver SHOULD store the receive time of the message and the timestamp time in the message, as specified in Section 5.3.4.2.
如第5.3.4.2节所述，如果消息被接受，接收方应在消息中存储消息的接收时间和时间戳时间。
Receivers SHOULD be configured with an allowed timestamp Delta value, a "fuzz factor" for comparisons, and an allowed clock drift parameter. The recommended default value for the allowed Delta is TIMESTAMP_DELTA; for fuzz factor TIMESTAMP_FUZZ; and for clock drift, TIMESTAMP_DRIFT (see Section 10.2).
接收机应配置允许的时间戳增量值、用于比较的“模糊因子”和允许的时钟漂移参数。允许的增量的建议默认值为TIMESTAMP_Delta；对于模糊因子时间戳_fuzz；对于时钟漂移，时间戳漂移（见第10.2节）。
To facilitate timestamp checking, each node SHOULD store the following information for each peer:
为了便于时间戳检查，每个节点应为每个对等节点存储以下信息：
o The receive time of the last received and accepted SEND message. This is called RDlast.
o 上次接收和接受的发送消息的接收时间。这称为RDlast。
o The time stamp in the last received and accepted SEND message. This is called TSlast.
o 上次接收和接受的发送消息中的时间戳。这叫做TSlast。
An accepted SEND message is any successfully verified Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement, or Redirect message from the given peer. The RSA Signature option MUST be used in such a message before it can update the above variables.
接受的发送消息是来自给定对等方的任何成功验证的邻居请求、邻居公告、路由器请求、路由器公告或重定向消息。在更新上述变量之前，必须在此类消息中使用RSA签名选项。
Receivers SHOULD then check the Timestamp field as follows:
然后，接收者应检查时间戳字段，如下所示：
o When a message is received from a new peer (i.e., one that is not stored in the cache), the received timestamp, TSnew, is checked, and the packet is accepted if the timestamp is recent enough to the reception time of the packet, RDnew:
o 当从新对等方（即，未存储在高速缓存中的对等方）接收到消息时，检查接收到的时间戳TSnew，并且如果时间戳最近到数据包的接收时间RDnew，则接受数据包：
-Delta < (RDnew - TSnew) < +Delta
-Delta < (RDnew - TSnew) < +Delta
The RDnew and TSnew values SHOULD be stored in the cache as RDlast and TSlast.
RDnew和TSnew值应作为RDlast和TSlast存储在缓存中。
o If the timestamp is NOT within the boundaries but the message is a Neighbor Solicitation message that the receiver should answer, the receiver SHOULD respond to the message. However, even if it does respond to the message, it MUST NOT create a Neighbor Cache entry. This allows nodes that have large differences in their clocks to continue communicating with each other by exchanging NS/NA pairs.
o 如果时间戳不在边界内，但该消息是接收方应回答的邻居请求消息，则接收方应响应该消息。但是，即使它确实响应消息，也不能创建邻居缓存项。这允许时钟差异较大的节点通过交换NS/NA对继续彼此通信。
o When a message is received from a known peer (i.e., one that already has an entry in the cache), the timestamp is checked against the previously received SEND message:
o 当从已知对等方（即缓存中已有条目的对等方）接收到消息时，将对照先前接收到的发送消息检查时间戳：
TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz
TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz
If this inequality does not hold, the receiver SHOULD silently discard the message. If, on the other hand, the inequality holds, the receiver SHOULD process the message.
如果这个不平等性不成立，接收者应该默默地丢弃消息。另一方面，如果不等式成立，则接收方应处理消息。
Moreover, if the above inequality holds and TSnew > TSlast, the receiver SHOULD update RDlast and TSlast. Otherwise, the receiver MUST NOT update RDlast or TSlast.
此外，如果上述不等式成立且TSnew>TSlast，则接收器应更新RDlast和TSlast。否则，接收器不得更新RDlast或TSlast。
As unsolicited messages may be used in a Denial-of-Service attack to make the receiver verify computationally expensive signatures, all nodes SHOULD apply a mechanism to prevent excessive use of resources for processing such messages.
由于拒绝服务攻击中可能会使用未经请求的消息来让接收方验证计算代价高昂的签名，因此所有节点都应应用一种机制来防止过度使用资源来处理此类消息。
NDP allows a node to configure itself automatically based on information learned shortly after connecting to a new link. It is particularly easy to configure "rogue" routers on an unsecured link, and it is particularly difficult for a node to distinguish between valid and invalid sources of router information, because the node needs this information before communicating with nodes outside of the link.
NDP允许节点根据连接到新链路后不久所了解到的信息自动配置自身。在不安全链路上配置“流氓”路由器特别容易，而且节点特别难以区分路由器信息的有效源和无效源，因为节点在与链路外的节点通信之前需要这些信息。
As the newly-connected node cannot communicate off-link, it cannot be responsible for searching information to help validate the router(s). However, given a certification path, the node can check someone else's search results and conclude that a particular message comes from an authorized source. In the typical case, a router already connected beyond the link can communicate if necessary with off-link nodes and construct a certification path.
由于新连接的节点无法进行离线通信，因此它无法负责搜索信息以帮助验证路由器。但是，给定一个认证路径，节点可以检查其他人的搜索结果，并得出特定消息来自授权来源的结论。在典型情况下，已经连接到链路之外的路由器可以在必要时与断开链路的节点通信，并构建认证路径。
The Secure Neighbor Discovery Protocol mandates a certificate format and introduces two new ICMPv6 messages used between hosts and routers to allow the host to learn a certification path with the assistance of the router.
安全邻居发现协议规定了一种证书格式，并在主机和路由器之间引入了两条新的ICMPv6消息，以允许主机在路由器的帮助下学习证书路径。
To protect Router Discovery, SEND requires that routers be authorized to act as routers. This authorization is provisioned in both routers and hosts. Routers are given certificates from a trust anchor, and the hosts are configured with the trust anchor(s) to authorize routers. This provisioning is specific to SEND and does not assume that certificates already deployed for some other purpose can be used.
为了保护路由器发现，SEND要求授权路由器充当路由器。此授权在路由器和主机中都提供。路由器从信任锚点获得证书，主机配置有信任锚点以授权路由器。此设置特定于发送，并且不假设可以使用已部署用于其他目的的证书。
The authorization for routers in SEND is twofold:
发送中路由器的授权有两种：
o Routers are authorized to act as routers. The router belongs to the set of routers trusted by the trust anchor. All routers in this set have the same authorization.
o 路由器被授权充当路由器。路由器属于受信任锚信任的路由器集。此集合中的所有路由器具有相同的授权。
o Optionally, routers may also be authorized to advertise a certain set of subnet prefixes. A specific router is given a specific set of subnet prefixes to advertise; other routers have an authorization to advertise other subnet prefixes. Trust anchors may also delegate a certain set of subnet prefixes to someone (such as an ISP) who, in turn, delegates parts of this set to individual routers.
o 可选地，路由器也可以被授权公布某一组子网前缀。为特定路由器提供一组特定的子网前缀以进行公告；其他路由器有权公布其他子网前缀。信任锚还可以将某一组子网前缀委托给某人（如ISP），而ISP又将该组前缀的一部分委托给各个路由器。
Note that while communicating with hosts, routers typically also present a number of other parameters beyond the above. For instance, routers have their own IP addresses, subnet prefixes have lifetimes, and routers control the use of stateless and stateful address autoconfiguration. However, the ability to be a router and the subnet prefixes are the most fundamental parameters to authorize. This is because the host needs to choose a router that it uses as its default router, and because the advertised subnet prefixes have an impact on the addresses the host uses. The subnet prefixes also represent a claim about the topological location of the router in the network.
请注意，在与主机通信时，路由器通常还提供上述参数之外的许多其他参数。例如，路由器有自己的IP地址，子网前缀有生存期，路由器控制无状态和有状态地址自动配置的使用。然而，作为路由器的能力和子网前缀是授权的最基本参数。这是因为主机需要选择一个用作其默认路由器的路由器，并且播发的子网前缀对主机使用的地址有影响。子网前缀还表示路由器在网络中的拓扑位置声明。
Care should be taken if the certificates used in SEND are also used to provide authorization in other circumstances; for example, with routing protocols. It is necessary to ensure that the authorization information is appropriate for all applications. SEND certificates may authorize a larger set of subnet prefixes than the router is authorized to advertise on a given interface. For instance, SEND allows the use of the null prefix, which might cause verification or routing problems in other applications. It is RECOMMENDED that SEND certificates containing the null prefix are only used for SEND.
如果SEND中使用的证书在其他情况下也用于提供授权，则应小心；例如，使用路由协议。必须确保授权信息适用于所有应用程序。发送证书可以授权比路由器授权在给定接口上播发的子网前缀更大的子网前缀集。例如，SEND允许使用空前缀，这可能会在其他应用程序中导致验证或路由问题。建议包含空前缀的发送证书仅用于发送。
Note that end hosts need not be provisioned with their own certified public keys, just as Web clients today do not require end host provisioning with certified keys. Public keys for CGA generation do not need to be certified, as these keys derive their ability to authorize operations on the CGA by the tie to the address.
请注意，终端主机不需要配置它们自己的认证公钥，就像今天的Web客户端不需要配置具有认证密钥的终端主机一样。生成CGA的公钥不需要经过认证，因为这些密钥通过与地址的绑定来获得授权CGA操作的能力。
The deployment model for trust anchors can be either a globally rooted public key infrastructure or a more local, decentralized deployment model similar to that currently used for TLS in Web servers. The centralized model assumes a global root capable of authorizing routers and, optionally, the address space they advertise. The end hosts are configured with the public keys of the global root. The global root could operate, for instance, under the Internet Assigned Numbers Authority (IANA) or as a co-operative among Regional Internet Registries (RIRs). However, no such global root currently exists.
信任锚的部署模型可以是全局根公钥基础设施，也可以是更局部、分散的部署模型，类似于当前用于Web服务器中TLS的部署模型。集中式模型假设一个全局根能够授权路由器，并且可以选择授权它们所公布的地址空间。使用全局根目录的公钥配置终端主机。例如，全球根目录可以在互联网分配号码管理局（IANA）下运行，或者作为区域互联网注册中心（RIR）之间的合作伙伴运行。但是，目前不存在这样的全局根。
In the decentralized model, end hosts are configured with a collection of trusted public keys. The public keys could be issued from various places; for example, a) a public key for the end host's own organization, b) a public key for the end host's home ISP and for ISPs with which the home ISP has a roaming agreement, or c) public keys for roaming brokers acting as intermediaries for ISPs that don't want to run their own certification authority.
在分散模型中，终端主机配置有一组受信任的公钥。公钥可以从不同的地方发出；例如，a）终端主机自身组织的公钥，b）终端主机的家庭ISP以及家庭ISP与之签订漫游协议的ISP的公钥，或c）作为不想运行其自身证书颁发机构的ISP中介的漫游代理的公钥。
This decentralized model works even when a SEND node is used both in networks that have certified routers and in networks that do not. As discussed in Section 8, a SEND node can fall back to the use of a non-SEND router. This makes it possible to start with a local trust anchor even if there is no trust anchor for all possible networks.
这种分散模型即使在有认证路由器的网络和没有认证路由器的网络中使用发送节点时也能工作。如第8节所述，发送节点可以退回到使用非发送路由器。这使得即使所有可能的网络都没有信任锚，也可以从本地信任锚开始。
The certification path of a router terminates in a Router Authorization Certificate that authorizes a specific IPv6 node to act as a router. Because authorization paths are not a common practice in the Internet at the time of this writing, the path MUST consist of standard Public Key Certificates (PKC, in the sense of [8]). The certification path MUST start from the identity of a trust anchor shared by the host and the router. This allows the host to anchor trust for the router's public key in the trust anchor. Note that there MAY be multiple certificates issued by a single trust anchor.
路由器的认证路径以路由器授权证书终止，该证书授权特定IPv6节点充当路由器。由于在撰写本文时，授权路径不是Internet中的常见做法，因此路径必须由标准公钥证书（PKC，在[8]的意义上）组成。认证路径必须从主机和路由器共享的信任锚点的标识开始。这允许主机在信任锚中锚定路由器公钥的信任。请注意，可能有多个证书由单个信任锚点颁发。
Router Authorization Certificates are X.509v3 certificates, as defined in RFC 3280 [7], and SHOULD contain at least one instance of the X.509 extension for IP addresses, as defined in [10]. The parent certificates in the certification path SHOULD contain one or more X.509 IP address extensions, back up to a trusted party (such as the user's ISP) that configured the original IP address block for the router in question, or that delegated the right to do so. The certificates for the intermediate delegating authorities SHOULD contain X.509 IP address extension(s) for subdelegations. The router's certificate is signed by the delegating authority for the subnet prefixes the router is authorized to advertise.
路由器授权证书是RFC 3280[7]中定义的X.509v3证书，并且应至少包含一个IP地址的X.509扩展实例，如[10]中所定义。证书路径中的父证书应包含一个或多个X.509 IP地址扩展，备份到为相关路由器配置原始IP地址块的受信任方（如用户的ISP）或授权这样做的受信任方。中间授权机构的证书应包含子授权的X.509 IP地址扩展。路由器的证书由授权机构对路由器有权公布的子网前缀进行签名。
The X.509 IP address extension MUST contain at least one addressesOrRanges element. This element MUST contain an addressPrefix element containing an IPv6 address prefix for a prefix that the router or the intermediate entity is authorized to route. If the entity is allowed to route any prefix, the IPv6 address prefix used is the null prefix, ::/0. The addressFamily element of the IPAddrBlocks sequence element MUST contain the IPv6 Address Family Identifier (0002), as specified in [10], for IPv6 subnet prefixes. Instead of an addressPrefix element, the addressesOrRange element MAY contain an addressRange element for a range of subnet prefixes, if more than one prefix is authorized. The X.509 IP address extension MAY contain additional IPv6 subnet prefixes, expressed as either an addressPrefix or an addressRange.
X.509 IP地址扩展必须至少包含一个AddressOrranges元素。此元素必须包含addressPrefix元素，该元素包含路由器或中间实体有权路由的前缀的IPv6地址前缀。如果允许实体路由任何前缀，则使用的IPv6地址前缀为空前缀：：/0。IPAddressBlocks序列元素的addressFamily元素必须包含IPv6子网前缀的IPv6地址族标识符（0002），如[10]中所述。如果授权了多个前缀，则addressesOrRange元素可以包含一系列子网前缀的addressRange元素，而不是addressPrefix元素。X.509 IP地址扩展可能包含其他IPv6子网前缀，表示为addressPrefix或addressRange。
A node receiving a Router Authorization Certificate MUST first check whether the certificate's signature was generated by the delegating authority. Then the client SHOULD check whether all the addressPrefix or addressRange entries in the router's certificate are contained within the address ranges in the delegating authority's certificate, and whether the addressPrefix entries match any addressPrefix entries in the delegating authority's certificate. If an addressPrefix or addressRange is not contained within the delegating authority's subnet prefixes or ranges, the client MAY attempt to take an intersection of the ranges/subnet prefixes and to use that intersection. If the resulting intersection is empty, the client MUST NOT accept the certificate. If the addressPrefix in the certificate is missing or is the null prefix, ::/0, the parent prefix or range SHOULD be used. If there is no parent prefix or range, the subnet prefixes that the router advertises are said to be unconstrained (see Section 7.3). That is, the router is allowed to advertise any prefix.
接收路由器授权证书的节点必须首先检查证书的签名是否由授权机构生成。然后，客户端应检查路由器证书中的所有addressPrefix或addressRange条目是否包含在授权机构证书中的地址范围内，以及addressPrefix条目是否与授权机构证书中的任何addressPrefix条目相匹配。如果addressPrefix或addressRange不包含在授权机构的子网前缀或范围内，则客户端可能会尝试获取范围/子网前缀的交集并使用该交集。如果生成的交叉点为空，则客户端不得接受证书。如果证书中的addressPrefix丢失或为空前缀，：：/0，则应使用父前缀或范围。如果没有父前缀或范围，则称路由器播发的子网前缀不受约束（参见第7.3节）。也就是说，允许路由器播发任何前缀。
The above checks SHOULD be done for all certificates in the path. If any of the checks fail, the client MUST NOT accept the certificate. The client also has to perform validation of advertised subnet prefixes as discussed in Section 7.3.
应对路径中的所有证书执行上述检查。如果任何检查失败，客户端不得接受证书。如第7.3节所述，客户端还必须对公布的子网前缀进行验证。
Hosts MUST check the subjectPublicKeyInfo field within the last certificate in the certificate path to ensure that only RSA public keys are used to attempt validation of router signatures. Hosts MUST disregard the certificate for SEND if it does not contain an RSA key.
主机必须检查证书路径中最后一个证书内的subjectPublicKeyInfo字段，以确保仅使用RSA公钥来尝试验证路由器签名。如果发送的证书不包含RSA密钥，则主机必须忽略该证书。
As it is possible that some public key certificates used with SEND do not immediately contain the X.509 IP address extension element, an implementation MAY contain facilities that allow the prefix and range checks to be relaxed. However, any such configuration options SHOULD be switched off by default. The system SHOULD have a default configuration that requires rigorous prefix and range checks.
由于与SEND一起使用的某些公钥证书可能不立即包含X.509 IP地址扩展元素，因此实现可能包含允许放宽前缀和范围检查的功能。但是，默认情况下应关闭任何此类配置选项。系统应具有需要严格前缀和范围检查的默认配置。
The following is an example of a certification path. Suppose that isp_group_example.net is the trust anchor. The host has this certificate:
以下是证书路径的示例。假设isp_group_example.net是信任锚。主机具有以下证书：
Certificate 1: Issuer: isp_group_example.net Validity: Jan 1, 2004 through Dec 31, 2004 Subject: isp_group_example.net Extensions: IP address delegation extension: Prefixes: P1, ..., Pk ... possibly other extensions ... ... other certificate parameters ...
证书1：颁发者：isp\u group\u example.net有效期：2004年1月1日至2004年12月31日主题：isp\u group\u example.net扩展：IP地址委派扩展：前缀：P1，…，Pk。。。可能还有其他扩展。。。其他证书参数。。。
When the host attaches to a link served by router_x.isp_foo_example.net, it receives the following certification path:
当主机连接到路由器_x.isp_foo_example.net提供服务的链路时，它会收到以下认证路径：
Certificate 2: Issuer: isp_group_example.net Validity: Jan 1, 2004 through Dec 31, 2004 Subject: isp_foo_example.net Extensions: IP address delegation extension: Prefixes: Q1, ..., Qk ... possibly other extensions ... ... other certificate parameters ...
证书2：颁发者：isp_group_example.net有效期：2004年1月1日至2004年12月31日主题：isp_foo_example.net扩展：IP地址委派扩展：前缀：Q1，…，Qk。。。可能还有其他扩展。。。其他证书参数。。。
Certificate 3: Issuer: isp_foo_example.net Validity: Jan 1, 2004 through Dec 31, 2004 Subject: router_x.isp_foo_example.net Extensions: IP address delegation extension: Prefixes R1, ..., Rk ... possibly other extensions ...
证书3：颁发者：isp_foo_example.net有效期：2004年1月1日至2004年12月31日主题：路由器_x.isp_foo_example.net扩展：IP地址委派扩展：前缀R1，…，Rk。。。可能还有其他的扩展。。。
... other certificate parameters ...
... 其他证书参数。。。
When the three certificates are processed, the usual RFC 3280 [7] certificate path validation is performed. Note, however, that when a node checks certificates received from a router, it typically does not have a connection to the Internet yet, and so it is not possible to perform an on-line Certificate Revocation List (CRL) check, if necessary. Until this check is performed, acceptance of the certificate MUST be considered provisional, and the node MUST perform a check as soon as it has established a connection with the Internet through the router. If the router has been compromised, it could interfere with the CRL check. Should performance of the CRL check be disrupted or should the check fail, the node SHOULD immediately stop using the router as a default and use another router on the link instead.
处理三个证书时，将执行通常的RFC 3280[7]证书路径验证。然而，请注意，当节点检查从路由器接收的证书时，它通常还没有到Internet的连接，因此如果需要，不可能执行在线证书吊销列表（CRL）检查。在执行此检查之前，必须将证书的接受视为临时性的，并且节点必须在通过路由器与Internet建立连接后立即执行检查。如果路由器被破坏，它可能会干扰CRL检查。如果CRL检查的性能中断或检查失败，则节点应立即停止使用路由器作为默认路由器，并改用链路上的另一个路由器。
In addition, the IP addresses in the delegation extension MUST be a subset of the IP addresses in the delegation extension of the issuer's certificate. So in this example, R1, ..., Rs must be a subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If the certification path is valid, then router_foo.isp_foo_example.com is authorized to route the prefixes R1,...,Rs.
此外，委派扩展中的IP地址必须是颁发者证书委派扩展中IP地址的子集。所以在这个例子中，R1，…，Rs必须是Q1，…，Qr和Q1，…，的子集，Qr必须是P1，…，Pk的子集。如果认证路径有效，则router_foo.isp_foo_example.com有权路由前缀R1、…、Rs。
As deployment of the IP address extension is, itself, not common, a network service provider MAY choose to deploy standard identity certificates on the router to supply the router's public key for signed Router Advertisements.
由于IP地址扩展的部署本身并不常见，因此网络服务提供商可以选择在路由器上部署标准身份证书，以便为签名的路由器广告提供路由器的公钥。
If there is no prefix information further up in the certification path, a host interprets a standard identity certificate as allowing unconstrained prefix advertisements.
如果证书路径中没有前缀信息，主机会将标准身份证书解释为允许无限制的前缀播发。
If the other certificates contain prefix information, a standard identity certificate is interpreted as allowing those subnet prefixes.
如果其他证书包含前缀信息，则标准标识证书将被解释为允许使用这些子网前缀。
The Certification Path Solicitation (CPS) message is sent by a host when it wishes to request a certification path between a router and one of the host's trust anchors. The Certification Path Advertisement (CPA) message is sent in reply to the CPS message. These messages are kept separate from the rest of Neighbor and Router Discovery to reduce the effect of the potentially voluminous certification path information on other messages.
当主机希望请求路由器和主机的一个信任锚之间的认证路径时，会发送认证路径请求（CPS）消息。发送认证路径公告（CPA）消息以响应CPS消息。这些消息与邻居和路由器发现的其余部分保持分离，以减少可能大量的认证路径信息对其他消息的影响。
The Authorization Delegation Discovery (ADD) process does not exclude other forms of discovering certification paths. For instance, during fast movements, mobile nodes may learn information (including the certification paths) about the next router from a previous router, or nodes may be preconfigured with certification paths from roaming partners.
授权委派发现（ADD）过程不排除发现证书路径的其他形式。例如，在快速移动期间，移动节点可从先前路由器学习关于下一路由器的信息（包括认证路径），或可使用来自漫游伙伴的认证路径预先配置节点。
Where hosts themselves are certified by a trust anchor, these messages MAY also optionally be used between hosts to acquire the peer's certification path. However, the details of such usage are beyond the scope of this specification.
在主机本身由信任锚认证的情况下，还可以选择在主机之间使用这些消息来获取对等方的认证路径。然而，这种用法的细节超出了本规范的范围。
Hosts send Certification Path Solicitations in order to prompt routers to generate Certification Path Advertisements.
主机发送证书路径请求以提示路由器生成证书路径公告。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IP字段：
Source Address
源地址
A link-local unicast address assigned to the sending interface, or to the unspecified address if no address is assigned to the sending interface.
分配给发送接口的链路本地单播地址，如果没有分配给发送接口，则分配给未指定的地址。
Destination Address
目的地址
Typically the All-Routers multicast address, the Solicited-Node multicast address, or the address of the host's default router.
通常是所有路由器的多播地址、请求的节点多播地址或主机默认路由器的地址。
Hop Limit
跳数限制
255
255
ICMP Fields:
ICMP字段：
Type
类型
148
148
Code
密码
0
0
Checksum
校验和
The ICMP checksum [6].
ICMP校验和[6]。
Identifier
标识符
A 16-bit unsigned integer field, acting as an identifier to help match advertisements to solicitations. The Identifier field MUST NOT be zero, and its value SHOULD be randomly generated. This randomness does not have to be cryptographically hard, as its purpose is only to avoid collisions.
一个16位无符号整数字段，用作帮助将广告与请求匹配的标识符。标识符字段不能为零，其值应随机生成。这种随机性不需要加密，因为其目的只是为了避免冲突。
Component
组成部分
This 16-bit unsigned integer field is set to 65,535 if the sender seeks to retrieve all certificates. Otherwise, it is set to the component identifier corresponding to the certificate that the receiver wants to retrieve (see Sections 6.4.2 and 6.4.6).
如果发送方试图检索所有证书，则此16位无符号整数字段设置为65535。否则，它被设置为与接收方想要检索的证书相对应的组件标识符（参见第6.4.2节和第6.4.6节）。
Valid Options:
有效选项：
Trust Anchor
信任锚
One or more trust anchors that the client is willing to accept. The first (or only) Trust Anchor option MUST contain a DER Encoded X.501 Name; see Section 6.4.3. If there is more than one Trust Anchor option, the options beyond the first may contain any type of trust anchor.
客户愿意接受的一个或多个信任锚。第一个（或唯一一个）信任锚选项必须包含DER编码的X.501名称；见第6.4.3节。如果存在多个信任锚选项，则第一个选项之外的选项可能包含任何类型的信任锚。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. All included options MUST have a length greater than zero.
此协议的未来版本可能会定义新的选项类型。接收者必须默默地忽略他们不识别的任何选项，并继续处理消息。所有包含的选项的长度必须大于零。
ICMP length (derived from the IP length) MUST be 8 or more octets.
ICMP长度（源自IP长度）必须为8个或更多八位字节。
Routers send out Certification Path Advertisement messages in response to a Certification Path Solicitation.
路由器发送认证路径公告消息以响应认证路径请求。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | All Components |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | All Components |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IP字段：
Source Address
源地址
A link-local unicast address assigned to the interface from which this message is sent. Note that routers may use multiple addresses, and therefore this address is not sufficient for the unique identification of routers.
分配给发送此消息的接口的链路本地单播地址。请注意，对于多个路由器，此地址可能不足以识别。
Destination Address
目的地址
Either the Solicited-Node multicast address of the receiver or the link-scoped All-Nodes multicast address.
接收器的请求节点多播地址或链接作用域为所有节点多播地址。
Hop Limit
跳数限制
255
255
ICMP Fields:
ICMP字段：
Type
类型
149
149
Code
密码
0
0
Checksum
校验和
The ICMP checksum [6].
ICMP校验和[6]。
Identifier
标识符
A 16-bit unsigned integer field, acting as an identifier to help match advertisements to solicitations. The Identifier field MUST be zero for advertisements sent to the All-Nodes multicast address and MUST NOT be zero for others.
一个16位无符号整数字段，用作帮助将广告与请求匹配的标识符。对于发送到所有节点多播地址的播发，标识符字段必须为零，对于其他播发，标识符字段不得为零。
All Components
所有组件
A 16-bit unsigned integer field, used to inform the receiver of the number of certificates in the entire path.
一个16位无符号整数字段，用于通知接收方整个路径中的证书数量。
A single advertisement SHOULD be broken into separately sent components if there is more than one certificate in the path, in order to avoid excessive fragmentation at the IP layer.
如果路径中有多个证书，则应将单个播发分解为单独发送的组件，以避免IP层出现过度碎片。
Individual certificates in a path MAY be stored and used as received before all the certificates have arrived; this makes the protocol slightly more reliable and less prone to Denial-of-Service attacks.
路径中的单个证书可以在所有证书到达之前按接收方式存储和使用；这使得协议稍微更可靠，更不容易受到拒绝服务攻击。
Examples of packet lengths of Certification Path Advertisement messages for typical certification paths are listed in Appendix C.
附录C中列出了典型认证路径的认证路径广告消息的数据包长度示例。
Component
组成部分
A 16-bit unsigned integer field, used to inform the receiver which certificate is being sent.
一个16位无符号整数字段，用于通知接收方正在发送哪个证书。
The first message in an N-component advertisement has the Component field set to N-1, the second set to N-2, and so on. A zero indicates that there are no more components coming in this advertisement.
N分量广告中的第一条消息的分量字段设置为N-1，第二条消息设置为N-2，依此类推。零表示此广告中没有更多组件。
The sending of path components SHOULD be ordered so that the certificate after the trust anchor is sent first. Each certificate sent after the first can be verified with the previously sent certificates. The certificate of the sender comes last. The trust anchor certificate SHOULD NOT be sent.
应该对路径组件的发送进行排序，以便首先发送信任锚点之后的证书。在第一个证书之后发送的每个证书都可以与以前发送的证书进行验证。发送者的证书在最后。不应发送信任锚证书。
Reserved
含蓄的
An unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
未使用的字段。发送方必须将其初始化为零，接收方必须忽略它。
Valid Options:
有效选项：
Certificate
证明书
One certificate is provided in each Certificate option to establish part of a certification path to a trust anchor.
在每个证书选项中提供一个证书，以建立到信任锚的部分证书路径。
The certificate of the trust anchor itself SHOULD NOT be sent.
不应发送信任锚点本身的证书。
Trust Anchor
信任锚
Zero or more Trust Anchor options may be included to help receivers decide which advertisements are useful for them. If present, these options MUST appear in the first component of a multi-component advertisement.
可以包括零个或多个信任锚选项，以帮助接收者决定哪些广告对他们有用。如果存在，这些选项必须出现在多组件广告的第一个组件中。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. All included options MUST have a length that is greater than zero.
此协议的未来版本可能会定义新的选项类型。接收者必须默默地忽略他们不识别的任何选项，并继续处理消息。所有包含的选项的长度必须大于零。
The ICMP length (derived from the IP length) MUST be 8 or more octets.
ICMP长度（源自IP长度）必须为8个或更多八位字节。
The format of the Trust Anchor option is described in the following:
信任锚选项的格式如下所述：
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 | Name Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Name Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
15
15
Length
长
The length of the option (including the Type, Length, Name Type, Pad Length, and Name fields), in units of 8 octets.
选项的长度（包括类型、长度、名称类型、填充长度和名称字段），以8个八位字节为单位。
Name Type
名称类型
The type of the name included in the Name field. This specification defines two legal values for this field:
名称字段中包含的名称类型。本规范为该字段定义了两个合法值：
1 DER Encoded X.501 Name 2 FQDN
1 DER编码的X.501名称2 FQDN
Pad Length
衬垫长度
The number of padding octets beyond the end of the Name field but within the length specified by the Length field. Padding octets MUST be set to zero by senders and ignored by receivers.
超出名称字段末尾但在长度字段指定长度内的填充八位字节数。发送方必须将填充八位字节设置为零，接收方必须忽略。
Name
名称
When the Name Type field is set to 1, the Name field contains a DER encoded X.501 Name identifying the trust anchor. The value is encoded as defined in [12] and [7].
当名称类型字段设置为1时，名称字段包含一个DER编码的X.501名称，用于标识信任锚点。该值按照[12]和[7]中的定义进行编码。
When the Name Type field is set to 2, the Name field contains a Fully Qualified Domain Name of the trust anchor; for example, "trustanchor.example.com". The name is stored as a string, in the DNS wire format, as specified in RFC 1034 [1]. Additionally, the restrictions discussed in RFC 3280 [7], Section 4.2.1.7 apply.
当名称类型字段设置为2时，名称字段包含信任锚点的完全限定域名；例如，“trustanchor.example.com”。按照RFC 1034[1]中的规定，名称以DNS wire格式存储为字符串。此外，RFC 3280[7]第4.2.1.7节中讨论的限制也适用。
In the FQDN case, the Name field is an "IDN-unaware domain name slot", as defined in [9]. That is, it can contain only ASCII characters. An implementation MAY support internationalized domain names (IDNs) using the ToASCII operation; see [9] for more information.
在FQDN情况下，名称字段是一个“IDN未知域名槽”，如[9]中所定义。也就是说，它只能包含ASCII字符。一个实现可以支持使用ToASCII操作的国际化域名（idn）；有关更多信息，请参见[9]。
All systems MUST support the DER Encoded X.501 Name. Implementations MAY support the FQDN name type.
所有系统必须支持DER编码的X.501名称。实现可能支持FQDN名称类型。
Padding
衬料
A variable-length field making the option length a multiple of 8, beginning after the previous field ends and continuing to the end of the option, as specified by the Length field.
一个可变长度字段，使选项长度为8的倍数，从上一个字段结束后开始，一直到选项结束，如长度字段所指定。
The format of the certificate option is described in the following:
证书选项的格式如下所述：
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 | Cert Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Cert Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
16
16
Length
长
The length of the option (including the Type, Length, Cert Type, Pad Length, and Certificate fields), in units of 8 octets.
选项的长度（包括类型、长度、证书类型、键盘长度和证书字段），以8个八位字节为单位。
Cert Type
证书类型
The type of the certificate included in the Certificate field. This specification defines only one legal value for this field:
证书字段中包含的证书类型。本规范仅为该字段定义一个合法值：
1 X.509v3 Certificate, as specified below
1个X.509v3证书，如下所述
Reserved
含蓄的
An 8-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver.
保留供将来使用的8位字段。发送方必须将该值初始化为零，接收方必须忽略该值。
Certificate
证明书
When the Cert Type field is set to 1, the Certificate field contains an X.509v3 certificate [7], as described in Section 6.3.1.
当证书类型字段设置为1时，证书字段包含X.509v3证书[7]，如第6.3.1节所述。
Padding
衬料
A variable length field making the option length a multiple of 8, beginning after the ASN.1 encoding of the previous field [7, 15] ends and continuing to the end of the option, as specified by the Length field.
一个可变长度字段，使选项长度为8的倍数，从前面字段[7，15]的ASN.1编码结束后开始，继续到选项的结尾，如长度字段所指定。
A router MUST silently discard any received Certification Path Solicitation messages that do not conform to the message format defined in Section 6.4.1. The contents of the Reserved field and of any unrecognized options MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values. The contents of any defined options that are not specified to be used with Router Solicitation messages MUST be ignored, and the packet processed in the normal manner. The only defined option that may appear is the Trust Anchor option. A solicitation that passes the validity checks is called a "valid solicitation".
路由器必须以静默方式丢弃任何接收到的不符合第6.4.1节中定义的消息格式的认证路径请求消息。必须忽略保留字段和任何无法识别的选项的内容。将来对协议的向后兼容更改可能会指定保留字段的内容或添加新选项；向后不兼容的更改可能使用不同的代码值。必须忽略未指定用于路由器请求消息的任何已定义选项的内容，并以正常方式处理数据包。唯一可能出现的定义选项是信任锚选项。通过有效性检查的邀约称为“有效邀约”。
Routers SHOULD send advertisements in response to valid solicitations received on an advertising interface. If the source address in the solicitation was the unspecified address, the router MUST send the response to the link-scoped All-Nodes multicast address. If the source address was a unicast address, the router MUST send the response to the Solicited-Node multicast address corresponding to the source address, except when under load, as specified below. Routers SHOULD NOT send Certification Path Advertisements more than MAX_CPA_RATE times within a second. When there are more solicitations, the router SHOULD send the response to the All-Nodes multicast address regardless of the source address that appeared in the solicitation.
路由器应发送广告以响应在广告接口上收到的有效请求。如果请求中的源地址是未指定的地址，路由器必须将响应发送到链接范围内的所有节点多播地址。如果源地址是单播地址，路由器必须将响应发送到与源地址对应的请求节点多播地址，除非在负载下，如下所述。路由器在一秒钟内发送认证路径广告的次数不应超过MAX_CPA_RATE次数。当有更多请求时，路由器应将响应发送到所有节点多播地址，而不管请求中出现的源地址。
In an advertisement, the router SHOULD include suitable Certificate options so that a certification path can be established to the solicited trust anchor (or a part of it, if the Component field in the solicitation is not equal to 65,535). Note also that a single advertisement is broken into separately sent components and ordered in a particular way (see Section 6.4.2) when there is more than one certificate in the path.
在公告中，路由器应包括适当的证书选项，以便可以建立到请求的信任锚（或其一部分，如果请求中的组件字段不等于65535）的证书路径。还请注意，当路径中有多个证书时，单个广告被分解为单独发送的组件，并以特定方式订购（见第6.4.2节）。
The anchor is identified by the Trust Anchor option. If the Trust Anchor option is represented as a DER Encoded X.501 Name, then the Name must be equal to the Subject field in the anchor's certificate. If the Trust Anchor option is represented as an FQDN, the FQDN must be equal to an FQDN in the subjectAltName field of the anchor's certificate. The router SHOULD include the Trust Anchor option(s) in the advertisement for which the certification path was found.
锚由信任锚选项标识。如果信任锚选项表示为DER编码的X.501名称，则该名称必须等于锚证书中的Subject字段。如果信任锚点选项表示为FQDN，则FQDN必须等于锚点证书的subjectAltName字段中的FQDN。路由器应在找到其证书路径的播发中包含信任锚选项。
If the router is unable to find a path to the requested anchor, it SHOULD send an advertisement without any certificates. In this case, the router SHOULD include the Trust Anchor options that were solicited.
如果路由器无法找到到请求的锚的路径，它应该发送一个没有任何证书的播发。在这种情况下，路由器应该包括请求的信任锚选项。
A host MUST silently discard any received Certification Path Advertisement messages that do not conform to the message format defined in Section 6.4.2. The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol MAY specify the contents of the Reserved field or add new options; backward-incompatible changes MUST use different Code values. The contents of any defined options not specified to be used with Certification Path Advertisement messages MUST be ignored, and the packet processed in the normal manner. The only defined options that may appear are the Certificate and Trust Anchor options. An advertisement that passes the validity checks is called a "valid advertisement".
主机必须以静默方式丢弃任何接收到的不符合第6.4.2节中定义的消息格式的认证路径公告消息。必须忽略保留字段和任何无法识别的选项的内容。将来对协议的向后兼容更改可能会指定保留字段的内容或添加新选项；向后不兼容的更改必须使用不同的代码值。必须忽略未指定用于认证路径公告消息的任何已定义选项的内容，并以正常方式处理数据包。可能出现的唯一定义选项是证书和信任锚选项。通过有效性检查的广告称为“有效广告”。
Hosts SHOULD store certification paths retrieved in Certification Path Discovery messages if they start from an anchor trusted by the host. The certification paths MUST be verified, as defined in Section 6.3, before storing them. Routers send the certificates one by one, starting from the trust anchor end of the path.
如果从主机信任的锚点开始，主机应存储在证书路径发现消息中检索的证书路径。在存储认证路径之前，必须按照第6.3节的规定对其进行验证。路由器从路径的信任锚点端开始逐个发送证书。
Note: Except to allow for message loss and reordering for temporary purposes, hosts might not store certificates received in a Certification Path Advertisement unless they contain a certificate that can be immediately verified either to the trust anchor or to a certificate that has been verified earlier. This measure is intended to prevent Denial-of-Service attacks, whereby an attacker floods a host with certificates that the host cannot validate and overwhelms memory for certificate storage.
注意：除了允许出于临时目的丢失消息和重新排序外，主机可能不会存储在证书路径播发中接收的证书，除非它们包含可以立即验证到信任锚点或先前已验证的证书的证书。此措施旨在防止拒绝服务攻击，即攻击者向主机发送主机无法验证的证书，并占用存储证书的内存。
Note that caching this information, and the implied verification results between network attachments for use over multiple attachments to the network, can help improve performance. But periodic certificate revocation checks are still needed, even with cached results, to make sure that the certificates are still valid.
请注意，缓存此信息以及网络附件之间的隐含验证结果，以便在网络的多个附件上使用，有助于提高性能。但是仍然需要定期的证书撤销检查，即使是缓存的结果，以确保证书仍然有效。
The host SHOULD retrieve a certification path when a Router Advertisement has been received with a public key that is not available from a certificate in the hosts' cache, or when there is no certification path to one of the host's trust anchors. In these situations, the host MAY send a Certification Path Solicitation message to retrieve the path. If there is no response within CPS_RETRY seconds, the message should be retried. The wait interval for each subsequent retransmission MUST exponentially increase, doubling each time. If there is no response after CPS_RETRY_MAX seconds, the host abandons the certification path retrieval process. If the host receives only a part of a certification path within CPS_RETRY_FRAGMENTS seconds of receiving the first part, it MAY in
当使用主机缓存中的证书不可用的公钥接收到路由器播发时，或者当主机的信任锚之一没有证书路径时，主机应检索证书路径。在这些情况下，主机可以发送证书路径请求消息来检索路径。如果在CPS_重试秒内没有响应，则应重试该消息。每次后续重传的等待间隔必须以指数形式增加，每次增加一倍。如果在CPS_RETRY_MAX seconds之后没有响应，主机将放弃证书路径检索过程。如果主机在收到第一部分后的几秒钟内仅收到CPS_RETRY_片段内的证书路径的一部分，则它可能在
addition transmit a Certification Path Solicitation message with the Component field set to a value not equal to 65,535. This message can be retransmitted by using the same process as for the initial message. If there are multiple missing certificates, additional CPS messages can be sent after getting a response to first one. However, the complete retrieval process may last at most CPS_RETRY_MAX seconds.
此外，传输认证路径请求消息时，组件字段设置为不等于65535的值。可以使用与初始消息相同的过程重新传输此消息。如果有多个丢失的证书，则在收到对第一个证书的响应后，可以发送额外的CPS消息。但是，完整的检索过程可能最多持续CPS_RETRY_MAX秒。
Certification Path Solicitations SHOULD NOT be sent if the host has a currently valid certification path from a reachable router to a trust anchor.
如果主机具有从可访问路由器到信任锚点的当前有效证书路径，则不应发送证书路径请求。
When soliciting certificates for a router, a host MUST send Certification Path Solicitations either to the All-Routers multicast address, if it has not selected a default router yet, or to the default router's IP address, if a default router has already been selected.
为路由器请求证书时，主机必须将证书路径请求发送到所有路由器的多播地址（如果尚未选择默认路由器），或者发送到默认路由器的IP地址（如果已选择默认路由器）。
If two hosts want to establish trust with the CPS and CPA messages, the CPS message SHOULD be sent to the Solicited-Node multicast address of the receiver. The advertisements SHOULD be sent as specified above for routers. However, the exact details are outside the scope of this specification.
如果两台主机希望与CPS和CPA消息建立信任，则应将CPS消息发送到接收方的请求节点多播地址。广告应按照上述路由器规定发送。但是，具体细节不在本规范范围内。
When processing possible advertisements sent as responses to a solicitation, the host MAY prefer to process those advertisements with the same Identifier field value as that of the solicitation first. This makes Denial-of-Service attacks against the mechanism harder (see Section 9.3).
当处理作为对请求的响应而发送的可能广告时，主机可能倾向于首先处理具有与请求相同的标识符字段值的那些广告。这使得针对该机制的拒绝服务攻击更加困难（见第9.3节）。
End hosts are configured with a set of trust anchors in order to protect Router Discovery. A trust anchor configuration consists of the following items:
终端主机配置了一组信任锚，以保护路由器发现。信任锚配置由以下项目组成：
o A public key signature algorithm and associated public key, which may optionally include parameters.
o 一种公钥签名算法和相关联的公钥，其可以可选地包括参数。
o A name as described in Section 6.4.3.
o 第6.4.3节所述的名称。
o An optional public key identifier.
o 可选的公钥标识符。
o An optional list of address ranges for which the trust anchor is authorized.
o 信任锚授权的地址范围的可选列表。
If the host has been configured to use SEND, it SHOULD possess the above information for at least one trust anchor.
如果主机已配置为使用SEND，则至少应具有一个信任锚的上述信息。
Routers are configured with a collection of certification paths and a collection of certificates containing certified keys, down to the key and certificate for the router itself. Certified keys are required for routers so that a certification path can be established between the router's certificate and the public key of a trust anchor.
路由器配置有一组认证路径和一组包含认证密钥的证书，直至路由器本身的密钥和证书。路由器需要认证密钥，以便在路由器的证书和信任锚的公钥之间建立认证路径。
If the router has been configured to use SEND, it should be configured with its own key pair and certificate, and with at least one certification path.
如果路由器已配置为使用SEND，则应使用其自己的密钥对和证书以及至少一个证书路径进行配置。
By default, a SEND-enabled node SHOULD use only CGAs for its own addresses. Other types of addresses MAY be used in testing, in diagnostics, or for other purposes. However, this document does not describe how to choose between different types of addresses for different communications. A dynamic selection can be provided by an API, such as the one defined in [21].
默认情况下，启用发送的节点应仅将CGA用于其自己的地址。其他类型的地址可用于测试、诊断或其他目的。但是，本文档没有描述如何为不同的通信选择不同类型的地址。API可以提供动态选择，如[21]中定义的API。
If the Target Address and Destination Address fields in the ICMP Redirect message are equal, then this message is used to inform hosts that a destination is, in fact, a neighbor. In this case, the receiver MUST verify that the given address falls within the range defined by the router's certificate. Redirect messages failing this check MUST be treated as unsecured, as described in Section 7.3.
如果ICMP重定向消息中的目标地址和目标地址字段相等，则此消息用于通知主机目标实际上是邻居。在这种情况下，接收方必须验证给定地址是否在路由器证书定义的范围内。如第7.3节所述，未通过此检查的重定向消息必须视为不安全消息。
Note that base NDP rules prevent a host from accepting a Redirect message from a router that the host is not using to reach the destination mentioned in the redirect. This prevents an attacker from tricking a node into redirecting traffic when the attacker is not the default router.
请注意，基本NDP规则阻止主机接受来自路由器的重定向消息，而主机不使用该消息到达重定向中提到的目的地。这可以防止攻击者在不是默认路由器时诱使节点重定向流量。
The router's certificate defines the address range(s) that it is allowed to advertise securely. A router MAY, however, advertise a combination of certified and uncertified subnet prefixes. Uncertified subnet prefixes are treated as unsecured (i.e., processed in the same way as unsecured router advertisements sent by non-SEND routers). The processing of unsecured messages is specified in Section 8. Note that SEND nodes that do not attempt to interoperate with non-SEND nodes MAY simply discard the unsecured information.
路由器的证书定义允许安全播发的地址范围。然而，路由器可以公布经认证和未经认证的子网前缀的组合。未经认证的子网前缀被视为不安全的（即，以与非发送路由器发送的不安全路由器广告相同的方式处理）。第8节规定了不安全消息的处理。请注意，不尝试与非发送节点互操作的发送节点可能只会丢弃不安全的信息。
Certified subnet prefixes fall into the following two categories:
经认证的子网前缀分为以下两类：
Constrained
受限
If the network operator wants to constrain which routers are allowed to route particular subnet prefixes, routers should be configured with certificates having subnet prefixes listed in the prefix extension. These routers SHOULD advertise the subnet prefixes that they are certified to route, or a subset thereof.
如果网络运营商希望限制允许哪些路由器路由特定子网前缀，则应为路由器配置具有前缀扩展中列出的子网前缀的证书。这些路由器应该公布它们被认证为路由的子网前缀或其子集。
Unconstrained
无拘无束
Network operators that do not want to constrain routers this way should configure routers with certificates containing either the null prefix or no prefix extension at all.
不希望以这种方式约束路由器的网络运营商应使用包含空前缀或根本不包含前缀扩展的证书配置路由器。
Upon processing a Prefix Information option within a Router Advertisement, nodes SHOULD verify that the prefix specified in this option falls within the range defined by the certificate, if the certificate contains a prefix extension. Options failing this check are treated as containing uncertified subnet prefixes.
在路由器公告中处理前缀信息选项时，如果证书包含前缀扩展，则节点应验证此选项中指定的前缀是否在证书定义的范围内。未通过此检查的选项将被视为包含未经验证的子网前缀。
Nodes SHOULD use one of the certified subnet prefixes for stateless autoconfiguration. If none of the advertised subnet prefixes match, the host SHOULD use a different advertising router as its default router, if one is available. If the node is performing stateful autoconfiguration, it SHOULD check the address provided by the DHCP server against the certified subnet prefixes and SHOULD NOT use the address if the prefix is not certified.
节点应使用其中一个认证的子网前缀进行无状态自动配置。如果所有播发的子网前缀都不匹配，则主机应使用不同的播发路由器作为其默认路由器（如果有）。如果节点正在执行有状态自动配置，则应根据已认证的子网前缀检查DHCP服务器提供的地址，如果前缀未经认证，则不应使用该地址。
This specification does not address the protection of NDP packets for nodes configured with a static address (e.g., PREFIX::1). Future certification path-based authorization specifications are needed for these nodes. This specification also does not apply to addresses generated by the IPv6 stateless address autoconfiguration from a fixed interface identifiers (such as EUI-64).
本规范不涉及对配置有静态地址（例如前缀：：1）的节点的NDP数据包的保护。这些节点需要未来基于认证路径的授权规范。本规范也不适用于IPv6无状态地址自动配置从固定接口标识符（如EUI-64）生成的地址。
It is outside the scope of this specification to describe the use of trust anchor authorization between nodes with dynamically changing addresses. These addresses may be the result of stateful or stateless address autoconfiguration, or may have resulted from the use of RFC 3041 [17] addresses. If the CGA method is not used, nodes are required to exchange certification paths that terminate in a certificate authorizing a node to use an IP address having a particular interface identifier. This specification does not specify the format of these certificates, as there are currently only a few
描述在地址动态变化的节点之间使用信任锚授权不在本规范的范围内。这些地址可能是有状态或无状态地址自动配置的结果，也可能是使用RFC 3041[17]地址的结果。如果未使用CGA方法，则节点需要交换证书路径，该路径终止于授权节点使用具有特定接口标识符的IP地址的证书。本规范没有指定这些证书的格式，因为目前只有少数证书
cases where they are provided by the link layer, and it is up to the link layer to provide certification for the interface identifier. This may be the subject of a future specification. It is also outside the scope of this specification to describe how stateful address autoconfiguration works with the CGA method.
由链路层提供，并且由链路层为接口标识符提供认证的情况。这可能是未来规范的主题。描述有状态地址自动配置如何与CGA方法一起工作也超出了本规范的范围。
The Target Address in Neighbor Advertisement is required to be equal to the source address of the packet, except in proxy Neighbor Discovery, which is not supported by this specification.
邻居播发中的目标地址必须等于数据包的源地址，本规范不支持的代理邻居发现中的目标地址除外。
During the transition to secured links, or as a policy consideration, network operators may want to run a particular link with a mixture of nodes accepting secured and unsecured messages. Nodes that support SEND SHOULD support the use of secured and unsecured NDP messages at the same time.
在过渡到安全链路期间，或者作为策略考虑，网络运营商可能希望运行一个特定的链路，同时使用接受安全和不安全消息的节点。支持发送的节点应同时支持使用安全和非安全NDP消息。
In a mixed environment, SEND nodes receive both secured and unsecured messages but give priority to secured ones. Here, the "secured" messages are those that contain a valid signature option, as specified above, and "unsecured" messages are those that contain no signature option.
在混合环境中，发送节点接收安全消息和非安全消息，但优先考虑安全消息。这里，“安全”消息是那些包含有效签名选项的消息，如上所述，“不安全”消息是那些不包含签名选项的消息。
A SEND node SHOULD have a configuration option that causes it to ignore all unsecured Neighbor Solicitation and Advertisement, Router Solicitation and Advertisement, and Redirect messages. This can be used to enforce SEND-only networks. The default for this configuration option SHOULD be that both secured and unsecured messages are allowed.
发送节点应具有一个配置选项，该选项使其忽略所有不安全的邻居请求和播发、路由器请求和播发以及重定向消息。这可用于强制实施仅发送网络。此配置选项的默认值应为允许安全消息和不安全消息。
A SEND node MAY also have a configuration option whereby it disables the use of SEND completely, even for the messages it sends itself. This configuration option SHOULD be switched off by default; that is, SEND is used. Plain (non-SEND) NDP nodes will obviously send only unsecured messages. Per RFC 2461 [4], such nodes will ignore the unknown options and will treat secured messages in the same way that they treat unsecured ones. Secured and unsecured nodes share the same network resources, such as subnet prefixes and address spaces.
发送节点还可以有一个配置选项，通过该选项，它可以完全禁用SEND的使用，即使对于它自己发送的消息也是如此。默认情况下，应关闭此配置选项；也就是说，使用SEND。显然，非安全节点（NDP）只发送普通消息。根据RFC 2461[4]，此类节点将忽略未知选项，并以处理不安全消息的相同方式处理安全消息。安全节点和非安全节点共享相同的网络资源，如子网前缀和地址空间。
SEND nodes configured to use SEND at least in their own messages behave in a mixed environment as explained below.
配置为至少在其自己的消息中使用SEND的发送节点在混合环境中运行，如下所述。
SEND adheres to the rules defined for the base NDP protocol, with the following exceptions:
SEND遵守为基本NDP协议定义的规则，但以下情况除外：
o All solicitations sent by a SEND node MUST be secured.
o 必须保护发送节点发送的所有请求。
o Unsolicited advertisements sent by a SEND node MUST be secured.
o 必须保护发送节点发送的未经请求的广告。
o A SEND node MUST send a secured advertisement in response to a secured solicitation. Advertisements sent in response to an unsecured solicitation MUST be secured as well, but MUST NOT contain the Nonce option.
o 发送节点必须发送安全广告以响应安全请求。为响应无担保邀约而发送的广告也必须有担保，但不得包含Nonce选项。
o A SEND node that uses the CGA authorization method to protect Neighbor Solicitations SHOULD perform Duplicate Address Detection as follows. If Duplicate Address Detection indicates that the tentative address is already in use, the node generates a new tentative CGA. If after three consecutive attempts no non-unique address is generated, it logs a system error and gives up attempting to generate an address for that interface.
o 使用CGA授权方法保护邻居请求的发送节点应执行重复地址检测，如下所示。如果重复地址检测表明临时地址已在使用，则节点将生成新的临时CGA。如果连续三次尝试后未生成非唯一地址，则会记录系统错误并放弃为该接口生成地址的尝试。
When performing Duplicate Address Detection for the first tentative address, the node accepts both secured and unsecured Neighbor Advertisements and Solicitations received in response to the Neighbor Solicitations. When performing Duplicate Address Detection for the second or third tentative address, it ignores unsecured Neighbor Advertisements and Solicitations. (The security implications of this are discussed in Section 9.2.3 and in [11].)
当对第一个暂定地址执行重复地址检测时，节点接受安全和不安全的邻居播发以及响应邻居请求而接收的请求。当对第二个或第三个暂定地址执行重复地址检测时，它会忽略不安全的邻居播发和请求。（第9.2.3节和[11]中讨论了这一点的安全影响。）
o The node MAY have a configuration option whereby it ignores unsecured advertisements, even when performing Duplicate Address Detection for the first tentative address. This configuration option SHOULD be disabled by default. This is a recovery mechanism for cases in which attacks against the first address become common.
o 该节点可以具有配置选项，由此它忽略不安全的播发，即使在对第一暂定地址执行重复地址检测时也是如此。默认情况下，应禁用此配置选项。这是一种恢复机制，适用于攻击第一个地址变得常见的情况。
o The Neighbor Cache, Prefix List, and Default Router list entries MUST have a secured/unsecured flag that indicates whether the message that caused the creation or last update of the entry was secured or unsecured. Received unsecured messages MUST NOT cause changes to existing secured entries in the Neighbor Cache, Prefix List, or Default Router List. Received secured messages MUST cause an update of the matching entries, which MUST be flagged as secured.
o 邻居缓存、前缀列表和默认路由器列表项必须具有安全/不安全标志，该标志指示导致创建或上次更新该项的消息是安全的还是不安全的。收到的不安全消息不得导致更改邻居缓存、前缀列表或默认路由器列表中的现有安全条目。收到的安全消息必须导致匹配项的更新，这些项必须标记为安全。
o Neighbor Solicitations for the purpose of Neighbor Unreachability Detection (NUD) MUST be sent to that neighbor's solicited-nodes multicast address if the entry is not secured with SEND.
o 如果条目未使用SEND进行保护，则必须将用于邻居不可达性检测（NUD）的邻居请求发送到该邻居请求的节点多播地址。
Upper layer confirmations on unsecured neighbor cache entries SHOULD NOT update neighbor cache state from STALE to REACHABLE on a SEND node if the neighbor cache entry has never previously been REACHABLE. This ensures that if an entry spoofing a valid SEND
如果发送节点上的邻居缓存项以前从未可访问，则对不安全邻居缓存项的上层确认不应将邻居缓存状态从过时更新为可访问。这可以确保如果一个条目欺骗了一个有效的发送
host is created by a non-SEND attacker without being solicited, NUD will be done with the entry for data transmission within five seconds of use.
主机是由非发送攻击者在未被请求的情况下创建的，NUD将在使用后5秒内完成数据传输。
As a result, in mixed mode, attackers can take over a Neighbor Cache entry of a SEND node for a longer time only if (a) the SEND node was not communicating with the victim node, so that there is no secure entry for it, and (b) the SEND node is not currently on the link (or is unable to respond).
因此，在混合模式下，只有在（a）发送节点未与受害节点通信，因此没有安全条目，以及（b）发送节点当前不在链路上（或无法响应）时，攻击者才能接管发送节点的邻居缓存条目更长时间。
o The conceptual sending algorithm is modified so that an unsecured router is selected only if there is no reachable SEND router for the prefix. That is, the algorithm for selecting a default router favors reachable SEND routers over reachable non-SEND ones.
o 修改了概念发送算法，以便仅当前缀没有可到达的发送路由器时，才选择不安全的路由器。也就是说，选择默认路由器的算法倾向于可到达的发送路由器，而不是可到达的非发送路由器。
o A node MAY adopt a router sending unsecured messages, or a router for which secured messages have been received but for which full security checks have not yet been completed, while security checking is underway. Security checks in this case include certification path solicitation, certificate verification, CRL checks, and RA signature checks. A node MAY also adopt a router sending unsecured messages if a router known to be secured becomes unreachable, but because the unreachability may be the result of an attack it SHOULD attempt to find a router known to be secured as soon as possible. Note that although this can speed up attachment to a new network, accepting a router that is sending unsecured messages or for which security checks are not complete opens the node to possible attacks. Nodes that choose to accept such routers do so at their own risk. The node SHOULD, in any case, prefer a router known to be secure as soon as one is made available with completed security checks.
o 节点可以采用发送不安全消息的路由器，或者在安全检查正在进行时已接收到安全消息但尚未完成完整安全检查的路由器。这种情况下的安全检查包括证书路径请求、证书验证、CRL检查和RA签名检查。如果已知安全的路由器变得不可访问，则节点也可采用发送不安全消息的路由器，但由于不可访问性可能是攻击的结果，因此节点应尝试尽快找到已知安全的路由器。请注意，尽管这可以加快连接到新网络的速度，但接受发送不安全消息或未完成安全检查的路由器会使节点面临可能的攻击。选择接受此类路由器的节点自行承担风险。在任何情况下，节点都应该选择一个已知安全的路由器，只要完成安全检查就可以使用。
SEND does not provide confidentiality for NDP communications.
SEND不为NDP通信提供机密性。
SEND does not compensate for an unsecured link layer. For instance, there is no assurance that payload packets actually come from the same peer against which the NDP was run.
发送不补偿不安全的链路层。例如，无法保证有效负载数据包实际上来自运行NDP的同一对等方。
There may not be cryptographic binding in SEND between the link layer frame address and the IPv6 address. An unsecured link layer could allow nodes to spoof the link layer address of other nodes. An attacker could disrupt IP service by sending out a Neighbor Advertisement on an unsecured link layer, with the link layer source address on the frame set as the source address of a victim, a valid
链路层帧地址和IPv6地址之间的发送中可能没有加密绑定。不安全的链路层可能允许节点欺骗其他节点的链路层地址。攻击者可以通过在不安全的链路层上发送邻居公告（帧上的链路层源地址设置为受害者的源地址，有效的
CGA address and a valid signature corresponding to itself, and a Target Link-layer Address extension corresponding to the victim. The attacker could then make a traffic stream bombard the victim in a DoS attack. This cannot be prevented just by securing the link layer.
CGA地址和对应于自身的有效签名，以及对应于受害者的目标链路层地址扩展。然后，攻击者可以使流量流在DoS攻击中轰炸受害者。这不能仅仅通过保护链路层来防止。
Even on a secured link layer, SEND does not require that the addresses on the link layer and Neighbor Advertisements correspond. However, performing these checks is RECOMMENDED if the link layer technology permits.
即使在安全链路层上，SEND也不要求链路层上的地址与邻居播发对应。但是，如果链路层技术允许，建议执行这些检查。
Prior to participating in Neighbor Discovery and Duplicate Address Detection, nodes must subscribe to the link-scoped All-Nodes Multicast Group and the Solicited-Node Multicast Group for the address that they are claiming as their addresses; RFC 2461 [4]. Subscribing to a multicast group requires that the nodes use MLD [16]. MLD contains no provision for security. An attacker could send an MLD Done message to unsubscribe a victim from the Solicited-Node Multicast address. However, the victim should be able to detect this attack because the router sends a Multicast-Address-Specific Query to determine whether any listeners are still on the address, at which point the victim can respond to avoid being dropped from the group. This technique will work if the router on the link has not been compromised. Other attacks using MLD are possible, but they primarily lead to extraneous (but not necessarily overwhelming) traffic.
在参与邻居发现和重复地址检测之前，节点必须订阅链路范围内的所有节点多播组和请求的节点多播组，以获取其声称为其地址的地址；RFC2461[4]。订阅多播组需要节点使用MLD[16]。MLD不包含安全规定。攻击者可以发送MLD Done消息，从请求的节点多播地址取消订阅受害者。但是，受害者应该能够检测到这种攻击，因为路由器发送一个多播地址特定的查询，以确定是否有任何侦听器仍在该地址上，在这一点上，受害者可以做出响应，以避免从组中删除。如果链路上的路由器未被破坏，此技术将起作用。使用MLD的其他攻击也是可能的，但它们主要导致无关的（但不一定是压倒性的）流量。
The SEND protocol is designed to counter the threats to NDP, as outlined in [22]. The following subsections contain a regression of the SEND protocol against the threats, to illustrate which aspects of the protocol counter each threat.
如[22]所述，发送协议旨在应对NDP面临的威胁。以下小节包含发送协议对威胁的回归，以说明协议的哪些方面可以应对每个威胁。
This threat is defined in Section 4.1.1 of [22]. The threat is that a spoofed message may cause a false entry in a node's Neighbor Cache. There are two cases:
[22]第4.1.1节对该威胁进行了定义。威胁在于，伪造的消息可能导致节点的邻居缓存中出现错误条目。有两种情况：
1. Entries made as a side effect of a Neighbor Solicitation or Router Solicitation. A router receiving a Router Solicitation with a Target Link-Layer Address extension and the IPv6 source address unequal to the unspecified address inserts an entry for the IPv6 address into its Neighbor Cache. Also, a node performing Duplicate Address Detection (DAD) that receives a Neighbor Solicitation for the same address regards the situation as a collision and ceases to solicit for the address.
1. 作为邻居请求或路由器请求的副作用而创建的条目。接收到目标链路层地址扩展和IPv6源地址不等于未指定地址的路由器请求的路由器将IPv6地址的条目插入其邻居缓存。此外，执行重复地址检测（DAD）的节点接收到相同地址的邻居请求，该节点将该情况视为冲突，并停止请求该地址。
In either case, SEND counters these threats by requiring that the RSA Signature and CGA options be present in these solicitations.
在任何一种情况下，SEND都会通过要求在这些请求中提供RSA签名和CGA选项来应对这些威胁。
SEND nodes can send Router Solicitation messages with a CGA source address and a CGA option, which the router can verify, so that the Neighbor Cache binding is correct. If a SEND node must send a Router Solicitation with the unspecified address, the router will not update its Neighbor Cache, as per base NDP.
发送节点可以发送带有CGA源地址和CGA选项的路由器请求消息，路由器可以对此进行验证，以便邻居缓存绑定正确。如果发送节点必须发送带有未指定地址的路由器请求，路由器将不会按照基本NDP更新其邻居缓存。
2. Entries made as a result of a Neighbor Advertisement message. SEND counters this threat by requiring that the RSA Signature and CGA options be present in these advertisements.
2. 作为邻居广告消息的结果而创建的条目。SEND通过要求在这些广告中提供RSA签名和CGA选项来反击这种威胁。
Also see Section 9.2.5, below, for discussion about replay protection and timestamps.
有关重播保护和时间戳的讨论，请参见下文第9.2.5节。
This attack is described in Section 4.1.2 of [22]. SEND counters it by requiring that a node responding to Neighbor Solicitations sent as NUD probes include an RSA Signature option and proof of authorization to use the interface identifier in the address being probed. If these prerequisites are not met, the node performing NUD discards the responses.
[22]的第4.1.2节描述了这种攻击。SEND要求响应作为NUD探测发送的邻居请求的节点包括RSA签名选项和授权证明，以在被探测的地址中使用接口标识符，从而对其进行反击。如果不满足这些先决条件，则执行NUD的节点将丢弃响应。
This attack is described in Section 4.1.3 of [22]. SEND counters this attack by requiring that the Neighbor Advertisements sent as responses to DAD include an RSA Signature option and proof of authorization to use the interface identifier in the address being tested. If these prerequisites are not met, the node performing DAD discards the responses.
[22]第4.1.3节描述了这种攻击。SEND通过要求作为响应发送给DAD的邻居播发包含RSA签名选项和授权证明，以便在被测试的地址中使用接口标识符来反击此攻击。如果不满足这些先决条件，则执行DAD的节点将丢弃响应。
When a SEND node performs DAD, it may listen for address collisions from non-SEND nodes for the first address it generates, but not for new attempts. This protects the SEND node from DAD DoS attacks by non-SEND nodes or attackers simulating non-SEND nodes, at the cost of a potential address collision between a SEND node and a non-SEND node. The probability and effects of such an address collision are discussed in [11].
当发送节点执行DAD时，它可能会侦听非发送节点生成的第一个地址的地址冲突，但不会侦听新的尝试。这可以保护发送节点免受非发送节点或模拟非发送节点的攻击者的DAD DoS攻击，但代价是发送节点和非发送节点之间可能存在地址冲突。[11]讨论了这种地址冲突的概率和影响。
These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6, and 4.2.7 of [22]. SEND counters them by requiring that Router Advertisements contain an RSA Signature option, and that the signature is calculated by using the public key of a node that can
[22]的第4.2.1、4.2.4、4.2.5、4.2.6和4.2.7节对这些攻击进行了描述。SEND通过要求路由器广告包含RSA签名选项，并通过使用可以
prove its authorization to route the subnet prefixes contained in any Prefix Information Options. The router proves its authorization by showing a certificate containing the specific prefix or an indication that the router is allowed to route any prefix. A Router Advertisement without these protections is discarded.
证明其有权路由任何前缀信息选项中包含的子网前缀。路由器通过显示包含特定前缀的证书或允许路由器路由任何前缀的指示来证明其授权。没有这些保护的路由器广告将被丢弃。
SEND does not protect against brute force attacks on the router, such as DoS attacks, or against compromise of the router, as described in Sections 4.4.2 and 4.4.3 of [22].
如[22]第4.4.2节和第4.4.3节所述，SEND不能防止对路由器的暴力攻击（如DoS攻击）或对路由器的危害。
This attack is described in Section 4.3.1 of [22]. SEND protects against attacks in Router Solicitation/Router Advertisement and Neighbor Solicitation/Neighbor Advertisement transactions by including a Nonce option in the solicitation and requiring that the advertisement include a matching option. Together with the signatures, this forms a challenge-response protocol.
[22]的第4.3.1节描述了这种攻击。SEND通过在请求中包含Nonce选项并要求该通知包含匹配选项来防止路由器请求/路由器公告和邻居请求/邻居公告事务中的攻击。与签名一起，形成一个质询-响应协议。
SEND protects against attacks from unsolicited messages such as Neighbor Advertisements, Router Advertisements, and Redirects by including a Timestamp option. The following security issues are relevant only for unsolicited messages:
SEND通过包含时间戳选项来防止来自未经请求的消息（如邻居公告、路由器公告和重定向）的攻击。以下安全问题仅与未经请求的邮件相关：
o A window of vulnerability for replay attacks exists until the timestamp expires.
o 在时间戳过期之前，存在重播攻击的漏洞窗口。
However, such vulnerabilities are only useful for attackers if the advertised parameters change during the window. Although some parameters (such as the remaining lifetime of a prefix) change often, radical changes typically happen only in the context of some special case, such as switching to a new link layer address due to a broken interface adapter.
但是，只有当播发的参数在窗口期间发生更改时，此类漏洞才对攻击者有用。尽管某些参数（例如前缀的剩余生存期）经常更改，但基本更改通常仅在某些特殊情况下发生，例如由于接口适配器损坏而切换到新的链路层地址。
SEND nodes are also protected against replay attacks as long as they cache the state created by the message containing the timestamp. The cached state allows the node to protect itself against replayed messages. However, once the node flushes the state for whatever reason, an attacker can re-create the state by replaying an old message while the timestamp is still valid. Because most SEND nodes are likely to use fairly coarse-grained timestamps, as explained in Section 5.3.1, this may affect some nodes.
只要发送节点缓存由包含时间戳的消息创建的状态，发送节点也可以防止重播攻击。缓存状态允许节点保护自己不受重播消息的影响。但是，一旦节点出于任何原因刷新状态，攻击者可以在时间戳仍然有效的情况下通过重播旧消息重新创建状态。由于大多数发送节点可能使用相当粗粒度的时间戳，如第5.3.1节所述，这可能会影响某些节点。
o Attacks against time synchronization protocols such as NTP [23] may cause SEND nodes to have an incorrect timestamp value. This can be used to launch replay attacks, even outside the normal window of vulnerability. To protect against these attacks, it is
o 对NTP[23]等时间同步协议的攻击可能会导致发送节点的时间戳值不正确。这可用于发起重播攻击，甚至在正常漏洞窗口之外。为了防止这些攻击，它是
recommended that SEND nodes keep independently maintained clocks or apply suitable security measures for the time synchronization protocols.
建议发送节点保持独立维护的时钟或为时间同步协议应用适当的安全措施。
This attack is described in Section 4.3.2 of [22]. In it, the attacker bombards the router with packets for fictitious addresses on the link, causing the router to busy itself by performing Neighbor Solicitations for addresses that do not exist. SEND does not address this threat because it can be addressed by techniques such as rate limiting Neighbor Solicitations, restricting the amount of state reserved for unresolved solicitations, and clever cache management. These are all techniques involved in implementing Neighbor Discovery on the router.
[22]的第4.3.2节描述了这种攻击。在这种情况下，攻击者用数据包轰炸路由器，寻找链路上的虚拟地址，通过对不存在的地址执行邻居请求，使路由器忙起来。SEND无法解决此威胁，因为它可以通过限制邻居请求的速率、限制为未解决请求保留的状态量以及智能缓存管理等技术来解决。这些都是在路由器上实现邻居发现所涉及的技术。
The CGAs have a 59-bit hash value. The security of the CGA mechanism has been discussed in [11].
CGA具有59位哈希值。CGA机制的安全性已在[11]中讨论过。
Some Denial-of-Service attacks remain against NDP and SEND itself. For instance, an attacker may try to produce a very high number of packets that a victim host or router has to verify by using asymmetric methods. Although safeguards are required to prevent an excessive use of resources, this can still render SEND non-operational.
一些拒绝服务攻击仍然针对NDP并发送自身。例如，攻击者可能试图产生大量数据包，受害主机或路由器必须使用非对称方法验证这些数据包。尽管需要保护措施来防止过度使用资源，但这仍然会导致SEND无法运行。
When CGA protection is used, SEND deals with the DoS attacks by using the verification process described in Section 5.2.2. In this process, a simple hash verification of the CGA property of the address is performed before the more expensive signature verification. However, even if the CGA verification succeeds, no claims about the validity of the message can be made until the signature has been checked.
当使用CGA保护时，SEND使用第5.2.2节中描述的验证过程处理DoS攻击。在此过程中，在更昂贵的签名验证之前，对地址的CGA属性执行简单的哈希验证。但是，即使CGA验证成功，在检查签名之前，也不能声明消息的有效性。
When trust anchors and certificates are used for address validation in SEND, the defenses are not quite as effective. Implementations SHOULD track the resources devoted to the processing of packets received with the RSA Signature option and start selectively discarding packets if too many resources are spent. Implementations MAY also first discard packets that are not protected with CGA.
当在SEND中使用信任锚和证书进行地址验证时，防御就没有那么有效了。实现应该跟踪用于处理使用RSA签名选项接收的数据包的资源，并在花费太多资源时开始有选择地丢弃数据包。实现还可以首先丢弃不受CGA保护的数据包。
The Authorization Delegation Discovery process may also be vulnerable to Denial-of-Service attacks. An attack may target a router by requesting that a large number of certification paths be discovered for different trust anchors. Routers SHOULD defend against such attacks by caching discovered information (including negative
授权委派发现过程也可能容易受到拒绝服务攻击。通过请求为不同的信任锚发现大量的认证路径，攻击可能以路由器为目标。路由器应该通过缓存发现的信息（包括负面信息）来防御此类攻击
responses) and by limiting the number of different discovery processes in which they engage.
响应），并限制他们参与的不同发现过程的数量。
Attackers may also target hosts by sending a large number of unnecessary certification paths, forcing hosts to spend useless memory and verification resources on them. Hosts can defend against such attacks by limiting the amount of resources devoted to the certification paths and their verification. Hosts SHOULD also prioritize advertisements sent as a response to solicitations the hosts have sent about unsolicited advertisements.
攻击者还可能通过发送大量不必要的认证路径来攻击主机，迫使主机在这些路径上花费无用的内存和验证资源。主机可以通过限制用于认证路径及其验证的资源量来抵御此类攻击。主机还应优先考虑作为响应主机发送的关于未经请求的广告的请求而发送的广告。
Host constants:
主机常数：
CPS_RETRY 1 second CPS_RETRY_FRAGMENTS 2 seconds CPS_RETRY_MAX 15 seconds
CPS\u重试1秒CPS\u重试\u片段2秒CPS\u重试\u最多15秒
Router constants:
路由器常数：
MAX_CPA_RATE 10 times per second
最大CPA\U速率为每秒10次
TIMESTAMP_DELTA 300 seconds (5 minutes) TIMESTAMP_FUZZ 1 second TIMESTAMP_DRIFT 1 % (0.01)
时间戳增量300秒（5分钟）时间戳模糊1秒时间戳漂移1%（0.01）
This document defines two new ICMP message types, used in Authorization Delegation Discovery. These messages must be assigned ICMPv6 type numbers from the informational message range:
本文档定义了两种新的ICMP消息类型，用于授权委派发现。必须从信息性消息范围为这些消息分配ICMPv6类型编号：
o The Certification Path Solicitation message (148), described in Section 6.4.1.
o 第6.4.1节中描述的认证路径请求消息（148）。
o The Certification Path Advertisement message (149), described in Section 6.4.2.
o 第6.4.2节中描述的认证路径公告消息（149）。
This document defines six new Neighbor Discovery Protocol [4] options, which must be assigned Option Type values within the option numbering space for Neighbor Discovery Protocol messages:
本文档定义了六个新的邻居发现协议[4]选项，必须在邻居发现协议消息的选项编号空间内为其分配选项类型值：
o The CGA option (11), described in Section 5.1.
o 第5.1节中描述的CGA选项（11）。
o The RSA Signature option (12), described in Section 5.2.
o RSA签名选项（12），如第5.2节所述。
o The Timestamp option (13), described in Section 5.3.1.
o 时间戳选项（13），如第5.3.1节所述。
o The Nonce option (14), described in Section 5.3.2.
o 第5.3.2节中所述的当前选项（14）。
o The Trust Anchor option (15), described in Section 6.4.3.
o 第6.4.3节所述的信任锚选项（15）。
o The Certificate option (16), described in Section 6.4.4.
o 第6.4.4节中描述的证书选项（16）。
This document defines a new 128-bit value under the CGA Message Type [11] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.
本文档在CGA消息类型[11]名称空间0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08下定义了一个新的128位值。
This document defines a new name space for the Name Type field in the Trust Anchor option. Future values of this field can be allocated by using Standards Action [3]. The current values for this field are
此文档为信任锚选项中的“名称类型”字段定义了一个新的名称空间。可以使用标准操作[3]分配此字段的未来值。此字段的当前值为
1 DER Encoded X.501 Name
1 DER编码的X.501名称
2 FQDN
2 FQDN
Another new name space is allocated for the Cert Type field in the Certificate option. Future values of this field can be allocated by using Standards Action [3]. The current values for this field are
为证书选项中的证书类型字段分配了另一个新的名称空间。可以使用标准操作[3]分配此字段的未来值。此字段的当前值为
1 X.509v3 Certificate
1个X.509v3证书
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC24611998年12月。
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[5] Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
[6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[6] Conta，A.和S.Deering，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 2463，1998年12月。
[7] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[7] Housley，R.，Polk，W.，Ford，W.和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[8] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[8] Farrell，S.和R.Housley，“用于授权的互联网属性证书配置文件”，RFC 3281，2002年4月。
[9] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[9] Faltstrom，P.，Hoffman，P.和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[10] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[10] Lynn，C.，Kent，S.和K.Seo，“IP地址和AS标识符的X.509扩展”，RFC 3779，2004年6月。
[11] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[11] Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[12] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.
[12] 国际电信联盟，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）的规范”，ITU-T建议X.690，2002年7月。
[13] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS 1, November 2002.
[13] RSA实验室，“RSA加密标准，2.1版”，PKCS 1，2002年11月。
[14] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[14] 国家标准与技术研究所，“安全哈希标准”，FIPS PUB 180-11995年4月<http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[15] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[16] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[16] Deering，S.，Fenner，W.和B.Haberman，“IPv6多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[17] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[17] Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC3041，2001年1月。
[18] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[18] Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[19] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", Work in Progress, March 2003.
[19] Arkko，J.，“ICMPv6对IKE和IPsec策略的影响”，正在进行的工作，2003年3月。
[20] Arkko, J., "Manual SA Configuration for IPv6 Link Local Messages", Work in Progress, June 2002.
[20] Arkko，J.，“IPv6链路本地消息的手动SA配置”，正在进行的工作，2002年6月。
[21] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API for Address Selection", Work in Progress, October 2003.
[21] Nordmark，E.，Chakrabarti，S.和J.Laganier，“用于地址选择的IPv6套接字API”，正在进行的工作，2003年10月。
[22] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[22] Nikander，P.，Kempf，J.和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 3756，2004年5月。
[23] Bishop, M., "A Security Analysis of the NTP Protocol", Sixth Annual Computer Security Conference Proceedings, December 1990.
[23] Bishop，M.，“NTP协议的安全分析”，第六届年度计算机安全会议论文集，1990年12月。
Tuomas Aura contributed the transition mechanism specification in Section 8. Jonathan Trostle contributed the certification path example in Section 6.3.1. Bill Sommerfeld was involved with much of the early design work.
Tuomas Aura在第8节中提供了过渡机构规范。Jonathan Trostle在第6.3.1节中提供了认证路径示例。Bill Sommerfeld参与了许多早期设计工作。
The authors would also like to thank Tuomas Aura, Bill Sommerfeld, Erik Nordmark, Gabriel Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien Laganier, Francis Dupont, Pekka Savola, Wenxiao He, Valtteri Niemi, Mike Roe, Russ Housley, Thomas Narten, and Steven Bellovin for interesting discussions in this problem space and for feedback regarding the SEND protocol.
作者还要感谢图马斯·奥拉、比尔·索末菲尔德、埃里克·诺德马克、加布里埃尔·黑山、帕西·埃隆、格雷格·戴利、乔恩·伍德、朱利安·拉加尼尔、弗朗西斯·杜邦、佩卡·萨沃拉、文晓何、瓦泰里·尼米、迈克·罗伊、罗斯·霍斯利、托马斯·纳滕、，和Steven Bellovin在这个问题空间进行了有趣的讨论，并就发送协议提供了反馈。
In this section, we outline a cache management algorithm that allows a node to remain partially functional even under a cache-filling DoS attack. This appendix is informational, and real implementations SHOULD use different algorithms in order to avoid the dangers of a mono-cultural code.
在本节中，我们将介绍一种缓存管理算法，该算法允许节点即使在缓存填充DoS攻击下也保持部分功能。本附录仅供参考，实际实现应使用不同的算法，以避免单一文化代码的危险。
There are at least two distinct cache-related attack scenarios:
至少存在两种不同的缓存相关攻击场景：
1. There are a number of nodes on a link, and someone launches a cache filling attack. The goal here is to make sure that the nodes can continue to communicate even if the attack is going on.
1. 链路上有多个节点，有人发起缓存填充攻击。这里的目标是确保节点可以继续通信，即使攻击正在进行。
2. There is already a cache-filling attack going on, and a new node arrives to the link. The goal here is to make it possible for the new node to become attached to the network, in spite of the attack.
2. 缓存填充攻击正在进行，一个新节点到达链接。这里的目标是使新节点能够在受到攻击的情况下连接到网络。
As the intent is to limit the damage to existing, valid cache entries, it is clearly better to be very selective in throwing out entries. Reducing the timestamp Delta value is very discriminatory against nodes with a large clock difference, as an attacker can reduce its clock difference arbitrarily. Throwing out old entries just because their clock difference is large therefore seems like a bad approach.
由于目的是限制对现有有效缓存项的损坏，因此在抛出项时非常有选择性显然更好。减少时间戳增量值对于具有较大时钟差的节点是非常有区别的，因为攻击者可以任意减少其时钟差。因此，仅仅因为它们的时钟差异很大就扔掉旧条目似乎是一种糟糕的方法。
It is reasonable to have separate cache spaces for new and old entries, where when under attack, the newly cached entries would be more readily dropped. One could track traffic and only allow reasonable new entries that receive genuine traffic to be converted into old cache entries. Although such a scheme can make attacks harder, it will not fully prevent them. For example, an attacker could send a little traffic (i.e., a ping or TCP syn) after each NS
为新条目和旧条目设置单独的缓存空间是合理的，当受到攻击时，新缓存的条目将更容易被丢弃。可以跟踪流量，只允许接收真实流量的合理新条目转换为旧缓存条目。尽管这样的方案会使攻击更加困难，但它并不能完全防止攻击。例如，攻击者可以在每个NS之后发送少量流量（即ping或TCP syn）
to trick the victim into promoting its cache entry to the old cache. To counter this, the node can be more intelligent in keeping its cache entries than it would be just by having a black/white old/new boundary.
诱使受害者将其缓存项升级到旧缓存。为了解决这个问题，节点可以更智能地保留其缓存项，而不仅仅是使用黑白旧/新边界。
Distinction of the Sec parameter from the CGA Parameters when forcing cache entries out -- by keeping entries with larger Sec parameters preferentially -- also appears to be a possible approach, as CGAs with higher Sec parameters are harder to spoof.
当强制缓存项退出时，区分Sec参数和CGA参数（通过优先保留具有较大Sec参数的项）似乎也是一种可能的方法，因为具有较高Sec参数的CGA更难欺骗。
In one example scenario using SEND, an Authorization Delegation Discovery test run was made with a certification path length of 4. Three certificates are sent by using Certification Path Advertisement messages, as the trust anchor's certificate is already known by both parties. With a key length of 1024 bits, the certificate lengths in the test run ranged from 864 to 888 bytes; the variation is due to the differences in the certificate issuer names and address prefix extensions. The different certificates had between 1 and 4 address prefix extensions.
在使用SEND的一个示例场景中，使用4的认证路径长度进行授权委派发现测试运行。三个证书通过使用证书路径公告消息发送，因为信任锚的证书已经为双方所知。密钥长度为1024位，测试运行中的证书长度范围为864到888字节；这种变化是由于证书颁发者名称和地址前缀扩展名的差异造成的。不同的证书具有1到4个地址前缀扩展名。
The three Certification Path Advertisement messages ranged from 1050 to 1,066 bytes on an Ethernet link layer. The certificate itself accounts for the bulk of the packet. The rest is the trust anchor option, ICMP header, IPv6 header, and link layer header.
以太网链路层上的三个认证路径公告消息的范围为1050到1066字节。证书本身占数据包的大部分。其余的是信任锚选项、ICMP头、IPv6头和链路层头。
Authors' Addresses
作者地址
Jari Arkko Ericsson Jorvas 02420 Finland
雅丽爱立信芬兰公司02420
EMail: jari.arkko@ericsson.com
EMail: jari.arkko@ericsson.com
James Kempf DoCoMo Communications Labs USA 181 Metro Drive San Jose, CA 94043 USA
詹姆斯·肯普夫·多科莫通信实验室美国加利福尼亚州圣何塞市地铁路181号，邮编94043
EMail: kempf@docomolabs-usa.com
EMail: kempf@docomolabs-usa.com
Brian Zill Microsoft Research One Microsoft Way Redmond, WA 98052 USA
Brian Zill Microsoft Research One Microsoft Way Redmond，WA 98052美国
EMail: bzill@microsoft.com
EMail: bzill@microsoft.com
Pekka Nikander Ericsson Jorvas 02420 Finland
Pekka Nikander Ericsson Jorvas 02420芬兰
EMail: Pekka.Nikander@nomadiclab.com
EMail: Pekka.Nikander@nomadiclab.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。