Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7112 Huawei Technologies
Updates: 2460 V. Manral
Category: Standards Track Ionos Networks
ISSN: 2070-1721 R. Bonica
Juniper Networks
January 2014
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7112 Huawei Technologies
Updates: 2460 V. Manral
Category: Standards Track Ionos Networks
ISSN: 2070-1721 R. Bonica
Juniper Networks
January 2014
Implications of Oversized IPv6 Header Chains
超大IPv6头链的含义
Abstract
摘要
The IPv6 specification allows IPv6 Header Chains of an arbitrary size. The specification also allows options that can, in turn, extend each of the headers. In those scenarios in which the IPv6 Header Chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the First Fragment of a packet may fail to include the entire IPv6 Header Chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the First Fragment of a packet is required to contain the entire IPv6 Header Chain.
IPv6规范允许任意大小的IPv6头链。该规范还允许相应地扩展每个标题的选项。在IPv6报头链或选项异常长且数据包碎片化的情况下，或片段大小非常小的情况下，数据包的第一个片段可能无法包含整个IPv6报头链。本文档讨论了此类通信的互操作性和安全问题，并更新了RFC 2460，以使数据包的第一个片段包含整个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/rfc7112.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7112.
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. Requirements Language ...........................................3
3. Terminology .....................................................3
4. Motivation ......................................................4
5. Updates to RFC 2460 .............................................5
6. IANA Considerations .............................................5
7. Security Considerations .........................................6
8. Acknowledgements ................................................6
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................7
1. Introduction ....................................................2
2. Requirements Language ...........................................3
3. Terminology .....................................................3
4. Motivation ......................................................4
5. Updates to RFC 2460 .............................................5
6. IANA Considerations .............................................5
7. Security Considerations .........................................6
8. Acknowledgements ................................................6
9. References ......................................................7
9.1. Normative References .......................................7
9.2. Informative References .....................................7
With IPv6, optional internet-layer information is carried in one or more IPv6 Extension Headers [RFC2460]. Extension Headers are placed between the IPv6 header and the Upper-Layer Header in a packet. The term "Header Chain" refers collectively to the IPv6 header, Extension Headers, and Upper-Layer Header occurring in a packet. In those scenarios in which the IPv6 Header Chain is unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the Header Chain may span multiple fragments.
在IPv6中，可选的internet层信息被携带在一个或多个IPv6扩展头[RFC2460]中。扩展头放在数据包的IPv6头和上层头之间。术语“报头链”共同指出现在数据包中的IPv6报头、扩展报头和上层报头。在IPv6头链异常长且数据包碎片化的场景中，或在片段大小非常小的场景中，头链可能跨越多个片段。
While IPv4 had a fixed maximum length for the set of all IPv4 options present in a single IPv4 packet, IPv6 does not have any equivalent maximum limit at present. This document updates the set of IPv6 specifications to create an overall limit on the size of the combination of IPv6 options and IPv6 Extension Headers that is allowed in a single IPv6 packet. Namely, it updates RFC 2460 such that the First Fragment of a fragmented datagram is required to contain the entire IPv6 Header Chain.
虽然IPv4对单个IPv4数据包中存在的所有IPv4选项集具有固定的最大长度，但IPv6目前没有任何等效的最大限制。本文档更新了IPv6规范集，以对单个IPv6数据包中允许的IPv6选项和IPv6扩展头组合的大小创建总体限制。也就是说，它更新了RFC2460，使得碎片数据报的第一个片段需要包含整个IPv6报头链。
It should be noted that this requirement does not preclude the use of large payloads but, instead, merely requires that all headers, starting from the IPv6 base header and continuing up to the Upper-Layer Header (e.g., TCP or the like) be present in the First Fragment.
应注意，该要求并不排除使用大有效载荷，而是仅要求所有报头（从IPv6基本报头开始，一直到上层报头（例如TCP等））都出现在第一个片段中。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
For the purposes of this document, the terms Extension Header, IPv6 Header Chain, First Fragment, and Upper-Layer Header are used as follows:
在本文档中，术语扩展头、IPv6头链、第一个片段和上层头的用法如下：
Extension Header:
扩展标题：
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 Extension Headers.
[RFC2460]第4节定义了扩展标头。作为[RFC7045]的结果，[IANA-PROTO]提供了分配的互联网协议编号列表，并指定其中哪些协议编号也表示扩展头。
First Fragment:
第一段：
An IPv6 fragment with 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 header chain; otherwise, the "No Next Header" value (Next Header = 59) terminates it.
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 header chain, it must be referenced by the "Next Header" field of the previous member of the header chain. However, if a second IPv6 header appears in the 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 header chain. Likewise, if an Encapsulating Security Payload (ESP) header appears in the header chain, it is considered to be an Upper-Layer Header, and it terminates the header chain.
IPv6标头链的第一个成员始终是IPv6标头。要使后续标题符合标题链成员的资格，必须由标题链上一个成员的“下一个标题”字段引用。但是，如果第二个IPv6报头出现在报头链中，如IPv6通过IPv6进行隧道传输时，则第二个IPv6报头将被视为上层报头并终止报头链。同样，如果封装安全有效负载（ESP）头出现在头链中，则将其视为上层头，并终止头链。
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 occur in the header chain, they are considered to be Upper-Layer Headers, and they terminate the header chain.
在一般情况下，上层标头是标头链的第一个成员，它既不是IPv6标头，也不是IPv6扩展标头。但是，如果在报头链中出现ESP报头或第二个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 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.
上层有效负载和上层有效负载之后的任何协议数据都不被视为IPv6头链的一部分。在一个简单的示例中，如果上层报头是TCP报头，则TCP有效负载不是IPv6报头链的一部分。在更复杂的示例中，如果上层报头是ESP报头，则ESP报头中的有效负载数据或有效负载数据后面的任何字段都不是IPv6报头链的一部分。
Many forwarding devices implement stateless firewalls. A stateless firewall enforces a forwarding policy on a packet-by-packet basis. In order to enforce its forwarding policy, the stateless firewall may need to glean information from both the IPv6 and upper-layer headers.
许多转发设备实现无状态防火墙。无状态防火墙在逐包的基础上实施转发策略。为了实施其转发策略，无状态防火墙可能需要从IPv6和上层头中收集信息。
For example, assume that a stateless firewall discards all traffic received from an interface unless it is destined for a particular TCP port on a particular IPv6 address. When this firewall is presented with a fragmented packet that is destined for a different TCP port, and the entire header chain is contained within the First Fragment, the firewall discards the First Fragment and allows subsequent fragments to pass. Because the First Fragment was discarded, the packet cannot be reassembled at the destination. Insomuch as the packet cannot be reassembled, the forwarding policy is enforced.
例如，假设无状态防火墙丢弃从接口接收的所有流量，除非该流量的目的地是特定IPv6地址上的特定TCP端口。当此防火墙呈现一个指向不同TCP端口的碎片数据包，并且整个头链包含在第一个片段中时，防火墙将丢弃第一个片段，并允许后续片段通过。由于第一个片段已被丢弃，因此无法在目的地重新组装数据包。由于无法重新组装数据包，因此将强制执行转发策略。
However, when the firewall is presented with a fragmented packet and the header chain spans multiple fragments, the First Fragment does not contain enough information for the firewall to enforce its forwarding policy. Lacking sufficient information, the stateless firewall either forwards or discards that fragment. Regardless of the action that it takes, it may fail to enforce its forwarding policy.
但是，当防火墙呈现一个碎片数据包且头链跨越多个碎片时，第一个碎片包含的信息不足以让防火墙强制执行其转发策略。由于缺乏足够的信息，无状态防火墙要么转发，要么丢弃该片段。无论采取何种操作，它都可能无法强制执行其转发策略。
When a host fragments an IPv6 datagram, it MUST include the entire IPv6 Header Chain in the First Fragment.
当主机对IPv6数据报进行分段时，它必须在第一个分段中包含整个IPv6头链。
A host that receives a First Fragment that does not satisfy the above-stated requirement SHOULD discard the packet and SHOULD send an ICMPv6 error message to the source address of the offending packet (subject to the rules for ICMPv6 errors specified in [RFC4443]). However, for backwards compatibility, implementations MAY include a configuration option that allows such fragments to be accepted.
接收到不满足上述要求的第一个片段的主机应丢弃该数据包，并向违规数据包的源地址发送ICMPv6错误消息（根据[RFC4443]中规定的ICMPv6错误规则）。然而，为了向后兼容，实现可能包括一个允许接受这些片段的配置选项。
Likewise, an intermediate system (e.g., router or firewall) that receives an IPv6 First Fragment that does not satisfy the above-stated requirement MAY discard that packet, and it MAY send an ICMPv6 error message to the source address of the offending packet (subject to the rules for ICMPv6 error messages specified in [RFC4443]). Intermediate systems having this capability SHOULD support configuration (e.g., enable/disable) of whether or not such packets are dropped by the intermediate system.
类似地，接收不满足上述要求的IPv6第一段的中间系统（例如路由器或防火墙）可以丢弃该数据包，并且可以向违规数据包的源地址发送ICMPv6错误消息（根据[RFC4443]中规定的ICMPv6错误消息规则）。具有此功能的中间系统应支持配置（例如，启用/禁用）中间系统是否丢弃此类数据包。
If a host or intermediate system discards a First Fragment because it does not satisfy the above-stated requirement and sends an ICMPv6 error message due to the discard, then the ICMPv6 error message MUST be Type 4 ("Parameter Problem") and MUST use Code 3 ("First Fragment has incomplete IPv6 Header Chain"). The Pointer field contained by the ICMPv6 Parameter Problem message MUST be set to zero. The format for the ICMPv6 error message is the same regardless of whether a host or intermediate system originates it.
如果主机或中间系统因不满足上述要求而丢弃第一个片段，并因丢弃而发送ICMPv6错误消息，则ICMPv6错误消息必须为类型4（“参数问题”），并且必须使用代码3（“第一个片段具有不完整的IPv6头链”）。ICMPv6参数问题消息包含的指针字段必须设置为零。无论是主机还是中间系统发出ICMPv6错误消息，其格式都是相同的。
As a result of the above-mentioned requirement, a packet's header chain length cannot exceed the Path MTU associated with its destination. Hosts discover the Path MTU using procedures such as those defined in [RFC1981] and [RFC4821]. Hosts that do not discover the Path MTU MUST limit the IPv6 Header Chain length to 1280 bytes. Limiting the IPv6 Header Chain length to 1280 bytes ensures that the header chain length does not exceed the IPv6 minimum MTU [RFC2460].
作为上述要求的结果，分组的报头链长度不能超过与其目的地相关联的路径MTU。主机使用[RFC1981]和[RFC4821]中定义的过程来发现路径MTU。未发现路径MTU的主机必须将IPv6头链长度限制为1280字节。将IPv6头链长度限制为1280字节可确保头链长度不超过IPv6最小MTU[RFC2460]。
IANA has added the following "Type 4 - Parameter Problem" message to the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry:
IANA已将以下“类型4-参数问题”消息添加到“Internet控制消息协议版本6（ICMPv6）参数”注册表中：
CODE NAME/DESCRIPTION 3 IPv6 First Fragment has incomplete IPv6 Header Chain
代码名称/说明3 IPv6第一个片段的IPv6头链不完整
No new security exposures or issues are raised by this document. This document describes how undesirably fragmented packets can be leveraged to evade stateless packet filtering. Having made that observation, this document updates [RFC2460] so that undesirably fragmented packets are forbidden. Therefore, a security vulnerability is removed.
本文件未提出任何新的安全风险或问题。本文档描述了如何利用不希望的碎片数据包来规避无状态数据包过滤。观察到这一点后，本文档对[RFC2460]进行了更新，从而禁止了不必要的碎片数据包。因此，安全漏洞被删除。
This specification allows nodes that drop the aforementioned packets to signal such packet drops with ICMPv6 "Parameter Problem, IPv6 First Fragment has incomplete IPv6 header chain" (Type 4, Code 3) error messages.
此规范允许丢弃上述数据包的节点使用ICMPv6“参数问题，IPv6第一个片段具有不完整的IPv6头链”（类型4，代码3）错误消息来发出此类数据包丢弃的信号。
As with all ICMPv6 error/diagnostic messages, deploying Source Address Forgery Prevention filters helps reduce the chances of an attacker successfully performing a reflection attack by sending forged illegal packets with the victim's/target's IPv6 address as the IPv6 source address of the illegal packet [RFC2827] [RFC3704].
与所有ICMPv6错误/诊断消息一样，部署源地址伪造预防筛选器有助于减少攻击者成功执行反射攻击的机会，方法是发送伪造的非法数据包，将受害者/目标的IPv6地址作为非法数据包的IPv6源地址[RFC2827][RFC3704]。
A firewall that performs stateless deep packet inspection (i.e., examines application payload content) might still be unable to correctly process fragmented packets, even if the IPv6 Header Chain is not fragmented.
执行无状态深度数据包检查（即检查应用程序有效负载内容）的防火墙可能仍然无法正确处理分段数据包，即使IPv6头链没有分段。
The authors would like to thank Ran Atkinson for contributing text and ideas that were incorporated into this document.
作者要感谢Ran Atkinson为本文件提供的文本和想法。
The authors would like to thank (in alphabetical order) Ran Atkinson, Fred Baker, Stewart Bryant, Brian Carpenter, Benoit Claise, Dominik Elsbroek, Wes George, Mike Heard, Bill Jouris, Suresh Krishnan, Dave Thaler, Ole Troan, Eric Vyncke, and Peter Yee, for providing valuable comments on earlier versions of this document.
作者要感谢（按字母顺序排列）Ran Atkinson、Fred Baker、Stewart Bryant、Brian Carpenter、Benoit Claise、Dominik Elsbroek、Wes George、Mike Heard、Bill Jouris、Suresh Krishnan、Dave Thaler、Ole Troan、Eric Vyncke和Peter Yee对本文件早期版本提供的宝贵意见。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[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月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[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月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[IANA-PROTO] Internet Assigned Numbers Authority, "Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers>.
[IANA-PROTO]互联网分配号码管理局，“协议号码”<http://www.iana.org/assignments/protocol-numbers>.
Authors' Addresses
作者地址
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
Vishwas Manral Ionos Networks Sunnyvale, CA 94089 US
美国加利福尼亚州桑尼维尔市维斯瓦斯曼拉尔电离层网络公司，邮编94089
Phone: 408-447-1497 EMail: vishwas@ionosnetworks.com
电话：408-447-1497电子邮件：vishwas@ionosnetworks.com
Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US
罗纳德P.博尼卡Juniper Networks 2251美国弗吉尼亚州赫恩登市企业园大道20171
Phone: 571 250 5819 EMail: rbonica@juniper.net
电话：571 250 5819电子邮件：rbonica@juniper.net