Internet Engineering Task Force (IETF) I. Gashinsky
Request for Comments: 6583 Yahoo!
Category: Informational J. Jaeggli
ISSN: 2070-1721 Zynga
W. Kumari
Google, Inc.
March 2012
Internet Engineering Task Force (IETF) I. Gashinsky
Request for Comments: 6583 Yahoo!
Category: Informational J. Jaeggli
ISSN: 2070-1721 Zynga
W. Kumari
Google, Inc.
March 2012
Operational Neighbor Discovery Problems
操作邻居发现问题
Abstract
摘要
In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted.
在IPv4中，子网通常很小，大小刚好足以覆盖子网上的实际计算机数量。相比之下，默认的IPv6子网大小是a/64，这个数字如此之大，以至于覆盖了数万亿个地址，其中绝大多数是未分配的。因此，过于简单的邻居发现（ND）实现可能容易受到故意或意外拒绝服务（DoS）的攻击，从而尝试对大量未分配的地址执行地址解析。此类拒绝服务攻击可能是（由攻击者）故意发起的，也可能是由合法的操作工具或事故条件造成的。由于这些漏洞，新设备可能无法“加入”网络，可能无法建立新的IPv6流，并且现有的IPv6传输流可能会中断。
This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks.
本文档详细描述了DoS的可能性，并建议可能的实施改进以及在某些情况下可用于防止或至少减轻此类攻击影响的操作缓解技术。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6583.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6583.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Applicability ..............................................3
2. The Problem .....................................................3
3. Terminology .....................................................4
4. Background ......................................................5
5. Neighbor Discovery Overview .....................................6
6. Operational Mitigation Options ..................................7
6.1. Filtering of Unused Address Space ..........................7
6.2. Minimal Subnet Sizing ......................................7
6.3. Routing Mitigation .........................................8
6.4. Tuning of the NDP Queue Rate Limit .........................8
7. Recommendations for Implementors ................................8
7.1. Prioritize NDP Activities ..................................9
7.2. Queue Tuning ..............................................10
8. Security Considerations ........................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................11
1. Introduction ....................................................3
1.1. Applicability ..............................................3
2. The Problem .....................................................3
3. Terminology .....................................................4
4. Background ......................................................5
5. Neighbor Discovery Overview .....................................6
6. Operational Mitigation Options ..................................7
6.1. Filtering of Unused Address Space ..........................7
6.2. Minimal Subnet Sizing ......................................7
6.3. Routing Mitigation .........................................8
6.4. Tuning of the NDP Queue Rate Limit .........................8
7. Recommendations for Implementors ................................8
7.1. Prioritize NDP Activities ..................................9
7.2. Queue Tuning ..............................................10
8. Security Considerations ........................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................11
This document describes implementation issues with IPv6's Neighbor Discovery protocol that can result in vulnerabilities when a network is scanned, either by an intruder or through the use of scanning tools that perform network inventory, security audits, etc. (e.g., "nmap").
本文档描述了IPv6邻居发现协议的实施问题，当入侵者或通过使用执行网络资源清册、安全审计等的扫描工具（如“nmap”）扫描网络时，可能会导致漏洞。
This document describes the problem in detail, suggests possible implementation improvements, as well as operational mitigation techniques, that can, in some cases, protect against such attacks.
本文档详细描述了该问题，提出了可能的实施改进，以及在某些情况下可以防止此类攻击的操作缓解技术。
The RFCs generally describe the behavior of protocols, that is, "what" is to be done by a protocol, but not exactly "how" it is to be implemented. The exact details of how best to implement a protocol will depend on the overall hardware and software architecture of a particular device. The actual "how" decisions are (correctly) left in the hands of implementors, so long as implementation differences will generally produce proper on-the-wire behavior.
RFC通常描述协议的行为，即协议要做什么，但不确切地描述协议要如何实现。如何最好地实现协议的确切细节将取决于特定设备的总体硬件和软件架构。只要实现差异通常会产生适当的在线行为，实际的“如何”决策（正确地）就留在实现者手中。
While reading this document, it is important to keep in mind that discussions of how things have been implemented beyond basic compliance with the specification is not within the scope of the Neighbor Discovery RFCs.
阅读本文档时，重要的是要记住，关于如何在基本符合规范的情况下实现的讨论不在邻居发现RFC的范围内。
This document is primarily intended for operators of IPV6 networks and implementors of [RFC4861]. The document provides some operational considerations as well as recommendations to increase the resilience of the Neighbor Discovery protocol.
本文档主要面向IPV6网络运营商和[RFC4861]的实施者。该文档提供了一些操作注意事项以及提高邻居发现协议弹性的建议。
In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. For example, an IPv4 /20 contains only 4096 address. In contrast, the default IPv6 subnet size is a /64, a number so large it covers literally billions of billions of addresses, the overwhelming majority of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery may fail to perform as desired when they perform address resolution of large numbers of unassigned addresses. Such failures can be triggered either intentionally by an attacker launching a denial-of-service attack (DoS) [RFC4732] to exploit this vulnerability or unintentionally due to the use of legitimate operational tools that scan networks for inventory and other
在IPv4中，子网通常很小，大小刚好足以覆盖子网上的实际计算机数量。例如，IPv4/20只包含4096个地址。相比之下，默认的IPv6子网大小是a/64，这个数字如此之大，以至于可以覆盖几十亿个地址，其中绝大多数都是未分配的。因此，当邻居发现的简单实现执行大量未分配地址的地址解析时，它们可能无法按预期执行。攻击者发起拒绝服务攻击（DoS）[RFC4732]以利用此漏洞可能会故意触发此类故障，也可能是由于使用合法的操作工具扫描网络中的库存和其他信息而无意触发此类故障
purposes. As a result of these failures, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transport flows may be interrupted.
目的。由于这些故障，新设备可能无法“加入”网络，可能无法建立新的IPv6流，并且现有IPv6传输流可能会中断。
Network scans attempt to find and probe devices on a network. Typically, scans are performed on a range of target addresses, or all the addresses on a particular subnet. When such probes are directed via a router, and the target addresses are on a directly attached network, the router will attempt to perform address resolution on a large number of destinations (i.e., some fraction of the 2^64 addresses on the subnet). The router's process of testing for the (non)existence of neighbors can induce a denial-of-service condition, where the number of necessary Neighbor Discovery requests overwhelms the implementation's capacity to process them, exhausts available memory and replaces existing in-use mappings with incomplete entries that will never be completed. A directed DoS attack may seek to intentionally create similar conditions to those created unintentionally by a network scan. The resulting network disruption may impact existing traffic, and devices that join the network may find that address resolution attempts fail. The DoS as a consequence of network scanning was previously described in [RFC5157].
网络扫描尝试查找和探测网络上的设备。通常，在一系列目标地址或特定子网上的所有地址上执行扫描。当此类探测通过路由器定向，且目标地址位于直接连接的网络上时，路由器将尝试在大量目的地上执行地址解析（即子网上2^64地址的一小部分）。路由器测试邻居（不存在）的过程可能导致拒绝服务情况，其中必要的邻居发现请求数量超过了实现处理它们的能力，耗尽了可用内存，并用永远不会完成的不完整条目替换现有在用映射。定向DoS攻击可能会故意造成与网络扫描无意中造成的情况类似的情况。由此产生的网络中断可能会影响现有流量，并且加入网络的设备可能会发现地址解析尝试失败。由于网络扫描而导致的DoS在[RFC5157]中已有描述。
In order to mitigate risk associated with this DoS threat, some router implementations have taken steps to rate-limit the processing rate of Neighbor Solicitations (NS). While these mitigations do help, they do not fully address the issue and may introduce their own set of issues to the Neighbor Discovery process.
为了减轻与此DoS威胁相关的风险，一些路由器实现已采取步骤限制邻居请求（NS）的处理速率。虽然这些缓解措施确实有所帮助，但它们并没有完全解决该问题，并且可能会给邻居发现过程带来自己的一组问题。
Address Resolution: Address resolution is the process through which a node determines the link-layer address of a neighbor given only its IP address. In IPv6, address resolution is performed as part of Neighbor Discovery [RFC4861], Section 7.2.
地址解析：地址解析是一个过程，通过该过程，节点仅在给定其IP地址的情况下确定邻居的链路层地址。在IPv6中，地址解析作为邻居发现[RFC4861]第7.2节的一部分执行。
Forwarding Plane: The part of a router responsible for forwarding packets. In higher-end routers, the forwarding plane is typically implemented in specialized hardware optimized for performance. Steps in the forwarding process include determining the correct outgoing interface for a packet, decrementing its Time To Live (TTL), verifying and updating the checksum, placing the correct link-layer header on the packet, and forwarding it.
转发平面：路由器中负责转发数据包的部分。在高端路由器中，转发平面通常在针对性能优化的专用硬件中实现。转发过程中的步骤包括确定数据包的正确传出接口、减少其生存时间（TTL）、验证和更新校验和、在数据包上放置正确的链路层报头以及转发数据包。
Control Plane: The part of the router implementation that maintains the data structures that determine where packets should be forwarded. The control plane is typically implemented as a "slower" software process running on a general purpose processor and is responsible for such functions as communicating network
控制平面：路由器实现的一部分，用于维护确定数据包转发位置的数据结构。控制平面通常被实现为在通用处理器上运行的“较慢”软件进程，并负责网络通信等功能
status changes via routing protocols, maintaining the forwarding table, performing management, and resolving the correct link-layer address for adjacent neighbors. The control plane "controls" the forwarding plane by programming it with the information needed for packet forwarding.
通过路由协议、维护转发表、执行管理和解析相邻邻居的正确链路层地址来更改状态。控制平面通过使用分组转发所需的信息对转发平面进行编程来“控制”转发平面。
Neighbor Cache: As described in [RFC4861], the data structure that holds the cache of (amongst other things) IP address to link-layer address mappings for connected nodes. As the information in the Neighbor Cache is needed by the forwarding plane every time it forwards a packet, it is usually implemented in an Application-specific Integrated Circuit (ASIC).
邻居缓存（Neighbor Cache）：如[RFC4861]所述，该数据结构保存连接节点的IP地址到链路层地址映射的缓存（以及其他内容）。由于转发平面每次转发数据包时都需要邻居缓存中的信息，因此通常在专用集成电路（ASIC）中实现。
Neighbor Discovery Process: The Neighbor Discovery Process (NDP) is that part of the control plane that implements the Neighbor Discovery protocol. NDP is responsible for performing address resolution and maintaining the Neighbor Cache. When forwarding packets, the forwarding plane accesses entries within the Neighbor Cache. When the forwarding plane processes a packet for which the corresponding Neighbor Cache Entry (NCE) is missing or incomplete, it notifies NDP to take appropriate action (typically via a shared queue). NDP picks up requests from the shared queue and performs any necessary discovery action. In many implementations, the NDP is also responsible for responding to router solicitation messages, Neighbor Unreachability Detection (NUD), etc.
邻居发现过程：邻居发现过程（NDP）是实现邻居发现协议的控制平面的一部分。NDP负责执行地址解析和维护邻居缓存。转发数据包时，转发平面访问邻居缓存中的条目。当转发平面处理对应的邻居缓存项（NCE）丢失或不完整的数据包时，它通知NDP采取适当的措施（通常通过共享队列）。NDP从共享队列中提取请求并执行任何必要的发现操作。在许多实现中，NDP还负责响应路由器请求消息、邻居不可达性检测（NUD）等。
Modern router architectures separate the forwarding of packets (forwarding plane) from the decisions needed to decide where the packets should go (control plane). In order to deal with the high number of packets per second, the forwarding plane is generally implemented in hardware and is highly optimized for the task of forwarding packets. In contrast, the NDP control plane is mostly implemented in software processes running on a general purpose processor.
现代路由器架构将数据包的转发（转发平面）与决定数据包应该去哪里（控制平面）所需的决策分离开来。为了处理每秒大量的数据包，转发平面通常在硬件中实现，并针对转发数据包的任务进行了高度优化。相反，NDP控制平面主要在通用处理器上运行的软件进程中实现。
When a router needs to forward an IP packet, the forwarding plane logic performs the longest match lookup to determine where to send the packet and what outgoing interface to use. To deliver the packet to an adjacent node, the forwarding plane encapsulates the packet in a link-layer frame (which contains a header with the link-layer destination address). The forwarding plane logic checks the Neighbor Cache to see if it already has a suitable link-layer destination, and if not, places the request for the required information into a queue, and signals the control plane (i.e., NDP) that it needs the link-layer address resolved.
当路由器需要转发IP数据包时，转发平面逻辑执行最长匹配查找，以确定发送数据包的位置以及使用哪个传出接口。为了将分组传送到相邻节点，转发平面将分组封装在链路层帧（其中包含具有链路层目的地地址的报头）中。转发平面逻辑检查邻居缓存，以查看其是否已经具有合适的链路层目的地，如果没有，则将对所需信息的请求放入队列，并向控制平面（即NDP）发出信号，表明其需要解析链路层地址。
In order to protect NDP specifically and the control plane generally from being overwhelmed with these requests, appropriate steps must be taken. For example, the size and fill rate of the queue might be limited. NDP running in the control plane of the router dequeues requests and performs the address resolution function (by performing a neighbor solicitation and listening for a neighbor advertisement). This process is usually also responsible for other activities needed to maintain link-layer information, such as Neighbor Unreachability Detection (NUD).
为了特别保护NDP和控制平面不被这些请求淹没，必须采取适当的步骤。例如，队列的大小和填充率可能会受到限制。在路由器的控制平面中运行的NDP将请求出列并执行地址解析功能（通过执行邻居请求和侦听邻居公告）。此过程通常还负责维护链路层信息所需的其他活动，如邻居不可访问性检测（NUD）。
By sending appropriate packets to addresses on a given subnet, an attacker can cause the router to queue attempts to resolve so many addresses that it crowds out attempts to resolve "legitimate" addresses (and in many cases becomes unable to perform maintenance of existing entries in the Neighbor Cache, and unable to answer Neighbor Solicitation). This condition can result in the inability to resolve new neighbors and loss of reachability to neighbors with existing NCEs. During testing, it was concluded that four simultaneous nmap sessions from a low-end computer were sufficient to make a router's Neighbor Discovery process unusable; therefore, forwarding became unavailable to the destination subnets.
通过向给定子网上的地址发送适当的数据包，攻击者可以使路由器将解析太多地址的尝试排队，从而挤出解析“合法”地址的尝试（在许多情况下，无法维护邻居缓存中的现有条目，也无法响应邻居请求）. 这种情况可能导致无法解析新邻居，并且失去与现有邻居的可达性。在测试过程中，得出的结论是，来自低端计算机的四个同步nmap会话足以使路由器的邻居发现过程无法使用；因此，目标子网无法进行转发。
The failure to maintain proper NDP behavior whilst under attack has been observed across multiple platforms and implementations, including the largest modern router platforms available (at the inception of work on this document).
在多个平台和实施中，包括现有最大的现代路由器平台（在本文档开始工作时），观察到在受到攻击时无法保持正确的NDP行为。
When a packet arrives at (or is generated by) a router for a destination on an attached link, the router needs to determine the correct link-layer address to use in the destination field of the Layer 2 encapsulation. The router checks the Neighbor Cache for an existing Neighbor Cache Entry for the neighbor, and if none exists, invokes the address resolution portions of the IPv6 Neighbor Discovery [RFC4861] protocol to determine the link-layer address of the neighbor.
当数据包到达（或由）连接链路上的目的地路由器时，路由器需要确定在第2层封装的目的地字段中使用的正确链路层地址。路由器检查邻居缓存中是否存在邻居的现有邻居缓存条目，如果不存在，则调用IPv6邻居发现[RFC4861]协议的地址解析部分来确定邻居的链路层地址。
[RFC4861], Section 5.2, outlines how this process works. A very high-level summary is that the device creates a new Neighbor Cache Entry for the neighbor, sets the state to INCOMPLETE, queues the packet, and initiates the actual address resolution process. The device then sends out one or more Neighbor Solicitations, and when it receives a corresponding Neighbor Advertisement, completes the Neighbor Cache Entry and sends the queued packet.
[RFC4861]第5.2节概述了该过程的工作原理。一个非常高级的总结是，设备为邻居创建一个新的邻居缓存条目，将状态设置为“未完成”，对数据包进行排队，并启动实际的地址解析过程。然后，设备发送一个或多个邻居请求，当它接收到相应的邻居播发时，完成邻居缓存条目并发送排队的数据包。
This section provides some feasible mitigation options that can be employed today by network operators in order to protect network availability while vendors implement more effective protection measures. It can be stated that some of these options are "kludges", and can be operationally difficult to manage. They are presented, as they represent options we currently have. It is each operator's responsibility to evaluate and understand the impact of changes to their network due to these measures.
本节提供了一些可行的缓解方案，网络运营商现在可以采用这些方案，以便在供应商实施更有效的保护措施时保护网络可用性。可以说，其中一些选择是“乱七八糟”的，在操作上很难管理。它们是呈现的，因为它们代表了我们目前拥有的选项。每个运营商都有责任评估和了解这些措施对其网络的影响。
The DoS condition is induced by making a router try to resolve addresses on the subnet at a high rate. By carefully addressing machines into a small portion of a subnet (such as the lowest numbered addresses), it is possible to filter access to addresses not in that assigned portion of address space using Access Control Lists (ACLs), or by null routing, features which are available on most existing platforms. This will prevent the attacker from making the router attempt to resolve unused addresses. For example, if there are only 50 hosts connected to an interface, you may be able to filter any address above the first 64 addresses of that subnet by null-routing the subnet carrying a more specific /122 route or by applying ACLs on the WAN link to prevent the attack traffic reaching the vulnerable device.
拒绝服务条件是由路由器试图以高速率解析子网上的地址引起的。通过小心地将机器寻址到子网的一小部分（如编号最低的地址），可以使用访问控制列表（ACL）或空路由（大多数现有平台上都提供的功能）过滤对地址空间中未分配部分的地址的访问。这将防止攻击者使路由器尝试解析未使用的地址。例如，如果只有50台主机连接到一个接口，则可以通过对承载更具体/122路由的子网进行空路由，或通过在WAN链路上应用ACL来防止攻击流量到达易受攻击的设备，从而过滤该子网前64个地址以上的任何地址。
As mentioned at the beginning of this section, it is fully understood that this is ugly (and difficult to manage); but failing other options, it may be a useful technique especially when responding to an attack.
如本节开头所述，完全理解这是丑陋的（且难以管理）；但如果没有其他选择，它可能是一种有用的技术，尤其是在响应攻击时。
This solution requires that the hosts be statically or statefully addressed (as is often done in a datacenter), and they may not interact well with networks using [RFC4862].
此解决方案要求主机以静态或状态寻址（通常在数据中心中这样做），并且它们可能无法使用[RFC4862]与网络进行良好交互。
By sizing subnets to reflect the number of addresses actually in use, the problem can be avoided. For example, [RFC6164] recommends sizing the subnets for inter-router links so they only have two addresses (a /127). It is worth noting that this practice is common in IPv4 networks, in part to protect against the harmful effects of Address Resolution Protocol (ARP) request flooding.
通过调整子网的大小以反映实际使用的地址数，可以避免该问题。例如，[RFC6164]建议调整路由器间链路的子网大小，以便它们只有两个地址（a/127）。值得注意的是，这种做法在IPv4网络中很常见，部分是为了防止地址解析协议（ARP）请求洪泛的有害影响。
Subnet prefixes longer than a /64 are not able to use stateless auto-configuration [RFC4862], so this approach is not suitable for use with hosts that are not statically configured.
长于a/64的子网前缀不能使用无状态自动配置[RFC4862]，因此此方法不适用于非静态配置的主机。
One very effective technique is to route the subnet to a discard interface (most modern router platforms can discard traffic in hardware / the forwarding plane) and then have individual hosts announce routes for their IP addresses into the network (or use some method to inject much more specific addresses into the local routing domain). For example, the network 2001:db8:1:2:3::/64 could be routed to a discard interface on "border" routers, and then individual hosts could announce 2001:db8:1:2:3::10/128, 2001:db8:1:2: 3::66/128 into the IGP. This is typically done by having the IP address bound to a virtual interface on the host (for example, the loopback interface), enabling IP forwarding on the host and having it run a routing daemon. For obvious reasons, host participation in the IGP makes many operators uncomfortable, but it can be a very powerful technique if used in a disciplined and controlled manner. One method to help address these concerns is to have the hosts participate in a different IGP (or difference instance of the same IGP) and carefully redistribute into the main IGP.
一种非常有效的技术是将子网路由到丢弃接口（大多数现代路由器平台可以丢弃硬件/转发平面中的通信量），然后让各个主机将其IP地址的路由通知到网络中（或者使用某种方法将更具体的地址注入本地路由域）。例如，网络2001:db8:1:2:3:：/64可以路由到“边界”路由器上的丢弃接口，然后各个主机可以将2001:db8:1:2:3:：10/128、2001:db8:1:2:3:：66/128通知到IGP中。这通常是通过将IP地址绑定到主机上的虚拟接口（例如，环回接口）、在主机上启用IP转发并使其运行路由守护程序来实现的。出于显而易见的原因，主机参与IGP使许多操作员感到不舒服，但如果以有纪律和受控的方式使用，这可能是一种非常强大的技术。有助于解决这些问题的一种方法是让主机参与不同的IGP（或同一IGP的不同实例），并小心地重新分配到主IGP中。
Many implementations provide a means to control the rate of resolution of unknown addresses. By tuning this rate, it may be possible to ameliorate the issue, as with most tuning knobs (especially those that deal with rate-limiting), the attack may be completed more quickly due to the lower threshold. By excessively lowering this rate, you may negatively impact how long the device takes to learn new addresses under normal conditions (for example, after clearing the Neighbor Cache or when the router first boots). Under attack conditions, you may be unable to resolve "legitimate" addresses sooner than if you had just left the parameter untouched.
许多实现提供了一种控制未知地址解析率的方法。通过调整此速率，可能会改善问题，就像大多数调整旋钮（尤其是那些处理速率限制的旋钮）一样，由于阈值较低，攻击可能会更快完成。通过过度降低此速率，您可能会对设备在正常情况下（例如，清除邻居缓存后或路由器首次启动时）学习新地址所需的时间产生负面影响。在攻击条件下，您可能无法比您刚刚保持参数不变更快地解析“合法”地址。
It is worth noting that this technique is worth investigating only if the device has separate queues for resolution of unknown addresses and the maintenance of existing entries.
值得注意的是，只有当设备具有用于解析未知地址和维护现有条目的单独队列时，此技术才值得研究。
This section provides some recommendations to implementors of IPv6 Neighbor Discovery.
本节向IPv6邻居发现的实施者提供一些建议。
At a high-level, implementors should program defensively. That is, they should assume that attackers will attempt to exploit implementation weaknesses, and they should ensure that implementations are robust to various attacks. In the case of Neighbor Discovery, the following general considerations apply:
在高层，实施者应该防御性地编程。也就是说，他们应该假设攻击者会试图利用实现弱点，并且他们应该确保实现对各种攻击具有鲁棒性。在邻居发现的情况下，以下一般注意事项适用：
Manage Resources Explicitly: Resources such as processor cycles, memory, etc., are never infinite, yet with IPv6's large subnets, it is easy to cause NDP to generate large numbers of address resolution requests for nonexistent destinations. Implementations need to limit resources devoted to processing Neighbor Discovery requests in a thoughtful manner.
显式管理资源：处理器周期、内存等资源从来都不是无限的，但由于IPv6的大型子网，很容易导致NDP为不存在的目的地生成大量地址解析请求。实现需要限制用于以深思熟虑的方式处理邻居发现请求的资源。
Prioritize: Some NDP requests are more important than others. For example, when resources are limited, responding to Neighbor Solicitations for one's own address is more important than initiating address resolution requests that create new entries. Likewise, performing Neighbor Unreachability Detection, which by definition is only invoked on destinations that are actively being used, is more important than creating new entries for possibly nonexistent neighbors.
优先顺序：一些NDP请求比其他请求更重要。例如，当资源有限时，响应邻居对自己地址的请求比启动创建新条目的地址解析请求更重要。同样，执行邻居不可达性检测（根据定义，该检测仅在正在使用的目的地上调用）比为可能不存在的邻居创建新条目更重要。
Not all Neighbor Discovery activities are equally important. Specifically, requests to perform large numbers of address resolutions on non-existent Neighbor Cache Entries should not come at the expense of servicing requests related to keeping existing, in-use entries properly up to date. Thus, implementations should divide work activities into categories having different priorities. The following gives examples of different activities and their importance in rough priority order. If implemented, the operation and priority of these should be configurable by the operator.
并非所有邻居发现活动都同等重要。具体来说，对不存在的邻居缓存项执行大量地址解析的请求不应以服务与保持现有的、正在使用的项正确更新相关的请求为代价。因此，实现应该将工作活动划分为具有不同优先级的类别。以下给出了不同活动的示例及其重要性（按粗略的优先级顺序）。如果实施，操作员应可配置这些设备的操作和优先级。
1. It is critical to respond to Neighbor Solicitations for one's own address, especially for a router. Whether for address resolution or Neighbor Unreachability Detection, failure to respond to Neighbor Solicitations results in immediate problems. Failure to respond to NS requests that are part of NUD can cause neighbors to delete the NCE for that address and will result in follow-up NS messages using multicast. Once an entry has been flushed, existing traffic for destinations using that entry can no longer be forwarded until address resolution completes successfully. In other words, not responding to NS messages further increases the NDP load and causes ongoing communication to fail.
1. 响应邻居请求自己的地址是至关重要的，特别是对于路由器。无论是地址解析还是邻居不可访问性检测，未能响应邻居请求都会导致直接的问题。未能响应作为NUD一部分的NS请求可能会导致邻居删除该地址的NCE，并将导致后续使用多播的NS消息。刷新条目后，在地址解析成功完成之前，无法再转发使用该条目的目的地的现有流量。换句话说，不响应NS消息会进一步增加NDP负载并导致正在进行的通信失败。
2. It is critical to revalidate one's own existing NCEs in need of refresh. As part of NUD, ND is required to frequently revalidate existing, in-use entries. Failure to do so can result in the entry being discarded. For in-use entries, discarding the entry will almost certainly result in a subsequent request to perform address resolution on the entry, but this time using multicast.
2. 重新验证需要更新的现有NCE是至关重要的。作为NUD的一部分，ND需要经常重新验证现有的、正在使用的条目。不这样做可能导致条目被丢弃。对于正在使用的条目，丢弃条目几乎肯定会导致后续请求对条目执行地址解析，但这次使用多播。
As above, once the entry has been flushed, existing traffic for destinations using that entry can no longer be forwarded until address resolution completes successfully.
如上所述，一旦刷新了条目，在地址解析成功完成之前，使用该条目的目的地的现有流量将无法再转发。
3. To maintain the stability of the control plane, Neighbor Discovery activity related to traffic sourced by the router (as opposed to traffic being forwarded by the router) should be given high priority. Whenever network problems occur, debugging and making other operational changes requires being able to query and access the router. In addition, routing protocols dependent on Neighbor Discovery for connectivity may begin to react (negatively) to perceived connectivity problems, causing additional undesirable ripple effects.
3. 为了保持控制平面的稳定性，应该优先考虑与来自路由器的流量（而不是由路由器转发的流量）相关的邻居发现活动。无论何时出现网络问题，调试和进行其他操作更改都需要能够查询和访问路由器。此外，依赖于邻居发现进行连接的路由协议可能会开始对感知到的连接问题做出（负面）反应，从而导致额外的不良连锁反应。
4. Traffic to unknown addresses should be given lowest priority. Indeed, it may be useful to distinguish between "never seen" addresses and those that have been seen before, but that do not have a corresponding NCE. Specifically, the conceptual processing algorithm in IPv6 Neighbor Discovery [RFC4861] calls for deleting NCEs under certain conditions. Rather than delete them completely, however, it might be useful to at least keep track of the fact that an entry at one time existed, in order to prioritize address resolution requests for such neighbors compared with neighbors that have never been seen before.
4. 对未知地址的通信应给予最低优先级。事实上，区分“从未见过”的地址和以前见过但没有相应NCE的地址可能很有用。具体而言，IPv6邻居发现[RFC4861]中的概念处理算法要求在特定条件下删除NCE。但是，与其完全删除它们，不如至少跟踪某个条目曾经存在的事实，以便将此类邻居的地址解析请求与以前从未见过的邻居进行优先级排序。
On implementations in which requests to NDP are submitted via a single queue, router vendors should provide operators with means to control both the rate of link-layer address resolution requests placed into the queue and the size of the queue. This will allow operators to tune Neighbor Discovery for their specific environment. The ability to set, or have per-interface or per-prefix queue limits at a rate below that of the global queue limit might restrict the damage to the Neighbor Discovery processing to the network targeted by the attack.
在通过单个队列提交NDP请求的实现中，路由器供应商应向运营商提供控制放入队列的链路层地址解析请求速率和队列大小的方法。这将允许运营商针对其特定环境调整邻居发现。以低于全局队列限制的速率设置或拥有每个接口或每个前缀队列限制的能力可能会将对邻居发现处理的损害限制到攻击目标网络。
Setting those values must be a very careful balancing act -- the lower the rate of entry into the queue, the less load there will be on the ND process; however, it will take the router longer to learn legitimate destinations as a result. In a datacenter with 6,000 hosts attached to a single router, setting that value to be under 1000 would mean that resolving all of the addresses from an initial state (or something that invalidates the address cache, such as a Spanning Tree Protocol (STP) Topology Change Notification (TCN)) may take over 6 seconds. Similarly, the lower the size of the queue, the higher the likelihood of an attack being able to knock out legitimate traffic (but less memory utilization on the router).
设置这些值必须是非常谨慎的平衡行为——进入队列的速率越低，ND进程上的负载就越小；但是，路由器需要更长的时间才能了解合法的目的地。在一个有6000台主机连接到单个路由器的数据中心中，将该值设置为1000以下意味着从初始状态解析所有地址（或使地址缓存无效的某个状态，如生成树协议（STP）拓扑更改通知（TCN））可能需要6秒以上的时间。类似地，队列大小越小，攻击破坏合法流量的可能性越高（但路由器上的内存利用率越低）。
This document outlines mitigation options that operators can use to protect themselves from denial-of-service attacks. Implementation advice to router vendors aimed at ameliorating known problems carries the risk of previously unforeseen consequences. It is not believed that these mitigation techniques or the implementation of finer-grained queuing of NDP activity create additional security risks or DoS exposure.
本文档概述了操作员可用于保护自己免受拒绝服务攻击的缓解选项。向路由器供应商提供旨在改善已知问题的实施建议会带来以前无法预见的后果的风险。不相信这些缓解技术或NDP活动细粒度排队的实施会产生额外的安全风险或DoS暴露。
The authors would like to thank Ron Bonica, Troy Bonin, John Jason Brzozowski, Randy Bush, Vint Cerf, Tassos Chatzithomaoglou, Jason Fesler, Wes George, Erik Kline, Jared Mauch, Chris Morrow, and Suran De Silva. Special thanks to Thomas Narten and Ray Hunter for detailed review and (even more so) for providing text!
作者要感谢Ron Bonica、Troy Bonin、John Jason Brzowski、Randy Bush、Vint Cerf、Tassos Chatzittomoglou、Jason Fesler、Wes George、Erik Kline、Jared Mauch、Chris Morrow和Suran De Silva。特别感谢Thomas Narten和Ray Hunten提供的详细评论和（甚至更多）提供的文本！
Apologies for anyone we may have missed; it was not intentional.
为我们错过的任何人道歉；这不是故意的。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-Router Links", RFC 6164, April 2011.
[RFC6164]Kohno，M.，Nitzan，B.，Bush，R.，Matsuzaki，Y.，Colitti，L.，和T.Narten，“在路由器间链路上使用127位IPv6前缀”，RFC 61642011年4月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]Handley，M.，Rescorla，E.，和IAB，“互联网拒绝服务注意事项”，RFC 4732，2006年12月。
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008.
[RFC5157]Chown，T.，“IPv6对网络扫描的影响”，RFC 5157，2008年3月。
Authors' Addresses
作者地址
Igor Gashinsky Yahoo! 45 W 18th St New York, NY USA
igorgashinskyyahoo！美国纽约州纽约市第18街西45号
EMail: igor@yahoo-inc.com
EMail: igor@yahoo-inc.com
Joel Jaeggli Zynga 111 Evelyn Sunnyvale, CA USA
Joel Jaeggli Zynga 111美国加利福尼亚州伊芙琳桑尼维尔
EMail: jjaeggli@zynga.com
EMail: jjaeggli@zynga.com
Warren Kumari Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA USA
沃伦·库马里谷歌公司，美国加利福尼亚州山景公园道1600圆形剧场
EMail: warren@kumari.net
EMail: warren@kumari.net