Network Working Group P. Nikander, Ed.
Request for Comments: 3756 Ericsson Research Nomadic Lab
Category: Informational J. Kempf
DoCoMo USA Labs
E. Nordmark
Sun Microsystems Laboratories
May 2004
Network Working Group P. Nikander, Ed.
Request for Comments: 3756 Ericsson Research Nomadic Lab
Category: Informational J. Kempf
DoCoMo USA Labs
E. Nordmark
Sun Microsystems Laboratories
May 2004
IPv6 Neighbor Discovery (ND) Trust Models and Threats
IPv6邻居发现（ND）信任模型和威胁
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery.
现有的IETF标准规定IPv6邻居发现（ND）和地址自动配置机制可以使用IPsec身份验证头（AH）进行保护。然而，由于自动密钥管理面临的实际问题，当前规范将安全解决方案限制为手动密钥。本文档指定了三种不同的信任模型，并讨论了与IPv6邻居发现相关的威胁。本讨论的目的是定义保护IPv6邻居发现的要求。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Remarks . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Previous Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Trust Models . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Corporate Intranet Model. . . . . . . . . . . . . . . . . 5
3.2. Public Wireless Network with an Operator. . . . . . . . . 6
3.3. Ad Hoc Network. . . . . . . . . . . . . . . . . . . . . . 7
4. Threats on a (Public) Multi-Access Link. . . . . . . . . . . . 8
4.1. Non router/routing related threats. . . . . . . . . . . . 9
4.1.1. Neighbor Solicitation/Advertisement Spoofing . . . 9
4.1.2. Neighbor Unreachability Detection (NUD) failure. . 10
4.1.3. Duplicate Address Detection DoS Attack . . . . . . 11
4.2. Router/routing involving threats. . . . . . . . . . . . . 12
4.2.1. Malicious Last Hop Router. . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Remarks . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Previous Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Trust Models . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Corporate Intranet Model. . . . . . . . . . . . . . . . . 5
3.2. Public Wireless Network with an Operator. . . . . . . . . 6
3.3. Ad Hoc Network. . . . . . . . . . . . . . . . . . . . . . 7
4. Threats on a (Public) Multi-Access Link. . . . . . . . . . . . 8
4.1. Non router/routing related threats. . . . . . . . . . . . 9
4.1.1. Neighbor Solicitation/Advertisement Spoofing . . . 9
4.1.2. Neighbor Unreachability Detection (NUD) failure. . 10
4.1.3. Duplicate Address Detection DoS Attack . . . . . . 11
4.2. Router/routing involving threats. . . . . . . . . . . . . 12
4.2.1. Malicious Last Hop Router. . . . . . . . . . . . . 12
4.2.2. Default router is 'killed' . . . . . . . . . . . . 13
4.2.3. Good Router Goes Bad . . . . . . . . . . . . . . . 14
4.2.4. Spoofed Redirect Message . . . . . . . . . . . . . 14
4.2.5. Bogus On-Link Prefix . . . . . . . . . . . . . . . 14
4.2.6. Bogus Address Configuration Prefix . . . . . . . . 15
4.2.7. Parameter Spoofing . . . . . . . . . . . . . . . . 16
4.3. Replay attacks and remotely exploitable attacks . . . . . 17
4.3.1. Replay attacks . . . . . . . . . . . . . . . . . . 17
4.3.2. Neighbor Discovery DoS Attack. . . . . . . . . . . 18
4.4. Summary of the attacks. . . . . . . . . . . . . . . . . . 19
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
7. Informative References . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 23
4.2.2. Default router is 'killed' . . . . . . . . . . . . 13
4.2.3. Good Router Goes Bad . . . . . . . . . . . . . . . 14
4.2.4. Spoofed Redirect Message . . . . . . . . . . . . . 14
4.2.5. Bogus On-Link Prefix . . . . . . . . . . . . . . . 14
4.2.6. Bogus Address Configuration Prefix . . . . . . . . 15
4.2.7. Parameter Spoofing . . . . . . . . . . . . . . . . 16
4.3. Replay attacks and remotely exploitable attacks . . . . . 17
4.3.1. Replay attacks . . . . . . . . . . . . . . . . . . 17
4.3.2. Neighbor Discovery DoS Attack. . . . . . . . . . . 18
4.4. Summary of the attacks. . . . . . . . . . . . . . . . . . 19
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
7. Informative References . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 23
The IPv6 Neighbor Discovery (ND) RFC 2461 [2] and Address Autoconfiguration RFC 2462 [3] mechanisms are used by nodes in an IPv6 network to learn the local topology, including the IP to MAC address mappings for the local nodes, the IP and MAC addresses of the routers present in the local network, and the routing prefixes served by the local routers. The current specifications suggest that IPsec AH RFC 2402 [1] may be used to secure the mechanisms, but does not specify how. It appears that using current AH mechanisms is problematic due to key management problems [8].
IPv6网络中的节点使用IPv6邻居发现（ND）RFC 2461[2]和地址自动配置RFC 2462[3]机制来了解本地拓扑，包括本地节点的IP到MAC地址映射、本地网络中存在的路由器的IP和MAC地址，以及本地路由器提供的路由前缀。当前规范建议可以使用IPsec AH RFC 2402[1]来保护这些机制，但未指定如何保护。由于关键管理问题，使用当前AH机制似乎存在问题[8]。
To solve the problem, the Secure Neighbor Discovery (SEND) working group was chartered in Fall 2002. The goal of the working group is to define protocol support for securing IPv6 Neighbor Discovery without requiring excessive manual keying.
为了解决这个问题，安全邻居发现（SEND）工作组于2002年秋季成立。该工作组的目标是定义协议支持，以确保IPv6邻居发现的安全，而无需过多的手动键控。
The purpose of this document is to define the types of networks in which the Secure IPv6 Neighbor Discovery mechanisms are expected to work, and the threats that the security protocol(s) must address. To fulfill this purpose, this document first defines three different trust models, roughly corresponding to secured corporate intranets, public wireless access networks, and pure ad hoc networks. After that, a number of threats are discussed in the light of these trust models. The threat catalog is aimed to be exhaustive, but it is likely that some threats are still missing. Thus, ideas for new threats to consider are solicited.
本文档的目的是定义安全IPv6邻居发现机制预期工作的网络类型，以及安全协议必须解决的威胁。为了实现这一目的，本文首先定义了三种不同的信任模型，大致对应于安全的企业内部网、公共无线接入网络和纯自组织网络。然后，根据这些信任模型讨论了一些威胁。威胁目录旨在详尽无遗，但可能仍缺少一些威胁。因此，征求新的威胁的想法被征求。
Note that the SEND WG charter limits the scope of the working group to secure Neighbor Discovery functions. Furthermore, the charter explicitly mentions zero configuration as a fundamental goal behind Neighbor Discovery. Network access authentication and access control are outside the scope of this work.
请注意，SEND WG章程限制了工作组保护邻居发现功能的范围。此外，宪章明确提到零配置是邻居发现背后的一个基本目标。网络访问身份验证和访问控制不在本工作范围内。
During the discussions while preparing this document, the following aspects that may help to evaluate the eventual solutions were mentioned.
在编写本文件的讨论过程中，提到了可能有助于评估最终解决方案的以下方面。
Zero configuration
零配置
Interaction with access control solutions
与访问控制解决方案的交互
Scalability
可伸缩性
Efficiency
效率
However, the main evaluation criteria are formed by the trust models and threat lists. In other words, the solutions are primarily evaluated by seeing how well they secure the networks against the identified threats, and only secondarily from the configuration, access control, scalability, and efficiently point of view.
然而，主要的评估标准是由信任模型和威胁列表形成的。换句话说，对解决方案的评估主要是通过查看它们如何保护网络免受已识别的威胁，其次是从配置、访问控制、可扩展性和有效性的角度。
IMPORTANT. This document occasionally discusses solution proposals, such as Cryptographically Generated Addresses (CGA) [7] and Address Based Keys (ABK) [6]. However, such discussion is solely for illustrative purposes. Its purpose is to give the readers a more concrete idea of *some* possible solutions. Such discussion does NOT indicate any preference on solutions on the behalf of the authors or the working group.
重要的本文档偶尔讨论解决方案建议，如加密生成地址（CGA）[7]和基于地址的密钥（ABK）[6]。然而，此类讨论仅用于说明目的。它的目的是让读者对一些可能的解决方案有一个更具体的想法。这种讨论并不表明代表作者或工作组对解决办法有任何偏好。
It should be noted that the term "trust" is used in this document in a rather non-technical manner. The most appropriate interpretation is to consider it as an expression of an organizational or collective belief, i.e., an expression of commonly shared beliefs about the future behavior of the other involved parties. Conversely, the term "trust relationship" denotes a mutual a priori relationship between the involved organizations or parties where the parties believe that the other parties will behave correctly even in the future. A trust relationship makes it possible to configure authentication and authorization information between the parties, while the lack of such a relationship makes it impossible to pre-configure such information.
应注意的是，本文件中使用的术语“信任”是一种非技术性的方式。最恰当的解释是把它看作是一个组织或集体信念的表达，即对其他参与方未来行为的共同信念的表达。相反，术语“信任关系”表示相关组织或当事方之间的相互先验关系，当事方相信其他当事方即使在未来也会正确行事。信任关系使得可以在各方之间配置身份验证和授权信息，而缺少这种关系使得无法预先配置此类信息。
The RFCs that specify the IPv6 Neighbor Discovery and Address Autoconfiguration protocols [2] [3] contain the required discussion of security in a Security Considerations section. Some of the threats identified in this document were raised in the original RFCs. The recommended remedy was to secure the involved packets with an IPsec AH [1] header. However, that recommendation oversimplifies the problem by leaving the AH key management for future work. For example, a host attempting to gain access to a Public Access network may or may not have the required IPsec security associations set up with the network. In a roaming (but not necessarily mobile) situation, where a user is currently accessing the network through a service provider different from the home provider, it is not likely that the host will have been preconfigured with the proper mutual trust relationship for the foreign provider's network, allowing it to directly authenticate the network and get itself authenticated.
指定IPv6邻居发现和地址自动配置协议[2][3]的RFC在“安全注意事项”部分包含所需的安全性讨论。本文件中确定的一些威胁在原始RFC中提出。建议的补救措施是使用IPsec AH[1]头保护相关数据包。然而，该建议将AH密钥管理留给未来的工作，从而过度简化了问题。例如，试图访问公共访问网络的主机可能具有也可能没有与网络建立所需的IPsec安全关联。在漫游（但不一定是移动）情况下，当用户当前通过与归属提供商不同的服务提供商访问网络时，主机不太可能已经被预配置为具有针对外部提供商的网络的适当互信关系，允许它直接对网络进行身份验证，并对自身进行身份验证。
As of today, any IPsec security association between the host and the last hop routers or other hosts on the link would need to be completely manually preconfigured, since the Neighbor Discovery and Address Autoconfiguration protocols deal to some extent with how a host obtains initial access to a link. Thus, if a security association is required for initial access and the host does not have that association, there is currently no standard way that the host can dynamically configure itself with that association, even if it has the necessary minimum prerequisite keying material. This situation could induce administration hardships when events such as re-keying occur.
到目前为止，主机与链路上的最后一跳路由器或其他主机之间的任何IPsec安全关联都需要完全手动预配置，因为邻居发现和地址自动配置协议在某种程度上处理主机如何获得对链路的初始访问权。因此，如果初始访问需要安全关联，而主机没有该关联，则当前没有标准方法可以让主机使用该关联动态配置自己，即使它具有必要的最低先决条件密钥材料。当发生诸如重新键入之类的事件时，这种情况可能会导致管理困难。
In addition, Neighbor Discovery and Address Autoconfiguration use a few fixed multicast addresses plus a range of 16 million "solicited node" multicast addresses. A naive application of pre-configured SAs would require pre-configuring an unmanageable number of SAs on each host and router just in case a given solicited node multicast address is used. Preconfigured SAs are impractical for securing such a large potential address range.
此外，邻居发现和地址自动配置使用几个固定的多播地址加上1600万个“请求节点”多播地址。预配置SA的简单应用程序需要在每个主机和路由器上预配置数量不可管理的SA，以防使用给定的请求节点多播地址。预配置的SA对于保护如此大的潜在地址范围是不切实际的。
When considering various security solutions for the IPv6 Neighbor Discovery (ND) [2], it is important to keep in mind the underlying trust models. The trust models defined in this section are used later in this document, when discussing specific threats.
在考虑IPv6邻居发现（ND）[2]的各种安全解决方案时，务必记住底层信任模型。本节中定义的信任模型将在本文档后面讨论特定威胁时使用。
In the following, the RFC 2461/RFC 2462 mechanisms are loosely divided into two categories: Neighbor Discovery (ND) and Router Discovery (RD). The former denotes operations that do not primarily involve routers while the operations in the latter category do.
在下文中，RFC 2461/RFC 2462机制大致分为两类：邻居发现（ND）和路由器发现（RD）。前者表示不主要涉及路由器的操作，而后者中的操作则主要涉及路由器。
Three different trust models are specified:
指定了三种不同的信任模型：
1. A model where all authenticated nodes trust each other to behave correctly at the IP layer and not to send any ND or RD messages that contain false information. This model is thought to represent a situation where the nodes are under a single administration and form a closed or semi-closed group. A corporate intranet is a good example.
1. 一种模型，在该模型中，所有经过身份验证的节点相互信任，以便在IP层上正确运行，并且不发送任何包含虚假信息的ND或RD消息。该模型被认为代表了一种情况，即节点处于单一管理之下，并形成一个封闭或半封闭的组。企业内部网就是一个很好的例子。
2. A model where there is a router trusted by the other nodes in the network to be a legitimate router that faithfully routes packets between the local network and any connected external networks. Furthermore, the router is trusted to behave correctly at the IP layer and not to send any ND or RD messages that contain false information.
2. 一种模型，其中网络中的其他节点信任一个路由器，该路由器是一个合法的路由器，在本地网络和任何连接的外部网络之间忠实地路由数据包。此外，路由器可以在IP层正常工作，不会发送任何包含虚假信息的ND或RD消息。
This model is thought to represent a public network run by an operator. The clients pay to the operator, have its credentials, and trust it to provide the IP forwarding service. The clients do not trust each other to behave correctly; any other client node must be considered able to send falsified ND and RD messages.
该模型被认为代表了由运营商运营的公共网络。客户向运营商付费，拥有其凭证，并信任运营商提供IP转发服务。客户不信任对方的行为是否正确；任何其他客户端节点都必须能够发送伪造的ND和RD消息。
3. A model where the nodes do not directly trust each other at the IP layer. This model is considered suitable for e.g., ad hoc networks.
3. 节点在IP层不直接相互信任的模型。该模型被认为适用于例如adhoc网络。
Note that even though the nodes are assumed to trust each other in the first trust model (corporate intranet), it is still desirable to limit the extent of damage a node is able to inflict to the local network if it becomes compromised.
注意，即使在第一信任模型（公司内部网）中假设节点彼此信任，仍然希望限制节点在受到损害时能够对本地网络造成的损害程度。
In a corporate intranet or other network where all nodes are under one administrative domain, the nodes may be considered to be reliable at the IP layer. Thus, once a node has been accepted to be a member of the network, it is assumed to behave in a trustworthy manner.
在所有节点都位于一个管理域下的公司内部网或其他网络中，可以认为节点在IP层是可靠的。因此，一旦节点被接受为网络的成员，就假定其以可信的方式行为。
Under this model, if the network is physically secured or if the link layer is cryptographically secured to the extent needed, no other protection is needed for IPv6 ND, as long as none of the nodes become compromised. For example, a wired LAN with 802.1x access control or
在这种模式下，如果网络在物理上是安全的，或者如果链路层在需要的程度上是加密安全的，那么IPv6 ND就不需要其他保护，只要没有节点受到危害。例如，具有802.1x访问控制或
a WLAN with 802.11i Robust Security Network (RSN) with AES encryption may be considered secure enough, requiring no further protection under this trust model. On the other hand, ND security would add protection depth even under this model (see below). Furthermore, one should not overestimate the level of security any L2 mechanism is able to provide.
具有802.11i健壮安全网络（RSN）和AES加密的WLAN可能被认为足够安全，在这种信任模型下不需要进一步保护。另一方面，即使在这种模式下，ND安全性也会增加保护深度（见下文）。此外，我们不应该高估任何二语机制能够提供的安全级别。
If the network is not physically secured and the link layer does not have cryptographic protection, or if the cryptographic protection is not secure enough (e.g., just 802.1x and not 802.11i in a WLAN), the nodes in the network may be vulnerable to some or all of the threats outlined in Section 4. In such a case some protection is desirable to secure ND. Providing such protection falls within the main initial focus of the SEND working group.
如果网络没有物理安全且链路层没有加密保护，或者如果加密保护不够安全（例如，WLAN中只有802.1x而不是802.11i），则网络中的节点可能容易受到第4节中概述的部分或全部威胁的攻击。在这种情况下，需要一些保护来保护ND。提供这种保护属于SEND工作组最初的主要重点。
Furthermore, it is desirable to limit the amount of potential damage in the case a node becomes compromised. For example, it might still be acceptable that a compromised node is able to launch a denial-of-service attack, but it is undesirable if it is able to hijack existing connections or establish man-in-the-middle attacks on new connections.
此外，希望在节点受损的情况下限制潜在损害的量。例如，受损节点能够发起拒绝服务攻击可能仍然是可以接受的，但如果它能够劫持现有连接或在新连接上建立中间人攻击则是不可取的。
As mentioned in Section 2, one possibility to secure ND would be to use IPsec AH with symmetric shared keys, known by all trusted nodes and by no outsiders. However, none of the currently standardized automatic key distribution mechanisms work right out-of-the-box. For further details, see [8]. Furthermore, using a shared key would not protect against a compromised node.
如第2节所述，保护ND的一种可能性是使用IPsec AH和对称共享密钥，所有受信任节点都知道，没有外人知道。然而，目前没有一种标准化的自动密钥分配机制是开箱即用的。有关更多详细信息，请参见[8]。此外，使用共享密钥不会保护节点免受危害。
More specifically, the currently used key agreement protocol, IKE, suffers from a chicken-and-egg problem [8]: one needs an IP address to run IKE, IKE is needed to establish IPsec SAs, and IPsec SAs are required to configure an IP address. Furthermore, there does not seem to be any easy and efficient ways of securing ND with symmetric key cryptography. The required number of security associations would be very large [9].
更具体地说，当前使用的密钥协议IKE存在鸡和蛋的问题[8]：运行IKE需要IP地址，建立IPsec SAs需要IKE，配置IP地址需要IPsec SAs。此外，似乎没有任何简单有效的方法可以使用对称密钥加密来保护ND。所需的安全关联数量将非常多[9]。
As an example, one possible approach to overcome this limitation is to use public key cryptography, and to secure ND packets directly with public key signatures.
例如，克服此限制的一种可能方法是使用公钥加密，并直接使用公钥签名保护ND数据包。
A scenario where an operator runs a public wireless (or wireline) network, e.g., a WLAN in a hotel, airport, or cafe, has a different trust model. Here the nodes may be assumed to trust the operator to provide the IP forwarding service in a trustworthy manner, and not to disrupt or misdirect the clients' traffic. However, the clients do
运营商运行公共无线（或有线）网络（例如，酒店、机场或咖啡馆中的WLAN）的场景具有不同的信任模型。这里，可以假设节点信任运营商以可信的方式提供IP转发服务，并且不会中断或误导客户端的流量。然而，客户确实如此
not usually trust each other. Typically the router (or routers) fall under one administrative domain, and the client nodes each fall under their own administrative domain.
通常不互相信任。通常，路由器属于一个管理域，客户端节点属于各自的管理域。
It is assumed that under this scenario the operator authenticates all the client nodes, or at least requires authorization in the form of a payment. At the same time, the clients must be able to authenticate the router and make sure that it belongs to the trusted operator. Depending on the link-layer authentication protocol and its deployment, the link layer may take care of the mutual authentication. The link-layer authentication protocol may allow the client nodes and the access router to create a security association. Note that there exist authentication protocols, e.g., particular EAP methods, that do not create secure keying material and/or do not allow the client to authenticate the network.
假设在这种情况下，运营商对所有客户机节点进行身份验证，或者至少需要支付形式的授权。同时，客户端必须能够对路由器进行身份验证，并确保它属于受信任的运营商。根据链路层认证协议及其部署，链路层可能负责相互认证。链路层认证协议可允许客户端节点和接入路由器创建安全关联。注意，存在不创建安全密钥材料和/或不允许客户端对网络进行身份验证的身份验证协议，例如特定EAP方法。
In this scenario, cryptographically securing the link layer does not necessarily block all the threats outlined in Section 4; see the individual threat descriptions. Specifically, even in 802.11i RSN with AES encryption the broadcast and multicast keys are shared between all nodes. Even if the underlying link layer was aware of all the nodes' link-layer addresses, and were able to check that no source addresses were falsified, there would still be vulnerabilities.
在这种情况下，以加密方式保护链路层不一定会阻止第4节中概述的所有威胁；请参见个人威胁描述。具体而言，即使在使用AES加密的802.11i RSN中，广播和多播密钥也在所有节点之间共享。即使底层链路层知道所有节点的链路层地址，并且能够检查源地址是否被伪造，仍然存在漏洞。
One should also note that link-layer security and IP topology do not necessarily match. For example, the wireless access point may not be visible at the IP layer at all. In such a case cryptographic security at the link layer does not provide any security with regard to IP Neighbor Discovery.
还应注意，链路层安全性和IP拓扑不一定匹配。例如，无线接入点在IP层可能根本不可见。在这种情况下，链路层的加密安全性不提供任何关于IP邻居发现的安全性。
There seems to be at least two ways to bring in security into this scenario. One possibility seems to be to enforce strong security between the clients and the access router, and make the access router aware of the IP and link-layer protocol details. That is, the router would check ICMPv6 packet contents, and filter packets that contain information which does not match the network topology. The other possibly acceptable way is to add cryptographic protection to the ICMPv6 packets carrying ND messages.
似乎至少有两种方法可以将安全性引入到这个场景中。一种可能性似乎是在客户端和访问路由器之间实施强大的安全性，并使访问路由器了解IP和链路层协议的详细信息。也就是说，路由器将检查ICMPv6数据包内容，并过滤包含与网络拓扑不匹配的信息的数据包。另一种可能可接受的方法是向承载ND消息的ICMPv6数据包添加加密保护。
In an ad hoc network, or any network without a trusted operator, none of the nodes trust each other. In a generic case, the nodes meet each other for the first time, and there are no guarantees that the other nodes would behave correctly at the IP layer. They must be considered suspicious to send falsified ND and RD messages.
在自组织网络或任何没有可信操作员的网络中，节点之间都不相互信任。在一般情况下，节点第一次相遇，无法保证其他节点在IP层的行为正常。如果他们发送伪造的ND和RD信息，必须被视为可疑。
Since there are no a priori trust relationships, the nodes cannot rely on traditional authentication. That is, the traditional authentication protocols rely on some existing relationship between the parties. The relationship may be direct or indirect. The indirect case relies on one or more trusted third parties, thereby creating a chain of trust relationships between the parties.
由于不存在先验信任关系，节点不能依赖于传统的身份验证。也就是说，传统的认证协议依赖于双方之间存在的某种关系。这种关系可以是直接的，也可以是间接的。间接案件依赖于一个或多个受信任的第三方，从而在各方之间建立了信任关系链。
In the generic ad hoc network case, there are no trusted third parties, nor do the parties trust each other directly. Thus, the traditional means of first authenticating and then authorizing the users (to use their addresses) do not work.
在一般的adhoc网络中，不存在可信任的第三方，也不存在相互直接信任的第三方。因此，传统的先认证然后授权用户（使用他们的地址）的方法不起作用。
It is still possible to use self-identifying mechanisms, such as Cryptographically Generated Addresses (CGA) [7]. These allow the nodes to ensure that they are talking to the same nodes (as before) at all times, and that each of the nodes indeed have generated their IP address themselves and not "stolen" someone else's address. It may also be possible to learn the identities of any routers using various kinds of heuristics, such as testing the node's ability to convey cryptographically protected traffic towards a known and trusted node somewhere in the Internet. Methods like these seem to mitigate (but not completely block) some of the attacks outlined in the next section.
仍然可以使用自识别机制，如加密生成地址（CGA）[7]。这些允许节点确保它们始终与相同的节点（与以前一样）通信，并且每个节点确实自己生成了它们的IP地址，而不是“窃取”其他人的地址。还可以使用各种试探法来学习任何路由器的身份，例如测试节点向因特网某处的已知和可信节点传送受密码保护的流量的能力。类似的方法似乎可以减轻（但不能完全阻止）下一节中概述的一些攻击。
In this section we discuss threats against the current IPv6 Neighbor Discovery mechanisms, when used in multi-access links. The threats are discussed in the light of the trust models defined in the previous section.
在本节中，我们将讨论当前IPv6邻居发现机制在多址链路中使用时面临的威胁。这些威胁将根据前一节中定义的信任模型进行讨论。
There are three general types of threats:
威胁一般有三种类型：
1. Redirect attacks in which a malicious node redirects packets away from the last hop router or other legitimate receiver to another node on the link.
1. 重定向攻击，其中恶意节点将数据包从最后一跳路由器或其他合法接收器重定向到链路上的另一个节点。
2. Denial-of-Service (DoS) attacks, in which a malicious node prevents communication between the node under attack and all other nodes, or a specific destination address.
2. 拒绝服务（DoS）攻击，其中恶意节点阻止受攻击节点与所有其他节点或特定目标地址之间的通信。
3. Flooding Denial-of-Service (DoS) attacks, in which a malicious node redirects other hosts' traffic to a victim node, and thereby creates a flood of bogus traffic at the victim host.
3. 洪泛拒绝服务（DoS）攻击，其中恶意节点将其他主机的流量重定向到受害节点，从而在受害主机上产生大量虚假流量。
A redirect attack can be used for DoS purposes by having the node to which the packets were redirected drop the packets, either completely or by selectively forwarding some of them and not others.
重定向攻击可用于DoS目的，方法是让数据包重定向到的节点完全丢弃数据包，或者有选择地转发其中一些数据包而不是其他数据包。
The subsections below identify specific threats for IPv6 network access. The threat descriptions are organized in three subsections. We first consider threats that do not involve routers or routing information. We next consider threats that do involve routers or routing information. Finally, we consider replay attacks and threats that are remotely exploitable. All threats are discussed in the light of the trust models.
下面的小节确定了IPv6网络访问的特定威胁。威胁描述分为三个小节。我们首先考虑不涉及路由器或路由信息的威胁。接下来我们考虑涉及路由器或路由信息的威胁。最后，我们考虑重放攻击和远程可利用的威胁。根据信任模型讨论了所有威胁。
In this section we discuss attacks against "pure" Neighbor Discovery functions, i.e., Neighbor Discovery (ND), Neighbor Unreachability Detection (NUD), and Duplicate Address Detection (DAD) in Address Autoconfiguration.
在本节中，我们将讨论针对“纯”邻居发现功能的攻击，即地址自动配置中的邻居发现（ND）、邻居不可达性检测（NUD）和重复地址检测（DAD）。
Nodes on the link use Neighbor Solicitation and Advertisement messages to create bindings between IP addresses and MAC addresses. More specifically, there are two cases when a node creates neighbor cache entries upon receiving Solicitations:
链路上的节点使用邻居请求和播发消息在IP地址和MAC地址之间创建绑定。更具体地说，当节点在接收请求时创建邻居缓存项时，有两种情况：
1. A node receives a Neighbor Solicitation that contains a node's address. The node can use that to populate its neighbor cache. This is basically a performance optimization, and a SHOULD in the base documents.
1. 节点接收包含节点地址的邻居请求。节点可以使用它来填充其邻居缓存。这基本上是一种性能优化，应该在基本文档中包含。
2. During Duplicate Address Detection (DAD), if a node receives a Neighbor Solicitation for the same address it is soliciting for, the situation is considered a collision, and the node must cease to solicit for the said address.
2. 在重复地址检测（DAD）期间，如果节点接收到对其请求的相同地址的邻居请求，则该情况被视为冲突，并且该节点必须停止请求所述地址。
In contrast to solicitation messages that create or modify state only in these specific occasions, state is usually modified whenever a node receives a solicited-for advertisement message.
与仅在这些特定情况下创建或修改状态的请求消息不同，每当节点接收到请求的广告消息时，通常会修改状态。
An attacking node can cause packets for legitimate nodes, both hosts and routers, to be sent to some other link-layer address. This can be done by either sending a Neighbor Solicitation with a different source link-layer address option, or sending a Neighbor Advertisement with a different target link-layer address option.
攻击节点可导致合法节点（主机和路由器）的数据包被发送到其他链路层地址。这可以通过使用不同的源链路层地址选项发送邻居请求，或者使用不同的目标链路层地址选项发送邻居公告来实现。
The attacks succeed because the Neighbor Cache entry with the new link-layer address overwrites the old. If the spoofed link-layer address is a valid one, as long as the attacker responds to the unicast Neighbor Solicitation messages sent as part of the Neighbor Unreachability Detection, packets will continue to be redirected. This is a redirect/DoS attack.
攻击之所以成功，是因为具有新链路层地址的邻居缓存项覆盖了旧的。如果伪造的链路层地址有效，只要攻击者响应作为邻居不可访问性检测一部分发送的单播邻居请求消息，数据包将继续被重定向。这是一种重定向/拒绝服务攻击。
This mechanism can be used for a DoS attack by specifying an unused link-layer address; however, this DoS attack is of limited duration since after 30-50 seconds (with default timer values) the Neighbor Unreachability Detection mechanism will discard the bad link-layer address and multicast anew to discover the link-layer address. As a consequence, the attacker will need to keep responding with fabricated link-layer addresses if it wants to maintain the attack beyond the timeout.
通过指定未使用的链路层地址，该机制可用于DoS攻击；但是，此DoS攻击的持续时间有限，因为在30-50秒（使用默认计时器值）后，邻居不可达性检测机制将丢弃坏的链路层地址，并重新进行多播以发现链路层地址。因此，如果攻击者希望在超时后继续攻击，则需要继续使用伪造的链路层地址进行响应。
The threat discussed in this subsection involves Neighbor Solicitation and Neighbor Advertisement messages.
本小节讨论的威胁涉及邻居请求和邻居广告消息。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes are exposed to this threat. In the case where just the operator is trusted, the nodes may rely on the operator to certify the address bindings for other local nodes. From the security point of view, the router may act as a trusted proxy for the other nodes. This assumes that the router can be trusted to represent correctly the other nodes on the link. In the ad hoc network case, and optionally in the other two cases, the nodes may use self certifying techniques (e.g., CGA) to authorize address bindings.
如果对链接的访问仅限于受信任的节点，则不必担心此攻击；如果一个受信任的节点受到威胁，其他节点就会暴露在这种威胁之下。在仅信任操作员的情况下，节点可以依赖操作员来验证其他本地节点的地址绑定。从安全角度来看，路由器可以充当其他节点的可信代理。这假设路由器可以被信任以正确表示链路上的其他节点。在自组织网络情况下，并且可选地在另外两种情况下，节点可以使用自认证技术（例如，CGA）来授权地址绑定。
Additionally, some implementations log an error and refuse to accept ND overwrites, instead requiring the old entry to time out first.
此外，一些实现记录错误并拒绝接受ND覆盖，而是要求旧条目先超时。
Nodes on the link monitor the reachability of local destinations and routers with the Neighbor Unreachability Detection procedure [2]. Normally the nodes rely on upper-layer information to determine whether peer nodes are still reachable. However, if there is a sufficiently long delay on upper-layer traffic, or if the node stops receiving replies from a peer node, the NUD procedure is invoked. The node sends a targeted NS to the peer node. If the peer is still reachable, it will reply with a NA. However, if the soliciting node receives no reply, it tries a few more times, eventually deleting the neighbor cache entry. If needed, this triggers the standard address resolution protocol to learn the new MAC address. No higher level traffic can proceed if this procedure flushes out neighbor cache entries after determining (perhaps incorrectly) that the peer is not reachable.
链路上的节点使用邻居不可达性检测程序监控本地目的地和路由器的可达性[2]。通常，节点依赖上层信息来确定对等节点是否仍然可以到达。但是，如果上层通信有足够长的延迟，或者如果节点停止接收来自对等节点的响应，则会调用NUD过程。节点向对等节点发送目标NS。如果对等方仍然可以访问，它将使用NA进行回复。但是，如果请求节点没有收到回复，它会再尝试几次，最终删除邻居缓存项。如果需要，这会触发标准地址解析协议来学习新的MAC地址。如果此过程在确定（可能错误地）无法访问对等方后清除邻居缓存项，则无法继续进行更高级别的通信。
A malicious node may keep sending fabricated NAs in response to NUD NS messages. Unless the NA messages are somehow protected, the attacker may be able to extend the attack for a long time using this technique. The actual consequences depend on why the node become
恶意节点可能会继续发送伪造的NAs以响应NUD NS消息。除非NA消息受到某种保护，否则攻击者可能会使用此技术将攻击延长很长时间。实际后果取决于节点变为
unreachable for the first place, and how the target node would behave if it knew that the node has become unreachable. This is a DoS attack.
首先是不可访问的，以及如果目标节点知道该节点已变得不可访问，该节点将如何运行。这是DoS攻击。
The threat discussed in this subsection involves Neighbor Solicitation/Advertisement messages.
本小节讨论的威胁涉及邻居请求/广告消息。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes are exposed to this DoS threat. Under the two other trust models, a solution requires that the node performing NUD is able to make a distinction between genuine and fabricated NA responses.
如果对链接的访问仅限于受信任的节点，则不必担心此攻击；如果一个受信任的节点受到威胁，其他节点将暴露于此DoS威胁。在其他两种信任模型下，解决方案要求执行NUD的节点能够区分真实和伪造的NA响应。
In networks where the entering hosts obtain their addresses using stateless address autoconfiguration [3], an attacking node could launch a DoS attack by responding to every duplicate address detection attempt made by an entering host. If the attacker claims the address, then the host will never be able to obtain an address. The attacker can claim the address in two ways: it can either reply with an NS, simulating that it is performing DAD, too, or it can reply with an NA, simulating that it has already taken the address into use. This threat was identified in RFC 2462 [3]. The issue may also be present when other types of address configuration is used, i.e., whenever DAD is invoked prior to actually configuring the suggested address. This is a DoS attack.
在进入主机使用无状态地址自动配置获取其地址的网络中[3]，攻击节点可以通过响应进入主机的每次重复地址检测尝试来发起DoS攻击。如果攻击者声称该地址，则主机将永远无法获取该地址。攻击者可以通过两种方式声明该地址：它可以使用NS进行回复，模拟它也在执行DAD，也可以使用NA进行回复，模拟它已经使用了该地址。该威胁已在RFC 2462[3]中确定。当使用其他类型的地址配置时，即在实际配置建议的地址之前调用DAD时，也可能存在此问题。这是DoS攻击。
The threat discussed in this subsection involves Neighbor Solicitation/Advertisement messages.
本小节讨论的威胁涉及邻居请求/广告消息。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes become exposed to this DoS threat. Under the two other trust models, a solution requires that the node performing DAD is able to verify whether the sender of the NA response is authorized to use the given IP address or not. In the trusted operator case, the operator may act as an authorizer, keeping track of allocated addresses and making sure that no node has allocated more than a few (hundreds of) addresses. On the other hand, it may be detrimental to adopt such a practice, since there may be situations where it is desirable for one node to have a large number of addresses, e.g., creating a separate address per TCP connection, or when running an ND proxy. Thus, it may be inappropriate to suggest that ISPs could control how many addresses a legitimate host can have; the discussion above must be considered only as examples, as stated in the beginning of this document.
如果对链接的访问仅限于受信任的节点，则不必担心此攻击；如果一个受信任的节点受到威胁，其他节点将暴露于此DoS威胁。在另外两种信任模型下，解决方案要求执行DAD的节点能够验证NA响应的发送方是否有权使用给定的IP地址。在受信任的运营商情况下，运营商可以充当授权人，跟踪分配的地址，并确保没有节点分配的地址超过几个（数百个）。另一方面，采用这种做法可能有害，因为可能存在一个节点需要有大量地址的情况，例如，每个TCP连接创建一个单独的地址，或者在运行ND代理时。因此，建议ISP控制一个合法主机可以拥有多少地址可能是不合适的；如本文件开头所述，上述讨论只能作为示例考虑。
In the ad hoc network case one may want to structure the addresses in such a way that self authorization is possible.
在adhoc网络的情况下，人们可能希望以能够进行自我授权的方式来构造地址。
In this section we consider threats pertinent to router discovery or other router assisted/related mechanisms.
在这一节中，我们考虑与路由器发现相关的威胁或其他路由器辅助/相关机制。
This threat was identified in [5] but was classified as a general IPv6 threat and not specific to Mobile IPv6. It is also identified in RFC 2461 [2]. This threat is a redirect/DoS attack.
该威胁已在[5]中确定，但被归类为一般IPv6威胁，而非特定于移动IPv6。RFC 2461[2]中也对其进行了识别。此威胁是重定向/拒绝服务攻击。
An attacking node on the same subnet as a host attempting to discover a legitimate last hop router could masquerade as an IPv6 last hop router by multicasting legitimate-looking IPv6 Router Advertisements or unicasting Router Advertisements in response to multicast Router Advertisement Solicitations from the entering host. If the entering host selects the attacker as its default router, the attacker has the opportunity to siphon off traffic from the host, or mount a man-in-the-middle attack. The attacker could ensure that the entering host selected itself as the default router by multicasting periodic Router Advertisements for the real last hop router having a lifetime of zero. This may spoof the entering host into believing that the real access router is not willing to take any traffic. Once accepted as a legitimate router, the attacker could send Redirect messages to hosts, then disappear, thus covering its tracks.
与主机位于同一子网上的攻击节点试图发现合法的最后一跳路由器，可通过多播合法外观的IPv6路由器播发或单播路由器播发来伪装为IPv6最后一跳路由器，以响应来自进入主机的多播路由器播发请求。如果进入的主机选择攻击者作为其默认路由器，则攻击者有机会从主机中分流流量，或发起中间人攻击。攻击者可以通过对生存期为零的真实最后一跳路由器进行定期多播路由器播发，确保进入主机选择自己作为默认路由器。这可能会欺骗进入的主机，使其相信真正的访问路由器不愿意接受任何流量。一旦被接受为合法路由器，攻击者就可以向主机发送重定向消息，然后消失，从而掩盖其踪迹。
This threat is partially mitigated in RFC 2462; in Section 5.5.3 of RFC 2462 it is required that if the advertised prefix lifetime is less than 2 hours and less than the stored lifetime, the stored lifetime is not reduced unless the packet was authenticated. However, the default router selection procedure, as defined in Section 6.3.6. of RFC 2461, does not contain such a rule.
RFC 2462部分缓解了这一威胁；在RFC 2462第5.5.3节中，要求如果公布的前缀生存期小于2小时且小于存储的生存期，则存储的生存期不得缩短，除非对数据包进行了身份验证。但是，默认路由器选择程序，如第6.3.6节所定义。RFC 2461中，不包含此类规则。
The threat discussed in this subsection involves Router Advertisement and Router Advertisement Solicitation messages.
本小节讨论的威胁涉及路由器广告和路由器广告请求消息。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes are exposed to this threat. However, the threat can be partially mitigated through a number of means, for example, by configuring the nodes to prefer existing routers over new ones. Note that this approach does not necessarily prevent one from introducing new routers into the network, depending on the details of implementation. At minimum, it just makes the existing nodes to prefer the existing routers over the new ones.
如果对链接的访问仅限于受信任的节点，则不必担心此攻击；如果一个受信任的节点受到威胁，其他节点就会暴露在这种威胁之下。然而，可以通过多种方法部分缓解威胁，例如，通过配置节点使其更喜欢现有路由器而不是新路由器。请注意，这种方法并不一定会阻止用户将新路由器引入网络，具体取决于实现的细节。至少，它只会使现有节点更喜欢现有路由器而不是新路由器。
In the case of a trusted operator, there must be a means for the nodes to make a distinction between trustworthy routers, run by the operator, and other nodes. There are currently no widely accepted solutions for the ad hoc network case, and the issue remains as a research question.
对于可信的运营商，节点必须有一种方法来区分运营商运行的可信路由器和其他节点。目前还没有被广泛接受的解决方案，这个问题仍然是一个研究问题。
In this attack, an attacker 'kills' the default router(s), thereby making the nodes on the link to assume that all nodes are local. In Section 5.2 of RFC 2461 [2] it is stated that "[if] the Default Router List is empty, the sender assumes that the destination is on-link." Thus, if the attacker is able to make a node to believe that there are no default routers on the link, the node will try to send the packets directly, using Neighbor Discovery. After that the attacker can use NS/NA spoofing even against off-link destinations.
在此攻击中，攻击者“杀死”默认路由器，从而使链路上的节点假定所有节点都是本地节点。在RFC 2461[2]的第5.2节中，指出“[如果]默认路由器列表为空，发送方假设目的地在链路上。”因此，如果攻击者能够使节点相信链路上没有默认路由器，则节点将尝试使用邻居发现直接发送包。在此之后，攻击者甚至可以对断开链接的目的地使用NS/NA欺骗。
There are a few identified ways how an attacker can 'kill' the default router(s). One is to launch a classic DoS attack against the router so that it does not appear responsive any more. The other is to send a spoofed Router Advertisement with a zero Router Lifetime (see Section 6.3.4 of RFC 2461 [2]). However, see also the discussion in Section 4.2.1, above.
攻击者可以通过几种方式“杀死”默认路由器。一种是对路由器发起典型的DoS攻击，这样它就不会出现任何响应。另一种是发送路由器寿命为零的伪造路由器广告（见RFC 2461[2]第6.3.4节）。但是，另见上文第4.2.1节中的讨论。
This attack is mainly a DoS attack, but it could also be used to redirect traffic to the next better router, which may be the attacker.
此攻击主要是DoS攻击，但也可用于将流量重定向到下一个更好的路由器，该路由器可能是攻击者。
The threat discussed in this subsection involves Router Advertisement messages. One variant of this threat may be possible by overloading the router, without using any ND/RD messages.
本小节讨论的威胁涉及路由器广告消息。这种威胁的一种变体可能是路由器过载，而不使用任何ND/RD消息。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes are exposed to this threat. In the case of a trusted operator, there must be a means for the nodes to make a distinction between trustworthy routers, run by the operator, and other nodes. That protects against spoofed Router Advertisements, but it does not protect against router overloading. There are currently no widely accepted solutions for the ad hoc network case, and the issue remains as a research question.
如果对链接的访问仅限于受信任的节点，则不必担心此攻击；如果一个受信任的节点受到威胁，其他节点就会暴露在这种威胁之下。对于可信的运营商，节点必须有一种方法来区分运营商运行的可信路由器和其他节点。这可以防止伪造的路由器广告，但不能防止路由器过载。目前还没有被广泛接受的解决方案，这个问题仍然是一个研究问题。
Thanks to Alain Durand for identifying this threat.
感谢阿兰·杜兰德发现了这一威胁。
In this attack, a router that previously was trusted is compromised. The attacks available are the same as those discussed in Section 4.2.1. This is a redirect/DoS attack.
在这次攻击中，以前受信任的路由器受到威胁。可用攻击与第4.2.1节中讨论的攻击相同。这是一种重定向/拒绝服务攻击。
There are currently no known solutions for any of the presented three trust models. On the other hand, on a multi-router link one could imagine a solution involving revocation of router rights. The situation remains as a research question.
目前，对于所提出的三种信任模型中的任何一种，都没有已知的解决方案。另一方面，在多路由器链路上，可以想象一种涉及撤销路由器权限的解决方案。这种情况仍然是一个研究问题。
The Redirect message can be used to send packets for a given destination to any link-layer address on the link. The attacker uses the link-local address of the current first-hop router in order to send a Redirect message to a legitimate host. Since the host identifies the message by the link-local address as coming from its first hop router, it accepts the Redirect. As long as the attacker responds to Neighbor Unreachability Detection probes to the link-layer address, the Redirect will remain in effect. This is a redirect/DoS attack.
重定向消息可用于将给定目的地的数据包发送到链路上的任何链路层地址。攻击者使用当前第一跳路由器的链路本地地址向合法主机发送重定向消息。由于主机通过链路本地地址将消息标识为来自其第一跳路由器，因此它接受重定向。只要攻击者对链路层地址的邻居不可达性检测探测作出响应，重定向将保持有效。这是一种重定向/拒绝服务攻击。
The threat discussed in this subsection involves Redirect messages.
本小节讨论的威胁涉及重定向消息。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes are exposed to this threat. In the case of a trusted operator, there must be a means for the nodes to make a distinction between trustworthy routers, run by the operator, and other nodes. There are currently no widely accepted solutions for the ad hoc network case, and the issue remains as a research question.
如果对链接的访问仅限于受信任的节点，则不必担心此攻击；如果一个受信任的节点受到威胁，其他节点就会暴露在这种威胁之下。对于可信的运营商，节点必须有一种方法来区分运营商运行的可信路由器和其他节点。目前还没有被广泛接受的解决方案，这个问题仍然是一个研究问题。
An attacking node can send a Router Advertisement message specifying that some prefix of arbitrary length is on-link. If a sending host thinks the prefix is on-link, it will never send a packet for that prefix to the router. Instead, the host will try to perform address resolution by sending Neighbor Solicitations, but the Neighbor Solicitations will not result in a response, denying service to the attacked host. This is a DoS attack.
攻击节点可以发送路由器广告消息，指定链路上存在任意长度的前缀。如果发送主机认为前缀在链路上，它将永远不会向路由器发送该前缀的数据包。相反，主机将尝试通过发送邻居请求来执行地址解析，但邻居请求不会导致响应，从而拒绝向受攻击主机提供服务。这是DoS攻击。
The attacker can use an arbitrary lifetime on the bogus prefix advertisement. If the lifetime is infinity, the sending host will be denied service until it loses the state in its prefix list e.g., by rebooting, or after the same prefix is advertised with a zero
攻击者可以在虚假前缀广告上使用任意生存期。如果生存期是无限的，发送主机将被拒绝服务，直到它丢失其前缀列表中的状态，例如，通过重新启动，或在相同前缀以零播发之后
lifetime. The attack could also be perpetrated selectively for packets destined to a particular prefix by using 128 bit prefixes, i.e., full addresses.
一生通过使用128位前缀（即完整地址），也可以有选择地对以特定前缀为目的地的数据包实施攻击。
Additionally, the attack may cause a denial-of-service by flooding the routing table of the node. The node would not be able to differentiate between legitimate on-link prefixes and bogus ones when making decisions as to which ones are kept and which are dropped. Inherently, any finite system must have some point at which new received prefixes must be dropped rather than accepted.
此外，该攻击可能会通过淹没节点的路由表而导致拒绝服务。在决定保留哪些前缀和删除哪些前缀时，节点将无法区分合法的链接前缀和伪造的链接前缀。从本质上讲，任何有限系统都必须有一个点，在这个点上，新接收的前缀必须被丢弃，而不是被接受。
This attack can be extended into a redirect attack if the attacker replies to the Neighbor Solicitations with spoofed Neighbor Advertisements, thereby luring the nodes on the link to send the traffic to it or to some other node.
如果攻击者使用伪造的邻居广告回复邻居请求，从而诱使链路上的节点将流量发送到该节点或其他节点，则此攻击可以扩展为重定向攻击。
This threat involves Router Advertisement message. The extended attack combines the attack defined in Section 4.1.1 and in this section, and involves Neighbor Solicitation, Neighbor Advertisement, and Router Advertisement messages.
此威胁涉及路由器广告消息。扩展攻击结合了第4.1.1节和本节中定义的攻击，涉及邻居请求、邻居广告和路由器广告消息。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised, the other nodes are exposed to this threat. In the case of a trusted operator, there must be a means for the nodes to make a distinction between trustworthy routers, run by the operator, and other nodes. There are currently no known solutions for the ad hoc network case, and the issue remains as a research question.
如果对链接的访问仅限于受信任的节点，则不必担心此攻击；如果一个受信任的节点受到威胁，其他节点就会暴露在这种威胁之下。对于可信的运营商，节点必须有一种方法来区分运营商运行的可信路由器和其他节点。目前还没有针对adhoc网络的已知解决方案，该问题仍然是一个研究问题。
As an example, one possible approach to limiting the damage of this attack is to require advertised on-link prefixes be /64s (otherwise it's easy to advertise something short like 0/0 and this attack is very easy).
例如，限制此攻击损害的一种可能方法是要求在链接前缀上公布be/64s（否则很容易公布类似于0/0的简短内容，并且此攻击非常容易）。
An attacking node can send a Router Advertisement message specifying an invalid subnet prefix to be used by a host for address autoconfiguration. A host executing the address autoconfiguration algorithm uses the advertised prefix to construct an address [3], even though that address is not valid for the subnet. As a result, return packets never reach the host because the host's source address is invalid. This is a DoS attack.
攻击节点可以发送路由器公告消息，指定主机用于地址自动配置的无效子网前缀。执行地址自动配置算法的主机使用播发前缀来构造地址[3]，即使该地址对于子网无效。因此，返回数据包永远不会到达主机，因为主机的源地址无效。这是DoS攻击。
This attack has the potential to propagate beyond the immediate attacked host if the attacked host performs a dynamic update to the DNS based on the bogus constructed address. DNS update [4] causes the bogus address to be added to the host's address record in the
如果受攻击主机基于伪造的构造地址对DNS执行动态更新，则此攻击有可能传播到直接受攻击主机之外。DNS更新[4]会将伪造地址添加到主机的地址记录中
DNS. Should this occur, applications performing name resolution through the DNS obtain the bogus address and an attempt to contact the host fails. However, well-written applications will fall back and try the other addresses registered in DNS, which may be correct.
DNS。如果出现这种情况，则通过DNS执行名称解析的应用程序将获得虚假地址，并且尝试联系主机失败。但是，编写良好的应用程序将退回并尝试在DNS中注册的其他地址，这可能是正确的。
A distributed attacker can make the attack more severe by creating a falsified reverse DNS entry that matches with the dynamic DNS entry created by the target. Consider an attacker who has legitimate access to a prefix <ATTACK_PRFX>, and a target who has an interface ID <TARGET_IID>. The attacker creates a reverse DNS entry for <ATTACK_PRFX>:<TARGET_IID>, pointing to the real domain name of the target, e.g., "secure.target.com". Next the attacker advertises the <ATTACK_PRFX> prefix at the target's link. The target will create an address <ATTACK_PRFX>:<TARGET_IID>, and update its DNS entry so that "secure.target.com" points to <ATTACK_PRFX>:<TARGET_IID>.
分布式攻击者可以通过创建与目标创建的动态DNS条目相匹配的伪造反向DNS条目，使攻击更加严重。考虑攻击者可以合法访问前缀< AtaskHPrfx>，以及一个具有接口ID < TalkTyIID>的目标。攻击者为<ATTACK_PRFX>：<TARGET_IID>创建反向DNS条目，指向目标的真实域名，例如“secure.TARGET.com”。接下来，攻击者在目标链接上播发<ATTACK_PRFX>前缀。目标将创建一个地址<ATTACK\u PRFX>：<target\u IID>，并更新其DNS条目，以便“secure.target.com”指向<ATTACK\u PRFX>：<target\u IID>。
At this point "secure.target.com" points to <ATTACK_PRFX>:<TARGET_IID>, and <ATTACK_PRFX>:<TARGET_IID> points to "secure.target.com". This threat is mitigated by the fact that the attacker can be traced since the owner of the <ATTACK_PRFX> is available at the registries.
此时，“secure.target.com”指向<ATTACK\u PRFX>：<target\u IID>，<ATTACK\u PRFX>：<target\u IID>指向“secure.target.com”。由于<ATTACK_PRFX>的所有者可以在注册表中找到，因此攻击者可以被追踪，这一事实减轻了这种威胁。
There is also a related possibility of advertising a target prefix as an autoconfiguration prefix on a busy link, and then have all nodes on this link try to communicate to the external world with this address. If the local router doesn't have ingress filtering on, then the target link may get a large number of replies for those initial communication attempts.
还有一种相关的可能性，即在繁忙链路上宣传目标前缀作为自动配置前缀，然后让此链路上的所有节点尝试使用此地址与外部世界通信。如果本地路由器未启用入口过滤，则目标链路可能会收到大量针对这些初始通信尝试的回复。
The basic threat discussed in this subsection involves Router Advertisement messages. The extended attack scenarios involve the DNS, too.
本小节讨论的基本威胁涉及路由器广告消息。扩展攻击场景也涉及DNS。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised the other nodes are exposed to this threat. In the case of a trusted operator, there must be a means for the nodes to make a distinction between trustworthy routers, run by the operator, and other nodes. There are currently no known solutions for the ad hoc network case, and the issue remains as a research question.
如果对链接的访问仅限于受信任的节点，则不必担心此攻击；如果一个受信任的节点受到威胁，其他节点将暴露于此威胁。对于可信的运营商，节点必须有一种方法来区分运营商运行的可信路由器和其他节点。目前还没有针对adhoc网络的已知解决方案，该问题仍然是一个研究问题。
IPv6 Router Advertisements contain a few parameters used by hosts when they send packets and to tell hosts whether or not they should perform stateful address configuration [2]. An attacking node could send out a valid-seeming Router Advertisement that duplicates the
IPv6路由器播发包含主机在发送数据包时使用的一些参数，用于告知主机是否应执行有状态地址配置[2]。攻击节点可能会发送一个看似有效的路由器广告，该广告会复制
Router Advertisement from the legitimate default router, except the included parameters are designed to disrupt legitimate traffic. This is a DoS attack.
来自合法默认路由器的路由器播发，但包含的参数旨在中断合法流量。这是DoS攻击。
Specific attacks include:
具体攻击包括：
1. The attacker includes a Current Hop Limit of one or another small number which the attacker knows will cause legitimate packets to be dropped before they reach their destination.
1. 攻击者包括一个或另一个小数字的当前跃点限制，攻击者知道这将导致合法数据包在到达目的地之前被丢弃。
2. The attacker implements a bogus DHCPv6 server or relay and the 'M' and/or 'O' flag is set, indicating that stateful address configuration and/or stateful configuration of other parameters should be done. The attacker is then in a position to answer the stateful configuration queries of a legitimate host with its own bogus replies.
2. 攻击者实施了一个伪造的DHCPv6服务器或中继，并设置了“M”和/或“O”标志，表示应进行有状态地址配置和/或其他参数的有状态配置。然后，攻击者可以使用自己的虚假回复回答合法主机的有状态配置查询。
The threat discussed in this subsection involves Router Advertisement messages.
本小节讨论的威胁涉及路由器广告消息。
Note that securing DHCP alone does not resolve this problem. There are two reasons for this. First, the attacker may prevent the node from using DHCP in the first place. Second, depending on the node's local configuration, the attacker may spoof the node to use a less trusted DHCP server. (The latter is a variant of the so called "bidding down" or "down grading" attacks.)
请注意，仅保护DHCP并不能解决此问题。这有两个原因。首先，攻击者可能会首先阻止节点使用DHCP。其次，根据节点的本地配置，攻击者可能会欺骗节点使用不太可信的DHCP服务器。（后者是所谓“降价”或“降级”攻击的变体。）
As an example, one possible approach to mitigate this threat is to ignore very small hop limits. The nodes could implement a configurable minimum hop limit, and ignore attempts to set it below said limit.
例如，缓解这种威胁的一种可能方法是忽略非常小的跃点限制。节点可以实现可配置的最小跳数限制，并忽略将其设置为低于所述限制的尝试。
This attack is not a concern if access to the link is restricted to trusted nodes; if a trusted node is compromised the other nodes are exposed to this treat. In the case of a trusted operator, there must be a means for the nodes to make a distinction between trustworthy routers, run by the operator, and other nodes. There are currently no known solutions for the ad hoc network case, and the issue remains a research question.
如果对链接的访问仅限于受信任的节点，则不必担心此攻击；如果一个受信任的节点受到损害，其他节点将暴露于这种情况。对于可信的运营商，节点必须有一种方法来区分运营商运行的可信路由器和其他节点。目前还没有针对adhoc网络的已知解决方案，该问题仍然是一个研究问题。
All Neighbor Discovery and Router Discovery messages are prone to replay attacks. That is, even if they were cryptographically protected so that their contents cannot be forged, an attacker would
所有邻居发现和路由器发现消息都容易受到重播攻击。也就是说，即使它们受到加密保护，因此其内容无法伪造，攻击者也会
be able to capture valid messages and replay them later. Thus, independent on what mechanism is selected to secure the messages, that mechanism must be protected against replay attacks.
能够捕获有效消息并在以后重播。因此，无论选择何种机制来保护消息，都必须保护该机制免受重播攻击。
Fortunately it is fairly easy to defeat most replay attacks. In request-reply exchanges, such as Solicitation-Advertisement, the request may contain a nonce that must appear also in the reply. Thus, old replies are not valid since they do not contain the right nonce. Correspondingly, stand-alone messages, such as unsolicited Advertisements or Redirect messages, may be protected with timestamps or counters. In practise, roughly synchronized clocks and timestamps seem to work well, since the recipients may keep track of the difference between the clocks of different nodes, and make sure that all new messages are newer than the last seen message.
幸运的是，击败大多数重播攻击相当容易。在请求-应答交换中，例如征求广告，请求可能包含一个必须出现在应答中的nonce。因此，旧答复无效，因为它们不包含正确的nonce。相应地，独立消息，例如未经请求的广告或重定向消息，可以使用时间戳或计数器进行保护。实际上，大致同步的时钟和时间戳似乎工作得很好，因为接收者可以跟踪不同节点的时钟之间的差异，并确保所有新消息都比最后看到的消息更新。
In this attack, the attacking node begins fabricating addresses with the subnet prefix and continuously sending packets to them. The last hop router is obligated to resolve these addresses by sending neighbor solicitation packets. A legitimate host attempting to enter the network may not be able to obtain Neighbor Discovery service from the last hop router as it will be already busy with sending other solicitations. This DoS attack is different from the others in that the attacker may be off-link. The resource being attacked in this case is the conceptual neighbor cache, which will be filled with attempts to resolve IPv6 addresses having a valid prefix but invalid suffix. This is a DoS attack.
在这种攻击中，攻击节点开始制造带有子网前缀的地址，并持续向它们发送数据包。最后一跳路由器有义务通过发送邻居请求包来解析这些地址。试图进入网络的合法主机可能无法从最后一跳路由器获得邻居发现服务，因为它将忙于发送其他请求。此DoS攻击不同于其他攻击，因为攻击者可能处于断开链接状态。在这种情况下，受到攻击的资源是概念上的邻居缓存，它将被尝试解析具有有效前缀但后缀无效的IPv6地址所填充。这是DoS攻击。
The threat discussed in this subsection involves Neighbor Solicitation messages.
本小节讨论的威胁涉及邻居请求消息。
This attack does not directly involve the trust models presented. However, if access to the link is restricted to registered nodes, and the access router keeps track of nodes that have registered for access on the link, the attack may be trivially plugged. However, no such mechanisms are currently standardized.
此攻击不直接涉及所提供的信任模型。但是，如果对链路的访问仅限于已注册的节点，并且访问路由器跟踪已在链路上注册访问的节点，则攻击可能会很容易被阻断。然而，目前没有标准化此类机制。
In a way, this problem is fairly similar to the TCP SYN flooding problem. For example, rate limiting Neighbor Solicitations, restricting the amount of state reserved for unresolved solicitations, and clever cache management may be applied.
在某种程度上，这个问题相当类似于TCP SYN泛洪问题。例如，可以应用速率限制邻居请求、限制为未解析请求保留的状态量以及智能缓存管理。
It should be noted that both hosts and routers need to worry about this problem. The router case was discussed above. Hosts are also vulnerable since the neighbor discovery process can potentially be abused by an application that is tricked into sending packets to arbitrary on-link destinations.
应该注意的是，主机和路由器都需要担心这个问题。上面讨论了路由器案例。主机也容易受到攻击，因为邻居发现过程可能会被应用程序滥用，该应用程序会被欺骗向任意链接目的地发送数据包。
Columns:
柱：
N/R Neighbor Discovery (ND) or Router Discovery (RD) attack
N/R邻居发现（ND）或路由器发现（RD）攻击
R/D Redirect/DoS (Redir) or just DoS attack
R/D重定向/拒绝服务（Redir）或直接拒绝服务攻击
Msgs Messages involved in the attack: NA, NS, RA, RS, Redir
参与攻击的Msgs消息：NA、NS、RA、RS、Redir
1 Present in trust model 1 (corporate intranet)
1存在于信任模型1（公司内部网）
2 Present in trust model 2 (public operator run network)
2存在于信任模型2中（公共运营商运营网络）
3 Present in trust model 3 (ad hoc network)
3存在于信任模型3（自组织网络）中
Symbols in trust model columns:
信任模型列中的符号：
- The threat is not present or not a concern.
- 威胁不存在或不值得关注。
+ The threat is present and at least one solution is known.
+ 存在威胁，并且至少知道一种解决方案。
R The threat is present but solving it is a research problem.
R威胁是存在的，但解决它是一个研究问题。
Note that the plus sign '+' in the table does not mean that there is a ready-to-be-applied, standardized solution. If solutions existed, this document would be unnecessary. Instead, it denotes that in the authors' opinion the problem has been solved in principle, and there exists a publication that describes some approach to solve the problem, or a solution may be produced by straightforward application of known research and/or engineering results.
请注意，表中的加号“+”并不意味着有现成的标准化解决方案。如果存在解决方案，则无需本文件。相反，它表示，在作者看来，问题已在原则上得到解决，并且有一份出版物描述了解决问题的一些方法，或者可以通过直接应用已知研究和/或工程结果来产生解决方案。
In the other hand, and 'R' indicates that the authors' are not aware of any publication describing a solution to the problem, and cannot at the time of writing think about any simple and easy extension of known research and/or engineering results to solve the problem.
另一方面，和“R”表示作者“不知道任何描述问题解决方案的出版物，并且在撰写本文时无法考虑对已知研究和/或工程结果进行任何简单和容易的扩展以解决问题”。
+-------+----------------------+-----+-------+-------+---+---+---+
| Sec | Attack name | N/R | R/D | Msgs | 1 | 2 | 3 |
+-------+----------------------+-----+-------+-------+---+---+---+
| 4.1.1 | NS/NA spoofing | ND | Redir | NA NS | + | + | + |
| 4.1.2 | NUD failure | ND | DoS | NA NS | - | + | + |
| 4.1.3 | DAD DoS | ND | DoS | NA NS | - | + | + |
+-------+----------------------+-----+-------+-------+---+---+---+
| 4.2.1 | Malicious router | RD | Redir | RA RS | + | + | R |
| 4.2.2 | Default router killed| RD | Redir | RA |+/R|+/R| R | 1)
| 4.2.3 | Good router goes bad | RD | Redir | RA RS | R | R | R |
| 4.2.4 | Spoofed redirect | RD | Redir | Redir | + | + | R |
| 4.2.5 | Bogus on-link prefix | RD | DoS | RA | - | + | R | 2)
| 4.2.6 | Bogus address config | RD | DoS | RA | - | + | R | 3)
| 4.2.7 | Parameter spoofing | RD | DoS | RA | - | + | R |
+-------+----------------------+-----+-------+-------+---+---+---+
| 4.3.1 | Replay attacks | All | Redir | All | + | + | + |
| 4.3.2 | Remote ND DoS | ND | DoS | NS | + | + | + |
+------------------------------+-----+-------+-------+---+---+---+
+-------+----------------------+-----+-------+-------+---+---+---+
| Sec | Attack name | N/R | R/D | Msgs | 1 | 2 | 3 |
+-------+----------------------+-----+-------+-------+---+---+---+
| 4.1.1 | NS/NA spoofing | ND | Redir | NA NS | + | + | + |
| 4.1.2 | NUD failure | ND | DoS | NA NS | - | + | + |
| 4.1.3 | DAD DoS | ND | DoS | NA NS | - | + | + |
+-------+----------------------+-----+-------+-------+---+---+---+
| 4.2.1 | Malicious router | RD | Redir | RA RS | + | + | R |
| 4.2.2 | Default router killed| RD | Redir | RA |+/R|+/R| R | 1)
| 4.2.3 | Good router goes bad | RD | Redir | RA RS | R | R | R |
| 4.2.4 | Spoofed redirect | RD | Redir | Redir | + | + | R |
| 4.2.5 | Bogus on-link prefix | RD | DoS | RA | - | + | R | 2)
| 4.2.6 | Bogus address config | RD | DoS | RA | - | + | R | 3)
| 4.2.7 | Parameter spoofing | RD | DoS | RA | - | + | R |
+-------+----------------------+-----+-------+-------+---+---+---+
| 4.3.1 | Replay attacks | All | Redir | All | + | + | + |
| 4.3.2 | Remote ND DoS | ND | DoS | NS | + | + | + |
+------------------------------+-----+-------+-------+---+---+---+
Figure 1
图1
1. It is possible to protect the Router Advertisements, thereby closing one variant of this attack. However, closing the other variant (overloading the router) does not seem to be plausible within the scope of this working group.
1. 可以保护路由器广告，从而关闭此攻击的一个变体。然而，在本工作组的范围内，关闭另一个变体（使路由器过载）似乎是不合理的。
2. Note that the extended attack defined in Section 4.2.5 combines sending a bogus on-link prefix and performing NS/NA spoofing as per Section 4.1.1. Thus, if the NA/NS exchange is secured, the ability to use Section 4.2.5 for redirect is most probably blocked, too.
2. 请注意，第4.2.5节中定义的扩展攻击结合了发送虚假链路前缀和按照第4.1.1节执行NS/NA欺骗。因此，如果NA/NS交换是安全的，那么使用第4.2.5节进行重定向的能力也很可能被阻止。
3. The bogus DNS registration resulting from blindly registering the new address via DNS update [4] is not considered an ND security issue here. However, it should be noted as a possible vulnerability in implementations.
3. 由于通过DNS更新[4]盲目注册新地址而导致的虚假DNS注册在此不被视为ND安全问题。但是，应该注意到它在实现中可能存在漏洞。
For a slightly different approach, see also Section 7 in [9]. Especially the table in Section 7.7 of [9] is very good.
有关稍微不同的方法，请参见[9]中的第7节。特别是[9]第7.7节中的表格非常好。
This document discusses security threats to network access in IPv6. As such, it is concerned entirely with security.
本文档讨论IPv6中网络访问的安全威胁。因此，它完全与安全有关。
Thanks to Alper Yegin of DoCoMo Communications Laboratories USA for identifying the Neighbor Discovery DoS attack. We would also like to thank Tuomas Aura and Michael Roe of Microsoft Research Cambridge as well as Jari Arkko and Vesa-Matti Mantyla of Ericsson Research Nomadiclab for discussing some of the threats with us.
感谢美国DoCoMo通信实验室的Alper Yegin识别邻居发现DoS攻击。我们还要感谢微软剑桥研究院的托马斯奥拉（Tuomas Aura）和迈克尔·罗（Michael Roe）以及爱立信游牧研究实验室（Ericsson Research Nomadiclab）的贾里·阿尔科（Jari Arkko）和维萨·马蒂·曼蒂拉（Vesa Matti Mantyla）与我们讨论了一些威胁。
Thanks to Alper Yegin, Pekka Savola, Bill Sommerfeld, Vijay Devaparalli, Dave Thaler, and Alain Durand for their constructive comments.
感谢阿尔珀·耶金、佩卡·萨沃拉、比尔·索末菲、维杰·德瓦帕拉利、戴夫·泰勒和阿兰·杜兰德的建设性评论。
Thanks to Craig Metz for his numerous very good comments, and especially for more material of implementations that refuse to accept ND overrides, for the bogus on-link prefix threat, and for reminding us about replay attacks.
感谢Craig Metz发表了许多非常好的评论，特别是关于拒绝接受ND覆盖的实现的更多材料，关于链接前缀的虚假威胁，以及提醒我们重播攻击。
[1] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[1] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC24611998年12月。
[3] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[3] Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 2462，1998年12月。
[4] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[4] 威灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[5] Mankin, A., "Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6", Work in Progress.
[5] Mankin，A.“移动IPv6引入的威胁模型和移动IPv6中的安全要求”，正在进行中。
[6] Kempf, J., Gentry, C. and A. Silverberg, "Securing IPv6 Neighbor Discovery Using Address Based Keys (ABKs)", Work in Progress, June 2002.
[6] Kempf，J.，Gentry，C.和A.Silverberg，“使用基于地址的密钥（ABK）保护IPv6邻居发现”，正在进行的工作，2002年6月。
[7] Roe, M., "Authentication of Mobile IPv6 Binding Updates and Acknowledgments", Work in Progress, March 2002.
[7] Roe，M.，“移动IPv6绑定更新和确认的认证”，正在进行的工作，2002年3月。
[8] Arkko, J., "Effects of ICMPv6 on IKE", Work in Progress, March 2003.
[8] Arkko，J.，“ICMPv6对IKE的影响”，正在进行的工作，2003年3月。
[9] Arkko, J., "Manual Configuration of Security Associations for IPv6 Neighbor Discovery", Work in Progress, March 2003.
[9] Arkko，J.，“IPv6邻居发现安全关联的手动配置”，正在进行的工作，2003年3月。
Authors' Addresses
作者地址
Pekka Nikander (editor) Ericsson Research Nomadic Lab JORVAS FIN-02420 FINLAND
Pekka Nikander（编辑）爱立信研究游牧实验室JORVAS FIN-02420芬兰
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
James Kempf DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 USA
詹姆斯·肯普夫·多科莫美国实验室美国加利福尼亚州圣何塞市地铁路181号300室95110
Phone: +1 408 451 4711
EMail: kempf@docomolabs-usa.com
Phone: +1 408 451 4711
EMail: kempf@docomolabs-usa.com
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 94043 USA
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park，加利福尼亚州94043美国
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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编辑功能的资金目前由互联网协会提供。