Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6946 Huawei Technologies
Updates: 2460, 5722 May 2013
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6946 Huawei Technologies
Updates: 2460, 5722 May 2013
Category: Standards Track
ISSN: 2070-1721
Processing of IPv6 "Atomic" Fragments
IPv6“原子”片段的处理
Abstract
摘要
The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets are typically sent by hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal "fragmented traffic" (i.e., they are "reassembled" with any other queued fragments that supposedly correspond to the same original packet). Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 "Packet Too Big" error messages, and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications. Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector.
IPv6规范允许数据包包含一个片段头，而不会将数据包实际分割成多个片段（我们将这些数据包称为“原子片段”）。此类数据包通常由接收到ICMPv6“数据包太大”错误消息的主机发送，该错误消息播发小于1280字节的下一跳MTU，并且当前由一些实现作为正常的“碎片流量”进行处理（即，它们被“重新组装”）与假定与同一原始数据包对应的任何其他排队的片段）。因此，攻击者可以通过伪造ICMPv6“数据包太大”错误消息，使主机使用原子碎片，然后对此类流量发起任何基于碎片的攻击。本文件讨论上述原子碎片的生成以及相应的安全含义。此外，该文档正式更新RFC 2460和RFC 5722，使得IPv6原子碎片独立于任何其他片段处理，从而完全消除上述攻击向量。
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/rfc6946.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6946.
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. Terminology .....................................................4
3. Generation of IPv6 Atomic Fragments .............................4
4. Updating RFC 2460 and RFC 5722 ..................................5
5. Security Considerations .........................................6
6. Acknowledgements ................................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................7
Appendix A. Survey of Processing of IPv6 Atomic Fragments by
Different Operating Systems ............................8
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Generation of IPv6 Atomic Fragments .............................4
4. Updating RFC 2460 and RFC 5722 ..................................5
5. Security Considerations .........................................6
6. Acknowledgements ................................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................7
Appendix A. Survey of Processing of IPv6 Atomic Fragments by
Different Operating Systems ............................8
[RFC2460] specifies the IPv6 fragmentation mechanism, which allows IPv6 packets to be fragmented into smaller pieces such that they fit in the Path-MTU to the intended destination(s). [RFC2460] allows fragments to overlap, thus leading to ambiguity in the result of the reassembly process, which could be leveraged by attackers to bypass firewall rules and/or evade Network Intrusion Detection Systems (NIDS) [RFC5722].
[RFC2460]指定IPv6分段机制，该机制允许将IPv6数据包分段为更小的数据块，以便它们适合到预期目的地的路径MTU。[RFC2460]允许片段重叠，从而导致重组过程的结果不明确，攻击者可利用该结果绕过防火墙规则和/或规避网络入侵检测系统（NID）[RFC5722]。
[RFC5722] forbids overlapping fragments, specifying that when overlapping fragments are detected, all the fragments corresponding to that packet must be silently discarded.
[RFC5722]禁止重叠片段，指定当检测到重叠片段时，必须悄悄丢弃与该数据包对应的所有片段。
As specified in Section 5 of [RFC2460], when a host receives an ICMPv6 "Packet Too Big" message advertising a "Next-Hop MTU" smaller than 1280 (the minimum IPv6 MTU), it is not required to reduce the assumed Path-MTU, but must simply include a Fragment Header in all subsequent packets sent to that destination. The resulting packets
如[RFC2460]第5节所述，当主机收到一条ICMPv6“数据包太大”消息，该消息宣称“下一跳MTU”小于1280（最小IPv6 MTU），则无需减少假定路径MTU，但必须在发送到该目的地的所有后续数据包中仅包含一个片段头。生成的数据包
will thus not actually be fragmented into several pieces but will just include a Fragment Header with both the "Fragment Offset" and the "M" flag set to 0 (we refer to these packets as "atomic fragments"). IPv6/IPv4 translators employ the Fragment Identification information found in the Fragment Header to select an appropriate Fragment Identification value for the resulting IPv4 fragments.
因此，实际上不会被分割成多个片段，而只会包含一个片段头，其中“片段偏移量”和“M”标志都设置为0（我们将这些数据包称为“原子片段”）。IPv6/IPv4转换器使用在片段头中找到的片段标识信息为生成的IPv4片段选择适当的片段标识值。
While these packets are really atomic fragments (they can be processed by the IPv6 module and handed to the upper-layer protocol without waiting for any other fragments), many IPv6 implementations process them as regular fragments. Namely, they try to perform IPv6 fragment reassembly with the atomic fragment and any other fragments already queued with the same set {IPv6 Source Address, IPv6 Destination Address, Fragment Identification}. For example, in the case of IPv6 implementations that have been updated to support [RFC5722], if a fragment with the same {IPv6 Source Address, IPv6 Destination Address, Fragment Identification} is already queued for reassembly at a host when an atomic fragment is received with the same set {IPv6 Source Address, IPv6 Destination Address, Fragment Identification}, and both fragments overlap, all the fragments will be silently discarded.
虽然这些数据包实际上是原子片段（它们可以由IPv6模块处理并交给上层协议，而无需等待任何其他片段），但许多IPv6实现将它们作为常规片段进行处理。也就是说，它们尝试使用原子片段和已经使用相同集合{IPv6源地址、IPv6目标地址、片段标识}排队的任何其他片段执行IPv6片段重组。例如，在已更新为支持[RFC5722]的IPv6实现的情况下，如果具有相同{IPv6源地址、IPv6目标地址、片段标识}的片段已排队等待在主机上重新组装，则接收到具有相同集合的原子片段{IPv6源地址、IPv6目标地址、片段标识}，并且两个片段重叠，所有片段都将被默默地丢弃。
Processing of IPv6 atomic fragments as regular fragmented packets clearly provides an unnecessary vector to perform fragmentation-based attacks against non-fragmented traffic (i.e., IPv6 datagrams that are not really split into multiple pieces but that just include a Fragment Header).
将IPv6原子片段作为常规碎片数据包处理显然提供了一个不必要的向量，用于对非碎片流量（即，并非真正拆分为多个片段但仅包含片段头的IPv6数据报）执行基于碎片的攻击。
IPv6 fragmentation attacks have been discussed in great detail in [PREDICTABLE-ID] and [CPNI-IPv6], and [RFC5722] describes a specific firewall-circumvention attack that could be performed by leveraging overlapping fragments. The possible IPv6 fragmentation-based attacks are, in most cases, "ports" of the IPv4 fragmentation attacks discussed in [RFC6274].
[PREDICTABLE-ID]和[CPNI-IPv6]中详细讨论了IPv6碎片攻击，[RFC5722]描述了一种可以利用重叠碎片执行的特定防火墙规避攻击。在大多数情况下，可能的基于IPv6分段的攻击是[RFC6274]中讨论的IPv4分段攻击的“端口”。
Section 3 describes the generation of IPv6 atomic fragments and how they can be remotely "triggered" by a remote attacker. Section 4 formally updates [RFC2460] and [RFC5722] such that the aforementioned attack vector is eliminated. Appendix A contains a survey of the generation and processing of IPv6 atomic fragments in different versions of a number of popular IPv6 implementations.
第3节描述了IPv6原子片段的生成以及远程攻击者如何远程“触发”这些原子片段。第4节正式更新[RCF2460]和[RCFC2222]，从而消除上述攻击向量。附录A包含了一份关于在许多流行IPv6实现的不同版本中生成和处理IPv6原子片段的调查。
IPv6 atomic fragments: IPv6 packets that contain a Fragment Header with the Fragment Offset set to 0 and the M flag set to 0.
IPv6原子片段：包含片段偏移量设置为0且M标志设置为0的片段头的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]中所述进行解释。
Section 5 of [RFC2460] states:
[RFC2460]第5节规定：
"In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used."
“响应发送到IPv4目的地的IPv6数据包（即，从IPv6转换为IPv4的数据包），发起IPv6节点可能会收到一条ICMP数据包太大的消息，报告下一跳MTU小于1280。在这种情况下，IPv6节点不需要将后续数据包的大小减小到小于1280，但必须在这些数据包中包含一个片段头，以便IPv6到IPv4转换路由器可以获得适当的标识值在生成的IPv4片段中使用。请注意，这意味着负载可能必须减少到1232个八位字节（IPv6标头为1280减40，片段标头为8），如果使用其他扩展标头，则负载可能会更小。”
This means that any ICMPv6 "Packet Too Big" message advertising a "Next-Hop MTU" smaller than 1280 could trigger the generation of the so-called "atomic fragments" (i.e., IPv6 datagrams that include a Fragment Header but that are composed of a single fragment, with both the "Fragment Offset" and the "M" fields of the Fragment Header set to 0). This can be leveraged to perform a variety of fragmentation-based attacks [PREDICTABLE-ID] [CPNI-IPv6].
这意味着，任何宣传小于1280的“下一跳MTU”的ICMPv6“数据包太大”消息都可能触发所谓的“原子片段”的生成（即，包含片段头但由单个片段组成的IPv6数据报，片段头的“片段偏移量”和“M”字段均设置为0）。这可以用来执行各种基于碎片的攻击[PREDICTABLE-ID][CPNI-IPv6]。
For example, an attacker could forge IPv6 fragments with an appropriate {IPv6 Source Address, IPv6 Destination Address, Fragment Identification} tuple, such that these malicious fragments are incorrectly "reassembled" by the destination host together with some of the legitimate fragments of the original packet, thus leading to packet drops (and a potential denial of service).
例如，攻击者可以伪造具有适当{IPv6源地址、IPv6目标地址、片段标识}元组的IPv6片段，从而使目标主机将这些恶意片段与原始数据包的一些合法片段错误地“重新组装”在一起，从而导致数据包丢失（以及潜在的拒绝服务）。
From a security standpoint, this situation is exacerbated by the following factors:
从安全角度看，以下因素加剧了这一局势：
o Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and documented in [RFC5927]. It should be noted that in some cases, such as when an ICMPv6 error message has (supposedly) been elicited by a connectionless transport protocol (or some other connectionless protocol being encapsulated in IPv6), it may be virtually impossible to perform validation checks on the received ICMPv6 error messages.
o 按照[RFC4443]第5.2节中的建议和[RFC5927]中的记录，许多实现未能对收到的ICMPv6错误消息执行验证检查。应注意，在某些情况下，例如当无连接传输协议（或封装在IPv6中的其他无连接协议）已（假定）引发ICMPv6错误消息时，可能实际上不可能对接收到的ICMPv6错误消息执行验证检查。
o Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big" error messages, the Destination Cache [RFC4861] is usually updated to reflect that any subsequent packets to that destination should include a Fragment Header. This means that a single ICMPv6 "Packet Too Big" error message might affect multiple communication instances (e.g., TCP connections) with that IPv6 destination address.
o 在收到上述ICMPv6“数据包太大”错误消息之一后，通常会更新目标缓存[RFC4861]，以反映到该目标的任何后续数据包都应包含片段头。这意味着单个ICMPv6“数据包太大”错误消息可能会影响具有该IPv6目标地址的多个通信实例（例如TCP连接）。
o Some implementations employ predictable Fragment Identification values, thus greatly improving the chances of an attacker successfully performing fragmentation-based attacks [PREDICTABLE-ID].
o 一些实现采用可预测的片段标识值，从而大大提高了攻击者成功执行基于片段的攻击的机会[predictable-ID]。
Section 4.5 of [RFC2460] and Section 4 of [RFC5722] are updated as follows:
[RFC2460]第4.5节和[RFC5722]第4节更新如下：
A host that receives an IPv6 packet that includes a Fragment Header with the "Fragment Offset" equal to 0 and the "M" flag equal to 0 MUST process that packet in isolation from any other packets/fragments, even if such packets/fragments contain the same set {IPv6 Source Address, IPv6 Destination Address, Fragment Identification}. A received atomic fragment should be "reassembled" from the contents of that sole fragment.
接收包含“片段偏移量”等于0且“M”标志等于0的片段标头的IPv6数据包的主机必须与任何其他数据包/片段隔离处理该数据包，即使这些数据包/片段包含相同的集合{IPv6源地址、IPv6目标地址、片段标识}。一个收到的原子碎片应该从这个唯一碎片的内容中“重新组装”。
The Unfragmentable Part of the reassembled packet consists of all headers up to, but not including, the Fragment Header of the received atomic fragment.
重新组装的数据包的不可分割部分由所有头组成，包括但不包括接收到的原子片段的片段头。
The Next Header field of the last header of the Unfragmentable Part of the reassembled packet is obtained from the Next Header field of the Fragment Header of the received atomic fragment.
重新组装的分组的不可分割部分的最后报头的下一报头字段从所接收的原子片段的片段报头的下一报头字段获得。
The Payload Length of the reassembled packet is obtained by subtracting the length of the Fragment Header (that is, 8) from the Payload Length of the received atomic fragment.
通过从接收到的原子片段的有效载荷长度中减去片段头部的长度（即8）来获得重新组装的分组的有效载荷长度。
Additionally, if any fragments with the same set {IPv6 Source Address, IPv6 Destination Address, Fragment Identification} are present in the fragment reassembly queue when the atomic fragment is received, such fragments MUST NOT be discarded upon receipt of the "colliding" IPv6 atomic fragment, since IPv6 atomic fragments MUST NOT interfere with "normal" fragmented traffic.
此外，如果在接收到原子片段时，片段重组队列中存在具有相同集合{IPv6源地址、IPv6目标地址、片段标识}的任何片段，则在接收到“冲突”IPv6原子片段时不得丢弃此类片段，因为IPv6原子片段不得干扰“正常”支离破碎的流量。
This document describes how the traditional processing of IPv6 atomic fragments enables the exploitation of fragmentation-based attacks (such as those described in [PREDICTABLE-ID] and [CPNI-IPv6]). This document formally updates [RFC2460] and [RFC5722], such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector.
本文档描述了IPv6原子碎片的传统处理如何利用基于碎片的攻击（如[PREDICTABLE-ID]和[CPNI-IPv6]中所述的攻击）。该文件正式更新[RCF2460]和[RCFC2222]，使得IPv6原子碎片独立于任何其他片段处理，从而完全消除上述攻击向量。
The author would like to thank (in alphabetical order) Tore Anderson, Ran Atkinson, Remi Despres, Stephen Farrell, Brian Haberman, Timothy Hartrick, Steinar Haug, Philip Homburg, Simon Josefsson, Simon Perreault, Sean Turner, Florian Weimer, and Bjoern A. Zeeb for providing valuable comments on earlier versions of this document. Additionally, the author would like to thank Alexander Bluhm, who implemented this specification for OpenBSD.
作者要感谢（按字母顺序）托尔·安德森、兰·阿特金森、雷米·德斯普雷斯、斯蒂芬·法雷尔、布赖恩·哈伯曼、蒂莫西·哈特里克、施泰纳·豪格、菲利普·霍姆伯格、西蒙·约瑟夫森、西蒙·佩雷尔特、肖恩·特纳、弗洛里安·魏默和比约恩·泽布对本文件早期版本提供了宝贵的意见。此外，作者还要感谢Alexander Bluhm，他为OpenBSD实现了此规范。
This document is based on the technical report "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], authored by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI).
本文件基于由Fernando Gont代表英国国家基础设施保护中心（CPNI）编写的技术报告“互联网协议第6版（IPv6）的安全评估”[CPNI-IPv6]。
Finally, the author wishes to thank Nelida Garcia and Guillermo Gont for their love and support.
最后，作者要感谢内丽达·加西亚和吉列尔莫·贡特对我们的爱和支持。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年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月。
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009.
[RFC5722]Krishnan，S.，“重叠IPv6片段的处理”，RFC 5722，2009年12月。
[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）的安全评估”，英国国家基础设施保护中心（可根据要求提供）。
[PREDICTABLE-ID] Gont, F., "Security Implications of Predictable Fragment Identification Values", Work in Progress, March 2013.
[PREDICTABLE-ID]Gont，F.，“可预测碎片识别值的安全影响”，正在进行的工作，2013年3月。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5927]Gont，F.，“针对TCP的ICMP攻击”，RFC 5927，2010年7月。
[RFC6274] Gont, F., "Security Assessment of the Internet Protocol Version 4", RFC 6274, July 2011.
[RFC6274]Gont，F.，“互联网协议版本4的安全评估”，RFC 62742011年7月。
Appendix A. Survey of Processing of IPv6 Atomic Fragments by Different Operating Systems
附录A.不同操作系统处理IPv6原子片段的调查
This section includes a survey of the support of IPv6 atomic fragments in popular operating systems, as tested on October 30, 2012.
本节包括2012年10月30日测试的流行操作系统对IPv6原子片段支持的调查。
+---------------------+---------------------+-----------------------+
| Operating System | Generates atomic | Implements this |
| | fragments | specification |
+---------------------+---------------------+-----------------------+
| FreeBSD 8.0 | No | No |
+---------------------+---------------------+-----------------------+
| FreeBSD 8.2 | Yes | No |
+---------------------+---------------------+-----------------------+
| FreeBSD 9.0 | Yes | No |
+---------------------+---------------------+-----------------------+
| Linux 3.0.0-15 | Yes | Yes |
+---------------------+---------------------+-----------------------+
| NetBSD 5.1 | No | No |
+---------------------+---------------------+-----------------------+
| NetBSD-current | No | Yes |
+---------------------+---------------------+-----------------------+
| OpenBSD-current | Yes | Yes |
+---------------------+---------------------+-----------------------+
| Solaris 11 | Yes | Yes |
+---------------------+---------------------+-----------------------+
| Windows XP SP2 | Yes | No |
+---------------------+---------------------+-----------------------+
| Windows Vista | Yes | No |
| (Build 6000) | | |
+---------------------+---------------------+-----------------------+
| Windows 7 Home | Yes | No |
| Premium | | |
+---------------------+---------------------+-----------------------+
+---------------------+---------------------+-----------------------+
| Operating System | Generates atomic | Implements this |
| | fragments | specification |
+---------------------+---------------------+-----------------------+
| FreeBSD 8.0 | No | No |
+---------------------+---------------------+-----------------------+
| FreeBSD 8.2 | Yes | No |
+---------------------+---------------------+-----------------------+
| FreeBSD 9.0 | Yes | No |
+---------------------+---------------------+-----------------------+
| Linux 3.0.0-15 | Yes | Yes |
+---------------------+---------------------+-----------------------+
| NetBSD 5.1 | No | No |
+---------------------+---------------------+-----------------------+
| NetBSD-current | No | Yes |
+---------------------+---------------------+-----------------------+
| OpenBSD-current | Yes | Yes |
+---------------------+---------------------+-----------------------+
| Solaris 11 | Yes | Yes |
+---------------------+---------------------+-----------------------+
| Windows XP SP2 | Yes | No |
+---------------------+---------------------+-----------------------+
| Windows Vista | Yes | No |
| (Build 6000) | | |
+---------------------+---------------------+-----------------------+
| Windows 7 Home | Yes | No |
| Premium | | |
+---------------------+---------------------+-----------------------+
Table 1: Processing of IPv6 Atomic Fragments by Different OSes
表1：不同操作系统对IPv6原子片段的处理
In the table above, "generates atomic fragments" notes whether an implementation generates atomic fragments in response to received ICMPv6 "Packet Too Big" error messages that advertise an MTU smaller than 1280 bytes.
在上表中，“生成原子片段”说明了实现是否会生成原子片段，以响应接收到的ICMPv6“数据包太大”错误消息，该消息播发小于1280字节的MTU。
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