Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6980 SI6 Networks / UTN-FRH
Updates: 3971, 4861 August 2013
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6980 SI6 Networks / UTN-FRH
Updates: 3971, 4861 August 2013
Category: Standards Track
ISSN: 2070-1721
Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery
IPv6邻居发现中IPv6碎片的安全含义
Abstract
摘要
This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective countermeasures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated.
本文档分析了在邻居发现（ND）消息中使用IPv6分段的安全含义。它更新了RFC 4861，以便在所有邻居发现消息中禁止使用IPv6分段头，从而允许对邻居发现攻击采取简单有效的对策。最后，本文讨论了将IPv6分段与安全邻居发现（SEND）结合使用的安全影响，并正式更新了RFC 3971，以提供有关如何减轻上述安全影响的建议。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6980.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6980.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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. Traditional Neighbor Discovery and IPv6 Fragmentation ...........4
3. SEcure Neighbor Discovery (SEND) and IPv6 Fragmentation .........5
4. Rationale for Forbidding IPv6 Fragmentation in Neighbor
Discovery .......................................................6
5. Specification ...................................................6
6. Operational Advice ..............................................7
7. Security Considerations .........................................7
8. Acknowledgements ................................................8
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................9
Appendix A. Message Size When Carrying Certificates ...............10
1. Introduction ....................................................2
2. Traditional Neighbor Discovery and IPv6 Fragmentation ...........4
3. SEcure Neighbor Discovery (SEND) and IPv6 Fragmentation .........5
4. Rationale for Forbidding IPv6 Fragmentation in Neighbor
Discovery .......................................................6
5. Specification ...................................................6
6. Operational Advice ..............................................7
7. Security Considerations .........................................7
8. Acknowledgements ................................................8
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................9
Appendix A. Message Size When Carrying Certificates ...............10
The Neighbor Discovery Protocol (NDP) is specified in RFC 4861 [RFC4861]. It is used by both hosts and routers. Its functions include Neighbor Discovery (ND), Router Discovery (RD), address autoconfiguration, address resolution, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and redirection.
RFC 4861[RFC4861]中规定了邻居发现协议（NDP）。主机和路由器都使用它。它的功能包括邻居发现（ND）、路由器发现（RD）、地址自动配置、地址解析、邻居不可达性检测（NUD）、重复地址检测（DAD）和重定向。
Many of the possible attacks against the Neighbor Discovery Protocol are discussed in detail in [RFC3756]. In order to mitigate the aforementioned possible attacks, SEcure Neighbor Discovery (SEND) was standardized. SEND employs a number of mechanisms to certify the origin of Neighbor Discovery packets and the authority of routers, and to protect Neighbor Discovery packets from being the subject of modification or replay attacks.
[RFC3756]中详细讨论了许多可能针对邻居发现协议的攻击。为了减轻上述可能的攻击，安全邻居发现（SEND）被标准化。SEND使用多种机制来验证邻居发现数据包的来源和路由器的权限，并保护邻居发现数据包不受修改或重放攻击。
However, a number of factors, such as the high administrative overhead of deploying trust anchors and the unavailability of SEND implementations for many widely deployed operating systems, make SEND hard to deploy [Gont-DPSC]. Thus, in many general scenarios, it may be necessary and/or convenient to use other mitigation techniques for NDP-based attacks. The following mitigations are currently available for NDP attacks:
然而，许多因素，例如部署信任锚的高管理开销以及许多广泛部署的操作系统无法使用SEND实现，使得SEND难以部署[Gont-DPSC]。因此，在许多一般情况下，可能需要和/或方便使用其他缓解技术来应对基于NDP的攻击。以下缓解措施目前可用于NDP攻击：
o Static Access Control Lists (ACLs) in switches
o 交换机中的静态访问控制列表（ACL）
o Layer-2 filtering of Neighbor Discovery packets (such as RA-Guard [RFC6105])
o 邻居发现数据包的第二层过滤（如RA Guard[RFC6105]）
o Neighbor Discovery monitoring tools (e.g., NDPMon [NDPMon] and ramond [ramond])
o 邻居发现监视工具（例如，NDPMon[NDPMon]和ramond[ramond]）
o Intrusion Prevention Systems (IPS)
o 入侵防御系统（IPS）
IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique for attack vectors based on ICMPv6 Router Advertisement (RA) messages. It is meant to block attack packets at a layer-2 device before the attack packets actually reach the target nodes. [RFC6104] describes the problem statement of "Rogue IPv6 Router Advertisements", and [RFC6105] specifies the "IPv6 Router Advertisement Guard" functionality.
IPv6路由器广告防护（RA防护）是一种基于ICMPv6路由器广告（RA）消息的攻击向量缓解技术。这意味着在攻击包实际到达目标节点之前，在第2层设备上阻止攻击包。[RFC6104]描述了“恶意IPv6路由器广告”的问题陈述，[RFC6105]指定了“IPv6路由器广告保护”功能。
Tools such as NDPMon [NDPMon] and ramond [ramond] aim to monitor Neighbor Discovery traffic in the hopes of detecting possible attacks when there are discrepancies between the information advertised in Neighbor Discovery packets and the information stored on a local database.
诸如NDPMon[NDPMon]和ramond[ramond]之类的工具旨在监控邻居发现流量，以期在邻居发现数据包中公布的信息与本地数据库中存储的信息之间存在差异时检测可能的攻击。
Some Intrusion Prevention Systems (IPS) can mitigate Neighbor Discovery attacks. We recommend that Intrusion Prevention Systems implement mitigations for NDP attacks.
一些入侵防御系统（IPS）可以减轻邻居发现攻击。我们建议入侵预防系统对NDP攻击实施缓解措施。
IPv6 fragmentation introduces a key challenge for these mitigation or monitoring techniques, since it is trivial for an attacker to conceal his attack by fragmenting his packets into multiple fragments. This may limit or even eliminate the effectiveness of the aforementioned mitigation or monitoring techniques. Recent work [CPNI-IPv6] indicates that current implementations of the aforementioned mitigations for NDP attacks can be trivially evaded. For example, as noted in [RA-GUARD], current RA-Guard implementations can be trivially evaded by fragmenting the attack packets into multiple fragments, such that the layer-2 device cannot find all the necessary information to perform packet filtering in the same packet. While Neighbor Discovery monitoring tools could (in theory) implement IPv6
IPv6碎片化为这些缓解或监控技术带来了一个关键挑战，因为攻击者通过将数据包碎片化为多个碎片来隐藏其攻击是微不足道的。这可能会限制甚至消除上述缓解或监测技术的有效性。最近的工作[CPNI-IPv6]表明，上述NDP攻击缓解措施的当前实现可以很容易地避免。例如，如[RA-GUARD]中所述，当前的RA-GUARD实现可以通过将攻击数据包分割成多个片段来规避，从而第2层设备无法在同一数据包中找到执行数据包过滤所需的所有信息。而邻居发现监控工具（理论上）可以实现IPv6
fragment reassembly, this is usually an arms-race with the attacker (an attacker can generate lots of forged fragments to "confuse" the monitoring tools), and therefore the aforementioned tools are unreliable for the detection of such attacks.
碎片重组，这通常是与攻击者的军备竞赛（攻击者可以生成大量伪造碎片以“混淆”监控工具），因此上述工具对于检测此类攻击是不可靠的。
Section 2 analyzes the use of IPv6 fragmentation in traditional Neighbor Discovery. Section 3 analyzes the use of IPv6 fragmentation in SEcure Neighbor Discovery (SEND). Section 4 provides the rationale for forbidding the use of IPv6 fragmentation with Neighbor Discovery. Section 5 formally updates RFC 4861 such that the use of the IPv6 Fragment Header with traditional Neighbor Discovery is forbidden, and also formally updates RFC 3971 by providing advice on the use of IPv6 fragmentation with SEND. Section 6 provides operational advice about interoperability problems arising from the use of IPv6 fragmentation with Neighbor Discovery.
第2节分析了IPv6分段在传统邻居发现中的使用。第3节分析了IPv6分段在安全邻居发现（SEND）中的使用。第4节提供了禁止在邻居发现中使用IPv6分段的基本原理。第5节正式更新了RFC 4861，从而禁止将IPv6片段头与传统邻居发现一起使用，并通过提供有关使用IPv6片段与发送的建议，正式更新了RFC 3971。第6节提供了有关在邻居发现中使用IPv6碎片时产生的互操作性问题的操作建议。
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]中所述进行解释。
The only potential use case for IPv6 fragmentation with traditional (i.e., non-SEND) IPv6 Neighbor Discovery would be that in which a Router Advertisement must include a large number of options (Prefix Information Options, Route Information Options, etc.). However, this could still be achieved without employing fragmentation, by splitting the aforementioned information into multiple Router Advertisement messages.
使用传统（即非发送）IPv6邻居发现进行IPv6分段的唯一潜在使用情形是，路由器公告必须包括大量选项（前缀信息选项、路由信息选项等）。然而，这仍然可以在不采用分段的情况下通过将上述信息分割成多个路由器广告消息来实现。
Some Neighbor Discovery implementations are known to silently ignore Router Advertisement messages that employ fragmentation. Therefore, splitting the necessary information into multiple RA messages (rather than sending a large RA message that is fragmented into multiple IPv6 fragments) is probably desirable even from an interoperability point of view.
已知一些邻居发现实现会静默地忽略使用碎片的路由器广告消息。因此，即使从互操作性的角度来看，也可能需要将必要的信息拆分为多个RA消息（而不是发送分为多个IPv6片段的大型RA消息）。
Thus, avoiding the use of IPv6 fragmentation in traditional Neighbor Discovery would greatly simplify and improve the effectiveness of monitoring and filtering Neighbor Discovery traffic and would also prevent interoperability problems with those implementations that do not support fragmentation in Neighbor Discovery messages.
因此，避免在传统邻居发现中使用IPv6分段将大大简化和提高监视和过滤邻居发现流量的有效性，还将防止与那些不支持邻居发现消息中分段的实现的互操作性问题。
SEND packets typically carry more information than traditional Neighbor Discovery packets: for example, they include additional options such as the Cryptographically Generated Address (CGA) option and the RSA signature option.
发送数据包通常比传统的邻居发现数据包携带更多的信息：例如，它们包括额外的选项，如加密生成地址（CGA）选项和RSA签名选项。
When SEND nodes employ any of the Neighbor Discovery messages specified in [RFC4861], the situation is roughly the same: if more information than would fit in a non-fragmented Neighbor Discovery packet needs to be sent, it should be split into multiple Neighbor Discovery messages (such that IPv6 fragmentation is avoided).
当发送节点使用[RFC4861]中指定的任何邻居发现消息时，情况大致相同：如果需要发送的信息超过非碎片化邻居发现数据包中的信息量，则应将其拆分为多个邻居发现消息（从而避免IPv6碎片化）。
However, Certification Path Advertisement (CPA) messages (specified in [RFC3971]) pose a different situation, since the Certificate Option they include typically contains much more information than any other Neighbor Discovery option. For example, Appendix C of [RFC3971] reports Certification Path Advertisement messages from 1050 to 1066 bytes on an Ethernet link layer. Since the size of CPA messages could potentially exceed the MTU of the local link, Section 5 recommends that fragmented CPA messages be processed normally, but discourages the use of keys that would result in fragmented CPA messages.
但是，证书路径公布（CPA）消息（在[RFC3971]中指定）会造成不同的情况，因为它们包含的证书选项通常比任何其他邻居发现选项包含更多的信息。例如，[RFC3971]的附录C报告了以太网链路层上1050到1066字节的认证路径公告消息。由于CPA消息的大小可能超过本地链路的MTU，第5节建议正常处理分段CPA消息，但不鼓励使用可能导致分段CPA消息的密钥。
It should be noted that relying on fragmentation opens the door to a variety of IPv6 fragmentation-based attacks against SEND. In particular, if an attacker is located on the same broadcast domain as the victim host and Certification Path Advertisement messages employ IPv6 fragmentation, it would be trivial for the attacker to forge IPv6 fragments such that they result in "Fragment ID collisions", causing both the attack fragments and the legitimate fragments to be discarded by the victim node. This would eventually cause Authorization Delegation Discovery (Section 6 of [RFC3971]) to fail, thus leading the host to (depending on local configuration) either fall back to unsecured mode or reject the corresponding Router Advertisement messages (possibly resulting in a denial of service).
应该注意的是，依赖碎片为针对SEND的各种基于IPv6碎片的攻击打开了大门。特别是，如果攻击者与受害者主机位于同一广播域上，并且认证路径公告消息使用IPv6碎片，则攻击者伪造IPv6碎片以导致“碎片ID冲突”的行为将是微不足道的，导致受害者节点丢弃攻击碎片和合法碎片。这最终将导致授权委托发现（RFC3971第6节）失败，从而导致主机（取决于本地配置）返回到不安全模式或拒绝相应的路由器公告消息（可能导致拒绝服务）。
A number of considerations should be made regarding the use of IPv6 fragmentation with Neighbor Discovery:
在邻居发现中使用IPv6碎片时，应考虑以下几点：
o A significant number of existing implementations already silently drop fragmented ND messages, so the use of IPv6 fragmentation may hamper interoperability among IPv6 implementations.
o 大量现有的实现已经悄悄地丢弃了分段的ND消息，因此使用IPv6分段可能会妨碍IPv6实现之间的互操作性。
o Although it is possible to build an ND message that needs to be fragmented, such packets are unlikely to exist in the real world because of the large number of options that would be required for the resulting packet to exceed the minimum IPv6 MTU of 1280 octets.
o 尽管可以构建需要分段的ND消息，但由于生成的数据包超过1280个八位字节的最小IPv6 MTU需要大量选项，因此此类数据包不太可能存在于现实世界中。
o If an ND message was so large as to need fragmentation, there is an option to distribute the same information amongst more than one message, each of which is small enough to not need fragmentation.
o 如果ND消息太大以至于需要分段，那么可以选择在多个消息之间分发相同的信息，每个消息都足够小，不需要分段。
Thus, forbidding the use of IPv6 fragmentation with Neighbor Discovery normalizes existing behavior and sets the expectations of all implementations to the existing lowest common denominator.
因此，禁止在邻居发现中使用IPv6分段将规范现有行为，并将所有实现的期望值设置为现有的最低公分母。
Nodes MUST NOT employ IPv6 fragmentation for sending any of the following Neighbor Discovery and SEcure Neighbor Discovery messages:
节点不得使用IPv6碎片发送以下任何邻居发现和安全邻居发现消息：
o Neighbor Solicitation
o 邻居请求
o Neighbor Advertisement
o 邻居广告
o Router Solicitation
o 路由器请求
o Router Advertisement
o 路由器通告
o Redirect
o 重新使用
o Certification Path Solicitation
o 认证路径请求
Nodes SHOULD NOT employ IPv6 fragmentation for sending the following messages (see Section 6.4.2 of [RFC3971]):
节点不应使用IPv6分段发送以下消息（请参阅[RFC3971]第6.4.2节）：
o Certification Path Advertisement
o 认证路径广告
Nodes MUST silently ignore the following Neighbor Discovery and SEcure Neighbor Discovery messages if the packets carrying them include an IPv6 Fragmentation Header:
如果承载以下邻居发现和安全邻居发现消息的数据包包含IPv6分段头，则节点必须以静默方式忽略这些消息：
o Neighbor Solicitation
o 邻居请求
o Neighbor Advertisement
o 邻居广告
o Router Solicitation
o 路由器请求
o Router Advertisement
o 路由器通告
o Redirect
o 重新使用
o Certification Path Solicitation
o 认证路径请求
Nodes SHOULD normally process the following messages when the packets carrying them include an IPv6 Fragmentation Header:
当承载节点的数据包包含IPv6分段标头时，节点通常应处理以下消息：
o Certification Path Advertisement
o 认证路径广告
SEND nodes SHOULD NOT employ keys that would result in fragmented CPA messages.
发送节点不应使用会导致CPA消息碎片的密钥。
An operator detecting that Neighbor Discovery traffic is being silently dropped should find whether the corresponding Neighbor Discovery messages are employing IPv6 fragmentation. If they are, it is likely that the devices receiving such packets are silently dropping them merely because they employ IPv6 fragmentation. In such a case, an operator should check whether the sending device has an option to prevent fragmentation of ND messages, and/or see whether it is possible to reduce the options carried on such messages. We note that solving this (unlikely) problem might require a software upgrade to a version that does not employ IPv6 fragmentation with Neighbor Discovery.
检测到邻居发现通信正在被静默丢弃的操作员应查找相应的邻居发现消息是否使用IPv6分段。如果是，则接收此类数据包的设备很可能只是因为采用了IPv6分段而默默地丢弃这些数据包。在这种情况下，操作员应检查发送设备是否具有防止ND消息分段的选项，和/或查看是否可能减少此类消息上携带的选项。我们注意到，解决这个（不太可能的）问题可能需要将软件升级到不使用IPv6分段和邻居发现的版本。
The IPv6 Fragmentation Header can be leveraged to circumvent network monitoring tools and current implementations of mechanisms such as RA-Guard [RA-GUARD]. By updating the relevant specifications such that the IPv6 Fragment Header is not allowed in any Neighbor Discovery messages except Certification Path Advertisement messages, protection of local nodes against Neighbor Discovery attacks, as well as the monitoring of Neighbor Discovery traffic, are greatly simplified.
IPv6分段头可以用来绕过网络监视工具和当前的机制实现，如RA-Guard[RA-Guard]。通过更新相关规范，使得除认证路径公告消息外，任何邻居发现消息中都不允许使用IPv6片段头，从而大大简化了本地节点对邻居发现攻击的保护以及邻居发现流量的监控。
As noted in Section 3, the use of SEND could potentially result in fragmented Certification Path Advertisement messages, thus allowing an attacker to employ IPv6 fragmentation-based attacks against such messages. Therefore, to the extent that is possible, such use of fragmentation should be avoided.
如第3节所述，使用SEND可能导致证书路径广告消息碎片化，从而允许攻击者对此类消息采用基于IPv6碎片化的攻击。因此，应尽可能避免使用碎片。
The author would like to thank (in alphabetical order) Mikael Abrahamsson, Ran Atkinson, Ron Bonica, Jean-Michel Combes, David Farmer, Adrian Farrel, Stephen Farrell, Roque Gagliano, Brian Haberman, Bob Hinden, Philip Homburg, Ray Hunter, Arturo Servin, Mark Smith, and Martin Stiemerling for providing valuable comments on earlier versions of this document.
作者要感谢（按字母顺序排列）米凯尔·阿布拉罕松、冉·阿特金森、罗恩·博尼卡、让·米歇尔·库姆斯、大卫·法默、阿德里安·法雷尔、斯蒂芬·法雷尔、罗克·加利亚诺、布莱恩·哈伯曼、鲍勃·欣登、菲利普·霍姆伯格、雷·亨特、阿图罗·塞文、马克·史密斯、，以及Martin Stiemerling对本文件早期版本提供了宝贵的意见。
The author would also like to thank Roque Gagliano for contributing the information regarding message sizes in Appendix A, and Arturo Servin for presenting this document at IETF 81.
作者还要感谢Roque Gagliano在附录A中提供了有关消息大小的信息，以及Arturo Servin在IETF 81上介绍了本文件。
Finally, the author would like to thank his brother, friend, and colleague, Guillermo Gont, for his love and support.
最后，作者要感谢他的兄弟、朋友和同事吉列尔莫·冈特的爱和支持。
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]的成果。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[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月。
[RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)", RFC 6494, February 2012.
[RFC6494]Gagliano，R.，Krishnan，S.，和A.Kukec，“安全邻居发现（SEND）的证书配置文件和证书管理”，RFC 64942012年2月。
[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）的安全评估”，英国国家基础设施保护中心（可根据要求提供）。
[Gont-DPSC] Gont, F., "Results of a Security Assessment of the Internet Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Vienna, Austria, November 2011, <http://www.si6networks.com/presentations/deepsec2011/ fgont-deepsec2011-ipv6-security.pdf>.
[Gont DPSC]Gont，F.，“互联网协议版本6（IPv6）的安全评估结果”，DEEPSEC 2011年会议，奥地利维也纳，2011年11月<http://www.si6networks.com/presentations/deepsec2011/ fgont-deepsec2011-ipv6-security.pdf>。
[NDPMon] SourceForge, "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", July 2012, <http://ndpmon.sourceforge.net/>.
[NDPMon]SourceForge，“NDPMon-IPv6邻居发现协议监视器”，2012年7月<http://ndpmon.sourceforge.net/>.
[RA-GUARD] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", Work in Progress, November 2012.
[RA-GUARD]Gont，F.，“IPv6路由器广告防护（RA-GUARD）的实施建议”，正在进行的工作，2012年11月。
[ramond] SourceForge, "ramond", January 2009, <http://ramond.sourceforge.net/>.
[ramond]SourceForge，“ramond”，2009年1月<http://ramond.sourceforge.net/>.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756]Nikander，P.，Kempf，J.，和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 37562004年5月。
[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月。
[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月。
This section aims at estimating the size of normal Certification Path Advertisement messages.
本节旨在估计正常认证路径广告消息的大小。
Considering a Certification Path Advertisement (CPA) such as that of Appendix C of [RFC3971] (certification path length of 4, between 1 and 4 address prefix extensions, and a key length of 1024 bits), the certificate lengths range between 864 and 888 bytes (and the corresponding Ethernet packets from 1050 to 1066 bytes) [RFC3971].
考虑到诸如[RFC3971]附录C（认证路径长度为4，介于1和4个地址前缀扩展之间，密钥长度为1024位）的认证路径公告（CPA），证书长度范围在864和888字节之间（以及相应的以太网数据包从1050到1066字节）[RFC3971]。
Updating the aforementioned packet size to account for the larger (2048 bits) keys required by [RFC6494] results in packet sizes ranging from 1127 to 1238 bytes, which are smaller than the minimum IPv6 MTU (1280 bytes) and much smaller than the ubiquitous Ethernet MTU (1500 bytes).
更新上述数据包大小以考虑[RFC6494]所需的较大（2048位）密钥会导致数据包大小从1127字节到1238字节不等，小于最小IPv6 MTU（1280字节）且远小于无处不在的以太网MTU（1500字节）。
However, we note that packet sizes may vary depending on a number of factors, including:
然而，我们注意到，数据包大小可能会因许多因素而变化，包括：
o the number of prefixes included in the certificate
o 证书中包含的前缀数
o the length of Fully Qualified Domain Names (FQDNs) in Trust Anchor (TA) options [RFC3971] (if present)
o 信任锚（TA）选项[RFC3971]（如果存在）中完全限定域名（FQDN）的长度
If larger key sizes (e.g., 4096 bits) are required in the future, a larger MTU size might be required to convey such information in Neighbor Discovery packets without the need to employ fragmentation.
如果将来需要更大的密钥大小（例如，4096位），则可能需要更大的MTU大小来在邻居发现分组中传送此类信息，而无需采用分段。
Author's Address
作者地址
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