Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 7045 Univ. of Auckland
Updates: 2460, 2780 S. Jiang
Category: Standards Track Huawei Technologies Co., Ltd.
ISSN: 2070-1721 December 2013
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 7045 Univ. of Auckland
Updates: 2460, 2780 S. Jiang
Category: Standards Track Huawei Technologies Co., Ltd.
ISSN: 2070-1721 December 2013
Transmission and Processing of IPv6 Extension Headers
IPv6扩展头的传输和处理
Abstract
摘要
Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.
自从IPv6标准首次发布以来，各种IPv6扩展头已经标准化。本文档更新了RFC2460，以澄清中间节点应如何处理此类扩展头以及将来定义的任何扩展头。它还指定了IANA应该如何注册扩展头，并对RFC2780进行了相应的小更新。
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/rfc7045.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7045.
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 and Problem Statement . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirement to Transmit Extension Headers . . . . . . . . . . 5
2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 5
2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8
1. Introduction and Problem Statement . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirement to Transmit Extension Headers . . . . . . . . . . 5
2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 5
2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8
In IPv6, an extension header is any header that follows the initial 40 bytes of the packet and precedes the upper-layer header (which might be a transport header, an ICMPv6 header, or a notional "No Next Header").
在IPv6中，扩展头是在数据包的初始40字节之后并在上层头之前的任何头（可能是传输头、ICMPv6头或概念上的“无下一个头”）。
An initial set of IPv6 extension headers was defined by [RFC2460], which also described how they should be handled by intermediate nodes, with the exception of the Hop-by-Hop Options header:
[RFC2460]定义了一组初始的IPv6扩展标头，其中还描述了中间节点应如何处理这些标头，但逐跳选项标头除外：
...extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.
…在数据包到达IPv6报头的目的地地址字段中标识的节点（或多播情况下的每一组节点）之前，任何节点都不会沿数据包的传递路径检查或处理扩展报头。
This provision meant that forwarding nodes should be completely transparent to extension headers. There was no provision for forwarding nodes to modify them, remove them, insert them, or use them to affect forwarding behaviour. Thus, new extension headers could be introduced progressively and used only by hosts that have been updated to create and interpret them [RFC6564]. The extension header mechanism is an important part of the IPv6 architecture, and several new extension headers have been standardised since RFC 2460 was published.
这意味着转发节点对扩展头应该是完全透明的。没有规定转发节点可以修改、删除、插入或使用它们来影响转发行为。因此，可以逐步引入新的扩展头，并仅由已更新以创建和解释它们的主机使用[RFC6564]。扩展报头机制是IPv6体系结构的重要组成部分，自RFC2460发布以来，几个新的扩展报头已经标准化。
Today, IPv6 packets are not always forwarded by straightforward IP routing based on their first 40 bytes. Some routers, and a variety of intermediate nodes often referred to as middleboxes, such as firewalls, load balancers, or packet classifiers, might inspect other parts of each packet. Indeed, such middlebox functions are often embedded in routers. However, experience has shown that as a result, the network is not transparent to IPv6 extension headers. Contrary to Section 4 of RFC 2460, middleboxes sometimes examine and process
如今，IPv6数据包并不总是通过基于前40个字节的直接IP路由转发。一些路由器和各种中间节点（通常称为中间盒，如防火墙、负载平衡器或数据包分类器）可能会检查每个数据包的其他部分。事实上，这种中间盒功能通常嵌入在路由器中。然而，经验表明，因此，网络对IPv6扩展头不透明。与RFC 2460第4节相反，中间盒有时会检查和处理
the entire IPv6 packet before making a decision to either forward or discard the packet. This means that they need to traverse the chain of extension headers, if present, until they find the transport header (or an encrypted payload). Unfortunately, because not all IPv6 extension headers follow a uniform TLV format, this process is clumsy and requires knowledge of each extension header's format. A separate problem is that the header chain may even be fragmented [HEADER-CHAIN].
在决定转发或丢弃该数据包之前，请先删除整个IPv6数据包。这意味着它们需要遍历扩展头链（如果存在），直到找到传输头（或加密的负载）。不幸的是，由于并非所有IPv6扩展头都遵循统一的TLV格式，因此此过程非常笨拙，需要了解每个扩展头的格式。另一个问题是，头链甚至可能被分割[头链]。
The process is potentially slow as well as clumsy, possibly precluding its use in nodes attempting to process packets at line speed. The present document does not intend to solve this problem, which is caused by the fundamental architecture of IPv6 extension headers. This document focuses on clarifying how the header chain should be handled in the current IPv6 architecture.
该过程可能既慢又笨拙，可能会妨碍在试图以线路速度处理数据包的节点中使用它。本文档不打算解决这个问题，它是由IPv6扩展头的基本架构引起的。本文档重点说明在当前IPv6体系结构中应如何处理头链。
If they encounter an unrecognised extension header type, some firewalls treat the packet as suspect and drop it. Unfortunately, it is an established fact that several widely used firewalls do not recognise some or all of the extension headers standardised since RFC 2460 was published. It has also been observed that certain firewalls do not even handle all the extension headers standardised in RFC 2460, including the fragment header [FRAGDROP], causing fundamental problems of end-to-end connectivity. This applies in particular to firewalls that attempt to inspect packets at very high speed, since they cannot take the time to reassemble fragmented packets, especially when under a denial-of-service attack.
如果遇到无法识别的扩展头类型，某些防火墙会将该数据包视为可疑数据包并将其丢弃。不幸的是，一些广泛使用的防火墙无法识别RFC2460发布以来标准化的部分或全部扩展头，这是一个既定事实。还观察到，某些防火墙甚至不能处理RFC 2460中标准化的所有扩展头，包括片段头[FRAGDROP]，从而导致端到端连接的基本问题。这尤其适用于试图以非常高的速度检查数据包的防火墙，因为它们无法花时间重新组装碎片数据包，尤其是在受到拒绝服务攻击时。
Other types of middleboxes, such as load balancers or packet classifiers, might also fail in the presence of extension headers that they do not recognise.
其他类型的中间盒，如负载平衡器或数据包分类器，在存在无法识别的扩展头时也可能失败。
A contributory factor to this problem is that because extension headers are numbered out of the existing IP Protocol Number space, there is no collected list of them. For this reason, it is hard for an implementor to quickly identify the full set of standard extension headers. An implementor who consults only RFC 2460 will miss all extension headers defined subsequently.
导致此问题的一个因素是，由于扩展头的编号超出了现有IP协议编号空间，因此没有收集到扩展头的列表。因此，实现者很难快速识别完整的标准扩展头集。仅参考RFC2460的实现者将错过随后定义的所有扩展头。
This combination of circumstances creates a "Catch-22" situation [Heller] for the deployment of any newly standardised extension header except for local use. It cannot be widely deployed because existing middleboxes will drop it on many paths through the Internet. However, most middleboxes will not be updated to allow the new header to pass until it has been proved safe and useful on the open Internet, which is impossible until the middleboxes have been updated.
这种情况的组合为除本地使用之外的任何新标准化扩展头的部署创造了“第22条军规”的局面[Heller]。它不能被广泛部署，因为现有的中间包将把它放到互联网的许多路径上。然而，在开放互联网上证明新的头文件是安全和有用的之前，大多数中间包都不会被更新以允许新的头文件通过，而在中间包更新之前，这是不可能的。
The uniform TLV format now defined for extension headers [RFC6564] will improve the situation, but only for future extensions. Some tricky and potentially malicious cases will be avoided by forbidding very long chains of extension headers that need to be fragmented [HEADER-CHAIN]. This will alleviate concerns that stateless firewalls cannot locate a complete header chain as required by the present document.
现在为扩展头定义的统一TLV格式[RFC6564]将改善这种情况，但仅适用于将来的扩展。通过禁止需要分段的非常长的扩展头链[HEADER-CHAIN]，可以避免一些棘手的和潜在的恶意案例。这将缓解无状态防火墙无法按照本文档的要求定位完整的头链的担忧。
However, these changes are insufficient to correct the underlying problem. The present document clarifies that the above requirement from RFC 2460 applies to all types of nodes that forward IPv6 packets and to all extension headers standardised now and in the future. It also requests that IANA create a subsidiary registry that clearly identifies extension header types and updates RFC 2780 accordingly. Fundamental changes to the IPv6 extension header architecture are out of scope for this document.
然而，这些变化不足以纠正根本问题。本文件澄清了RFC 2460的上述要求适用于转发IPv6数据包的所有类型的节点以及现在和将来标准化的所有扩展头。它还要求IANA创建一个明确标识扩展头类型的附属注册表，并相应地更新RFC2780。对IPv6扩展标头体系结构的基本更改不在本文档范围内。
Also, hop-by-hop options are not handled by many high-speed routers or are processed only on a slow path. This document also updates the requirements for processing the Hop-by-Hop Options header to make them more realistic.
此外，逐跳选项不由许多高速路由器处理，或仅在慢速路径上处理。本文档还更新了处理逐跳选项标题的要求，使其更符合实际情况。
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]中所述进行解释。
In the remainder of this document, the term "forwarding node" refers to any router, firewall, load balancer, prefix translator, or any other device or middlebox that forwards IPv6 packets with or without examining the packet in any way.
在本文档的其余部分中，术语“转发节点”指任何路由器、防火墙、负载平衡器、前缀转换器或转发IPv6数据包的任何其他设备或中间盒，无论是否以任何方式检查数据包。
In this document, "standard" IPv6 extension headers are those specified in detail by IETF Standards Actions [RFC5226]. "Experimental" extension headers include those defined by any Experimental RFC and the header values 253 and 254 defined by [RFC3692] and [RFC4727] when used as experimental extension headers. "Defined" extension headers are the "standard" extension headers plus the "experimental" ones.
在本文档中，“标准”IPv6扩展头是IETF标准行动[RFC5226]中详细规定的头。“实验性”扩展头包括由任何实验性RFC定义的扩展头，以及用作实验性扩展头时由[RFC3692]和[RFC4727]定义的头值253和254。“已定义”扩展头是“标准”扩展头加上“实验”扩展头。
As mentioned above, forwarding nodes that discard packets containing extension headers are known to cause connectivity failures and deployment problems. Therefore, it is important that forwarding nodes that inspect IPv6 headers be able to parse all defined extension headers and deal with them appropriately, as specified in this section.
如上所述，丢弃包含扩展头的数据包的转发节点会导致连接失败和部署问题。因此，重要的是，检查IPv6头的转发节点能够解析所有定义的扩展头并适当地处理它们，如本节所述。
Any forwarding node along an IPv6 packet's path, which forwards the packet for any reason, SHOULD do so regardless of any extension headers that are present, as required by RFC 2460. Exceptionally, if a forwarding node is designed to examine extension headers for any reason, such as firewalling, it MUST recognise and deal appropriately with all standard IPv6 extension header types and SHOULD recognise and deal appropriately with experimental IPv6 extension header types. The list of standard and experimental extension header types is maintained by IANA (see Section 4), and implementors are advised to check this list regularly for updates.
按照RFC 2460的要求，沿IPv6数据包路径的任何转发节点（出于任何原因转发数据包）都应该这样做，而不管存在任何扩展头。例外情况下，如果转发节点被设计为出于任何原因（如防火墙）检查扩展头，则它必须识别并适当处理所有标准IPv6扩展头类型，并且应该识别并适当处理实验性IPv6扩展头类型。IANA维护标准和实验扩展头类型列表（参见第4节），建议实施者定期检查该列表以获取更新。
RFC 2460 requires destination hosts to discard packets containing unrecognised extension headers. However, intermediate forwarding nodes SHOULD NOT do this, since that might cause them to inadvertently discard traffic using a recently standardised extension header not yet recognised by the intermediate node. The exceptions to this rule are discussed next.
RFC2460要求目标主机丢弃包含无法识别的扩展头的数据包。但是，中间转发节点不应该这样做，因为这可能会导致它们使用中间节点尚未识别的最近标准化扩展报头无意中丢弃流量。下面将讨论此规则的例外情况。
If a forwarding node discards a packet containing a standard IPv6 extension header, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. This means that the discard policy for each standard type of extension header MUST be individually configurable. The default configuration SHOULD allow all standard extension headers.
如果转发节点丢弃包含标准IPv6扩展报头的数据包，则它必须是可配置策略的结果，而不仅仅是无法识别此类报头的结果。这意味着每个标准类型的扩展头的丢弃策略必须是可单独配置的。默认配置应允许所有标准扩展标题。
Experimental IPv6 extension headers SHOULD be treated in the same way as standard extension headers, including an individually configurable discard policy. However, the default configuration MAY drop experimental extension headers.
实验性IPv6扩展头应以与标准扩展头相同的方式处理，包括可单独配置的丢弃策略。但是，默认配置可能会删除实验性扩展标头。
Forwarding nodes MUST be configurable to allow packets containing unrecognised extension headers, but the default configuration MAY drop such packets.
转发节点必须可配置为允许包含无法识别的扩展头的数据包，但默认配置可能会丢弃此类数据包。
The IPv6 Routing Header Types 0 and 1 have been deprecated. Note that Type 0 was deprecated by [RFC5095]. However, this does not mean that the IPv6 Routing Header can be unconditionally dropped by
IPv6路由标头类型0和1已被弃用。请注意，类型0已被[RFC5095]弃用。然而，这并不意味着IPv6路由头可以被无条件地丢弃
forwarding nodes. Packets containing standardised and undeprecated Routing Headers SHOULD be forwarded by default. At the time of writing, these include Type 2 [RFC6275], Type 3 [RFC6554], and the experimental Routing Header Types 253 and 254 [RFC4727]. Others may be defined in the future.
转发节点。默认情况下，应转发包含标准化和未预先确定的路由头的数据包。在撰写本文时，这些类型包括类型2[RFC6275]、类型3[RFC6554]以及实验性路由报头类型253和254[RFC4727]。其他的可能在将来定义。
The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in [RFC2460]. However, it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path. Designers planning to use a hop-by-hop option need to be aware of this likely behaviour.
IPv6逐跳选项标头应由中间转发节点处理，如[RFC2460]中所述。然而，可以预期，高性能路由器要么忽略它，要么将包含它的数据包分配给一条缓慢的处理路径。计划使用逐跳选项的设计师需要了解这种可能的行为。
As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options header, if present, must be first.
作为提醒，在RFC 2460中，规定必须首先显示逐跳选项标头（如果存在）。
Forwarding nodes that operate as firewalls MUST conform to the requirements in the previous section in order to respect the IPv6 extension header architecture. In particular, packets containing standard extension headers are only to be discarded as a result of an intentionally configured policy.
作为防火墙运行的转发节点必须符合上一节中的要求，以遵守IPv6扩展标头体系结构。特别是，包含标准扩展头的数据包只会由于故意配置的策略而被丢弃。
These changes do not affect a firewall's ability to filter out traffic containing unwanted or suspect extension headers, if configured to do so. However, the changes do require firewalls to be capable of permitting any or all extension headers, if configured to do so. The default configurations are intended to allow normal use of any standard extension header, avoiding the connectivity issues described in Sections 1 and 2.1.
这些更改不会影响防火墙过滤包含不需要的或可疑的扩展头的流量（如果配置为这样做）的能力。但是，这些更改确实要求防火墙能够允许任何或所有扩展头（如果配置为允许的话）。默认配置旨在允许正常使用任何标准扩展标头，避免第1节和第2.1节中描述的连接问题。
As noted above, the default configuration might drop packets containing experimental extension headers. There is no header length field in an IPv6 header, and header types 253 and 254 might be used either for experimental extension headers or for experimental payload types. Therefore, there is no generic algorithm by which a firewall can distinguish these two cases and analyze the remainder of the packet. This should be considered when deciding on the appropriate default action for header types 253 and 254.
如上所述，默认配置可能会丢弃包含实验性扩展头的数据包。IPv6报头中没有报头长度字段，报头类型253和254可用于实验性扩展报头或实验性有效负载类型。因此，没有一种通用算法可以让防火墙区分这两种情况并分析数据包的其余部分。在决定253和254头类型的适当默认操作时，应考虑这一点。
When new extension headers are standardised in the future, those implementing and configuring forwarding nodes, including firewalls, will need to take them into account. A newly defined header will exercise new code paths in a host that does recognise it, so caution may be required. Additional security issues with experimental values
将来，当新的扩展头标准化时，那些实现和配置转发节点（包括防火墙）的人将需要考虑它们。新定义的头将在主机中执行新的代码路径，但主机无法识别它，因此可能需要谨慎。具有实验值的其他安全问题
or new extension headers are to be found in [RFC4727] and [RFC6564]. As a result, it is to be expected that the deployment process will be slow and will depend on satisfactory operational experience. Until deployment is complete, the new extension will fail in some parts of the Internet. This aspect needs to be considered when deciding to standardise a new extension. Specific security considerations for each new extension should be documented in the document that defines it.
或者可以在[RFC4727]和[RFC6564]中找到新的扩展头。因此，预计部署进程将缓慢，并将取决于令人满意的行动经验。在部署完成之前，新的扩展将在Internet的某些部分失败。在决定标准化新扩展时，需要考虑这一方面。每个新扩展的特定安全注意事项应记录在定义它的文档中。
IANA has added an extra column titled "IPv6 Extension Header" to the "Assigned Internet Protocol Numbers" registry to clearly mark those values that are also IPv6 extension header types defined by an IETF Standards Action or IESG Approval (see list below). This also applies to IPv6 extension header types defined in the future.
IANA在“分配的互联网协议号”注册表中添加了一个额外的标题为“IPv6扩展头”的列，以清楚地标记那些也是IETF标准行动或IESG批准定义的IPv6扩展头类型的值（见下面的列表）。这也适用于将来定义的IPv6扩展头类型。
Additionally, IANA has closed the existing empty "Next Header Types" registry to new entries and is redirecting its users to a new "IPv6 Extension Header Types" registry. This registry contains only those protocol numbers that are also marked as IPv6 Extension Header types in the "Assigned Internet Protocol Numbers" registry. Experimental values will be marked as such. The initial list will be as follows:
此外，IANA已将现有的空“下一个标头类型”注册表关闭到新条目，并将其用户重定向到新的“IPv6扩展标头类型”注册表。此注册表仅包含在“分配的Internet协议号”注册表中也标记为IPv6扩展头类型的协议号。实验值将按此进行标记。初步名单如下：
o 0, IPv6 Hop-by-Hop Option, [RFC2460]
o 0，IPv6逐跳选项，[RFC2460]
o 43, Routing Header for IPv6, [RFC2460], [RFC5095]
o 43，IPv6的路由头[RFC2460]，[RFC5095]
o 44, Fragment Header for IPv6, [RFC2460]
o 44，IPv6的片段头[RFC2460]
o 50, Encapsulating Security Payload, [RFC4303]
o 50，封装安全有效负载[RFC4303]
o 51, Authentication Header, [RFC4302]
o 51，认证头[RFC4302]
o 60, Destination Options for IPv6, [RFC2460]
o 60，IPv6的目标选项，[RFC2460]
o 135, Mobility Header, [RFC6275]
o 135，移动头，[RFC6275]
o 139, Experimental use, Host Identity Protocol [RFC5201]
o 139，实验使用，主机标识协议[RFC5201]
o 140, Shim6 Protocol, [RFC5533]
o 140，Shim6协议，[RFC5533]
o 253, Use for experimentation and testing, [RFC3692], [RFC4727]
o 253，用于实验和测试，[RFC3692]，[RFC4727]
o 254, Use for experimentation and testing, [RFC3692], [RFC4727]
o 254，用于试验和测试，[RFC3692]，[RFC4727]
This list excludes type 59, No Next Header, [RFC2460], which is not an extension header as such.
此列表不包括类型59，无下一个标头[RFC2460]，它本身不是扩展标头。
The references to the IPv6 Next Header field in [RFC2780] are to be interpreted as also applying to the IPv6 Extension Header field, and the "IPv6 Extension Header Types" registry will be managed accordingly.
[RFC2780]中对IPv6下一个标头字段的引用将被解释为也适用于IPv6扩展标头字段，并且将相应地管理“IPv6扩展标头类型”注册表。
This document was triggered by mailing list discussions including John Leslie, Stefan Marksteiner, and others. Valuable comments and contributions were made by Dominique Barthel, Tim Chown, Lorenzo Colitti, Fernando Gont, C. M. Heard, Bob Hinden, Ray Hunter, Suresh Krishnan, Marc Lampo, Sandra Murphy, Michael Richardson, Dan Romascanu, Dave Thaler, Joe Touch, Bjoern Zeeb, and others.
本文档由邮件列表讨论引发，包括John Leslie、Stefan Marksteiner和其他人。多米尼克·巴特尔、蒂姆·乔恩、洛伦佐·科利蒂、费尔南多·冈特、C.M.赫德、鲍勃·欣登、雷·亨特、苏雷什·克里希南、马克·兰波、桑德拉·墨菲、迈克尔·理查森、丹·罗马斯库、戴夫·泰勒、乔·图奇、比约恩·泽布和其他人发表了宝贵的评论和贡献。
Brian Carpenter was a visitor at the Computer Laboratory at Cambridge University during part of this work.
布赖恩·卡彭特是剑桥大学计算机实验室的一名访客，他参与了这项工作的一部分。
[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月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780]Bradner，S.和V.Paxson，“互联网协议和相关报头中值的IANA分配指南”，BCP 37，RFC 2780，2000年3月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]Fenner，B.，“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”，RFC 4727，2006年11月。
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, April 2012.
[RFC6564]Krishnan，S.，Woodyatt，J.，Kline，E.，Hoagland，J.，和M.Bhatia，“IPv6扩展头的统一格式”，RFC 6564，2012年4月。
[FRAGDROP] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, M., and T. Taylor, "Why Operators Filter Fragments and What It Implies", Work in Progress, June 2013.
[FRAGDROP]Jaeggli，J.，Coletti，L.，Kumari，W.，Vyncke，E.，Kaeo，M.，和T.Taylor，“为什么操作员过滤碎片及其含义”，正在进行的工作，2013年6月。
[HEADER-CHAIN] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", Work in Progress, October 2013.
[头链]Gont，F.，Manral，V.，和R.Bonica，“超大IPv6头链的影响”，正在进行的工作，2013年10月。
[Heller] Heller, J., "Catch-22", Simon and Schuster, November 1961.
[Heller]Heller，J.，“第22条军规”，西蒙和舒斯特，1961年11月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
[RFC5095]Abley，J.，Savola，P.，和G.Neville Neil，“IPv6中0型路由头的弃用”，RFC 5095，2007年12月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533]Nordmark，E.和M.Bagnulo，“Shim6:IPv6的3级多主垫片协议”，RFC 55332009年6月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, March 2012.
[RFC6554]Hui，J.，Vasseur，JP.，Culler，D.，和V.Manral，“低功耗和有损网络（RPL）路由协议源路由的IPv6路由头”，RFC 65542012年3月。
Authors' Addresses
作者地址
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
Brian Carpenter奥克兰大学计算机系，奥克兰92019，新西兰1142
EMail: brian.e.carpenter@gmail.com
EMail: brian.e.carpenter@gmail.com
Sheng Jiang Huawei Technologies Co., Ltd. Q14, Huawei Campus No. 156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China
盛江华为技术有限公司中国北京市海淀区北青路156号华为校区Q14，邮编100095
EMail: jiangsheng@huawei.com
EMail: jiangsheng@huawei.com