Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6564 Ericsson
Updates: 2460 J. Woodyatt
Category: Standards Track Apple
ISSN: 2070-1721 E. Kline
Google
J. Hoagland
Symantec
M. Bhatia
Alcatel-Lucent
April 2012
Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6564 Ericsson
Updates: 2460 J. Woodyatt
Category: Standards Track Apple
ISSN: 2070-1721 E. Kline
Google
J. Hoagland
Symantec
M. Bhatia
Alcatel-Lucent
April 2012
A Uniform Format for IPv6 Extension Headers
IPv6扩展头的统一格式
Abstract
摘要
In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport-layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6. It also provides a common format for defining any new IPv6 extension headers, if they are needed.
在IPv6中，可选的internet层信息编码在单独的报头中，这些报头可以放在IPv6报头和传输层报头之间。目前定义了少量此类扩展头。本文档描述了定义新扩展头时可能出现的问题，并讨论了IPv6中的替代扩展机制。它还提供了一种通用格式，用于定义任何新的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/rfc6564.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6564.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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. Conventions Used in This Document ...............................3
3. Applicability ...................................................3
4. Proposed IPv6 Extension Header Format ...........................4
5. Backward Compatibility ..........................................4
6. Future Work .....................................................5
7. Security Considerations .........................................5
8. Acknowledgements ................................................5
9. Normative References ............................................5
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Applicability ...................................................3
4. Proposed IPv6 Extension Header Format ...........................4
5. Backward Compatibility ..........................................4
6. Future Work .....................................................5
7. Security Considerations .........................................5
8. Acknowledgements ................................................5
9. Normative References ............................................5
The base IPv6 standard [RFC2460] defines extension headers as an expansion mechanism to carry optional internet-layer information. Extension headers, with the exception of the Hop-by-Hop Options header, are not usually processed on intermediate nodes. However, several existing deployed IPv6 routers and several existing deployed IPv6 firewalls, in contradiction to [RFC2460], are capable of parsing past or ignoring all currently defined IPv6 extension headers (e.g., to examine transport-layer header fields) at wire speed (e.g., by using custom Application-specific Integrated Circuits (ASICs) for packet processing). Hence, one must also consider that any new IPv6 extension header will break IPv6 deployments that use these existing capabilities.
基本IPv6标准[RFC2460]将扩展头定义为一种扩展机制，用于承载可选的internet层信息。除了逐跳选项标头之外，扩展标头通常不会在中间节点上处理。然而，与[RFC2460]相反，几个现有部署的IPv6路由器和几个现有部署的IPv6防火墙能够以线速解析过去或忽略所有当前定义的IPv6扩展报头（例如，检查传输层报头字段）（例如，通过使用自定义的应用程序专用集成电路（ASIC））用于数据包处理）。因此，还必须考虑任何新的IPv6扩展头将打破使用这些现有能力的IPv6部署。
Any IPv6 header or option that has hop-by-hop behavior, and is intended for general use in the public IPv6 Internet, could be subverted to create an attack on IPv6 routers that process packets containing such a header or option. Reports from the field indicate that some IP routers deployed within the global Internet are configured either to ignore the presence of headers with hop-by-hop
任何具有逐跳行为且用于公共IPv6 Internet的IPv6标头或选项都可能被破坏，从而在处理包含此类标头或选项的数据包的IPv6路由器上创建攻击。来自现场的报告表明，全球互联网中部署的某些IP路由器被配置为忽略具有逐跳的报头的存在
behavior or to drop packets containing headers with hop-by-hop behavior.
行为或丢弃包含具有逐跳行为的标头的数据包。
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]中所述进行解释。
The base IPv6 standard [RFC2460] allows the use of both extension headers and destination options in order to encode optional destination information in an IPv6 packet. The use of destination options to encode this information provides more flexible handling characteristics and better backward compatibility than using extension headers. Because of this, implementations SHOULD use destination options as the preferred mechanism for encoding optional destination information, and use a new extension header only if destination options do not satisfy their needs. The request for creation of a new IPv6 extension header MUST be accompanied by a specific explanation of why destination options could not be used to convey this information.
基本IPv6标准[RFC2460]允许同时使用扩展头和目标选项，以便在IPv6数据包中编码可选的目标信息。与使用扩展头相比，使用目标选项编码此信息提供了更灵活的处理特性和更好的向后兼容性。因此，实现应该使用目的地选项作为编码可选目的地信息的首选机制，并且仅当目的地选项不满足其需要时才使用新的扩展头。创建新IPv6扩展标头的请求必须附带一个特定的解释，说明为什么无法使用目标选项来传递此信息。
The base IPv6 standard [RFC2460] defines 3 extension headers (i.e., Routing header, Destination Options header, Hop-by-Hop Options header) to be used for any new IPv6 options. The same standard only allows the creation of new extension headers in limited circumstances ([RFC2460], Section 4.6).
基本IPv6标准[RFC2460]定义了3个扩展头（即路由头、目标选项头、逐跳选项头），用于任何新的IPv6选项。同一标准仅允许在有限的情况下创建新的扩展标头（[RFC2460]，第4.6节）。
As noted above, the use of any option with hop-by-hop behavior can be problematic in the global public Internet. New IPv6 extension header(s) having hop-by-hop behavior MUST NOT be created or specified. New options for the existing Hop-by-Hop Header SHOULD NOT be created or specified unless no alternative solution is feasible. Any proposal to create a new option for the existing Hop-by-Hop Header MUST include a detailed explanation of why the hop-by-hop behavior is absolutely essential in the document proposing the new option with hop-by-hop behavior.
如上所述，在全球公共互联网中，使用具有逐跳行为的任何选项都可能会有问题。不得创建或指定具有逐跳行为的新IPv6扩展标头。除非没有可行的替代解决方案，否则不应创建或指定现有逐跳标头的新选项。任何为现有逐跳标头创建新选项的建议都必须在建议具有逐跳行为的新选项的文档中详细说明为何逐跳行为是绝对必要的。
The use of IPv6 Destination Options to encode information provides more flexible handling characteristics and better backward compatibility than using a new extension header. Because of this, new optional information to be sent SHOULD be encoded in a new option for the existing IPv6 Destination Options header.
与使用新的扩展头相比，使用IPv6目标选项编码信息提供了更灵活的处理特性和更好的向后兼容性。因此，要发送的新可选信息应编码在现有IPv6目标选项标头的新选项中。
Mindful of the need for compatibility with existing IPv6 deployments, new IPv6 extension headers MUST NOT be created or specified, unless no existing IPv6 extension header can be used by specifying a new option for that existing IPv6 extension header. Any proposal to create or specify a new IPv6 extension header MUST include a detailed technical explanation of why no existing IPv6 extension header can be used in the document proposing the new IPv6 extension header.
考虑到需要与现有IPv6部署兼容，不得创建或指定新的IPv6扩展标头，除非通过为现有IPv6扩展标头指定新选项无法使用现有IPv6扩展标头。任何创建或指定新IPv6扩展标头的建议都必须包含详细的技术说明，说明在建议新IPv6扩展标头的文档中不能使用现有IPv6扩展标头的原因。
Any IPv6 extension headers defined in the future, keeping in mind the restrictions specified in Section 3 and also the restrictions specified in [RFC2460], MUST use the consistent format defined in Figure 1. This minimizes breakage in intermediate nodes that examine these extension headers.
将来定义的任何IPv6扩展头都必须使用图1中定义的一致格式，请记住第3节中指定的限制以及[RFC2460]中指定的限制。这将最小化检查这些扩展头的中间节点中的中断。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Header Specific Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Header Specific Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of header immediately following the extension header. Uses the same values as the IPv4 Protocol field [IANA_IP_PARAM].
下一个标题8位选择器。标识紧跟在扩展标头之后的标头类型。使用与IPv4协议字段[IANA_IP_PARAM]相同的值。
Hdr Ext Len 8-bit unsigned integer. Length of the extension header in 8-octet units, not including the first 8 octets.
Hdr Ext Len 8位无符号整数。扩展头的长度，以8个八位字节为单位，不包括前8个八位字节。
Header Specific Variable length. Fields specific to the Data extension header.
标题特定的可变长度。特定于数据扩展标题的字段。
Figure 1: Extension Header Layout
图1：扩展标题布局
The scheme proposed in this document is not intended to be backward compatible with all the currently defined IPv6 extension headers. It applies only to newly defined extension headers. Specifically, the
本文档中提出的方案并不打算与当前定义的所有IPv6扩展头向后兼容。它仅适用于新定义的扩展标题。具体来说
fragment header predates this document and does not follow the format proposed in this document.
片段标题早于本文档，不遵循本文档中建议的格式。
This document proposes one step in easing the inspection of extension headers by middleboxes. There is further work required in this area. Some issues that are left unresolved beyond this document include:
本文档提出了一个步骤，以简化中间盒对扩展标头的检查。这方面还需要进一步的工作。本文件以外的一些问题尚未解决，包括：
o There can be an arbitrary number of extension headers.
o 可以有任意数量的扩展标头。
o Extension headers must be processed in the order they appear.
o 扩展标题必须按照其出现的顺序进行处理。
o Extension headers may alter the processing of the payload itself, and hence the packet may not be processed properly without knowledge of said header.
o 扩展报头可以改变有效载荷本身的处理，因此在不知道所述报头的情况下，分组可能不能被正确处理。
This document proposes a standard format for the IPv6 extension headers that minimizes breakage at intermediate nodes that inspect but do not understand the contents of these headers. Intermediate nodes, such as firewalls, that skip over unknown headers might end up allowing the setup of a covert channel from the outside of the firewall to the inside using the data field(s) of the unknown extension headers.
本文档提出了IPv6扩展头的标准格式，该格式可最大限度地减少检查但不了解这些头内容的中间节点的中断。跳过未知标头的中间节点（如防火墙）可能最终允许使用未知扩展标头的数据字段设置从防火墙外部到内部的隐蔽通道。
The authors would like to thank Albert Manfredi, Bob Hinden, Brian Carpenter, Erik Nordmark, Hemant Singh, Lars Westberg, Markku Savela, Tatuya Jinmei, Thomas Narten, Vishwas Manral, Alfred Hoenes, Joel Halpern, Ran Atkinson, Steven Blake, Jari Arkko, Kathleen Moriarty, Stephen Farrell, Ralph Droms, Sean Turner, and Adrian Farrel for their reviews and suggestions that made this document better.
作者要感谢阿尔伯特·曼弗雷迪、鲍勃·欣登、布赖恩·卡彭特、埃里克·诺德马克、赫曼特·辛格、拉尔斯·韦斯特伯格、马克库·萨维拉、塔图亚·金梅、托马斯·纳腾、维斯瓦斯·曼拉尔、阿尔弗雷德·霍恩斯、乔尔·哈尔佩恩、冉·阿特金森、史蒂文·布莱克、贾里·阿尔科、凯瑟琳·莫里亚蒂、斯蒂芬·法雷尔、拉尔夫·德罗姆斯、肖恩·特纳、，和Adrian Farrel，感谢他们的评论和建议，这些评论和建议使本文件变得更好。
[IANA_IP_PARAM] IANA, "IP Parameters", <http://www.iana.org/assignments/ip-parameters>.
[IANA_IP_PARAM]IANA，“IP参数”<http://www.iana.org/assignments/ip-parameters>.
[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月。
Authors' Addresses
作者地址
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 x42871 EMail: suresh.krishnan@ericsson.com
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大QC皇家山镇电话：+1 514 345 7900 x42871电子邮件：suresh。krishnan@ericsson.com
James Woodyatt Apple Inc. 1 Infinite Loop Cupertino, CA 95014 US EMail: jhw@apple.com
James Woodyatt Apple Inc.1 Infinite Loop Cupertino，加利福尼亚州95014美国电子邮件：jhw@apple.com
Erik Kline Google Mori Tower 26F Roppongi 6-10-1 Minato ku Tokyo 106-6126 Japan Phone: +81 3-6384-9635 EMail: ek@google.com
Erik Kline Google Mori Tower 26F六本木6-10-1 Minato ku东京106-6126日本电话：+81 3-6384-9635电子邮件：ek@google.com
James Hoagland Symantec Corporation 350 Ellis St. Mountain View, CA 94043 US EMail: Jim_Hoagland@symantec.com URI: http://symantec.com/
James Hoagland Symantec Corporation 350 Ellis St.Mountain View，CA 94043美国电子邮件：Jim_Hoagland@symantec.comURI:http://symantec.com/
Manav Bhatia Alcatel-Lucent Bangalore India EMail: manav.bhatia@alcatel-lucent.com
Manav Bhatia Alcatel Lucent Bangalore India电子邮件：Manav。bhatia@alcatel-朗讯网