Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7610 SI6 Networks / UTN-FRH
BCP: 199 W. Liu
Category: Best Current Practice Huawei Technologies
ISSN: 2070-1721 G. Van de Velde
Alcatel-Lucent
August 2015
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7610 SI6 Networks / UTN-FRH
BCP: 199 W. Liu
Category: Best Current Practice Huawei Technologies
ISSN: 2070-1721 G. Van de Velde
Alcatel-Lucent
August 2015
DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers
DHCPv6屏蔽：针对恶意DHCPv6服务器进行保护
Abstract
摘要
This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 packet filtering at the layer 2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'); hence, it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6-Shield.
本文档指定了一种保护连接到交换网络的主机免受恶意DHCPv6服务器攻击的机制。它基于接收数据包的第2层设备上的DHCPv6数据包过滤。类似的机制已广泛部署在IPv4网络中（“DHCP窥探”）；因此，希望为IPv6网络提供类似的功能。本文档规定了DHCPv6 Shield实施的最佳当前实践。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见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/rfc7610.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7610.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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
2. Requirements Language ...........................................3
3. Terminology .....................................................3
4. DHCPv6-Shield Configuration .....................................5
5. DHCPv6-Shield Implementation Requirements .......................5
6. Security Considerations .........................................7
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References ....................................10
Acknowledgements ..................................................11
Authors' Addresses ................................................12
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Terminology .....................................................3
4. DHCPv6-Shield Configuration .....................................5
5. DHCPv6-Shield Implementation Requirements .......................5
6. Security Considerations .........................................7
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References ....................................10
Acknowledgements ..................................................11
Authors' Addresses ................................................12
This document specifies DHCPv6-Shield, a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers [RFC3315]. The basic concept behind DHCPv6-Shield is that a layer 2 device filters DHCPv6 messages intended for DHCPv6 clients (henceforth, "DHCPv6-server messages"), according to a number of different criteria. The most basic filtering criterion is that DHCPv6-server messages are discarded by the layer 2 device unless they are received on specific ports of the layer 2 device.
本文档指定了DHCPv6屏蔽，这是一种保护连接到交换网络的主机免受恶意DHCPv6服务器攻击的机制[RFC3315]。DHCPv6屏蔽背后的基本概念是，第2层设备根据许多不同的标准过滤针对DHCPv6客户端的DHCPv6消息（此后称为“DHCPv6服务器消息”）。最基本的过滤标准是，DHCPv6服务器消息被第2层设备丢弃，除非它们是在第2层设备的特定端口上接收的。
Before the DHCPv6-Shield device is deployed, the administrator specifies the layer 2 port(s) on which DHCPv6-server messages are to be allowed. Only those ports to which a DHCPv6 server or relay is to be connected should be specified as such. Once deployed, the DHCPv6-Shield device inspects received packets and allows (i.e., passes) DHCPv6-server messages only if they are received on layer 2 ports that have been explicitly configured for such purpose.
在部署DHCPv6屏蔽设备之前，管理员指定允许DHCPv6服务器消息的第2层端口。仅应将DHCPv6服务器或中继连接到的端口指定为该端口。一旦部署，DHCPv6屏蔽设备将检查接收到的数据包，并且仅当DHCPv6服务器消息是在已明确为此目的配置的第2层端口上接收时，才允许（即，传递）DHCPv6服务器消息。
DHCPv6-Shield is analogous to the Router Advertisement Guard (RA-Guard) mechanism [RFC6104] [RFC6105] [RFC7113], intended for protection against rogue Router Advertisement [RFC4861] messages.
DHCPv6屏蔽类似于路由器广告防护（RA防护）机制[RFC6104][RFC6105][RFC7113]，旨在防止恶意路由器广告[RFC4861]消息。
We note that DHCPv6-Shield mitigates only DHCPv6-based attacks against hosts. Attack vectors based on other messages meant for network configuration (such as ICMPv6 Router Advertisements) are not addressed by DHCPv6-Shield itself. In a similar vein, DHCPv6-Shield does not mitigate attacks against DHCPv6 servers (e.g., Denial of Service).
我们注意到，DHCPv6 Shield仅缓解针对主机的基于DHCPv6的攻击。基于用于网络配置的其他消息（如ICMPv6路由器广告）的攻击向量不由DHCPv6屏蔽本身解决。类似地，DHCPv6 Shield不会减轻针对DHCPv6服务器的攻击（例如，拒绝服务）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
DHCPv6-Shield:
DHCPv6屏蔽：
The set of filtering rules specified in this document, meant to mitigate attacks that employ DHCPv6-server packets.
本文档中指定的一组筛选规则，旨在减轻使用DHCPv6服务器数据包的攻击。
DHCPv6-Shield device:
DHCPv6屏蔽装置：
A layer 2 device (typically a layer 2 switch) that enforces the filtering policy specified in this document.
实施本文档中指定的过滤策略的第2层设备（通常为第2层交换机）。
For the purposes of this document, the terms "IPv6 Extension Header", "First Fragment", "IPv6 Header Chain", and "Upper-Layer Header" are used as specified in [RFC7112]:
在本文件中，术语“IPv6扩展头”、“第一个片段”、“IPv6头链”和“上层头”的使用如[RFC7112]中所述：
IPv6 Extension Header:
IPv6扩展标头：
IPv6 Extension Headers are defined in Section 4 of [RFC2460]. As a result of [RFC7045], [IANA-PROTO] provides a list of assigned Internet Protocol Numbers and designates which of those protocol numbers also represent IPv6 Extension Headers.
[RFC2460]第4节定义了IPv6扩展头。作为[RFC7045]的结果，[IANA-PROTO]提供了一个分配的互联网协议编号列表，并指定其中哪些协议编号也表示IPv6扩展头。
First Fragment:
第一段：
An IPv6 fragment with a Fragment Offset equal to 0.
片段偏移量等于0的IPv6片段。
IPv6 Header Chain:
IPv6头链：
The IPv6 Header Chain contains an initial IPv6 header, zero or more IPv6 Extension Headers, and optionally, a single Upper-Layer Header. If an Upper-Layer Header is present, it terminates the IPv6 Header Chain; otherwise, the "No Next Header" value (Next Header = 59) terminates it.
IPv6报头链包含初始IPv6报头、零个或多个IPv6扩展报头，以及可选的单个上层报头。如果存在上层报头，则终止IPv6报头链；否则，“无下一个标题”值（下一个标题=59）将终止它。
The first member of the IPv6 Header Chain is always an IPv6 header. For a subsequent header to qualify as a member of the IPv6 Header Chain, it must be referenced by the "Next Header" field of the previous member of the IPv6 Header Chain. However, if a second IPv6 header appears in the IPv6 Header Chain, as is the case when IPv6 is tunneled over IPv6, the second IPv6 header is considered to be an Upper-Layer Header and terminates the IPv6 Header Chain. Likewise, if an Encapsulating Security Payload (ESP) header appears in the IPv6 Header Chain, it is considered to be an Upper-Layer Header, and it terminates the IPv6 Header Chain.
IPv6标头链的第一个成员始终是IPv6标头。要使后续标头符合IPv6标头链成员的资格，它必须由IPv6标头链上一个成员的“下一个标头”字段引用。但是，如果第二个IPv6报头出现在IPv6报头链中，如IPv6通过IPv6进行隧道传输时，则第二个IPv6报头将被视为上层报头并终止IPv6报头链。同样，如果封装安全有效负载（ESP）头出现在IPv6头链中，则它被视为上层头，并终止IPv6头链。
Upper-Layer Header:
上层标题：
In the general case, the Upper-Layer Header is the first member of the Header Chain that is neither an IPv6 header nor an IPv6 Extension Header. However, if either an ESP header or a second IPv6 header occurs in the IPv6 Header Chain, it is considered to be an Upper-Layer Header, and it terminates the IPv6 Header Chain.
在一般情况下，上层标头是标头链的第一个成员，它既不是IPv6标头，也不是IPv6扩展标头。但是，如果在IPv6报头链中出现ESP报头或第二个IPv6报头，则将其视为上层报头，并终止IPv6报头链。
Neither the upper-layer payload nor any protocol data following the upper-layer payload is considered to be part of the IPv6 Header Chain. In a simple example, if the Upper-Layer Header is a TCP header, the TCP payload is not part of the IPv6 Header Chain. In a more complex example, if the Upper-Layer Header is an ESP
上层有效负载和上层有效负载之后的任何协议数据都不被视为IPv6头链的一部分。在一个简单的示例中，如果上层报头是TCP报头，则TCP有效负载不是IPv6报头链的一部分。在更复杂的示例中，如果上层标头是ESP
header, neither the payload data nor any of the fields that follow the payload data in the ESP header are part of the IPv6 Header Chain.
标头，ESP标头中的有效负载数据或有效负载数据后面的任何字段都不是IPv6标头链的一部分。
Before being deployed for production, the DHCPv6-Shield device is explicitly configured with respect to which layer 2 ports are allowed to receive DHCPv6 packets destined to DHCPv6 clients (i.e., DHCPv6-server messages). Only those layer 2 ports explicitly configured for such purpose are allowed to receive DHCPv6 packets to pass to DHCPv6 clients.
在部署用于生产之前，DHCPv6屏蔽设备被明确配置为允许接收发送给DHCPv6客户端的DHCPv6数据包的第2层端口（即DHCPv6服务器消息）。只有那些明确为此目的配置的第2层端口才允许接收要传递给DHCPv6客户端的DHCPv6数据包。
Following are the filtering rules that are enforced as part of a DHCPv6-Shield implementation on those ports that are not allowed to receive DHCPv6 packets to DHCPv6 clients:
以下是在不允许向DHCPv6客户端接收DHCPv6数据包的端口上作为DHCPv6屏蔽实现的一部分强制执行的筛选规则：
1. DHCPv6-Shield implementations MUST parse the entire IPv6 Header Chain present in the packet to identify whether or not it is a DHCPv6 packet meant for a DHCPv6 client (i.e., a DHCPv6-server message).
1. DHCPv6屏蔽实现必须解析数据包中存在的整个IPv6报头链，以确定它是否是针对DHCPv6客户端的DHCPv6数据包（即，DHCPv6服务器消息）。
RATIONALE: DHCPv6-Shield 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 negatives: DHCP6-server packets received on ports not allowed to receive such packets could be allowed simply because the DHCPv6-Shield device does not parse the entire IPv6 Header Chain present in the packet.
理由：DHCPv6屏蔽实现不得对其可检查的字节数实施限制（从IPv6数据包的开头开始），因为这可能会导致误报：在不允许接收此类数据包的端口上接收的DHCP6服务器数据包可能会被允许，因为DHCPv6屏蔽设备不会解析数据包中存在的整个IPv6报头链。
2. 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), DHCPv6-Shield MUST drop the packet and ought to log the packet drop event in an implementation-specific manner as a security fault.
2. 解析IPv6报头链时，如果该数据包是第一个片段（即，包含片段偏移量设置为0的片段报头的数据包），并且它无法包含整个IPv6报头链（即，从IPv6报头开始直到并包括上层报头的所有报头），DHCPv6 Shield必须丢弃数据包，并且应该以特定于实现的方式将数据包丢弃事件记录为安全故障。
RATIONALE: Packets that fail to contain the entire IPv6 Header Chain could otherwise be leveraged for circumventing DHCPv6-Shield. [RFC7112] requires that the First Fragment (i.e., the fragment with the Fragment Offset set to 0) contain the entire IPv6 Header Chain. [RFC7112] also allows intermediate systems such as routers to drop packets that fail to comply with this requirement.
理由：无法包含整个IPv6头链的数据包可能会被用来绕过DHCPv6屏蔽。[RFC7112]要求第一个片段（即片段偏移量设置为0的片段）包含整个IPv6头链。[RFC7112]还允许路由器等中间系统丢弃不符合此要求的数据包。
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 DHCPv6 packet meant for a DHCPv6 client received on a port where such packets are not allowed).
注意：此规则应仅适用于片段偏移量为0的IPv6片段（可以安全地传递非第一个片段，因为如果它们是DHCPv6数据包的一部分，则它们永远不会重新组合成完整的数据报，该数据包是在不允许此类数据包的端口上接收到的DHCPv6客户端的数据包）。
3. DHCPv6-Shield MUST provide a configuration knob that controls whether or not packets with unrecognized Next Header values are dropped; this configuration knob MUST default to "drop". When parsing the IPv6 Header Chain, if the packet contains an unrecognized Next Header value and the configuration knob is configured to "drop", DHCPv6-Shield MUST drop the packet and ought to log the packet drop event in an implementation-specific manner as a security fault.
3. DHCPv6 Shield必须提供一个配置旋钮，用于控制是否丢弃具有无法识别的下一个报头值的数据包；此配置旋钮必须默认为“下降”。解析IPv6报头链时，如果数据包包含无法识别的下一个报头值，并且配置旋钮配置为“丢弃”，DHCPv6 Shield必须丢弃数据包，并应以特定于实现的方式将数据包丢弃事件记录为安全故障。
RATIONALE: An unrecognized Next Header value could possibly identify an IPv6 Extension Header and thus be leveraged to conceal a DHCPv6-server packet (since there is no way for DHCPv6-Shield to parse past unrecognized Next Header values [IPV6-UEH]). [RFC7045] requires that nodes be configurable with respect to whether or not packets with unrecognized headers are forwarded and allows the default behavior to be that such packets be dropped.
理由：无法识别的下一个报头值可能会识别IPv6扩展报头，从而被用来隐藏DHCPv6服务器数据包（因为DHCPv6屏蔽无法解析过去无法识别的下一个报头值[IPv6-UEH]）。[RFC7045]要求节点可配置是否转发具有未识别头的数据包，并允许默认行为为丢弃此类数据包。
4. When parsing the IPv6 Header Chain, if the packet is identified to be a DHCPv6 packet meant for a DHCPv6 client, DHCPv6-Shield MUST drop the packet and SHOULD log the packet drop event in an implementation-specific manner as a security alert.
4. 解析IPv6报头链时，如果该数据包被标识为针对DHCPv6客户端的DHCPv6数据包，则DHCPv6 Shield必须丢弃该数据包，并应以特定于实现的方式将数据包丢弃事件记录为安全警报。
RATIONALE: Ultimately, the goal of DHCPv6-Shield is to drop DHCPv6 packets destined to DHCPv6 clients (i.e., DHCPv6-server messages) that are received on ports that have not been explicitly configured to allow the receipt of such packets.
理由：最终，DHCPv6屏蔽的目标是丢弃发送给DHCPv6客户端的DHCPv6数据包（即DHCPv6服务器消息），这些数据包是在未明确配置为允许接收此类数据包的端口上接收的。
5. In all other cases, DHCPv6-Shield MUST pass the packet as usual.
5. 在所有其他情况下，DHCPv6屏蔽必须像往常一样传递数据包。
NOTE: For the purpose of enforcing the DHCPv6-Shield filtering policy, an 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 DHCPv6-Shield 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 DHCPv6 message, what to do with such a packet is up to the receiving host.
注意：为了实施DHCPv6屏蔽过滤策略，ESP头[RFC4303]应被视为“上层协议”（即，应被视为IPv6头链中的最后一个头）。这意味着使用ESP的数据包将由DHCPv6屏蔽设备传递到预期目的地。如果目标主机与前述IPv6数据包的发送方没有安全关联，则该数据包将被丢弃。否则，如果接收主机上的IPsec实现认为该数据包有效并封装了DHCPv6消息，则如何处理该数据包取决于接收主机。
The rules above indicate that if a packet is dropped due to this filtering policy, the packet drop event should be logged in an implementation-specific manner as a security fault. It is useful for the logging mechanism to include a per-port drop counter dedicated to DHCPv6-Shield packet drops.
上述规则表明，如果由于此过滤策略而丢弃数据包，则应以特定于实现的方式将数据包丢弃事件记录为安全故障。日志机制包括专用于DHCPv6屏蔽数据包丢弃的每端口丢弃计数器非常有用。
In order to protect current end-node IPv6 implementations, Rule #2 has been defined such that the default is for packets that cannot be positively identified as not being DHCPv6-server packets (because the packet is a fragment that fails to include the entire IPv6 Header Chain) to be dropped. This means that, at least in theory, DHCPv6-Shield could result in false-positive blocking of some legitimate (non-DHCPv6-server) packets. However, as noted in [RFC7112], IPv6 packets that fail to include the entire IPv6 Header Chain are virtually impossible to police with stateless filters and firewalls; hence, they 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实施，已定义了规则#2，以便默认情况下，对于无法被肯定地识别为不是DHCPv6服务器数据包的数据包（因为该数据包是一个无法包含整个IPv6头链的片段），将被丢弃。这意味着，至少在理论上，DHCPv6屏蔽可能导致某些合法（非DHCPv6-server）数据包的误报阻塞。然而，如[RFC7112]中所述，无法包含整个IPv6头链的IPv6数据包实际上不可能通过无状态过滤器和防火墙进行监控；因此，它们不太可能在真实的网络中生存。[RFC7112]要求采用分段的主机在第一个分段（分段偏移量设置为0的分段）中包含整个IPv6头链，从而消除上述误报。
The aforementioned filtering rules implicitly handle the case of fragmented packets: if the DHCPv6-Shield device fails to identify the upper-layer protocol as a result of the use of fragmentation, the corresponding packets would be dropped.
上述过滤规则隐式地处理分段数据包的情况：如果DHCPv6屏蔽设备由于使用分段而无法识别上层协议，则相应的数据包将被丢弃。
Finally, we note that IPv6 implementations that allow overlapping fragments (i.e., that do not comply with [RFC5722]) might still be subject of DHCPv6-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实现可能仍然受到基于DHCPv6的攻击。然而，最近对IPv6实现[SI6-FRAG]的碎片重组策略的评估似乎表明，大多数当前实现符合[RFC5722]。
The recommendations in this document represent the ideal behavior of a DHCPv6-Shield device. However, in order to implement DHCPv6-Shield on the fast path, it may be necessary to limit the depth into the packet that can be scanned before giving up. In circumstances where there is such a limitation, it is recommended that implementations drop packets after attempting to find a protocol header up to that limit, whatever it is. Ideally, such devices should be configurable with a list of protocol header identifiers so that if new transport protocols are standardized after the device is released, they can be added to the list of protocol header types that the device recognizes. Since any protocol header that is not a UDP header would be passed by the DHCPv6-Shield algorithm, this would allow such devices to avoid blocking the use of new transport protocols. When
本文件中的建议代表了DHCPv6屏蔽设备的理想性能。然而，为了在快速路径上实现DHCPv6屏蔽，可能需要限制在放弃之前可以扫描的数据包的深度。在存在此类限制的情况下，建议实现在尝试查找达到该限制的协议头（无论是什么）后丢弃数据包。理想情况下，此类设备应可配置协议头标识符列表，以便在设备发布后，如果新的传输协议被标准化，则可以将其添加到设备识别的协议头类型列表中。由于任何不是UDP报头的协议报头都将由DHCPv6 Shield算法传递，这将允许此类设备避免阻止使用新的传输协议。什么时候
an implementation must stop searching for recognizable header types in a packet due to such limitations, the device SHOULD be configurable to either pass or drop that packet.
由于此类限制，实现必须停止在数据包中搜索可识别的报头类型，设备应可配置为传递或丢弃该数据包。
The mechanism specified in this document can be used to mitigate DHCPv6-based attacks against hosts. Attack vectors based on other messages meant for network configuration (such as ICMPv6 Router Advertisements) are out of the scope of this document. Additionally, the mechanism specified in this document does not mitigate attacks against DHCPv6 servers (e.g., Denial of Service).
本文档中指定的机制可用于减轻针对主机的基于DHCPv6的攻击。基于用于网络配置的其他消息（如ICMPv6路由器广告）的攻击向量不在本文档范围内。此外，本文档中指定的机制不会减轻针对DHCPv6服务器的攻击（例如，拒绝服务）。
If deployed in a layer 2 domain with several cascading switches, there will be an ingress port on the host's local switch that will need to be enabled for receiving DHCPv6-server messages. However, this local switch will be reliant on the upstream devices filtering out rogue DHCPv6-server messages, as the local switch has no way of determining which upstream DHCP-server messages are valid. Therefore, in order to be effective, DHCPv6-Shield should be deployed and enabled on all layer 2 switches of a given layer 2 domain.
如果部署在具有多个级联交换机的第2层域中，则主机的本地交换机上将有一个入口端口，需要启用该端口以接收DHCPv6服务器消息。但是，由于本地交换机无法确定哪些上游DHCP服务器消息有效，因此该本地交换机将依赖于过滤掉恶意DHCPv6服务器消息的上游设备。因此，为了有效，应该在给定的第2层域的所有第2层交换机上部署并启用DHCPv6屏蔽。
As noted in Section 5, IPv6 implementations that allow overlapping fragments (i.e., that do not comply with [RFC5722]) might still be subject to DHCPv6-based attacks. However, most current implementations seem to comply with [RFC5722] and hence forbid IPv6 overlapping fragments.
如第5节所述，允许重叠片段（即不符合[RFC5722]）的IPv6实现可能仍会受到基于DHCPv6的攻击。然而，大多数当前的实现似乎符合[RFC5722]，因此禁止IPv6重叠片段。
We note that if an attacker sends a fragmented DHCPv6 packet on a port not allowed to receive 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 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 a forged fragmented datagram in which at least one of the fragments is missing. [CPNI-IPv6] discusses some resource management strategies that could be implemented for the fragment reassembly buffer.
我们注意到，如果攻击者在不允许接收此类数据包的端口上发送一个分段的DHCPv6数据包，则第一个片段将被丢弃，其余片段将被传递。这意味着受害节点将为上述片段绑定内存缓冲区，这些片段永远不会重新组装成完整的数据报。如果攻击者发送了大量此类数据包，而受害节点未能对片段重组缓冲区实施适当的资源管理，则可能导致拒绝服务（DoS）。然而，这并不真正引入新的攻击向量，因为攻击者可以通过发送一个伪造的碎片数据报来执行相同的攻击，其中至少有一个片段丢失。[CPNI-IPv6]讨论了可用于片段重组缓冲区的一些资源管理策略。
Additionally, we note that the security of a site employing DHCPv6-Shield could be further improved by deploying [RFC7513] to mitigate IPv6 address spoofing attacks.
此外，我们注意到，通过部署[RFC7513]来减轻IPv6地址欺骗攻击，可以进一步提高使用DHCPv6屏蔽的站点的安全性。
Finally, we note that other mechanisms for mitigating attacks based on DHCPv6-server messages are available that have different deployment considerations. For example, [SECURE-DHCPV6] allows for authentication of DHCPv6-server packets if the IPv6 addresses of the DHCPv6 servers can be pre-configured at the client nodes.
最后，我们注意到，其他基于DHCPv6服务器消息的缓解攻击的机制具有不同的部署考虑。例如，[SECURE-DHCPV6]允许对DHCPV6服务器数据包进行身份验证，前提是可以在客户端节点上预先配置DHCPV6服务器的IPv6地址。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，DOI 10.17487/RFC4303，2005年12月<http://www.rfc-editor.org/info/rfc4303>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, DOI 10.17487/RFC5722, December 2009, <http://www.rfc-editor.org/info/rfc5722>.
[RFC5722]Krishnan，S.，“重叠IPv6片段的处理”，RFC 5722，DOI 10.17487/RFC5722，2009年12月<http://www.rfc-editor.org/info/rfc5722>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, <http://www.rfc-editor.org/info/rfc7045>.
[RFC7045]Carpenter，B.和S.Jiang，“IPv6扩展头的传输和处理”，RFC 7045，DOI 10.17487/RFC70452013年12月<http://www.rfc-editor.org/info/rfc7045>.
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, DOI 10.17487/RFC7112, January 2014, <http://www.rfc-editor.org/info/rfc7112>.
[RFC7112]Gont，F.，Manral，V.，和R.Bonica，“超大IPv6头链的影响”，RFC 7112，DOI 10.17487/RFC7112，2014年1月<http://www.rfc-editor.org/info/rfc7112>.
[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）的安全评估”，英国国家基础设施保护中心（可根据要求提供）。
[IANA-PROTO] IANA, "Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers>.
[IANA-PROTO]IANA，“协议编号”<http://www.iana.org/assignments/protocol-numbers>.
[IPV6-UEH] Gont, F., Liu, W., Krishnan, S., and H. Pfeifer, "IPv6 Universal Extension Header", Work in Progress, draft-gont-6man-rfc6564bis-00, April 2014.
[IPV6-UEH]Gont，F.，Liu，W.，Krishnan，S.，和H.Pfeifer，“IPV6通用扩展头”，正在进行的工作，草稿-Gont-6man-rfc6564bis-00，2014年4月。
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, DOI 10.17487/RFC6104, February 2011, <http://www.rfc-editor.org/info/rfc6104>.
[RFC6104]Chown，T.和S.Venaas，“流氓IPv6路由器广告问题声明”，RFC 6104，DOI 10.17487/RFC6104，2011年2月<http://www.rfc-editor.org/info/rfc6104>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, <http://www.rfc-editor.org/info/rfc6105>.
[RFC6105]Levy Abegnoli，E.，Van de Velde，G.，Popoviciu，C.，和J.Mohacsi，“IPv6路由器广告保护”，RFC 6105DOI 10.17487/RFC6105，2011年2月<http://www.rfc-editor.org/info/rfc6105>.
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, DOI 10.17487/RFC7113, February 2014, <http://www.rfc-editor.org/info/rfc7113>.
[RFC7113]Gont，F.，“IPv6路由器广告防护（RA防护）的实施建议”，RFC 7113，DOI 10.17487/RFC7113，2014年2月<http://www.rfc-editor.org/info/rfc7113>.
[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, <http://www.rfc-editor.org/info/rfc7513>.
[RFC7513]Bi，J.，Wu，J.，Yao，G.，和F.Baker，“DHCP源地址验证改进（SAVI）解决方案”，RFC 7513，DOI 10.17487/RFC7513，2015年5月<http://www.rfc-editor.org/info/rfc7513>.
[SECURE-DHCPV6] Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", Work in Progress, draft-ietf-dhc-secure-dhcpv6-07, September 2012.
[SECURE-DHCPV6]Jiang，S.和S.Shen，“使用CGAs保护DHCPV6”，正在进行的工作，草稿-ietf-dhc-SECURE-DHCPV6-072012年9月。
[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规避和改进。
Acknowledgements
致谢
The authors would like to thank Mike Heard, who provided detailed feedback on earlier draft versions of this document and helped a lot in producing a technically sound document throughout the whole publication process.
作者要感谢Mike Heard，他对本文件的早期草稿提供了详细的反馈，并在整个出版过程中帮助制作了一份技术上可靠的文件。
The authors would like to thank (in alphabetical order) Ben Campbell, Jean-Michel Combes, Sheng Jiang, Ted Lemon, Pete Resnick, Carsten Schmoll, Juergen Schoenwaelder, Robert Sleigh, Donald Smith, Mark Smith, Hannes Tschofenig, Eric Vyncke, and Qin Wu for providing valuable comments on earlier draft versions of this document.
作者要感谢（按字母顺序排列）本·坎贝尔、让·米歇尔·库姆斯、盛江、特德·莱蒙、皮特·雷斯尼克、卡斯滕·施莫尔、尤尔根·舍恩瓦埃尔德、罗伯特·斯莱、唐纳德·史密斯、马克·史密斯、汉内斯·茨霍芬尼、埃里克·温克和秦武对本文件早期草稿提出了宝贵意见。
Part of Section 3 of this document was borrowed from [RFC7112], authored by Fernando Gont, Vishwas Manral, and Ron Bonica.
本文件第3节的部分内容借用自[RFC7112]，作者为费尔南多·贡特、维什瓦·曼拉尔和罗恩·博尼卡。
This document is heavily based on [RFC7113], authored by Fernando Gont. Thus, the authors would like to thank the following individuals for providing valuable comments on [RFC7113]: 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.
本文档主要基于Fernando Gont编写的[RFC7113]。因此，作者要感谢以下个人对[RFC7113]提供了宝贵的意见：冉·阿特金森、卡尔·奥尔、罗伯特·唐尼、瓦萨姆·范、大卫·法默、迈克·赫德、马克·豪斯、尼克·希利亚德、雷·亨特、乔尔·杰格利、西蒙·佩雷尔特、阿图罗·塞文、冈特·范德维尔德、詹姆斯·伍迪亚特和比约恩·泽布。
The authors would like to thank Joel Jaeggli for his advice and guidance throughout the IETF process.
作者要感谢Joel Jaeggli在整个IETF过程中提供的建议和指导。
Fernando Gont would like to thank Diego Armando Maradona for his magic and inspiration.
费尔南多·贡特感谢迭戈·阿曼多·马拉多纳的魔力和灵感。
Authors' Addresses
作者地址
Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont SI6 Networks/UTN-FRH Evaristo Carriego 2644 Haedo，布宜诺斯艾利斯省1706阿根廷
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Will (Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 China
威尔（舒城）刘华威科技有限公司深圳市龙岗区坂田518129
Email: liushucheng@huawei.com
Email: liushucheng@huawei.com
Gunter Van de Velde Alcatel-Lucent Copernicuslaan 50 Antwerp, Antwerp 2018 Belgium
Gunter Van de Velde Alcatel-Lucent哥白尼50安特卫普，安特卫普2018比利时
Phone: +32 476 476 022
Email: gunter.van_de_velde@alcatel-lucent.com
Phone: +32 476 476 022
Email: gunter.van_de_velde@alcatel-lucent.com