Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7113 Huawei Technologies
Updates: 6105 February 2014
Category: Informational
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7113 Huawei Technologies
Updates: 6105 February 2014
Category: Informational
ISSN: 2070-1721
Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
IPv6路由器广告防护（RA防护）的实施建议
Abstract
摘要
The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA-Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated.
IPv6路由器广告防护（RA防护）机制通常用于缓解基于伪造ICMPv6路由器广告消息的攻击向量。许多现有IPv6部署依赖RA Guard作为抵御上述攻击向量的第一道防线。然而，已经发现RA Guard的一些实现容易通过使用IPv6扩展头进行规避。本文档描述了影响上述实现的规避技术，并正式更新了RFC 6105，从而消除了上述RA防护规避向量。
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/rfc7113.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7113.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Evasion Techniques for Some RA-Guard Implementations . . . . . 3
2.1. Attack Vector Based on IPv6 Extension Headers . . . . . . 3
2.2. Attack Vector Based on IPv6 Fragmentation . . . . . . . . 4
3. RA-Guard Implementation Advice . . . . . . . . . . . . . . . . 6
4. Other Implications . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Assessment Tools . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Evasion Techniques for Some RA-Guard Implementations . . . . . 3
2.1. Attack Vector Based on IPv6 Extension Headers . . . . . . 3
2.2. Attack Vector Based on IPv6 Fragmentation . . . . . . . . 4
3. RA-Guard Implementation Advice . . . . . . . . . . . . . . . . 6
4. Other Implications . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Assessment Tools . . . . . . . . . . . . . . . . . . 12
IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique for attack vectors based on ICMPv6 Router Advertisement [RFC4861] messages. [RFC6104] describes the problem statement of "Rogue IPv6 Router Advertisements", and [RFC6105] specifies the "IPv6 Router Advertisement Guard" functionality.
IPv6路由器广告防护（RA防护）是一种基于ICMPv6路由器广告[RFC4861]消息的攻击向量缓解技术。[RFC6104]描述了“恶意IPv6路由器广告”的问题陈述，[RFC6105]指定了“IPv6路由器广告保护”功能。
The concept behind RA-Guard is that a Layer-2 (L2) device filters ICMPv6 Router Advertisement messages, according to a number of different criteria. The most basic filtering criterion is that Router Advertisement messages are discarded by the L2 device unless they are received on a specified port of the L2 device. Clearly, the effectiveness of RA-Guard relies on the ability of the L2 device to identify ICMPv6 Router Advertisement messages.
RA Guard背后的概念是，第2层（L2）设备根据许多不同的标准过滤ICMPv6路由器广告消息。最基本的过滤标准是二级设备丢弃路由器广告消息，除非它们在二级设备的指定端口上接收。显然，RA Guard的有效性依赖于L2设备识别ICMPv6路由器广告消息的能力。
Some popular RA-Guard implementations have been found to be easy to circumvent by employing IPv6 Extension Headers [CPNI-IPv6]. This
通过使用IPv6扩展头[CPNI-IPv6]，发现一些流行的RA Guard实现很容易绕过。这
document describes such evasion techniques and provides advice to RA-Guard implementers such that the aforementioned evasion vectors can be eliminated.
该文件描述了此类规避技术，并向RA Guard实施者提供建议，以便消除上述规避向量。
It should be noted that the previously mentioned techniques could also be exploited to evade network monitoring tools such as NDPMon [NDPMon], ramond [ramond], and rafixd [rafixd], and could probably be exploited to perform stealth DHCPv6 [RFC3315] attacks.
应该注意的是，还可以利用前面提到的技术来规避网络监控工具，如NDPMon[NDPMon]、ramond[ramond]和rafixd[rafixd]，并且可能被利用来执行隐藏的DHCPv6[RFC3315]攻击。
The following subsections describe two different vectors that have been found to be effective for the evasion of popular implementations of RA-Guard. Section 2.1 describes an attack vector based on the use of IPv6 Extension Headers with ICMPv6 Router Advertisement messages, which may be used to circumvent the RA-Guard protection of those implementations that fail to process an entire IPv6 header chain when trying to identify the ICMPv6 Router Advertisement messages. Section 2.2 describes an attack method based on the use of IPv6 fragmentation, possibly in conjunction with the use of IPv6 Extension Headers. This later vector has been found to be effective against all existing implementations of RA-Guard.
以下小节描述了两种不同的向量，它们被发现可以有效地规避RA Guard的流行实现。第2.1节描述了基于IPv6扩展头的使用ICMPv6路由器广告消息的攻击向量，该方法可用于规避在试图识别ICMPv6路由器广告消息时无法处理整个IPv6头链的那些实现的RA保护。第2.2节描述了一种基于使用IPv6分段的攻击方法，可能与使用IPv6扩展头结合使用。后来发现，这个向量对于所有现有的RA Guard实现都是有效的。
While there is currently no legitimate use for IPv6 Extension Headers in ICMPv6 Router Advertisement messages, Neighbor Discovery [RFC4861] implementations allow the use of Extension Headers with these messages, by simply ignoring the received options. Some RA-Guard implementations try to identify ICMPv6 Router Advertisement messages by simply looking at the "Next Header" field of the fixed IPv6 header, rather than following the entire header chain. As a result, such implementations fail to identify any ICMPv6 Router Advertisement messages that include any Extension Headers (for example, a Hop-by-Hop Options header, a Destination Options header, etc.), and can be easily circumvented.
虽然目前在ICMPv6路由器广告消息中没有合法使用IPv6扩展头，但邻居发现[RFC4861]实现允许通过忽略接收到的选项将扩展头与这些消息一起使用。一些RA Guard实现试图通过查看固定IPv6报头的“下一个报头”字段，而不是遵循整个报头链来识别ICMPv6路由器广告消息。结果，这样的实现无法识别包括任何扩展头（例如，逐跳选项头、目的地选项头等）的任何ICMPv6路由器广告消息，并且可以容易地规避。
The following figure illustrates the structure of ICMPv6 Router Advertisement messages that implement this evasion technique:
下图说明了实现此规避技术的ICMPv6路由器广告消息的结构：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=60| |NH=58| | |
+-+-+-+ +-+-+-+ + +
| IPv6 Header | Dst Opt Hdr | ICMPv6 Router Advertisement |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=60| |NH=58| | |
+-+-+-+ +-+-+-+ + +
| IPv6 Header | Dst Opt Hdr | ICMPv6 Router Advertisement |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section presents a different attack vector, which has been found to be effective against all implementations of RA-Guard. The basic idea behind this attack vector is that if the forged ICMPv6 Router Advertisement is fragmented into at least two fragments, the L2 device implementing RA-Guard would be unable to identify the attack packet and would thus fail to block it.
本节介绍了一种不同的攻击向量，它被发现对RA守护的所有实现都是有效的。该攻击向量的基本思想是，如果伪造的ICMPv6路由器广告被分割成至少两个片段，则实现RA守护的L2设备将无法识别攻击包，因此将无法阻止攻击。
A first variant of this attack vector would be an original ICMPv6 Router Advertisement message preceded with a Destination Options header, which results in two fragments. The following figure illustrates the "original" attack packet, prior to fragmentation, and the two resulting fragments that are actually sent as part of the attack.
此攻击向量的第一个变体将是一个原始的ICMPv6路由器广告消息，它之前有一个目标选项头，这导致两个片段。下图说明了碎片之前的“原始”攻击数据包，以及作为攻击的一部分实际发送的两个结果碎片。
Original Packet:
原始数据包：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=60| |NH=58| | |
+-+-+-+ +-+-+-+ + +
| IPv6 Header | Dst Opt Hdr | ICMPv6 RA |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=60| |NH=58| | |
+-+-+-+ +-+-+-+ + +
| IPv6 Header | Dst Opt Hdr | ICMPv6 RA |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First Fragment:
第一段：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=44| |NH=60| |NH=58| |
+-+-+-+ +-+-+-+ +-+-+-+ +
| IPv6 Header | Frag Hdr | Dst Opt Hdr |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=44| |NH=60| |NH=58| |
+-+-+-+ +-+-+-+ +-+-+-+ +
| IPv6 Header | Frag Hdr | Dst Opt Hdr |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second Fragment:
第二段：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=44| |NH=60| | | |
+-+-+-+ +-+-+-+ + + +
| IPv6 Header | Frag Hdr | Dst Opt Hdr | ICMPv6 RA |
+ + + + +
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=44| |NH=60| | | |
+-+-+-+ +-+-+-+ + + +
| IPv6 Header | Frag Hdr | Dst Opt Hdr | ICMPv6 RA |
+ + + + +
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should be noted that the "Hdr Ext Len" field of the Destination Options header is present in the First Fragment (rather than the second). Therefore, it is impossible for a device processing only the second fragment to locate the ICMPv6 header contained in that fragment, since it is unknown how many bytes should be "skipped" to get to the next header following the Destination Options header.
应该注意的是，目标选项头的“Hdr Ext Len”字段出现在第一个片段（而不是第二个片段）中。因此，仅处理第二个片段的设备不可能找到该片段中包含的ICMPv6头，因为不知道应该“跳过”多少字节才能到达目标选项头之后的下一个头。
Thus, by leveraging the use of the Fragment Header together with the use of the Destination Options header, the attacker is able to conceal the type and contents of the ICMPv6 message he is sending (an ICMPv6 Router Advertisement in this example). Unless the L2 device were to implement IPv6 fragment reassembly, it would be impossible for the device to identify the ICMPv6 type of the message.
因此，通过利用片段标头和目标选项标头，攻击者能够隐藏他发送的ICMPv6消息的类型和内容（本例中为ICMPv6路由器公告）。除非L2设备实现IPv6片段重组，否则该设备将无法识别消息的ICMPv6类型。
An L2 device could, however, at least detect that an ICMPv6 message (of some type) is being sent, since the "Next Header" field of the Destination Options header contained in the First Fragment is set to "58" (ICMPv6).
然而，二级设备至少可以检测到（某种类型的）ICMPv6消息正在发送，因为第一个片段中包含的目标选项报头的“下一个报头”字段设置为“58”（ICMPv6）。
This idea can be taken further, such that it is also impossible for the L2 device to detect that the attacker is sending an ICMPv6 message in the first place. This can be achieved with an original ICMPv6 Router Advertisement message preceded with two Destination Options headers that results in two fragments. The following figure illustrates the "original" attack packet, prior to fragmentation, and the two resulting packets that are actually sent as part of the attack.
这一想法可以进一步推广，因此L2设备也不可能首先检测到攻击者正在发送ICMPv6消息。这可以通过一条原始ICMPv6路由器广告消息实现，该消息前面有两个目的地选项头，导致两个片段。下图说明了碎片之前的“原始”攻击数据包，以及作为攻击一部分实际发送的两个结果数据包。
Original Packet:
原始数据包：
+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=60| |NH=60| |NH=58| | |
+-+-+-+ +-+-+-+ +-+-+-+ + +
| IPv6 header | Dst Opt Hdr | Dst Opt Hdr | ICMPv6 RA |
+ + + + +
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=60| |NH=60| |NH=58| | |
+-+-+-+ +-+-+-+ +-+-+-+ + +
| IPv6 header | Dst Opt Hdr | Dst Opt Hdr | ICMPv6 RA |
+ + + + +
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First Fragment:
第一段：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=44| |NH=60| |NH=60| |
+-+-+-+ +-+-+-+ +-+-+-+ +
| IPv6 header | Frag Hdr | Dst Opt Hdr |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=44| |NH=60| |NH=60| |
+-+-+-+ +-+-+-+ +-+-+-+ +
| IPv6 header | Frag Hdr | Dst Opt Hdr |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second Fragment:
第二段：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=44| |NH=60| | |NH=58| | |
+-+-+-+ +-+-+-+ + +-+-+-+ + +
| IPv6 header | Frag Hdr | Dst O Hdr | Dst Opt Hdr | ICMPv6 RA |
+ + + + + +
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NH=44| |NH=60| | |NH=58| | |
+-+-+-+ +-+-+-+ + +-+-+-+ + +
| IPv6 header | Frag Hdr | Dst O Hdr | Dst Opt Hdr | ICMPv6 RA |
+ + + + + +
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this variant, the "Next Header" field of the Destination Options header contained in the First Fragment is set to "60" (Destination Options header); thus, it is impossible for a device processing only the First Fragment to detect that an ICMPv6 message is being sent in the first place.
在该变体中，第一个片段中包含的目标选项报头的“下一个报头”字段设置为“60”（目标选项报头）；因此，仅处理第一个片段的设备不可能首先检测到正在发送ICMPv6消息。
The second fragment presents the same challenges as the second fragment of the previous variant. That is, it would be impossible for a device processing only the second fragment to locate the second Destination Options header (and hence the ICMPv6 header), since the "Hdr Ext Len" field of the first Destination Options header is present in the First Fragment (rather than the second).
第二个片段与前一个变体的第二个片段面临相同的挑战。也就是说，仅处理第二个片段的设备不可能定位第二个目的地选项报头（因此ICMPv6报头），因为第一个目的地选项报头的“Hdr Ext Len”字段出现在第一个片段（而不是第二个片段）中。
The following filtering rules must be implemented as part of an RA-Guard implementation on ports that face interfaces that are not allowed to send ICMPv6 Router Advertisement messages, such that the vulnerabilities discussed in this document are eliminated:
以下过滤规则必须作为RA Guard实施的一部分，在面向不允许发送ICMPv6路由器公告消息的接口的端口上实施，以消除本文档中讨论的漏洞：
1. If the IPv6 Source Address of the packet is not a link-local address (fe80::/10), RA-Guard must pass the packet.
1. 如果数据包的IPv6源地址不是链路本地地址（fe80:：/10），RA Guard必须传递数据包。
RATIONALE: This prevents RA-Guard from dedicating processing cycles to filtering packets that originate off-net and that, if they are RA's, would not be accepted by the host. Section 6.1.2 of [RFC4861] requires nodes to discard Router Advertisement messages if their IPv6 Source Address is not a link-local address.
理由：这可防止RA Guard将处理周期专用于过滤来自网外的数据包，如果这些数据包是RA的，则主机不会接受。[RFC4861]第6.1.2节要求，如果节点的IPv6源地址不是链路本地地址，则节点丢弃路由器公告消息。
2. If the Hop Limit is not 255, RA-Guard must pass the packet.
2. 如果跃点限制不是255，RA Guard必须传递数据包。
RATIONALE: This prevents RA-Guard from dedicating processing cycles to filtering packets that originate off-net and that, if they are RA's, would not be accepted by the destination host. Section 6.1.2 of [RFC4861] requires nodes to discard Router Advertisement messages if their Hop Limit is not 255.
理由：这可防止RA Guard将处理周期专用于过滤来自网外的数据包，如果这些数据包是RA的，则目标主机不会接受这些数据包。[RFC4861]第6.1.2节要求，如果节点的跃点限制不是255，则节点丢弃路由器公告消息。
3. RA-Guard must parse the entire IPv6 header chain present in the packet, to identify whether the packet is a Router Advertisement message.
3. RA Guard必须解析数据包中存在的整个IPv6报头链，以确定数据包是否为路由器广告消息。
NOTE: RA-Guard implementations must not enforce a limit on the number of bytes they can inspect (starting from the beginning of the IPv6 packet), since this could introduce false positives: legitimate packets could be dropped simply because the RA-Guard device does not parse the entire IPv6 header chain present in the packet. An implementation that has such an implementation-specific limit must not claim compliance with this specification, and must pass the packet when such implementation-specific limit is reached.
注意：RA Guard实施不得强制限制它们可以检查的字节数（从IPv6数据包的开头开始），因为这可能会引入误报：合法数据包可能会被丢弃，因为RA Guard设备不会解析数据包中存在的整个IPv6头链。具有此类特定于实现的限制的实现不得声称符合本规范，并且必须在达到此类特定于实现的限制时通过数据包。
4. When parsing the IPv6 header chain, if the packet is a First Fragment (i.e., a packet containing a Fragment Header with the Fragment Offset set to 0) and it fails to contain the entire IPv6 header chain (i.e., all the headers starting from the IPv6 header up to, and including, the upper-layer header), RA-Guard must drop the packet and should log the packet drop event in an implementation-specific manner as a security fault.
4. 解析IPv6报头链时，如果该数据包是第一个片段（即，包含片段偏移量设置为0的片段报头的数据包），并且它无法包含整个IPv6报头链（即，从IPv6报头开始直到并包括上层报头的所有报头），RA Guard必须丢弃数据包，并应以特定于实现的方式将数据包丢弃事件记录为安全故障。
RATIONALE: [RFC7112] specifies that the First Fragment (i.e., the fragment with the Fragment Offset set to 0) must contain the entire IPv6 header chain, and allows intermediate systems such as routers to drop those packets that fail to comply with this requirement.
理由：[RFC7112]指定第一个片段（即片段偏移量设置为0的片段）必须包含整个IPv6报头链，并允许路由器等中间系统丢弃不符合此要求的数据包。
NOTE: This rule should only be applied to IPv6 fragments with a Fragment Offset of 0 (non-First Fragments can be safely passed, since they will never reassemble into a complete datagram if they are part of a Router Advertisement received on a port where such packets are not allowed).
注意：此规则应仅适用于片段偏移量为0的IPv6片段（非第一个片段可以安全传递，因为如果它们是在不允许此类数据包的端口上接收的路由器播发的一部分，则它们将永远不会重新组合成完整的数据报）。
5. When parsing the IPv6 header chain, if the packet is identified to be an ICMPv6 Router Advertisement message or the packet contains an unrecognized Next Header value [IANA-IP-PROTO], RA-Guard must drop the packet, and should log the packet drop event in an implementation-specific manner as a security fault. RA-Guard must provide a configuration knob that controls whether packets with unrecognized Next Header values are dropped; this configuration knob must default to "drop".
5. 解析IPv6报头链时，如果该数据包被标识为ICMPv6路由器广告消息，或者该数据包包含无法识别的下一个报头值[IANA-IP-PROTO]，RA Guard必须丢弃该数据包，并且应以特定于实现的方式将数据包丢弃事件记录为安全故障。RA Guard必须提供一个配置旋钮，用于控制是否丢弃具有无法识别的下一个报头值的数据包；此配置旋钮必须默认为“下降”。
RATIONALE: By definition, Router Advertisement messages are required to originate on-link, have a link-local IPv6 Source Address, and have a Hop Limit value of 255 [RFC4861]. [RFC7045] requires that nodes be configurable with respect to
理由：根据定义，路由器广告消息必须在链路上发起，具有链路本地IPv6源地址，且跃点限制值为255[RFC4861]。[RFC7045]要求节点可以针对以下方面进行配置：
whether packets with unrecognized headers are forwarded, and allows the default behavior to be that such packets be dropped.
是否转发具有无法识别的头的数据包，并允许默认行为为丢弃此类数据包。
6. In all other cases, RA-Guard must pass the packet as usual.
6. 在所有其他情况下，RA Guard必须像往常一样传递数据包。
NOTE: For the purpose of enforcing the RA-Guard filtering policy, an Encapsulating Security Payload (ESP) header [RFC4303] should be considered to be an "upper-layer protocol" (that is, it should be considered the last header in the IPv6 header chain). This means that packets employing ESP would be passed by the RA-Guard device to the intended destination. If the destination host does not have a security association with the sender of the aforementioned IPv6 packet, the packet would be dropped. Otherwise, if the packet is considered valid by the IPsec implementation at the receiving host and encapsulates a Router Advertisement message, it is up to the receiving host what to do with such a packet.
注意：为了实施RA Guard过滤策略，封装安全有效负载（ESP）头[RFC4303]应被视为“上层协议”（即，它应被视为IPv6头链中的最后一个头）。这意味着使用ESP的数据包将由RA Guard设备传递到预期目的地。如果目标主机与前述IPv6数据包的发送方没有安全关联，则该数据包将被丢弃。否则，如果接收主机上的IPsec实现认为该分组有效并封装了路由器广告消息，则由接收主机决定如何处理该分组。
If a packet is dropped due to this filtering policy, then the packet drop event should be logged in an implementation-specific manner as a security fault. The logging mechanism should include a drop counter dedicated to RA-Guard packet drops.
如果由于此过滤策略而丢弃数据包，则应以特定于实现的方式将数据包丢弃事件记录为安全故障。日志机制应包括专门用于RA Guard数据包丢弃的丢弃计数器。
In order to protect current end-node IPv6 implementations, Rule #4 has been defined as a default rule to drop packets that cannot be positively identified as not being Router Advertisement (RA) messages (because the packet is a fragment that fails to include the entire IPv6 header chain). This means that, at least in theory, RA-Guard could result in false-positive blocking of some legitimate non-RA packets that could not be positively identified as being non-RA. In order to reduce the likelihood of false positives, Rule #1 and Rule #2 require that packets that would not pass the required validation checks for RA messages (Section 6.1.2 of [RFC4861]) be passed without further inspection. In any case, as noted in [RFC7112], IPv6 packets that fail to include the entire IPv6 header chain are virtually impossible to police with state-less filters and firewalls and, hence, are unlikely to survive in real networks. [RFC7112] requires that hosts employing fragmentation include the entire IPv6 header chain in the First Fragment (the fragment with the Fragment Offset set to 0), thus eliminating the aforementioned false positives.
为了保护当前的终端节点IPv6实施，已将规则#4定义为一个默认规则，用于丢弃无法确定为非路由器广告（RA）消息的数据包（因为数据包是一个无法包含整个IPv6头链的片段）。这意味着，至少在理论上，RA Guard可能会导致对一些无法被肯定地识别为非RA的合法非RA数据包的误报阻塞。为了降低误报的可能性，规则#1和规则#2要求不通过RA消息所需验证检查的数据包（RFC4861第6.1.2节）在不进行进一步检查的情况下通过。在任何情况下，如[RFC7112]中所述，无法包含整个IPv6报头链的IPv6数据包几乎不可能使用无状态过滤器和防火墙进行监控，因此不可能在实际网络中生存。[RFC7112]要求采用分段的主机在第一个分段（分段偏移量设置为0的分段）中包含整个IPv6头链，从而消除上述误报。
This filtering policy assumes that host implementations require that the IPv6 Source Address of ICMPv6 Router Advertisement messages be a link-local address and that they discard the packet if this check fails, as required by the current IETF specifications [RFC4861]. Additionally, it assumes that hosts require the Hop Limit of Neighbor Discovery messages to be 255, and that they discard those packets otherwise.
此过滤策略假设主机实现要求ICMPv6路由器播发消息的IPv6源地址为链路本地地址，并且按照当前IETF规范[RFC4861]的要求，如果此检查失败，主机将丢弃数据包。此外，它假设主机要求邻居发现消息的跃点限制为255，否则会丢弃这些数据包。
The aforementioned filtering rules implicitly handle the case of fragmented packets: if the RA-Guard device fails to identify the upper-layer protocol as a result of the use of fragmentation, the corresponding packets would be dropped.
上述过滤规则隐式地处理分段数据包的情况：如果RA-Guard设备由于使用分段而无法识别上层协议，则相应的数据包将被丢弃。
Finally, we note that IPv6 implementations that allow overlapping fragments (i.e., that do not comply with [RFC5722]) might still be subject of RA-based attacks. However, a recent assessment of IPv6 implementations [SI6-FRAG] with respect to their fragment reassembly policy seems to indicate that most current implementations comply with [RFC5722].
最后，我们注意到，允许重叠片段（即，不符合[RFC5722]）的IPv6实现可能仍然受到基于RA的攻击。然而，最近对IPv6实现[SI6-FRAG]的碎片重组策略的评估似乎表明，大多数当前实现符合[RFC5722]。
A similar concept to that of RA-Guard has been implemented for protecting against forged DHCPv6 messages. Such protection can be circumvented with the same techniques discussed in this document, and the countermeasures for such evasion attack are analogous to those described in Section 3 of this document.
为防止伪造DHCPv6消息，实现了与RA Guard类似的概念。可以使用本文件中讨论的相同技术规避此类保护，此类规避攻击的对策与本文件第3节中描述的类似。
[DHCPv6-Shield] specifies a mechanism to protect against rogue DHCPv6 servers, while taking into consideration the evasion techniques discussed in this document.
[DHCPv6 Shield]指定了一种防止恶意DHCPv6服务器的机制，同时考虑了本文档中讨论的规避技术。
This document describes a number of techniques that have been found to be effective to circumvent popular RA-Guard implementations and provides advice to RA-Guard implementers such that those evasion vulnerabilities are eliminated.
本文档描述了一些被发现可以有效规避流行的RA Guard实现的技术，并向RA Guard实现者提供建议，以消除这些规避漏洞。
As noted in Section 3, IPv6 implementations that allow overlapping fragments (i.e., that do not comply with [RFC5722]) might still be subject of RA-based attacks. However, most current implementations seem to comply with [RFC5722].
如第3节所述，允许重叠片段（即不符合[RFC5722]）的IPv6实现可能仍然会受到基于RA的攻击。然而，大多数当前的实现似乎符合[RFC5722]。
We note that if an attacker sends a fragmented ICMPv6 Router Advertisement message on a port not allowed to send such packets, the First Fragment would be dropped, and the rest of the fragments would be passed. This means that the victim node would tie memory buffers for the aforementioned fragments, which would never reassemble into a complete datagram. If a large number of such packets were sent by an attacker, and the victim node failed to implement proper resource management for the IPv6 fragment reassembly buffer, this could lead to a Denial of Service (DoS). However, this does not really introduce a new attack vector, since an attacker could always perform the same attack by sending forged fragmented datagrams in which at
我们注意到，如果攻击者在不允许发送此类数据包的端口上发送碎片化ICMPv6路由器广告消息，第一个碎片将被丢弃，其余碎片将被传递。这意味着受害节点将为上述片段绑定内存缓冲区，这些片段永远不会重新组装成完整的数据报。如果攻击者发送了大量此类数据包，而受害节点未能对IPv6片段重组缓冲区实施适当的资源管理，则可能导致拒绝服务（DoS）。然而，这并不真正引入新的攻击向量，因为攻击者总是可以通过发送伪造的碎片数据报来执行相同的攻击。
least one of the fragments is missing. [CPNI-IPv6] discusses some resource management strategies that could be implemented for the IPv6 fragment reassembly buffer.
至少有一个碎片丢失了。[CPNI-IPv6]讨论了一些可用于IPv6片段重组缓冲区的资源管理策略。
We note that the most effective and efficient mitigation for these attacks would rely on the prohibiting the use of IPv6 fragmentation with Router Advertisement messages (as specified by [RFC6980]), such that the RA-Guard functionality is easier to implement. However, since such mitigation would require an update to existing implementations, it cannot be relied upon in the short or near term.
我们注意到，针对这些攻击的最有效的缓解措施将依赖于禁止对路由器广告消息使用IPv6分段（如[RFC6980]所述），从而使RA Guard功能更易于实现。然而，由于此类缓解措施需要对现有实施进行更新，因此短期或短期内无法依赖。
Finally, we note that RA-Guard only mitigates attack vectors based on ICMPv6 Router advertisement messages. Protection against similar attacks based on other messages (such as DCHPv6) is considered out of the scope of this document and is left for other documents (e.g., [DHCPv6-Shield]).
最后，我们注意到RA Guard仅基于ICMPv6路由器广告消息缓解攻击向量。针对基于其他消息（如DCHPv6）的类似攻击的保护不在本文档范围内，留给其他文档（如[DHCPv6 Shield]）。
The author would like to thank Ran Atkinson, who provided very detailed comments and suggested text that was incorporated into this document.
作者要感谢Ran Atkinson，他提供了非常详细的评论，并建议将文本纳入本文件。
The author would like to thank Ran Atkinson, Karl Auer, Robert Downie, Washam Fan, David Farmer, Mike Heard, Marc Heuse, Nick Hilliard, Ray Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, Gunter van de Velde, James Woodyatt, and Bjoern A. Zeeb, for providing valuable comments on earlier versions of this document.
作者要感谢Ran Atkinson、Karl Auer、Robert Downie、Washam Fan、David Farmer、Mike Heard、Marc Heuse、Nick Hilliard、Ray Hunter、Joel Jaeggli、Simon Perreault、Arturo Servin、Gunter van de Velde、James Woodyatt和Bjoern A.Zeeb为本文件的早期版本提供了宝贵意见。
The author would like to thank Arturo Servin, who presented this document at IETF 81.
作者要感谢Arturo Servin，他在IETF 81上介绍了本文件。
This document resulted from the project "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI).
本文件是由Fernando Gont代表英国国家基础设施保护中心（CPNI）开展的“互联网协议第6版（IPv6）安全评估”项目[CPNI-IPv6]的成果。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[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月。
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009.
[RFC5722]Krishnan，S.，“重叠IPv6片段的处理”，RFC 5722，2009年12月。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
[RFC6105]Levy Abegnoli，E.，Van de Velde，G.，Popoviciu，C.，和J.Mohacsi，“IPv6路由器广告保护”，RFC 61052011年2月。
[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, August 2013.
[RFC6980]Gont，F.，“IPv6分段与IPv6邻居发现的安全影响”，RFC 69802013年8月。
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, December 2013.
[RFC7045]Carpenter，B.和S.Jiang，“IPv6扩展头的传输和处理”，RFC 70452013年12月。
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, January 2014.
[RFC7112]Gont，F.，Manral，V.，和R.Bonica，“超大IPv6头链的影响”，RFC 7112，2014年1月。
[CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request).
[CPNI-IPv6]Gont，F.，“互联网协议第6版（IPv6）的安全评估”，英国国家基础设施保护中心（可根据要求提供）。
[DHCPv6-Shield] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6- Shield: Protecting Against Rogue DHCPv6 Servers", Work in Progress, October 2013.
[DHCPv6 Shield]Gont，F.，Liu，W.，和G.Van de Velde，“DHCPv6-屏蔽：防范恶意DHCPv6服务器”，正在进行的工作，2013年10月。
[IANA-IP-PROTO] IANA, "Assigned Internet Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers/>.
[IANA-IP-PROTO]IANA，“分配的互联网协议编号”<http://www.iana.org/assignments/protocol-numbers/>.
[NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", <http://ndpmon.sourceforge.net/>.
[NDPMon]“NDPMon-IPv6邻居发现协议监视器”<http://ndpmon.sourceforge.net/>.
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011.
[RFC6104]Chown，T.和S.Venaas，“流氓IPv6路由器广告问题声明”，RFC 61042011年2月。
[SI6-FRAG] SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6 fragmentation/reassembly", 2012, <http://blog.si6networks.com/2012/02/ ipv6-nids-evasion-and-improvements-in.html>.
[SI6-FRAG]SI6网络，“IPv6 NIDS规避和IPv6碎片化/重组的改进”，2012年<http://blog.si6networks.com/2012/02/ .html>中的ipv6 nids规避和改进。
[SI6-IPv6] "SI6 Networks' IPv6 toolkit", <http://www.si6networks.com/tools/ipv6toolkit>.
[SI6-IPv6]“SI6网络的IPv6工具包”<http://www.si6networks.com/tools/ipv6toolkit>.
[THC-IPV6] "The Hacker's Choice IPv6 Attack Toolkit", <http://www.thc.org/thc-ipv6/>.
[THC-IPV6]“黑客选择的IPV6攻击工具包”<http://www.thc.org/thc-ipv6/>.
[rafixd] "rafixd", <http://www.kame.net/dev/cvsweb2.cgi/kame/ kame/kame/rafixd/>.
[rafixd]“rafixd”<http://www.kame.net/dev/cvsweb2.cgi/kame/ kame/kame/rafixd/>。
[ramond] "ramond", <http://ramond.sourceforge.net/>.
[ramond]“ramond”<http://ramond.sourceforge.net/>.
[SI6-IPv6] is a publicly available set of tools (for Linux, *BSD, and Mac OS) that implements the techniques described in this document.
[SI6-IPv6]是一套公开可用的工具（用于Linux、*BSD和Mac OS），用于实现本文档中描述的技术。
[THC-IPV6] is a publicly available set of tools (for Linux) that implements some of the techniques described in this document.
[THC-IPV6]是一套公开的工具（用于Linux），它实现了本文档中描述的一些技术。
Author's Address
作者地址
Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo，布宜诺斯艾利斯省1706阿根廷
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com