Internet Engineering Task Force (IETF) M. Eubanks
Request for Comments: 6935 AmericaFree.TV LLC
Updates: 2460 P. Chimento
Category: Standards Track Johns Hopkins University Applied
ISSN: 2070-1721 Physics Laboratory
M. Westerlund
Ericsson
April 2013
Internet Engineering Task Force (IETF) M. Eubanks
Request for Comments: 6935 AmericaFree.TV LLC
Updates: 2460 P. Chimento
Category: Standards Track Johns Hopkins University Applied
ISSN: 2070-1721 Physics Laboratory
M. Westerlund
Ericsson
April 2013
IPv6 and UDP Checksums for Tunneled Packets
隧道数据包的IPv6和UDP校验和
Abstract
摘要
This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried. Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method.
本文档更新了IPv6规范（RFC 2460），以提高隧道协议使用UDP和IPv6来隧道数据包时的性能。性能改进是通过放宽IPv6 UDP校验和要求来实现的，该要求适用于头信息在所携带的“内部”数据包上受到保护的隧道协议。放宽这一要求将消除与在承载隧道协议数据包的IPv6数据包上计算UDP校验和相关的开销。本规范描述了当封装的数据包本身包含校验和时，如何放宽IPv6 UDP校验和要求。它还描述了这种方法的局限性和风险，并讨论了对使用这种方法的限制。
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/rfc6935.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6935.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Analysis of Corruption in Tunnel Context . . . . . . . . . 5
4.2. Limitation to Tunnel Protocols . . . . . . . . . . . . . . 7
4.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 8
5. The Zero UDP Checksum Update . . . . . . . . . . . . . . . . . 9
6. Additional Observations . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Analysis of Corruption in Tunnel Context . . . . . . . . . 5
4.2. Limitation to Tunnel Protocols . . . . . . . . . . . . . . 7
4.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 8
5. The Zero UDP Checksum Update . . . . . . . . . . . . . . . . . 9
6. Additional Observations . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
This document constitutes an update of the IPv6 specification [RFC2460] for cases where a tunnel protocol uses UDP with IPv6 to tunnel packets. With the rapid growth of the Internet, tunnel protocols have become increasingly important to enable the deployment of new protocols. Tunnel protocols can be deployed rapidly, while the time to upgrade and deploy a new protocol on a critical mass of routers, middleboxes, and hosts on the global Internet is now measured in decades. At the same time, the increasing use of firewalls and other security-related middleboxes means that truly new tunnel protocols, with new protocol numbers, are also unlikely to be deployable in a reasonable time frame. The result is an increasing interest in and use of UDP-based tunnel protocols. In such protocols, there is an encapsulated "inner" packet, and the "outer" packet carrying the tunneled inner packet is a UDP packet, which can pass through firewalls and other middleboxes that perform the filtering that is a fact of life on the current Internet.
本文档构成了IPv6规范[RFC2460]的更新，适用于隧道协议使用UDP和IPv6来隧道数据包的情况。随着互联网的快速发展，隧道协议对于新协议的部署变得越来越重要。隧道协议可以快速部署，而在全球互联网上的大量路由器、中间盒和主机上升级和部署新协议的时间现在可以用几十年来衡量。与此同时，防火墙和其他与安全相关的中间盒的使用越来越多，这意味着具有新协议编号的真正新的隧道协议也不可能在合理的时间范围内部署。其结果是人们对基于UDP的隧道协议越来越感兴趣并越来越多地使用它。在这些协议中，有一个封装的“内部”数据包，而携带隧道内部数据包的“外部”数据包是一个UDP数据包，它可以通过防火墙和其他执行过滤的中间盒，这是当前Internet上的一个事实。
Tunnel endpoints may be routers or middleboxes aggregating traffic from a number of tunnel users. Therefore, the computation of an additional checksum on the outer UDP packet may be seen as an unwarranted burden on nodes that implement a tunnel protocol, especially if the inner packets are already protected by a checksum. IPv4 has a checksum over the IP packet header, and the checksum on the outer UDP packet may be set to zero. However, IPv6 has no checksum in the IP header, and RFC 2460 [RFC2460] explicitly states that IPv6 receivers MUST discard UDP packets with a zero checksum. So, while sending a UDP datagram with a zero checksum is permitted in IPv4 packets, it is explicitly forbidden in IPv6 packets. To improve support for IPv6 UDP tunnels, this document updates RFC 2460 to allow endpoints to use a zero UDP checksum under constrained situations (primarily for IPv6 tunnel transports that carry checksum-protected packets), following the applicability statements and constraints in [RFC6936].
隧道端点可以是聚集来自多个隧道用户的流量的路由器或中间盒。因此，外部UDP分组上附加校验和的计算可能被视为对实现隧道协议的节点的不必要负担，特别是如果内部分组已经受到校验和的保护。IPv4在IP数据包头上有一个校验和，外部UDP数据包上的校验和可以设置为零。但是，IPv6在IP报头中没有校验和，RFC 2460[RFC2460]明确表示IPv6接收器必须丢弃校验和为零的UDP数据包。因此，虽然在IPv4数据包中允许发送校验和为零的UDP数据报，但在IPv6数据包中明确禁止发送校验和为零的UDP数据报。为了改进对IPv6 UDP隧道的支持，本文档更新了RFC 2460，以允许端点在受限情况下使用零UDP校验和（主要用于承载校验和保护数据包的IPv6隧道传输），遵循[RFC6936]中的适用性声明和约束。
When reading this document, the advice in "Unicast UDP Usage Guidelines for Application Designers" [RFC5405] is applicable. It discusses both UDP tunnels (Section 3.1.3) and the usage of checksums (Section 3.4).
阅读本文档时，“应用程序设计者单播UDP使用指南”[RFC5405]中的建议适用。它讨论了UDP隧道（第3.1.3节）和校验和的使用（第3.4节）。
While the origin of this specification is the problem raised by the draft titled "Automatic Multicast Tunnels", also known as "AMT" [AMT], we expect it to have wide applicability. Since the first draft of this RFC was written, the need for an efficient UDP tunneling mechanism has increased. Other IETF Working Groups, notably LISP [RFC6830] and Softwires [RFC5619], have expressed a need
虽然本规范的起源是题为“自动多播隧道”（也称为“AMT”[AMT]）的草案提出的问题，但我们希望它具有广泛的适用性。自从本RFC的初稿编写以来，对高效UDP隧道机制的需求已经增加。其他IETF工作组，特别是LISP[RFC6830]和Softwires[RFC5619]表示需要
to update the UDP checksum processing in RFC 2460. We therefore expect this update to be applicable in the future to other tunnel protocols specified by these and other IETF Working Groups.
更新RFC 2460中的UDP校验和处理。因此，我们期望该更新将来适用于这些和其他IETF工作组指定的其他隧道协议。
This document discusses only IPv6, because the problem being addressed does not exist for IPv4. Therefore, all references to "IP" should be understood as references to IPv6.
本文档仅讨论IPv6，因为IPv4不存在要解决的问题。因此，对“IP”的所有引用都应理解为对IPv6的引用。
The document uses the terms "tunneling" and "tunneled" as adjectives when describing packets. When we refer to "tunneling packets", we refer to the outer packet header that provides the tunneling function. When we refer to "tunneled packets", we refer to the inner packet, i.e., the packet being carried in the tunnel.
文档在描述数据包时使用术语“隧道”和“隧道”作为形容词。当我们提到“隧道数据包”时，我们指的是提供隧道功能的外部数据包头。当我们提到“隧道包”时，我们指的是内部包，即在隧道中承载的包。
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]中所述进行解释。
When using tunnel protocols based on UDP, there can be both a benefit and a cost to computing and checking the UDP checksum of the outer (encapsulating) UDP transport header. In certain cases, where reducing the forwarding cost is important, the cost of the computation may outweigh the benefit of the checksum. This document provides an update for usage of the UDP checksum with IPv6. The update is specified for use by a tunnel protocol that transports packets that are themselves protected by a checksum.
使用基于UDP的隧道协议时，计算和检查外部（封装）UDP传输头的UDP校验和既有好处，也有成本。在某些情况下，在降低转发成本很重要的情况下，计算成本可能超过校验和的好处。本文档提供了在IPv6中使用UDP校验和的更新。该更新指定由隧道协议使用，该协议传输自身受校验和保护的数据包。
"Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936] describes issues related to allowing UDP over IPv6 to have a valid zero UDP checksum and is the starting point for this discussion. Sections 4 and 5 of [RFC6936], respectively, identify node implementation and usage requirements for datagrams sent and received with a zero UDP checksum. These sections introduce constraints on the usage of a zero checksum for UDP over IPv6. The remainder of this section analyzes the use of general tunnels and explains the motivations for why tunnel protocols are being permitted to use the method described in this update. It also discusses issues with middleboxes.
“使用具有零校验和的IPv6 UDP数据报的适用性声明”[RFC6936]描述了与允许IPv6上的UDP具有有效的零UDP校验和相关的问题，是本讨论的起点。[RFC6936]的第4节和第5节分别确定了使用零UDP校验和发送和接收的数据报的节点实现和使用要求。这些部分介绍了在IPv6上对UDP使用零校验和的限制。本节的其余部分分析了一般隧道的使用，并解释了为什么允许隧道协议使用本更新中描述的方法的动机。它还讨论了与中间盒有关的问题。
This section analyzes the impact of the different corruption modes in the context of a tunnel protocol. It specifies what needs to be considered by the designer and user of a tunnel protocol for the protocol to be robust. It also summarizes why use of a zero UDP checksum is thought to be safe for deployment.
本节分析隧道协议上下文中不同损坏模式的影响。它指定了隧道协议的设计者和用户需要考虑什么才能使协议具有健壮性。它还总结了为什么使用零UDP校验和被认为是安全的部署。
o Context (i.e., tunneling state) should be established by exchanging application Protocol Data Units (PDUs) carried in checksummed UDP datagrams or by using other protocols that provide integrity protection against corruption. These control packets should also carry any negotiation required to enable the tunnel endpoint to accept UDP datagrams with a zero checksum and identify the set of ports that are used. It is important that the control traffic is robust against corruption, because undetected errors can lead to long-lived and significant failures that may affect much more than the single packet that was corrupted.
o 上下文（即隧道状态）应通过交换校验和UDP数据报中携带的应用程序协议数据单元（PDU）或使用提供完整性保护以防止损坏的其他协议来建立。这些控制数据包还应包含使隧道端点能够接受校验和为零的UDP数据报并标识所使用的端口集所需的任何协商。重要的是，控制流量对损坏具有鲁棒性，因为未检测到的错误可能会导致长期和严重的故障，其影响可能远大于损坏的单个数据包。
o Keepalive datagrams with a zero UDP checksum should be sent to validate the network path, because the path between tunnel endpoints can change, and therefore, the set of middleboxes along the path may change during the life of an association. Paths with middleboxes that drop datagrams with a zero UDP checksum will drop these keepalives. To enable the tunnel endpoints to discover and react to this behavior in a timely way, the keepalive traffic should include datagrams with a non-zero checksum and datagrams with a zero checksum.
o 应发送UDP校验和为零的Keepalive数据报以验证网络路径，因为隧道端点之间的路径可能会更改，因此，在关联的生命周期内，路径上的中间盒集可能会更改。具有中间盒的路径丢弃UDP校验和为零的数据报时，将丢弃这些keepalive。为了使隧道端点能够及时发现并响应此行为，keepalive流量应该包括具有非零校验和的数据报和具有零校验和的数据报。
o Receivers should attempt to detect corruption of the address information in an encapsulating packet. A robust tunnel protocol should track tunnel context based on the 5-tuple (tunneled protocol number, IPv6 source address, IPv6 destination address, UDP source port, UDP destination port). A corrupted datagram that arrives at a destination may be filtered based on this check.
o 接收方应尝试检测封装数据包中地址信息的损坏。健壮的隧道协议应基于5元组（隧道协议编号、IPv6源地址、IPv6目标地址、UDP源端口、UDP目标端口）跟踪隧道上下文。到达目的地的损坏数据报可能会根据此检查进行过滤。
* If the datagram header matches the 5-tuple and the node has enabled the zero checksum for this port, the payload is matched to the wrong context. The tunneled packet will then be decapsulated and forwarded by the tunnel egress.
* 如果数据报报头与5元组匹配，并且节点已为此端口启用零校验和，则有效负载与错误的上下文匹配。然后，隧道出口将对隧道包进行解封和转发。
* If a corrupted datagram matches a different 5-tuple and the node has enabled zero checksum for the port, the datagram payload is matched to the wrong context and may be processed by the wrong tunnel protocol, provided that it also passes the verification of that protocol.
* 如果损坏的数据报与不同的5元组匹配，并且节点已为端口启用零校验和，则数据报负载与错误的上下文匹配，并且可能由错误的隧道协议处理，前提是它也通过了该协议的验证。
* If a corrupted datagram matches a 5-tuple and node has not enabled the zero checksum for this port, the datagram will be discarded.
* 如果损坏的数据报与5元组匹配，并且节点未为此端口启用零校验和，则该数据报将被丢弃。
When only the source information is corrupted, the datagram could arrive at the intended applications or protocol, which will process the datagram and try to match it against an existing tunnel context. The likelihood that a corrupted packet enters a valid context is reduced when the protocol restricts processing to only the source addresses with established contexts. When both source and destination fields are corrupted, this also decreases the likelihood of matching a context. However, the exception is when errors replace one packet header with another, so both packets could be tunneled, and therefore the corrupted packet could match a previously defined context.
当只有源信息损坏时，数据报可能到达预期的应用程序或协议，该应用程序或协议将处理数据报并尝试将其与现有隧道上下文匹配。当协议仅将处理限制在具有已建立上下文的源地址时，损坏的数据包进入有效上下文的可能性降低。当源字段和目标字段都损坏时，这也会降低匹配上下文的可能性。但是，例外情况是错误将一个数据包头替换为另一个数据包头，因此两个数据包都可以通过隧道传输，因此损坏的数据包可以匹配先前定义的上下文。
o Receivers should attempt to detect corruption of source-fragmented encapsulating packets. A tunnel protocol may reassemble fragments associated with the wrong context at the right tunnel endpoint, it may reassemble fragments associated with a context at the wrong tunnel endpoint, or corrupted fragments may be reassembled at the right context at the right tunnel endpoint. In each of these cases, the IPv6 length of the encapsulating header may be checked (although [RFC6936] points out the weakness in this check). In addition, if the encapsulated packet is protected by a transport (or other) checksum, these errors can be detected (with some probability).
o 接收器应尝试检测源碎片封装数据包的损坏。隧道协议可以在正确的隧道端点处重新组装与错误的上下文相关联的片段，它可以在错误的隧道端点处重新组装与上下文相关联的片段，或者可以在正确的隧道端点处重新组装损坏的片段。在每种情况下，都可以检查封装头的IPv6长度（尽管[RFC6936]指出了此检查中的弱点）。此外，如果封装的数据包受到传输（或其他）校验和的保护，则可以检测到这些错误（具有一定的概率）。
o Compared to other applications, tunnel protocols using UDP have some advantages that reduce the risk for a corrupted tunnel packet reaching a destination that will receive it. These advantages result from processing by the network of the inner (tunneled) packet after it is forwarded from the tunnel egress using a wrong context:
o 与其他应用程序相比，使用UDP的隧道协议具有一些优势，可以降低损坏的隧道数据包到达接收它的目的地的风险。这些优势源于网络在使用错误上下文从隧道出口转发内部（隧道）分组后对其进行处理：
* A tunneled packet may be forwarded to the wrong address domain, for example, to a private address domain where the inner packet's address is not routable, or it may fail a source address check, such as Unicast Reverse Path Forwarding [RFC2827], resulting in the packet being dropped.
* 隧道包可能被转发到错误的地址域，例如，到内部包的地址不可路由的私有地址域，或者它可能无法通过源地址检查，例如单播反向路径转发[RFC2827]，从而导致包被丢弃。
* The destination address of a tunneled packet may not be reachable at all from the delivered domain. An example is an Ethernet frame where the destination MAC address is not present on the LAN segment that was reached.
* 隧道包的目标地址可能根本无法从交付的域访问。一个例子是以太网帧，其中到达的LAN段上不存在目标MAC地址。
* The type of the tunneled packet may prevent delivery. For example, an attempt to interpret an IP packet payload as an Ethernet frame would likely to result in the packet being dropped as invalid.
* 隧道包的类型可能会阻止传递。例如，试图将IP数据包有效负载解释为以太网帧可能会导致数据包被丢弃为无效。
* The tunneled packet checksum or integrity mechanism may detect corruption of the inner packet caused at the same time as corruption to the outer packet header. The resulting packet would likely be dropped as invalid.
* 隧道分组校验和或完整性机制可以检测在外部分组报头损坏的同时引起的内部分组损坏。生成的数据包可能会被丢弃为无效数据包。
Each of these checks significantly reduces the likelihood that a corrupted inner tunneled packet is finally delivered to a protocol listener that can be affected by the packet. While the methods do not guarantee correctness, they can reduce the risks of relaxing the UDP checksum requirement for a tunnel application using IPv6.
这些检查中的每一项都显著降低了损坏的内部隧道数据包最终被传送到可能受数据包影响的协议侦听器的可能性。虽然这些方法不能保证正确性，但它们可以降低使用IPv6的隧道应用程序放宽UDP校验和要求的风险。
This document describes the applicability of using a zero UDP checksum to support tunnel protocols. There are good motivations behind this, and the arguments are provided here.
本文档描述了使用零UDP校验和来支持隧道协议的适用性。这背后有很好的动机，这里提供了论据。
o Tunnels carry inner packets that have their own semantics, which may make any corruption less likely to reach the indicated destination and be accepted as a valid packet. This is true for IP packets with the addition of verification that can be made by the tunnel protocol, the network processing of the inner packet headers as discussed above, and verification of the inner packet checksums. Non-IP inner packets are likely to be subject to similar effects that may reduce the likelihood of a misdelivered packet being delivered to a protocol listener that can be affected by the packet.
o 隧道携带具有其自身语义的内部数据包，这可能会降低任何损坏到达指定目的地并被接受为有效数据包的可能性。这对于IP数据包来说是正确的，添加了可通过隧道协议进行的验证、如上所述的内部数据包报头的网络处理以及内部数据包校验和的验证。非IP内部分组可能受到类似的影响，这些影响可能降低误发分组被发送到可能受分组影响的协议侦听器的可能性。
o Protocols that directly consume the payload must have sufficient robustness against misdelivered packets (from any context), including ones that are corrupted in tunnels or corrupted by other usage of the zero checksum. This will require an integrity mechanism. Using a standard UDP checksum reduces the computational load in the receiver that is necessary to verify this mechanism.
o 直接使用有效负载的协议必须具有足够的健壮性，以防止（来自任何上下文的）错误传递的数据包，包括在隧道中损坏的数据包或因使用零校验和而损坏的数据包。这需要一个完整性机制。使用标准UDP校验和可以减少接收器中验证此机制所需的计算负载。
o The design for stateful protocols or protocols where corruption causes cascade effects requires extra care. In tunnel usage, each encapsulating packet provides no functions other than a transport from tunnel ingress to tunnel egress. A corruption will commonly affect only the single tunneled packet, not the established
o 对于有状态协议或损坏导致级联效应的协议的设计需要格外小心。在隧道使用中，每个封装包除了从隧道入口到隧道出口的传输之外不提供任何功能。损坏通常只会影响单个隧道数据包，而不会影响已建立的数据包
protocol state. One common effect is that the inner packet flow will see only a corruption and a misdelivery of the outer packet as a lost packet.
协议状态。一个常见的影响是，内部数据包流将只看到外部数据包作为丢失数据包的损坏和错误传递。
o Some non-tunnel protocols operate with general servers that do not know the source from which they will receive a packet. In such applications, a zero UDP checksum is unsuitable, because it is necessary to provide the first level of verification that the packet was intended for the receiving server. A verification prevents the server from processing the datagram payload; without this, the server may spend significant resources processing the packet, including sending replies or error messages.
o 一些非隧道协议与不知道从何处接收数据包的一般服务器一起运行。在这样的应用中，零UDP校验和是不合适的，因为有必要提供第一级验证，以确认数据包是用于接收服务器的。验证防止服务器处理数据报有效载荷；否则，服务器可能会花费大量资源处理数据包，包括发送回复或错误消息。
Tunnel protocols that encapsulate IP will generally be safe for deployment, because all IPv4 and IPv6 packets include at least one checksum at either the network or transport layer. The network delivery of the inner packet will then further reduce the effects of corruption. Tunnel protocols carrying non-IP packets may offer equivalent protection when the non-IP networks reduce the risk of misdelivery to applications. However, further analysis is necessary to understand the implications of misdelivery of corrupted packets for each non-IP protocol. The analysis above suggests that non-tunnel protocols can be expected to have significantly more cases where a zero checksum would result in misdelivery or negative side effects.
封装IP的隧道协议在部署时通常是安全的，因为所有IPv4和IPv6数据包在网络层或传输层至少包含一个校验和。然后，内部数据包的网络交付将进一步减少损坏的影响。当非IP网络降低误发到应用程序的风险时，承载非IP数据包的隧道协议可以提供同等的保护。然而，有必要进一步分析，以了解每个非IP协议错误交付损坏数据包的影响。上述分析表明，非隧道协议可能会出现更多零校验和会导致错误交付或负面副作用的情况。
One unfortunate side effect of increased use of a zero checksum is that it also increases the likelihood of acceptance when a datagram with a zero UDP checksum is misdelivered. This requires all tunnel protocols using this method to be designed to be robust in the face of misdelivery.
增加使用零校验和的一个不幸的副作用是，当UDP校验和为零的数据报误发时，它也增加了接受的可能性。这要求所有使用此方法的隧道协议设计为在错误交付时具有鲁棒性。
"Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936] specifies requirements for middleboxes and tunnels that need to traverse middleboxes. Tunnel protocols intending to use a zero UDP checksum need to ensure that they have defined a method for handling cases when a middlebox prevents the path between the tunnel ingress and egress from supporting transmission of datagrams with a zero UDP checksum. This is especially important as middleboxes that conform to RFC 2460 are likely to discard datagrams with a zero UDP checksum.
“使用具有零校验和的IPv6 UDP数据报的适用性声明”[RFC6936]规定了需要遍历中间盒的中间盒和隧道的要求。打算使用零UDP校验和的隧道协议需要确保它们定义了一种方法，用于处理中间盒阻止隧道入口和出口之间的路径支持传输具有零UDP校验和的数据报的情况。这一点尤其重要，因为符合RFC2460的中间盒可能会丢弃UDP校验和为零的数据报。
This specification updates IPv6 to allow a zero UDP checksum in the outer encapsulating datagram of a tunnel protocol. UDP endpoints that implement this update MUST follow the node requirements in "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].
此规范更新了IPv6，以允许在隧道协议的外部封装数据报中使用零UDP校验和。实现此更新的UDP端点必须遵循“使用具有零校验和的IPv6 UDP数据报的适用性声明”[RFC6936]中的节点要求。
The following text in [RFC2460], Section 8.1, fourth bullet should be deleted:
[RFC2460]第8.1节第四个项目符号中的以下文本应删除：
Unlike IPv4, when UDP packets are originated by an IPv6 node, the UDP checksum is not optional. That is, whenever originating a UDP packet, an IPv6 node must compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, it must be changed to hex FFFF for placement in the UDP header. IPv6 receivers must discard UDP packets containing a zero checksum, and should log the error.
与IPv4不同，当UDP数据包由IPv6节点发起时，UDP校验和不是可选的。也就是说，每当发起UDP数据包时，IPv6节点必须计算该数据包和伪报头上的UDP校验和，如果该计算结果为零，则必须将其更改为十六进制FFFF以放置在UDP报头中。IPv6接收器必须丢弃包含零校验和的UDP数据包，并应记录错误。
This text should be replaced by:
该文本应替换为：
An IPv6 node associates a mode with each used UDP port (for sending and/or receiving packets).
IPv6节点将模式与每个使用的UDP端口（用于发送和/或接收数据包）相关联。
Whenever originating a UDP packet for a port in the default mode, an IPv6 node MUST compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, the checksum MUST be changed to hex FFFF for placement in the UDP header, as specified in [RFC2460]. IPv6 receivers MUST by default discard UDP packets containing a zero checksum and SHOULD log the error.
每当在默认模式下为端口发起UDP数据包时，IPv6节点必须计算数据包和伪报头上的UDP校验和，如果该计算结果为零，则必须将校验和更改为十六进制FFFF，以便放置在UDP报头中，如[RFC2460]中所述。IPv6接收器默认情况下必须丢弃包含零校验和的UDP数据包，并应记录错误。
As an alternative, certain protocols that use UDP as a tunnel encapsulation MAY enable zero-checksum mode for a specific port (or set of ports) for sending and/or receiving. Any node implementing zero-checksum mode MUST follow the node requirements specified in Section 4 of "Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].
作为替代方案，使用UDP作为隧道封装的某些协议可以为用于发送和/或接收的特定端口（或一组端口）启用零校验和模式。任何实现零校验和模式的节点必须遵守“使用具有零校验和的IPv6 UDP数据报的适用性声明”[RFC6936]第4节中规定的节点要求。
Any protocol that enables zero-checksum mode for a specific port or ports MUST follow the usage requirements specified in Section 5 of "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].
为一个或多个特定端口启用零校验和模式的任何协议必须遵循“使用零校验和的IPv6 UDP数据报的适用性声明”[RFC6936]第5节中规定的使用要求。
Middleboxes supporting IPv6 MUST follow requirements 9, 10, and 11 of the usage requirements specified in Section 5 of "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936].
支持IPv6的中间盒必须遵循“使用零校验和的IPv6 UDP数据报的适用性声明”第5节中规定的使用要求的第9、10和11条要求[RFC6936]。
This update was motivated by the existence of a number of protocols being developed in the IETF that are expected to benefit from the change. The following observations are made:
此次更新的动机是IETF中正在开发的一些协议的存在，这些协议有望从变更中受益。提出以下意见：
o An empirically based analysis of the probabilities of packet corruption (with or without checksums) has not, to our knowledge, been conducted since about 2000. At the time of publication, it is now 2013. We strongly suggest that a new empirical study be performed, along with extensive analysis of the corruption probabilities of the IPv6 header. This could potentially allow revising the recommendations in this document.
o 据我们所知，自2000年以来，还没有对数据包损坏（有或没有校验和）的概率进行基于经验的分析。在出版时，现在是2013年。我们强烈建议进行新的实证研究，同时对IPv6报头的损坏概率进行广泛分析。这可能允许修改本文件中的建议。
o A key motivation for the increase in use of UDP in tunneling is a lack of protocol support in middleboxes. Specifically, new protocols, such as LISP [RFC6830], may prefer to use UDP tunnels to traverse an end-to-end path successfully and avoid having their packets dropped by middleboxes. If middleboxes were updated to support UDP-Lite [RFC3828], UDP-Lite would provide better protection than offered by this update. UDP-Lite may be suited to a variety of applications and would be expected to be preferred over this method for many tunnel protocols.
o 在隧道中增加UDP使用的一个关键动机是中间盒中缺少协议支持。具体而言，新协议，如LISP[RFC6830]，可能更喜欢使用UDP隧道成功地穿越端到端路径，并避免其数据包被中间盒丢弃。如果更新了中间件以支持UDP Lite[RFC3828]，UDP Lite将提供比此更新更好的保护。UDP Lite可能适用于各种应用，并且对于许多隧道协议来说，与此方法相比，UDP Lite有望成为首选。
o Another issue is that the UDP checksum is overloaded with the task of protecting the IPv6 header for UDP flows (as is the TCP checksum for TCP flows). Protocols that do not use a pseudo-header approach to computing a checksum or CRC have essentially no protection from misdelivered packets.
o 另一个问题是UDP校验和因保护UDP流的IPv6报头的任务而过载（TCP流的TCP校验和也是如此）。不使用伪报头方法计算校验和或CRC的协议基本上没有防止误发数据包的保护。
Less work is required to generate an attack using a zero UDP checksum than one using a standard full UDP checksum. However, this does not lead to significant new vulnerabilities, because checksums are not a security measure and can be easily generated by any attacker.
使用零UDP校验和生成攻击比使用标准完整UDP校验和生成攻击所需的工作量更少。但是，这不会导致新的重大漏洞，因为校验和不是安全措施，任何攻击者都可以轻松生成。
In general, any user of zero UDP checksums should apply the checks and context verification that are possible to minimize the risk of unintended traffic to reach a particular context. This will, however, not protect against an intentional attack that creates packets with the correct information. Source address validation can help prevent injection of traffic into contexts by an attacker.
一般来说，任何零UDP校验和的用户都应该应用检查和上下文验证，以尽可能减少到达特定上下文的意外流量的风险。然而，这并不能防止创建具有正确信息的数据包的故意攻击。源地址验证有助于防止攻击者将流量注入上下文。
Depending on the hardware design, the processing requirements may differ for tunnels that have a zero UDP checksum and those that calculate a checksum. This processing overhead may need to be considered when deciding whether to enable a tunnel and to determine
根据硬件设计，具有零UDP校验和的隧道和计算校验和的隧道的处理要求可能不同。在决定是否启用隧道并确定
an acceptable rate for transmission. This processing overhead can become a security risk for designs that can handle a significantly larger number of packets with zero UDP checksums compared to datagrams with a non-zero checksum, such as a tunnel egress. An attacker could attempt to inject non-zero checksummed UDP packets into a tunnel forwarding zero checksum UDP packets and cause overload in the processing of the non-zero checksums, e.g., if this happens in a router's slow path. Therefore, protection mechanisms should be employed when this threat exists. Protection may include source-address filtering to prevent an attacker from injecting traffic, as well as throttling the amount of non-zero checksum traffic. The latter may impact the functioning of the tunnel protocol.
可接受的传输速率。与具有非零校验和的数据报（如隧道出口）相比，这种处理开销可能会成为具有零UDP校验和的设计的安全风险。攻击者可能试图将非零校验和UDP数据包注入转发零校验和UDP数据包的隧道，并在处理非零校验和时造成过载，例如，如果这发生在路由器的慢速路径中。因此，当存在这种威胁时，应采用保护机制。保护可能包括源地址过滤，以防止攻击者注入流量，以及限制非零校验和流量。后者可能会影响隧道协议的功能。
We would like to thank Brian Haberman, Dan Wing, Joel Halpern, David Waltermire, J.W. Atwood, Peter Yee, Joe Touch, and the IESG of 2012 for discussions and reviews. Gorry Fairhurst has been very diligent in reviewing and helping to ensure alignment between this document and [RFC6936].
我们要感谢Brian Haberman、Dan Wing、Joel Halpern、David Waltermire、J.W.Atwood、Peter Yee、Joe Touch和2012年IESG的讨论和评论。Gorry Fairhurst在审查和帮助确保本文件与[RFC6936]保持一致方面一直非常努力。
[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月。
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013.
[RFC6936]Fairhurst，G.和M.Westerlund，“使用具有零校验和的IPv6 UDP数据报的适用性声明”，RFC 69362013年4月。
[AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, June 2012.
[AMT]Bumgardner，G.，“自动多播隧道”，正在进行的工作，2012年6月。
[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月。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC3828]Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，和G.Fairhurst，“轻量级用户数据报协议（UDP Lite）”，RFC 38282004年7月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
[RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent, "Softwire Security Analysis and Requirements", RFC 5619, August 2009.
[RFC5619]Yamamoto，S.，Williams，C.，Yokota，H.，和F.Parent，“软线安全分析和要求”，RFC 5619109年8月。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013.
[RFC6830]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，RFC 6830，2013年1月。
Authors' Addresses
作者地址
Marshall Eubanks AmericaFree.TV LLC P.O. Box 141 Clifton, Virginia 20124 USA
美国弗吉尼亚州克利夫顿市Marshall Eubanks AmericaFree.TV LLC邮政信箱141号，邮编20124
Phone: +1-703-501-4376
EMail: marshall.eubanks@gmail.com
Phone: +1-703-501-4376
EMail: marshall.eubanks@gmail.com
P.F. Chimento Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, Maryland 20723 USA
P.F.奇门托约翰霍普金斯大学应用物理实验室美国马里兰州劳雷尔市约翰霍普金斯路11100号20723
Phone: +1-443-778-1743
EMail: Philip.Chimento@jhuapl.edu
Phone: +1-443-778-1743
EMail: Philip.Chimento@jhuapl.edu
Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden
Magnus Westerlund Ericsson Farogatan 6 SE-164 80瑞典基斯塔
Phone: +46 10 719 00 00
EMail: magnus.westerlund@ericsson.com
Phone: +46 10 719 00 00
EMail: magnus.westerlund@ericsson.com