Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 6936 University of Aberdeen
Category: Standards Track M. Westerlund
ISSN: 2070-1721 Ericsson
April 2013
Internet Engineering Task Force (IETF) G. Fairhurst
Request for Comments: 6936 University of Aberdeen
Category: Standards Track M. Westerlund
ISSN: 2070-1721 Ericsson
April 2013
Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums
使用具有零校验和的IPv6 UDP数据报的适用性声明
Abstract
摘要
This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6.
本文档提供了在IPv6中使用UDP传输校验和的适用性声明。它定义了使用UDP校验和为零的IPv6 UDP数据报的建议和要求。它描述了UDP与IPv6一起使用以支持隧道封装时需要考虑的问题和设计原则，并分析了IPv6 UDP传输校验和的作用。该文档还确定了在包括中间盒的网络路径上部署的问题和约束。附录总结了在评估RFC 2460更新的安全性时考虑的权衡，RFC 2460更改了UDP校验和与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/rfc6936.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6936.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Motivation for New Approaches . . . . . . . . . . . . 6
1.3.2. Reducing Forwarding Costs . . . . . . . . . . . . . . 6
1.3.3. Need to Inspect the Entire Packet . . . . . . . . . . 7
1.3.4. Interactions with Middleboxes . . . . . . . . . . . . 7
1.3.5. Support for Load Balancing . . . . . . . . . . . . . . 8
2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 9
2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 9
2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 10
2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 10
2.4. Relationship of Zero UDP Checksum to UDP-Lite and UDP
with Checksum . . . . . . . . . . . . . . . . . . . . . . 11
3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 12
3.1. Effect of Packet Modification in the Network . . . . . . . 13
3.1.1. Corruption of the Destination IP Address Field . . . . 14
3.1.2. Corruption of the Source IP Address Field . . . . . . 15
3.1.3. Corruption of Port Information . . . . . . . . . . . . 16
3.1.4. Delivery to an Unexpected Port . . . . . . . . . . . . 16
3.1.5. Corruption of Fragmentation Information . . . . . . . 18
3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 20
3.3. Validating the Network Path . . . . . . . . . . . . . . . 20
3.4. Applicability of the Zero UDP Checksum Method . . . . . . 21
3.5. Impact on Non-Supporting Devices or Applications . . . . . 22
4. Constraints on Implementation of IPv6 Nodes Supporting
Zero Checksum . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Requirements on Usage of the Zero UDP Checksum . . . . . . . . 24
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Evaluation of Proposal to Update RFC 2460 to
Support Zero Checksum . . . . . . . . . . . . . . . . 33
A.1. Alternatives to the Standard Checksum . . . . . . . . . . 33
A.2. Comparison of Alternative Methods . . . . . . . . . . . . 34
A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 34
A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 35
A.2.3. Ingress and Egress Performance Implications . . . . . 36
A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 36
A.2.5. Corruption Detection Strength . . . . . . . . . . . . 37
A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 37
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Use of UDP Tunnels . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Motivation for New Approaches . . . . . . . . . . . . 6
1.3.2. Reducing Forwarding Costs . . . . . . . . . . . . . . 6
1.3.3. Need to Inspect the Entire Packet . . . . . . . . . . 7
1.3.4. Interactions with Middleboxes . . . . . . . . . . . . 7
1.3.5. Support for Load Balancing . . . . . . . . . . . . . . 8
2. Standards-Track Transports . . . . . . . . . . . . . . . . . . 9
2.1. UDP with Standard Checksum . . . . . . . . . . . . . . . . 9
2.2. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Using UDP-Lite as a Tunnel Encapsulation . . . . . . . 10
2.3. General Tunnel Encapsulations . . . . . . . . . . . . . . 10
2.4. Relationship of Zero UDP Checksum to UDP-Lite and UDP
with Checksum . . . . . . . . . . . . . . . . . . . . . . 11
3. Issues Requiring Consideration . . . . . . . . . . . . . . . . 12
3.1. Effect of Packet Modification in the Network . . . . . . . 13
3.1.1. Corruption of the Destination IP Address Field . . . . 14
3.1.2. Corruption of the Source IP Address Field . . . . . . 15
3.1.3. Corruption of Port Information . . . . . . . . . . . . 16
3.1.4. Delivery to an Unexpected Port . . . . . . . . . . . . 16
3.1.5. Corruption of Fragmentation Information . . . . . . . 18
3.2. Where Packet Corruption Occurs . . . . . . . . . . . . . . 20
3.3. Validating the Network Path . . . . . . . . . . . . . . . 20
3.4. Applicability of the Zero UDP Checksum Method . . . . . . 21
3.5. Impact on Non-Supporting Devices or Applications . . . . . 22
4. Constraints on Implementation of IPv6 Nodes Supporting
Zero Checksum . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Requirements on Usage of the Zero UDP Checksum . . . . . . . . 24
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Evaluation of Proposal to Update RFC 2460 to
Support Zero Checksum . . . . . . . . . . . . . . . . 33
A.1. Alternatives to the Standard Checksum . . . . . . . . . . 33
A.2. Comparison of Alternative Methods . . . . . . . . . . . . 34
A.2.1. Middlebox Traversal . . . . . . . . . . . . . . . . . 34
A.2.2. Load Balancing . . . . . . . . . . . . . . . . . . . . 35
A.2.3. Ingress and Egress Performance Implications . . . . . 36
A.2.4. Deployability . . . . . . . . . . . . . . . . . . . . 36
A.2.5. Corruption Detection Strength . . . . . . . . . . . . 37
A.2.6. Comparison Summary . . . . . . . . . . . . . . . . . . 37
The User Datagram Protocol (UDP) [RFC0768] transport is defined for IPv4 [RFC0791], and it is defined in "Internet Protocol, Version 6 (IPv6)" [RFC2460] for IPv6 hosts and routers. The UDP transport protocol has a minimal set of features. This limited set has enabled a wide range of applications to use UDP, but these applications do need to provide many important transport functions on top of UDP. The UDP usage guidelines [RFC5405] provide overall guidance for application designers, including the use of UDP to support tunneling. The key difference between UDP usage with IPv4 and IPv6 is that RFC 2460 mandates use of a calculated UDP checksum, i.e., a non-zero value, due to the lack of an IPv6 header checksum. The inclusion of the pseudo-header in the checksum computation provides a statistical check that datagrams have been delivered to the intended IPv6 destination node. Algorithms for checksum computation are described in [RFC1071].
用户数据报协议（UDP）[RFC0768]传输是为IPv4[RFC0791]定义的，它是在“Internet协议，版本6（IPv6）”[RFC2460]中为IPv6主机和路由器定义的。UDP传输协议具有最少的一组功能。这个有限的集合使许多应用程序能够使用UDP，但这些应用程序确实需要在UDP之上提供许多重要的传输功能。UDP使用指南[RFC5405]为应用程序设计者提供了总体指导，包括使用UDP支持隧道。IPv4和IPv6使用UDP的关键区别在于，由于缺少IPv6报头校验和，RFC 2460强制使用计算的UDP校验和，即非零值。在校验和计算中包含伪报头提供了一种统计检查，即数据报是否已发送到预期的IPv6目标节点。[RFC1071]中描述了校验和计算的算法。
The inability to use an IPv6 datagram with a zero UDP checksum has been found to be a real problem for certain classes of application, primarily tunnel applications. This class of application has been deployed with a zero UDP checksum using IPv4. The design of IPv6 raises different issues when considering the safety of using a UDP checksum with IPv6. These issues can significantly affect applications, whether an endpoint is the intended user or an innocent bystander (i.e., when a packet is received by a different endpoint to that intended).
对于某些类型的应用程序（主要是隧道应用程序），无法使用UDP校验和为零的IPv6数据报是一个实际问题。此类应用程序已使用IPv4部署为零UDP校验和。考虑到在IPv6中使用UDP校验和的安全性，IPv6的设计提出了不同的问题。这些问题会显著影响应用程序，无论端点是预期用户还是无辜旁观者（即，当数据包被预期用户的不同端点接收时）。
This document identifies a set of issues that must be considered and mitigated to enable safe deployment of IPv6 applications that use a zero UDP checksum. The appendix compares the strengths and weaknesses of a number of proposed solutions. The comparison of methods provided in this document is also expected to be useful when considering applications that have different goals from the ones whose needs led to the writing of this document, especially applications that can use existing standardized transport protocols. The analysis concludes that using a zero UDP checksum is the best method of the proposed alternatives to meet the goals of certain tunnel applications.
本文档确定了一组必须考虑和缓解的问题，以便能够安全部署使用零UDP校验和的IPv6应用程序。附录比较了许多建议解决方案的优缺点。本文件中提供的方法的比较在考虑目标不同于需要编写本文件的应用程序时也很有用，尤其是可以使用现有标准化传输协议的应用程序。分析得出结论，使用零UDP校验和是建议的备选方案中的最佳方法，以满足某些隧道应用的目标。
This document defines recommendations and requirements for use of IPv6 datagrams with a zero UDP checksum. This usage is expected to have initial deployment issues related to middleboxes, limiting the usability more than desired in the currently deployed Internet. However, this limitation will be largest initially and will decrease as updates are provided in middleboxes that support the zero UDP
本文档定义了使用UDP校验和为零的IPv6数据报的建议和要求。这种使用预计会出现与中间包相关的初始部署问题，从而限制了当前部署的Internet的可用性。然而，这一限制最初将是最大的，并且随着支持零UDP的中间盒中提供的更新而减少
checksum for IPv6. Therefore, in this document, we derive a set of constraints required to ensure safe deployment of a zero UDP checksum.
IPv6的校验和。因此，在本文中，我们导出了一组确保安全部署零UDP校验和所需的约束。
Finally, the document identifies some issues that require future consideration and possibly additional research.
最后，该文件确定了一些需要进一步考虑和可能需要进一步研究的问题。
Section 1 provides a background to key issues and introduces the use of UDP as a tunnel transport protocol.
第1节提供了关键问题的背景知识，并介绍了UDP作为隧道传输协议的使用。
Section 2 describes a set of standards-track datagram transport protocols that may be used to support tunnels.
第2节描述了一组可用于支持隧道的标准轨道数据报传输协议。
Section 3 discusses issues with a zero UDP checksum for IPv6. It considers the impact of corruption, the need for validation of the path, and when it is suitable to use a zero UDP checksum.
第3节讨论IPv6的零UDP校验和问题。它考虑了损坏的影响、路径验证的需要以及何时适合使用零UDP校验和。
Section 4 is an applicability statement that defines requirements and recommendations on the implementation of IPv6 nodes that support the use of a zero UDP checksum.
第4节是适用性声明，定义了支持使用零UDP校验和的IPv6节点的实现要求和建议。
Section 5 provides an applicability statement that defines requirements and recommendations for protocols and tunnel encapsulations that are transported over an IPv6 transport that does not perform a UDP checksum calculation to verify the integrity at the transport endpoints.
第5节提供了适用性声明，其中定义了通过IPv6传输传输的协议和隧道封装的要求和建议，该传输不执行UDP校验和计算以验证传输端点的完整性。
Section 6 provides the recommendations for standardization of zero UDP checksum, with a summary of the findings, and notes the remaining issues that need future work.
第6节提供了关于零UDP校验和标准化的建议，总结了研究结果，并指出了需要进一步研究的剩余问题。
Appendix A evaluates the set of proposals to update the UDP transport behavior and other alternatives intended to improve support for tunnel protocols. It concludes by assessing the trade-offs of the various methods and by identifying advantages and disadvantages for each method.
附录A评估了更新UDP传输行为的一组建议，以及旨在改善对隧道协议支持的其他替代方案。最后，评估各种方法的利弊，并确定每种方法的优缺点。
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]中所述进行解释。
One increasingly popular use of UDP is as a tunneling protocol, where a tunnel endpoint encapsulates the packets of another protocol inside UDP datagrams and transmits them to another tunnel endpoint. Using UDP as a tunneling protocol is attractive when the payload protocol is not supported by the middleboxes that may exist along the path, because many middleboxes support transmission using UDP. In this use, the receiving endpoint decapsulates the UDP datagrams and forwards the original packets contained in the payload [RFC5405]. Tunnels establish virtual links that appear to directly connect locations that are distant in the physical Internet topology, and they can be used to create virtual (private) networks.
UDP的一个日益流行的用途是作为隧道协议，其中隧道端点将另一协议的数据包封装在UDP数据报中，并将其传输到另一个隧道端点。当路径上可能存在的中间盒不支持有效负载协议时，使用UDP作为隧道协议很有吸引力，因为许多中间盒支持使用UDP传输。在这种使用中，接收端点解除UDP数据报的封装，并转发有效负载中包含的原始数据包[RFC5405]。隧道建立虚拟链接，直接连接物理Internet拓扑中较远的位置，可用于创建虚拟（专用）网络。
A number of tunnel encapsulations deployed over IPv4 have used the UDP transport with a zero checksum. Users of these protocols expect a similar solution for IPv6.
许多通过IPv4部署的隧道封装都使用了校验和为零的UDP传输。这些协议的用户期望IPv6也有类似的解决方案。
A number of tunnel protocols are also currently being defined (e.g., Automated Multicast Tunnels [AMT] and Locator/Identifier Separation Protocol (LISP) [RFC6830]). These protocols provided several motivations to update IPv6 UDP checksum processing so that it would benefit from simpler checksum processing, including:
目前还定义了一些隧道协议（例如，自动多播隧道[AMT]和定位器/标识符分离协议（LISP）[RFC6830]）。这些协议提供了更新IPv6 UDP校验和处理的几个动机，以便从更简单的校验和处理中获益，包括：
o Reducing forwarding costs, motivated by redundancy present in the encapsulated packet header, because in tunnel encapsulations, payload integrity and length verification may be provided by higher-layer encapsulations (often using the IPv4, UDP, UDP-Lite [RFC3828], or TCP checksums [RFC0793]).
o 由于在隧道封装中，有效负载完整性和长度验证可以通过更高层的封装（通常使用IPv4、UDP、UDP Lite[RFC3828]或TCP校验和[RFC0793]）来提供，因此，受封装的数据包报头中存在冗余的激励，降低了转发成本。
o Eliminating the need to access the entire packet when a tunnel endpoint forwards the packet.
o 当隧道端点转发数据包时，无需访问整个数据包。
o Enhancing the ability to traverse and function with middleboxes.
o 增强遍历和使用中间盒的能力。
o A desire to use the port number space to enable load sharing.
o 希望使用端口号空间来实现负载共享。
It is a common requirement to terminate a large number of tunnels on a single router or host. The processing cost per tunnel includes both state (memory requirements) and per-packet processing at the tunnel ingress and egress.
在单个路由器或主机上终止大量隧道是常见的要求。每个隧道的处理成本包括状态（内存需求）和隧道入口和出口处的每个分组处理。
Automatic IP Multicast Tunneling, known as AMT [AMT], currently specifies UDP as the transport protocol for packets carrying tunneled IP multicast packets. The current specification for AMT states that the UDP checksum in the outer packet header should be zero (see Section 6.6 of [AMT]). That section argues that the computation of an additional checksum is an unwarranted burden on nodes implementing lightweight tunneling protocols when an inner packet is already adequately protected. The AMT protocol needs to replicate a multicast packet to each gateway tunnel. In this case, the outer IP addresses are different for each tunnel; therefore, a different pseudo-header must be built to form the header for each tunnel egress that receives replicated multicast packets.
自动IP多播隧道（称为AMT[AMT]）目前指定UDP作为传输协议，用于传输通过隧道传输的IP多播数据包。AMT的当前规范规定，外部数据包报头中的UDP校验和应为零（见[AMT]第6.6节）。该部分认为，当内部数据包已经得到充分保护时，额外校验和的计算对于实现轻量级隧道协议的节点来说是一个不必要的负担。AMT协议需要将多播数据包复制到每个网关隧道。在这种情况下，每个隧道的外部IP地址不同；因此，必须构建不同的伪报头，以形成接收复制多播数据包的每个隧道出口的报头。
The argument concerning redundant processing costs is valid regarding the integrity of a tunneled packet. In some architectures (e.g., PC-based routers), other mechanisms may also significantly reduce checksum processing costs. For example, there are implementations that have optimized checksum processing algorithms, including the use of checksum offloading. This processing is readily available for IPv4 packets at high line rates. Such processing may be anticipated for IPv6 endpoints, allowing receivers to reject corrupted packets without further processing. However, for certain classes of tunnel endpoints, this off-loading is not available and is unlikely to become available in the near future.
关于冗余处理成本的论点对于隧道数据包的完整性是有效的。在某些架构（例如，基于PC的路由器）中，其他机制也可以显著降低校验和处理成本。例如，有些实现具有优化的校验和处理算法，包括使用校验和卸载。这种处理在高线路速率下可用于IPv4数据包。IPv6端点可以预期这种处理，允许接收器拒绝损坏的数据包而无需进一步处理。但是，对于某些类型的隧道端点，该卸载不可用，并且在不久的将来不太可能可用。
The currently deployed hardware in many routers uses a fast-path processing that provides only the first n bytes of a packet to the forwarding engine, where typically n <= 128.
许多路由器中当前部署的硬件使用快速路径处理，该处理仅向转发引擎提供数据包的前n个字节，其中通常n≤128。
When this design is used to support a tunnel ingress and egress, it prevents fast processing of a transport checksum over an entire (large) packet. Hence, the currently defined IPv6 UDP checksum is poorly suited for use within a router that is unable to access the entire packet and does not provide checksum off-loading. Thus, enabling checksum calculation over the complete packet can impact router design, performance, energy consumption, and cost.
当此设计用于支持隧道入口和出口时，可防止在整个（大）数据包上快速处理传输校验和。因此，当前定义的IPv6 UDP校验和不适合在无法访问整个数据包且不提供校验和卸载的路由器内使用。因此，在整个数据包上启用校验和计算可能会影响路由器的设计、性能、能耗和成本。
Many paths in the Internet include one or more middleboxes of various types. Large classes of middleboxes will handle zero UDP checksum packets, but do not support UDP-Lite or the other investigated proposals. These middleboxes include load balancers (see Section 1.3.5) including equal-cost multipath (ECMP) routing, traffic classifiers, and other functions that reads some fields in the UDP headers but does not validate the UDP checksum.
Internet中的许多路径包括一个或多个不同类型的中间盒。大类的中间盒将处理零UDP校验和数据包，但不支持UDP Lite或其他已调查的方案。这些中间盒包括负载平衡器（见第1.3.5节），包括等成本多路径（ECMP）路由、流量分类器和其他读取UDP报头中某些字段但不验证UDP校验和的功能。
There are also middleboxes that either validate or modify the UDP checksum. The two most common classes are firewalls and NATs. In IPv4, UDP encapsulation may be desirable for NAT traversal, because UDP support is commonly provided. It is also necessary due to the almost ubiquitous deployment of IPv4 NATs. There has also been discussion of NAT for IPv6, although not for the same reason as in IPv4. If IPv6 NAT becomes a reality, it hopefully will not present the same protocol issues as for IPv4. If NAT is defined for IPv6, it should take into consideration the use of a zero UDP checksum.
还存在验证或修改UDP校验和的中间盒。两个最常见的类是防火墙和NAT。在IPv4中，UDP封装可能适合NAT遍历，因为通常提供UDP支持。这也是必要的，因为IPv4 NAT的部署几乎无处不在。也有人讨论了IPv6的NAT，尽管原因与IPv4不同。如果IPv6 NAT成为现实，希望它不会出现与IPv4相同的协议问题。如果为IPv6定义了NAT，则应考虑使用零UDP校验和。
The requirements for IPv6 firewall traversal are likely be to be similar to those for IPv4. In addition, it can be reasonably expected that a firewall conforming to RFC 2460 will not regard datagrams with a zero UDP checksum as valid. Use of a zero UDP checksum with IPv6 requires firewalls to be updated before the full utility of the change becomes available.
IPv6防火墙穿越的要求可能与IPv4类似。此外，可以合理预期，符合RFC 2460的防火墙不会将UDP校验和为零的数据报视为有效。在IPv6中使用零UDP校验和要求在更改的完整实用程序可用之前更新防火墙。
It can be expected that datagrams with zero UDP checksum will initially not have the same middlebox traversal characteristics as regular UDP (RFC 2460). However, when implementations follow the requirements specified in this document, we expect the traversal capabilities to improve over time. We also note that deployment of IPv6-capable middleboxes is still in its initial phases. Thus, it might be that the number of non-updated boxes quickly becomes a very small percentage of the deployed middleboxes.
可以预期，UDP校验和为零的数据报最初不会具有与常规UDP（RFC 2460）相同的中间盒遍历特性。但是，当实现遵循本文档中指定的要求时，我们希望遍历功能会随着时间的推移而改进。我们还注意到，支持IPv6的中间件的部署仍处于初始阶段。因此，可能是未更新的框的数量很快就成为部署的中间框的一个很小的百分比。
The UDP port number fields have been used as a basis to design load-balancing solutions for IPv4. This approach has also been leveraged for IPv6. An alternate method would be to utilize the IPv6 flow label [RFC6437] as a basis for entropy for load balancing. This would have the desirable effect of freeing IPv6 load-balancing devices from the need to assume semantics for the use of the transport port field, and also, it works for all types of transport protocols.
UDP端口号字段已被用作设计IPv4负载平衡解决方案的基础。IPv6也采用了这种方法。另一种方法是利用IPv6流标签[RFC6437]作为负载平衡熵的基础。这将产生理想的效果，使IPv6负载平衡设备不再需要为传输端口字段的使用假设语义，而且它也适用于所有类型的传输协议。
This use of the Flow Label for load balancing is consistent with the intended use, although further clarity was needed to ensure the field can be consistently used for this purpose. Therefore, an updated IPv6 flow label [RFC6437] and ECMP routing [RFC6438] usage were specified. Router vendors could be encouraged to start using the IPv6 Flow Label as a part of the flow hash, providing support for ECMP without requiring use of UDP.
流量标签用于负载平衡与预期用途一致，但需要进一步澄清，以确保该字段可用于此目的。因此，指定了更新的IPv6流标签[RFC6437]和ECMP路由[RFC6438]用法。可以鼓励路由器供应商开始使用IPv6流标签作为流哈希的一部分，在不需要使用UDP的情况下提供对ECMP的支持。
However, the method for populating the outer IPv6 header with a value for the flow label is not trivial. If the inner packet uses IPv6, the flow label value could be copied to the outer packet header.
但是，用流标签的值填充外部IPv6标头的方法并不简单。如果内部数据包使用IPv6，则流标签值可以复制到外部数据包头。
However, many current endpoints set the flow label to a zero value (thus, no entropy). The ingress of a tunnel seeking to provide good entropy in the flow label field would therefore need to create a random flow label value and keep corresponding state so that all packets that were associated with a flow would be consistently given the same flow label. Although possible, this complexity may not be desirable in a tunnel ingress.
但是，许多当前端点将流标签设置为零值（因此没有熵）。因此，寻求在流标签字段中提供良好熵的隧道入口需要创建随机流标签值并保持相应的状态，以便与流相关联的所有分组将一致地被赋予相同的流标签。尽管可能，但这种复杂性在隧道入口中可能并不理想。
The end-to-end use of flow labels for load balancing is a long-term solution. Even if the usage of the flow label has been clarified, there will be a transition time before a significant proportion of endpoints start to assign a good quality flow label to the flows that they originate. The use of load balancing using the transport header fields would continue until any widespread deployment is finally achieved.
端到端使用流标签进行负载平衡是一个长期的解决方案。即使已经澄清了流标签的使用，在相当大比例的端点开始为其发起的流分配高质量的流标签之前，也会有一段过渡时间。在最终实现任何广泛部署之前，将继续使用使用传输头字段的负载平衡。
The IETF has defined a set of transport protocols that may be applicable for tunnels with IPv6. There is also a set of network-layer encapsulation tunnels, such as IP-in-IP and Generic Routing Encapsulation (GRE). These solutions, which are already standardized, are discussed first, before discussing the issues, because they provide background for the description of the issues and allow some comparison with existing issues.
IETF定义了一组传输协议，这些协议可能适用于具有IPv6的隧道。还有一组网络层封装隧道，如IP中的IP和通用路由封装（GRE）。这些已经标准化的解决方案在讨论问题之前首先进行讨论，因为它们为问题的描述提供了背景，并允许与现有问题进行一些比较。
UDP [RFC0768] with standard checksum behavior, as defined in RFC 2460, has already been discussed. UDP usage guidelines are provided in [RFC5405].
已经讨论了RFC 2460中定义的具有标准校验和行为的UDP[RFC0768]。[RFC5405]中提供了UDP使用指南。
UDP-Lite [RFC3828] offers an alternate transport to UDP and is specified as a proposed standard, RFC 3828. A MIB is defined in [RFC5097], and unicast usage guidelines are defined in [RFC5405]. There has been at least one open-source implementation of UDP-Lite as a part of the Linux kernel since version 2.6.20.
UDP Lite[RFC3828]提供到UDP的替代传输，并指定为建议的标准RFC 3828。MIB在[RFC5097]中定义，单播使用指南在[RFC5405]中定义。自版本2.6.20以来，作为Linux内核的一部分，至少有一个UDP Lite的开源实现。
UDP-Lite provides a checksum with an option for partial coverage. When using this option, a datagram is divided into a sensitive part (covered by the checksum) and an insensitive part (not covered by the checksum). When the checksum covers the entire packet, UDP-Lite is fully equivalent with UDP, with the exception that it uses a different value in the Next Header field in the IPv6 header. Errors or corruption in the insensitive part will not cause the datagram to be discarded by the transport layer at the receiving endpoint. A
UDP Lite提供了一个校验和选项，用于部分覆盖。使用此选项时，数据报分为敏感部分（由校验和覆盖）和不敏感部分（不由校验和覆盖）。当校验和覆盖整个数据包时，UDP Lite与UDP完全等效，只是在IPv6报头的下一个报头字段中使用了不同的值。不敏感部分中的错误或损坏不会导致数据报被接收端点的传输层丢弃。A.
minor side effect of using UDP-Lite is that it was specified for damage-tolerant payloads, and some link layers may employ different link encapsulations when forwarding UDP-Lite segments (e.g., radio access bearers). Most link layers will cover the insensitive part with the same strong Layer 2 frame Cyclic Redundancy Check (CRC) that covers the sensitive part.
使用UDP Lite的次要副作用是，它被指定用于损伤容限有效载荷，并且在转发UDP Lite段（例如，无线接入承载）时，某些链路层可能采用不同的链路封装。大多数链路层将使用覆盖敏感部分的相同强第2层帧循环冗余校验（CRC）覆盖不敏感部分。
Tunnel encapsulations, such as Control And Provisioning of Wireless Access Points (CAPWAP) [RFC5415], can use UDP-Lite, because it provides a transport-layer checksum, including an IP pseudo-header checksum, in IPv6, without the need for a router/middlebox to traverse the entire packet payload. This provides most of the verification required for delivery and still keeps a low complexity for the checksumming operation. UDP-Lite may set the length of checksum coverage on a per-packet basis. This feature could be used if a tunnel protocol is designed to verify only delivery of the tunneled payload and uses a calculated checksum for control information.
隧道封装，例如无线接入点的控制和供应（CAPWAP）[RFC5415]，可以使用UDP Lite，因为它在IPv6中提供传输层校验和，包括IP伪报头校验和，而不需要路由器/中间盒来遍历整个数据包负载。这提供了交付所需的大部分验证，并且仍然保持了校验和操作的低复杂性。UDP Lite可以基于每个数据包设置校验和覆盖的长度。如果隧道协议设计为仅验证隧道有效载荷的传递，并使用计算出的校验和作为控制信息，则可以使用此功能。
Currently, support for middlebox traversal using UDP-Lite is poor, because UDP-Lite uses a different IPv6 network-layer Next Header value than that used for UDP; therefore, few middleboxes are able to interpret UDP-Lite and take appropriate actions when forwarding the packet. This makes UDP-Lite less suited to protocols needing general Internet support, until such time as UDP-Lite has achieved better support in middleboxes and endpoints.
目前，对使用UDP Lite进行中间盒遍历的支持较差，因为UDP Lite使用的IPv6网络层下一个标头值与UDP使用的值不同；因此，很少有中间盒能够解释UDP Lite并在转发数据包时采取适当的操作。这使得UDP Lite不太适合需要一般Internet支持的协议，直到UDP Lite在中间盒和端点中获得更好的支持。
The IETF has defined a set of tunneling protocols or network-layer encapsulations, e.g., IP-in-IP and GRE. These either do not include a checksum or use a checksum that is optional, because tunnel encapsulations are typically layered directly over the Internet layer (identified by the upper layer type in the IPv6 Next Header field) and because they are not used as endpoint transport protocols. There is little chance of confusing a tunnel-encapsulated packet with other application data. Such confusion could result in corruption of application state or data.
IETF定义了一组隧道协议或网络层封装，例如IP中的IP和GRE。它们要么不包括校验和，要么使用可选的校验和，因为隧道封装通常直接分层在Internet层上（由IPv6下一个标头字段中的上层类型标识），并且不用作端点传输协议。将隧道封装的数据包与其他应用程序数据混淆的可能性很小。这种混淆可能导致应用程序状态或数据损坏。
From an end-to-end perspective, the principal difference between an endpoint transport and a tunnel encapsulation is the value of the network-layer Next Header field. In the former, it identifies a transport protocol that supports endpoint applications. In the latter, it identifies a tunnel protocol egress. This separation of function reduces the probability that corruption of a tunneled packet could result in the packet being erroneously delivered to an
从端到端的角度来看，端点传输和隧道封装之间的主要区别是网络层下一个报头字段的值。在前者中，它标识支持端点应用程序的传输协议。在后者中，它标识隧道协议出口。这种功能分离降低了隧道数据包的损坏可能导致数据包被错误地传送到网络的概率
application. Specifically, packets are delivered only to protocol modules that process a specific Next Header value. The Next Header field therefore provides a first-level check of correct demultiplexing. In contrast, the UDP port space is shared by many diverse applications, and therefore, UDP demultiplexing relies solely on the port numbers.
应用具体而言，数据包仅传送到处理特定下一报头值的协议模块。因此，下一个报头字段提供正确解复用的第一级检查。相反，UDP端口空间由许多不同的应用程序共享，因此，UDP解复用仅依赖于端口号。
2.4. Relationship of Zero UDP Checksum to UDP-Lite and UDP with Checksum
2.4. 零UDP校验和与UDP Lite和UDP与校验和的关系
The operation of IPv6 with UDP with a zero checksum is not the same as IPv4 with UDP with a zero checksum. Protocol designers should not be fooled into thinking that the two are the same. The requirements below list a set of additional considerations for IPv6.
IPv6与UDP具有零校验和的操作不同于IPv4与UDP具有零校验和的操作。协议设计者不应该被愚弄到认为两者是相同的。下面的要求列出了IPv6的一组附加注意事项。
Where possible, existing general tunnel encapsulations, such as GRE and IP-in-IP, should be used. This section assumes that such existing tunnel encapsulations do not offer the functionally required to satisfy the protocol designer's goals. This section considers the standardized alternative solutions rather than the full set of ideas evaluated in Appendix A. The alternatives to UDP with a zero checksum are UDP with a (calculated) checksum and UDP-Lite.
在可能的情况下，应使用现有的通用隧道封装，如GRE和IP-in-IP。本节假设现有的隧道封装不提供满足协议设计者目标所需的功能。本节考虑的是标准化的替代解决方案，而不是附录A中评估的整套方案。校验和为零的UDP的替代方案是校验和为（计算）的UDP和UDP Lite。
UDP with a checksum has the advantage of close to universal support in both endpoints and middleboxes. It also provides statistical verification of delivery to the intended destination (address and port). However, some classes of device have limited support for calculation of a checksum that covers a full datagram. For these devices, this limited support can incur significant processing costs (e.g., requiring processing in the router's slow path) and hence can reduce capacity or fail to function.
具有校验和的UDP具有在端点和中间盒中接近通用支持的优势。它还提供向预期目的地（地址和端口）交付的统计验证。然而，某些类别的设备对覆盖完整数据报的校验和计算的支持有限。对于这些设备，这种有限的支持可能会产生巨大的处理成本（例如，需要在路由器的慢路径中进行处理），因此可能会降低容量或无法正常工作。
UDP-Lite has the advantage of using a checksum that can be calculated only over the pseudo-header and the UDP header. This provides a statistical verification of delivery to the intended destination (address and port). The checksum can be calculated without access to the datagram payload, requiring access only to the part that is to be protected. A drawback is that UDP-Lite currently has limited support in both endpoints (i.e., is not supported on all operating system platforms) and middleboxes (which must support the UDP-Lite header type). Therefore, using a path verification method is recommended.
UDP Lite的优点是使用只能在伪报头和UDP报头上计算的校验和。这提供了向预期目的地（地址和端口）交付的统计验证。可以在不访问数据报有效负载的情况下计算校验和，只需要访问要保护的部分。缺点是UDP Lite目前在端点（即并非所有操作系统平台都支持）和中间盒（必须支持UDP Lite头类型）中的支持有限。因此，建议使用路径验证方法。
IPv6 and UDP with a zero checksum can also be used by nodes that do not permit calculation of a payload checksum. Many existing classes of middleboxes do not verify or change the transport checksum. For these middleboxes, IPv6 with a zero UDP checksum is expected to function where UDP-Lite would not. However, support for the zero UDP checksum in middleboxes that do change or verify the checksum is
具有零校验和的IPv6和UDP也可由不允许计算有效负载校验和的节点使用。许多现有的中间盒类不会验证或更改传输校验和。对于这些中间盒，预期UDP校验和为零的IPv6将在UDP Lite无法运行的情况下运行。但是，在更改或验证校验和是否正确的中间盒中支持零UDP校验和
currently limited, and this may result in datagrams with a zero UDP checksum being discarded. Therefore, using a path verification method is recommended.
当前受限，这可能会导致丢弃UDP校验和为零的数据报。因此，建议使用路径验证方法。
For some sets of constraints, no solution exists. For example, a protocol designer who needs to originate or receive datagrams on a device that cannot efficiently calculate a checksum over a full datagram and also needs these packets to pass through a middlebox that verifies or changes a UDP checksum, but that does not support a zero UDP checksum, cannot use the zero UDP checksum method. Similarly, a protocol designer who needs to originate datagrams on a device with UDP-Lite support, but needs the packets to pass through a middlebox that does not support UDP-Lite, cannot use UDP-Lite. For such cases, there is no optimal solution. The current recommendation is to use or fall back to using UDP with full checksum coverage.
对于某些约束集，不存在解决方案。例如，如果协议设计者需要在无法有效计算完整数据报校验和的设备上发起或接收数据报，并且还需要这些数据包通过验证或更改UDP校验和但不支持零UDP校验和的中间盒，则不能使用零UDP校验和方法。类似地，需要在支持UDP-Lite的设备上发起数据报，但需要数据包通过不支持UDP-Lite的中间盒的协议设计器也不能使用UDP-Lite。对于这种情况，没有最佳解决方案。当前的建议是使用或退回到使用具有完全校验和覆盖率的UDP。
This informative section evaluates issues about the proposal to update IPv6 [RFC2460] to enable the UDP transport checksum to be set to zero. Some of the identified issues are common to other protocols already in use. This section also provides background to help in understanding the requirements and recommendations that follow.
本信息性章节评估有关更新IPv6[RFC2460]以使UDP传输校验和设置为零的建议的问题。已确定的一些问题对于已经在使用的其他协议来说是常见的。本节还提供了背景知识，以帮助理解接下来的要求和建议。
The decision in RFC 2460 to omit an integrity check at the network level meant that the IPv6 transport checksum was overloaded with many functions, including validating:
RFC 2460中省略网络级完整性检查的决定意味着IPv6传输校验和因许多功能而过载，包括验证：
o That the endpoint address was not corrupted within a router, i.e., a packet was intended to be received by this destination, and that the packet does not consist of a wrong header spliced to a different payload.
o 端点地址在路由器内未损坏，即，数据包打算由该目的地接收，并且数据包不包含拼接到不同有效负载的错误报头。
o That extension header processing is correctly delimited, i.e., the start of data has not been corrupted. In this case, reception of a valid Next Header value provides some protection.
o 扩展头处理被正确地分隔，即数据的开头没有被破坏。在这种情况下，接收有效的下一个报头值提供了一些保护。
o Reassembly processing, when used.
o 使用时，重新组装处理。
o The length of the payload.
o 有效载荷的长度。
o The port values, i.e., the correct application receives the payload. (Applications should also check the expected use of source ports/addresses.)
o 端口值，即正确的应用程序接收有效负载。（应用程序还应检查源端口/地址的预期使用情况。）
o The payload integrity.
o 有效载荷的完整性。
In IPv4, the first four of these checks are performed using the IPv4 header checksum.
在IPv4中，这些检查中的前四项使用IPv4报头校验和执行。
In IPv6, these checks occur within the endpoint stack using the UDP checksum information. An IPv6 node also relies on the header information to determine whether to send an ICMPv6 error message [RFC4443] and to determine the node to which this is sent. Corrupted information may lead to misdelivery to an unintended application socket on an unexpected host.
在IPv6中，这些检查使用UDP校验和信息在端点堆栈中进行。IPv6节点还依赖于报头信息来确定是否发送ICMPv6错误消息[RFC4443]，并确定发送到的节点。损坏的信息可能会导致错误传递到意外主机上的意外应用程序套接字。
IP packets may be corrupted as they traverse an Internet path. Older evidence presented in "When the CRC and TCP Checksum Disagree" [Sigcomm2000] shows that this was an issue with IPv4 routers in the year 2000 and that occasional corruption could result from bad internal router processing in routers or hosts. These errors are not detected by the strong frame checksums employed at the link layer [RFC3819]. During the development of this document in 2009, a number of individuals provided reports of observed rates for received UDP datagrams using IPv4 where the UDP checksum had been detected as corrupt. These rates were as high as 1.39E-4 for some paths, but close to zero for other paths.
IP数据包在穿越Internet路径时可能会损坏。“当CRC和TCP校验和不一致时”[Sigcomm2000]中提供的旧证据表明，这是2000年IPv4路由器的一个问题，路由器或主机中的内部路由器处理不良可能会导致偶尔的损坏。链路层采用的强帧校验和[RFC3819]无法检测到这些错误。在2009年编写本文档期间，许多人提供了使用IPv4接收UDP数据报的观察速率报告，其中UDP校验和被检测为损坏。对于某些路径，这些比率高达1.39E-4，但对于其他路径，这些比率接近于零。
There is extensive experience with deployments using tunnel protocols in well-managed networks (e.g., corporate networks and service provider core networks). This has shown the robustness of methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS that do not employ a transport protocol checksum and that have not specified mechanisms to protect from corruption of the unprotected headers (such as the VPN Identifier in MPLS). Reasons for the robustness may include:
在管理良好的网络（如公司网络和服务提供商核心网络）中使用隧道协议进行部署方面有着丰富的经验。这表明了伪线仿真边到边（PWE3）和MPLS等方法的健壮性，这些方法不采用传输协议校验和，也没有指定机制来防止未受保护的报头（如MPLS中的VPN标识符）损坏。健壮性的原因可能包括：
o A reduced probability of corruption on paths through well-managed networks.
o 通过管理良好的网络的路径上的损坏概率降低。
o IP forms the majority of the inner traffic carried by these tunnels. Hence, from a transport perspective, endpoint verification is already being performed when a received IPv4 packet is processed or by the transport pseudo-header for an IPv6 packet. This update to UDP does not change this behavior.
o IP构成了这些隧道承载的大部分内部流量。因此，从传输的角度来看，当接收到的IPv4数据包被处理时，或者由IPv6数据包的传输伪报头执行端点验证。此UDP更新不会更改此行为。
o In certain cases, a combination of additional filtering (e.g., filtering a MAC destination address in a Layer 2 tunnel) significantly reduces the probability of final misdelivery to the IP stack.
o 在某些情况下，附加过滤的组合（例如，过滤第2层隧道中的MAC目的地地址）显著降低了最终误发到IP堆栈的概率。
o The tunnel protocols did not use a UDP transport header. Therefore, any corruption is unlikely to result in misdelivery to another UDP-based application. This concern is specific to UDP with IPv6.
o 隧道协议未使用UDP传输头。因此，任何损坏都不太可能导致错误交付到另一个基于UDP的应用程序。此问题特定于使用IPv6的UDP。
While this experience can guide the present recommendations, any update to UDP must preserve operation in the general Internet, which is heterogeneous and can include links and systems of widely varying characteristics. Transport protocols used by hosts need to be designed with this in mind, especially when there is need to traverse edge networks, where middlebox deployments are common.
虽然这一经验可以指导目前的建议，但对UDP的任何更新都必须保留通用Internet中的操作，该Internet是异构的，可以包括具有广泛不同特性的链路和系统。主机使用的传输协议需要考虑到这一点，特别是当需要穿越边缘网络时，因为在边缘网络中，中间盒部署很常见。
Currently, for the general Internet, there is no evidence that corruption is rare, nor is there evidence that corruption in IPv6 is rare. Therefore, it seems prudent not to relax checks on misdelivery. The emergence of low-end IPv6 routers and the proposed use of NAT with IPv6 provide further motivation to protect from misdelivery.
目前，对于一般互联网而言，没有证据表明腐败很少，也没有证据表明IPv6中的腐败很少。因此，不放松对误发的检查似乎是谨慎的。低端IPv6路由器的出现以及提议将NAT与IPv6结合使用，为防止误发提供了进一步的动力。
Corruption in the network may result in:
网络中的损坏可能导致：
o A datagram being misdelivered to the wrong host/router or the wrong transport entity within an endpoint. Such a datagram needs to be discarded.
o 数据报被错误地传送到端点内错误的主机/路由器或错误的传输实体。这样的数据报需要丢弃。
o A datagram payload being corrupted, but still delivered to the intended host/router transport entity. Such a datagram needs to be either discarded or correctly processed by an application that provides its own integrity checks.
o 数据报有效负载已损坏，但仍传送到预期的主机/路由器传输实体。这样的数据报需要由提供自身完整性检查的应用程序丢弃或正确处理。
o A datagram payload being truncated by corruption of the length field. Such a datagram needs to be discarded.
o 由于长度字段损坏而截断的数据报有效负载。这样的数据报需要丢弃。
Using a checksum significantly reduces the impact of errors, reducing the probability of undetected corruption of state (and data) on both the host stack and the applications using the transport service.
使用校验和可显著减少错误的影响，降低主机堆栈和使用传输服务的应用程序上未检测到的状态（和数据）损坏的概率。
The following sections examine the effect of modifications to the destination and source IP address fields, the port fields, and the fragmentation information.
以下各节将检查修改目标和源IP地址字段、端口字段和碎片信息的效果。
An IPv6 endpoint destination address could be modified in the network; for example, it could be corrupted by an error. This is not a concern for IPv4, because the IP header checksum will result in this packet being discarded by the receiving IP stack. When using IPv6, however, such modification in the network cannot be detected at
可以在网络中修改IPv6端点目标地址；例如，它可能被错误损坏。这与IPv4无关，因为IP报头校验和将导致接收IP堆栈丢弃此数据包。但是，在使用IPv6时，在网络中无法检测到此类修改
the network layer. Detection of this corruption by a UDP receiver relies on the IPv6 pseudo-header that is incorporated in the transport checksum.
网络层。UDP接收器检测此损坏依赖于传输校验和中包含的IPv6伪报头。
There are two possible outcomes:
有两种可能的结果：
o Delivery to a destination address that is not in use. The packet will not be delivered, but an error report could be generated.
o 传递到未使用的目标地址。数据包将不会被传递，但可能会生成错误报告。
o Delivery to a different destination address. This modification will normally be detected by the transport checksum, resulting in a silent discard. Without a computed checksum, the packet would be passed to the endpoint port demultiplexing function. If an application is bound to the associated ports, the packet payload will be passed to the application. (See Section 3.1.4 on port processing.)
o 传递到不同的目标地址。这种修改通常会被传输校验和检测到，从而导致无声丢弃。如果没有计算出的校验和，数据包将被传递到端点端口解复用函数。如果应用程序绑定到相关端口，则数据包有效负载将传递给应用程序。（参见第3.1.4节关于端口处理。）
This section examines what happens when the source IP address is corrupted in transit. This is not a concern in IPv4, because the IP header checksum will normally result in this packet being discarded by the receiving IP stack. Detection of this corruption by a UDP receiver relies on the IPv6 pseudo-header that is incorporated in the transport checksum.
本节检查当源IP地址在传输过程中损坏时会发生什么情况。这在IPv4中不是一个问题，因为IP报头校验和通常会导致接收IP堆栈丢弃此数据包。UDP接收器检测此损坏依赖于传输校验和中包含的IPv6伪报头。
Corruption of an IPv6 source address does not result in the IP packet being delivered to a different endpoint protocol or destination address. If only the source address is corrupted, the datagram will likely be processed in the intended context, although with erroneous origin information. When using unicast reverse path forwarding [RFC2827], a change in address may result in the router discarding the packet when the route to the modified source address is different from that of the source address of the original packet.
IPv6源地址的损坏不会导致IP数据包被传送到不同的端点协议或目标地址。如果只有源地址被破坏，数据报可能会在预期的上下文中被处理，尽管源信息是错误的。当使用单播反向路径转发[RFC2827]时，当到修改的源地址的路由与原始分组的源地址的路由不同时，地址的改变可能导致路由器丢弃分组。
The result will depend on the application or protocol that processes the packet. Some examples are:
结果将取决于处理数据包的应用程序或协议。例如：
o An application that requires a pre-established context may disregard the datagram as invalid or could map it to another context (if a context for the modified source address were already activated).
o 需要预先建立的上下文的应用程序可能会忽略无效的数据报，或者可能会将其映射到另一个上下文（如果已激活修改的源地址的上下文）。
o A stateless application will process the datagram outside of any context. A simple example is the ECHO server, which will respond with a datagram directed to the modified source address. This would create unwanted additional processing load and generate traffic to the modified endpoint address.
o 无状态应用程序将在任何上下文之外处理数据报。一个简单的例子是ECHO服务器，它将用指向修改后的源地址的数据报进行响应。这将创建不需要的额外处理负载，并生成到修改的端点地址的通信量。
o Some datagram applications build state using the information from packet headers. A previously unused source address would result in receiver processing and the creation of unnecessary transport-layer state at the receiver. For example, Real-time Protocol (RTP) [RFC3550] sessions commonly employ a source-independent receiver port. State is created for each received flow. Therefore, reception of a datagram with a corrupted source address will result in the accumulation of unnecessary state in the RTP state machine, including collision detection and response (since the same synchronization source (SSRC) value will appear to arrive from multiple source IP addresses).
o 一些数据报应用程序使用来自数据包头的信息构建状态。以前未使用的源地址将导致接收器处理和在接收器处创建不必要的传输层状态。例如，实时协议（RTP）[RFC3550]会话通常采用源独立的接收器端口。为每个接收的流创建状态。因此，接收具有损坏源地址的数据报将导致RTP状态机中累积不必要的状态，包括冲突检测和响应（因为相同的同步源（SSRC）值似乎来自多个源IP地址）。
o ICMP messages relating to a corrupted packet can be misdirected to the wrong source node.
o 与损坏数据包相关的ICMP消息可能被错误地定向到错误的源节点。
In general, the effect of corrupting the source address will depend upon the protocol that processes the packet and its robustness to this error. For the case where the packet is received by a tunnel endpoint, the tunnel application is expected to correctly handle a corrupted source address.
通常，损坏源地址的效果将取决于处理数据包的协议及其对此错误的鲁棒性。对于由隧道端点接收数据包的情况，隧道应用程序将正确处理损坏的源地址。
The impact of source address modification is more difficult to quantify when the receiving application is not the one originally intended and several fields have been modified in transit.
当接收应用程序不是最初预期的应用程序，并且在传输过程中修改了多个字段时，源地址修改的影响更难量化。
This section describes what happens if one or both of the UDP port values are corrupted in transit. This can also happen when IPv4 is used with a zero UDP checksum, but not when UDP checksums are calculated or when UDP-Lite is used. If the ports carried in the transport header of an IPv6 packet are corrupted in transit, packets may be delivered to the wrong application process (on the intended machine), responses or errors may be sent to the wrong application process (on the intended machine), or both may occur.
本节描述了当一个或两个UDP端口值在传输过程中损坏时会发生什么情况。当IPv4与零UDP校验和一起使用时也会发生这种情况，但在计算UDP校验和或使用UDP Lite时则不会发生这种情况。如果IPv6数据包的传输报头中携带的端口在传输过程中损坏，则数据包可能被传送到错误的应用程序进程（在目标机器上），响应或错误可能被发送到错误的应用程序进程（在目标机器上），或者两者都可能发生。
If one combines the corruption effects, such as a corrupted destination address and corrupted ports, there are a number of potential outcomes when traffic arrives at an unexpected port. The following are the possibilities and their outcomes for a packet that does not use UDP checksum validation:
如果将损坏影响（如损坏的目标地址和损坏的端口）结合起来，则当流量到达意外端口时，会有许多潜在结果。以下是不使用UDP校验和验证的数据包的可能性及其结果：
o The packet could be delivered to a port that is not in use. The packet is discarded, but could generate an ICMPv6 message (e.g., port unreachable).
o 数据包可能被传送到未使用的端口。数据包被丢弃，但可能会生成ICMPv6消息（例如，端口不可访问）。
o The packet could be delivered to a different node that implements the same application, so the packet may be accepted, but side effects could occur or accumulated state could be generated.
o 数据包可以被传送到实现相同应用程序的不同节点，因此数据包可以被接受，但可能会发生副作用或产生累积状态。
o The packet could be delivered to an application that does not implement the tunnel protocol, so the packet may be incorrectly parsed and may be misinterpreted, causing side effects or generating accumulated state.
o 数据包可能被传送到未实现隧道协议的应用程序，因此数据包可能被错误地解析，并可能被误解，导致副作用或产生累积状态。
The probability of each outcome depends on the statistical probability that the address or the port information for the source or destination becomes corrupted in the datagram such that they match those of an existing flow or server port. Unfortunately, such a match may be more likely for UDP than for connection-oriented transports, because:
每个结果的概率取决于源或目标的地址或端口信息在数据报中损坏的统计概率，以便它们与现有流或服务器端口的地址或端口信息匹配。不幸的是，与面向连接的传输相比，UDP更可能出现这种匹配，因为：
1. There is no handshake prior to communication and no sequence numbers (as in TCP, Datagram Congestion Control Protocol (DCCP), and Stream Control Transmission Protocol (SCTP)). This makes it hard to verify that an application process is given only the application data associated with a specific transport session.
1. 通信前没有握手，也没有序列号（如TCP、数据报拥塞控制协议（DCCP）和流控制传输协议（SCTP））。这使得很难验证应用程序进程是否只提供了与特定传输会话关联的应用程序数据。
2. Applications writers often bind to wildcard values in endpoint identifiers and do not always validate the correctness of datagrams they receive. (Guidance on this topic is provided in [RFC5405].)
2. 应用程序编写器通常绑定到端点标识符中的通配符值，并且并不总是验证它们接收的数据报的正确性。（有关此主题的指导，请参见[RFC5405]。）
While these rules could, in principle, be revised to declare naive applications as "historic", this remedy is not realistic. The transport owes it to the stack to do its best to reject bogus datagrams.
虽然原则上可以修改这些规则，将幼稚的申请宣布为“历史性的”，但这种补救办法并不现实。传输需要堆栈尽最大努力拒绝虚假数据报。
If checksum coverage is suppressed, the application needs to provide a method to detect and discard the unwanted data. A tunnel protocol would need to perform its own integrity checks on any control information if it is transported in datagrams with a zero UDP checksum. If the tunnel payload is another IP packet, the packets requiring checksums can be assumed to have their own checksums, provided that the rate of corrupted packets is not significantly larger due to the tunnel encapsulation. If a tunnel transports other inner payloads that do not use IP, the assumptions of corruption detection for that particular protocol must be fulfilled. This may require an additional checksum/CRC and/or integrity protection of the payload and tunnel headers.
如果校验和覆盖被抑制，应用程序需要提供一种方法来检测和丢弃不需要的数据。如果控制信息以UDP校验和为零的数据报传输，则隧道协议需要对任何控制信息执行其自身的完整性检查。如果隧道有效载荷是另一个IP分组，则可以假设需要校验和的分组具有它们自己的校验和，前提是由于隧道封装，损坏分组的速率不会显著增大。如果隧道传输不使用IP的其他内部有效负载，则必须满足该特定协议的损坏检测假设。这可能需要对有效负载和隧道头进行额外的校验和/CRC和/或完整性保护。
A protocol that uses a zero UDP checksum cannot assume that it is the only protocol using a zero UDP checksum. Therefore, it needs to handle misdelivery gracefully. It must be robust when malformed
使用零UDP校验和的协议不能假定它是唯一使用零UDP校验和的协议。因此，它需要优雅地处理错误交付。当格式不正确时，它必须是健壮的
packets are received on a listening port, and it must expect that these packets may contain corrupted data or data associated with a completely different protocol.
数据包是在侦听端口上接收的，必须预料这些数据包可能包含损坏的数据或与完全不同的协议相关的数据。
The fragmentation information in IPv6 employs a 32-bit identity field (compared to only a 16-bit field in IPv4), a 13-bit fragment offset, and a 1-bit flag indicating whether there are more fragments. Corruption of any of these fields may result in one of two outcomes:
IPv6中的碎片信息使用32位标识字段（而IPv4中只有16位字段）、13位碎片偏移量和1位标志，指示是否有更多碎片。这些领域的任何腐败都可能导致以下两种结果之一：
o Reassembly failure: An error in the "More Fragments" field for the last fragment will, for example, result in the packet never being considered complete, so it will eventually be timed out and discarded. A corruption in the ID field will result in the fragment not being delivered to the intended context, thus leaving the rest of the packet incomplete, unless that packet has been duplicated before the corruption. The incomplete packet will eventually be timed out and discarded.
o 重新组装失败：例如，最后一个片段的“更多片段”字段中的错误将导致数据包永远不会被认为是完整的，因此它最终将超时并被丢弃。ID字段中的损坏将导致片段无法传递到预期的上下文，从而使数据包的其余部分不完整，除非该数据包在损坏之前已被复制。不完整的数据包最终将超时并丢弃。
o Erroneous reassembly: The reassembled packet did not match the original packet. This can occur when the ID field of a fragment is corrupted, resulting in a fragment becoming associated with another packet and taking the place of another fragment. Corruption in the offset information can cause the fragment to be misaligned in the reassembly buffer, resulting in incorrect reassembly. Corruption can cause the packet to become shorter or longer; however, completing the reassembly is much less probable, because this would require consistent corruption of the IPv6 header's payload length and offset fields. To prevent erroneous assembly, the reassembling stack must provide strong checks that detect overlap and missing data. Note, however, that this is not guaranteed and has been clarified in "Handling of Overlapping IPv6 Fragments" [RFC5722].
o 重新组装错误：重新组装的数据包与原始数据包不匹配。当片段的ID字段损坏时，可能会发生这种情况，导致片段与另一个数据包关联并取代另一个片段。偏移量信息中的损坏可能会导致碎片在重新组装缓冲区中未对齐，从而导致错误的重新组装。损坏可能导致数据包变短或变长；但是，完成重新组装的可能性要小得多，因为这将需要对IPv6报头的有效负载长度和偏移量字段进行一致的损坏。为防止错误组装，重新组装堆栈必须提供强有力的检查，以检测重叠和丢失的数据。但是，请注意，这并不能保证，并且已在“重叠IPv6片段的处理”[RFC5722]中阐明。
The erroneous reassembly of packets is a general concern, and such packets should be discarded instead of being passed to higher-layer processes. The primary detector of packet length changes is the IP payload length field, with a secondary check provided by the transport checksum. The Upper-Layer Packet length field included in the pseudo-header assists in verifying correct reassembly, because the Internet checksum has a low probability of detecting insertion of data or overlap errors (due to misplacement of data). The checksum is also incapable of detecting insertion or removal of data that is all-zero in a chunk that is a multiple of 16 bits.
数据包的错误重组是一个普遍关注的问题，应该丢弃这些数据包，而不是将其传递给更高层的进程。包长度变化的主要检测器是IP有效负载长度字段，由传输校验和提供二次检查。伪报头中包含的上层数据包长度字段有助于验证正确的重新组装，因为互联网校验和检测数据插入或重叠错误（由于数据错位）的概率很低。校验和也无法检测16位的倍数块中全为零的数据的插入或删除。
The most significant risk of corruption results following mis-association of a fragment with a different packet. This risk can be significant, because the size of fragments is often the same (e.g., fragments that form when the path MTU results in fragmentation of a larger packet, which is common when addition of a tunnel encapsulation header increases the size of a packet). Detection of this type of error requires a checksum or other integrity check of the headers and the payload. While such protection is desirable for tunnel encapsulations using IPv4, because the small fragmentation ID can easily result in wraparound [RFC4963], this is especially desirable for tunnels that perform flow aggregation [TUNNELS].
碎片与不同数据包的错误关联会导致最严重的损坏风险。这种风险可能很大，因为片段的大小通常是相同的（例如，当路径MTU导致较大分组的碎片时形成的片段，这在添加隧道封装报头增加分组的大小时是常见的）。检测此类错误需要对报头和有效负载进行校验和或其他完整性检查。虽然这种保护对于使用IPv4的隧道封装是可取的，因为较小的碎片ID很容易导致环绕[RFC4963]，这对于执行流聚合[tunnels]的隧道尤其可取。
Tunnel fragmentation behavior matters. There can be outer or inner fragmentation tunnels in the Internet Architecture [TUNNELS]. If there is inner fragmentation by the tunnel, the outer headers will never be fragmented, and thus, a zero UDP checksum in the outer header will not affect the reassembly process. When a tunnel performs outer header fragmentation, the tunnel egress needs to perform reassembly of the outer fragments into an inner packet. The inner packet is either a complete packet or a fragment. If it is a fragment, the destination endpoint of the fragment will perform reassembly of the received fragments. The complete packet or the reassembled fragments will then be processed according to the packet Next Header field. The receiver may detect reassembly anomalies only when it uses a protocol with a checksum. The larger the number of reassembly processes to which a packet has been subjected, the greater the probability of an error. The following list describes some tunnel fragmentation behaviors:
隧道破碎行为很重要。互联网架构中可以有外部或内部碎片通道[通道]。如果隧道中存在内部碎片，则外部标头永远不会被碎片化，因此，外部标头中的零UDP校验和不会影响重新组装过程。当隧道执行外部报头分段时，隧道出口需要将外部片段重新组装到内部分组中。内部数据包要么是完整的数据包，要么是片段。如果它是一个片段，那么片段的目标端点将重新组装接收到的片段。然后，将根据packetnext报头字段处理完整的数据包或重新组装的片段。只有在使用带有校验和的协议时，接收器才可能检测到重组异常。数据包经过的重新组装过程的数量越多，出错的概率就越大。以下列表描述了一些隧道碎片行为：
o An IP-in-IP tunnel that performs inner fragmentation has similar properties to a UDP tunnel with a zero UDP checksum that also performs inner fragmentation.
o 执行内部分段的IP-in-IP隧道具有与UDP隧道相似的属性，UDP隧道具有零UDP校验和，该校验和也执行内部分段。
o An IP-in-IP tunnel that performs outer fragmentation has similar properties to a UDP tunnel with a zero UDP checksum that performs outer fragmentation.
o 执行外部分段的IP-in-IP隧道与执行外部分段的UDP校验和为零的UDP隧道具有类似的属性。
o A tunnel that performs outer fragmentation can result in a higher level of corruption due to both inner and outer fragmentation, enabling more chances for reassembly errors to occur.
o 执行外部碎片化的通道可能会由于内部和外部碎片化而导致更高级别的损坏，从而使重新组装错误发生的机会更多。
o Recursive tunneling can result in fragmentation at more than one header level, even for fragmentation of the encapsulated packet, unless the fragmentation is performed on the innermost IP header.
o 递归隧道可能导致多个报头级别的碎片，即使对于封装的数据包的碎片，除非碎片是在最内层的IP报头上执行的。
o Unless there is verification at each reassembly, the probability of undetected errors will increase with the number of times fragmentation is recursively applied, making both IP-in-IP and UDP with zero UDP checksum vulnerable to undetected errors.
o 除非在每次重新组装时进行验证，否则未检测到错误的概率将随着递归应用碎片的次数而增加，使得IP-in-IP和UDP校验和为零的UDP都容易发生未检测到的错误。
In conclusion, fragmentation of datagrams with a zero UDP checksum does not worsen the performance compared to some other commonly used tunnel encapsulations. However, caution is needed for recursive tunneling that offers no additional verification at the different tunnel layers.
总之，与其他一些常用的隧道封装相比，UDP校验和为零的数据报碎片不会降低性能。但是，递归隧道在不同的隧道层上不提供额外的验证，因此需要谨慎。
Corruption of IP packets can occur at any point along a network path: during packet generation, during transmission over the link, in the process of routing and switching, etc. Some transmission steps include a checksum or CRC that reduces the probability for corrupted packets being forwarded, but there still exists a probability that errors may propagate undetected.
IP数据包的损坏可能发生在网络路径上的任何一点：数据包生成期间、链路传输期间、路由和交换过程中等。一些传输步骤包括校验和或CRC，以降低损坏数据包被转发的概率，但是仍然存在错误传播而不被发现的可能性。
Unfortunately, the Internet community lacks reliable information to identify the most common functions or equipment that results in packet corruption. However, there are indications that the place where corruption occurs can vary significantly from one path to another. However, there is a risk in taking evidence from one usage domain and using it to infer characteristics for another. Methods intended for general Internet usage must therefore assume that corruption can occur, and mechanisms must be deployed to mitigate the effects of corruption and any resulting misdelivery.
不幸的是，互联网社区缺乏可靠的信息来识别导致数据包损坏的最常见功能或设备。然而，有迹象表明，腐败发生的地点可能因路径不同而有很大差异。然而，从一个使用领域获取证据并用其推断另一个使用领域的特征是有风险的。因此，用于一般互联网使用的方法必须假设可能发生损坏，并且必须部署机制来减轻损坏的影响以及由此产生的任何错误交付。
IP transports designed for use in the general Internet should not assume specific path characteristics. Network protocols may reroute packets, thus changing the set of routers and middleboxes along a path. Therefore, transports such as TCP, SCTP, and DCCP have been designed to negotiate protocol parameters, adapt to different network path characteristics, and receive feedback to verify that the current path is suited to the intended application. Applications using UDP and UDP-Lite need to provide their own mechanisms to confirm the validity of the current network path.
设计用于通用Internet的IP传输不应具有特定的路径特征。网络协议可能会重新路由数据包，从而改变路径上的路由器和中间盒集。因此，TCP、SCTP和DCCP等传输被设计为协商协议参数，适应不同的网络路径特征，并接收反馈以验证当前路径是否适合预期应用。使用UDP和UDP Lite的应用程序需要提供自己的机制来确认当前网络路径的有效性。
A zero value in the UDP checksum field is explicitly disallowed in RFC 2460. Thus, it may be expected that any device on the path that has a reason to look beyond the IP header, for example, to validate the UDP checksum, will consider such a packet as erroneous or illegal and may discard it, unless the device is updated to support the new behavior. Any middlebox that modifies the UDP checksum, for example,
RFC 2460中明确禁止UDP校验和字段中的零值。因此，可以预期，路径上的任何设备都有理由看超出IP报头，例如验证UDP校验和，将认为这样的分组是错误的或非法的，并且可能丢弃它，除非该设备被更新以支持新的行为。任何修改UDP校验和的中间盒，例如，
a NAT that changes the values of the IP and UDP header in such a way that the checksum over the pseudo-header changes value, will need to be updated to support this behavior. Until then, a zero UDP checksum packet is likely to be discarded, either directly in the middlebox or at the destination, when a zero UDP checksum has been modified to be non-zero by an incremental update.
如果NAT更改IP和UDP报头的值，从而使伪报头上的校验和更改值，则需要更新该NAT以支持此行为。在此之前，当通过增量更新将零UDP校验和修改为非零时，零UDP校验和数据包可能会被丢弃，无论是直接在中间盒中还是在目的地。
A pair of endpoints intending to use the new behavior will therefore need not only to ensure support at each endpoint, but also to ensure that the path between them will deliver packets with the new behavior. This may require using negotiation or an explicit mandate to use the new behavior by all nodes that support the new protocol.
因此，一对打算使用新行为的端点不仅需要确保每个端点的支持，还需要确保它们之间的路径将传递具有新行为的数据包。这可能需要所有支持新协议的节点使用协商或明确授权来使用新行为。
Enabling the use of a zero checksum places new requirements on equipment deployed within the network, such as middleboxes. A middlebox (e.g., a firewall or NAT) may enable zero checksum usage for a particular range of ports. Note that checksum off-loading and operating system design may result in all IPv6 UDP traffic being sent with a calculated checksum. This requires middleboxes that are configured to enable a zero UDP checksum to continue to work with bidirectional UDP flows that use a zero UDP checksum in only one direction, and therefore, they must not maintain separate state for a UDP flow based on its checksum usage.
启用零校验和对网络中部署的设备（如中间盒）提出了新的要求。中间盒（例如，防火墙或NAT）可以为特定范围的端口启用零校验和使用。请注意，校验和卸载和操作系统设计可能会导致所有IPv6 UDP通信都使用计算出的校验和发送。这需要配置为启用零UDP校验和的中间盒继续与仅在一个方向上使用零UDP校验和的双向UDP流一起工作，因此，它们不能根据校验和的使用情况为UDP流保持单独的状态。
Support along the path between endpoints can be guaranteed in limited deployments by appropriate configuration. In general, it can be expected to take time for deployment of any updated behavior to become ubiquitous.
通过适当的配置，可以保证在有限的部署中沿端点之间的路径提供支持。一般来说，任何更新行为的部署都需要时间才能变得无处不在。
A sender will need to probe the path to verify the expected behavior. Path characteristics may change, and usage therefore should be robust and able to detect a failure of the path under normal usage, and should be able to renegotiate. Note that a bidirectional path does not necessarily support the same checksum usage in both the forward and return directions. Receipt of a datagram with a zero UDP checksum does not imply that the remote endpoint can also receive a datagram with a zero UDP checksum. This behavior will require periodic validation of the path, adding complexity to any solution using the new behavior.
发送方需要探测路径以验证预期行为。路径特征可能会发生变化，因此使用应该是健壮的，能够在正常使用情况下检测到路径故障，并且应该能够重新协商。注意，双向路径不一定在正向和返回方向上都支持相同的校验和用法。接收UDP校验和为零的数据报并不意味着远程端点也可以接收UDP校验和为零的数据报。此行为将需要定期验证路径，从而增加使用新行为的任何解决方案的复杂性。
The update to the IPv6 specification defined in [RFC6935] modifies only IPv6 nodes that implement specific protocols designed to permit omission of a UDP checksum. This document provides an applicability statement for the updated method, indicating when the mechanism can (and cannot) be used. Enabling a zero UDP checksum, and ensuring
[RFC6935]中定义的IPv6规范更新仅修改实现特定协议的IPv6节点，这些协议旨在允许省略UDP校验和。本文档提供了更新方法的适用性声明，指出何时可以（何时不能）使用该机制。启用零UDP校验和，并确保
correct interactions with the stack, implies much more than simply disabling the checksum algorithm for specific packets at the transport interface.
与堆栈的正确交互，意味着不仅仅是在传输接口上禁用特定数据包的校验和算法。
When the zero UDP checksum method is widely available, we expect that it will be used by applications that perceive to gain benefit from it. Any solution that uses an end-to-end transport protocol rather than an IP-in-IP encapsulation needs to minimize the possibility that application processes could confuse a corrupted or wrongly delivered UDP datagram with that of data addressed to the application running on their endpoint.
当零UDP校验和方法被广泛使用时，我们期望它将被认为从中获益的应用程序使用。任何使用端到端传输协议而不是IP-in-IP封装的解决方案都需要最大限度地减少应用程序进程将损坏或错误传递的UDP数据报与发送到其端点上运行的应用程序的数据报混淆的可能性。
A protocol or application that uses the zero UDP checksum method must ensure that the lack of checksum does not affect the protocol operation. This includes being robust to receiving an unintended packet from another protocol or context following corruption of a destination or source address and/or port value. It also includes considering the need for additional implicit protection mechanisms required when using the payload of a UDP packet received with a zero checksum.
使用零UDP校验和方法的协议或应用程序必须确保缺少校验和不会影响协议操作。这包括在目的地或源地址和/或端口值损坏后从另一协议或上下文接收非预期数据包。它还包括考虑在使用通过零校验和接收的UDP数据包的有效负载时需要额外的隐式保护机制。
It is important to consider the potential impact of using a zero UDP checksum on endpoint devices and applications that are not modified to support the new behavior or, by default or preference, do not use the regular behavior. These applications must not be significantly impacted by the update.
重要的是考虑使用零UDP校验和对端点设备和应用的潜在影响，这些端点设备和应用程序未被修改以支持新的行为，或者默认情况下或偏好不使用常规行为。这些应用程序不得受到更新的显著影响。
To illustrate why this necessary, consider the implications of a node that enables use of a zero UDP checksum at the interface level. This would result in all applications that listen to a UDP socket receiving datagrams where the checksum was not verified. This could have a significant impact on an application that was not designed with the additional robustness needed to handle received packets with corruption, creating state or destroying existing state in the application.
为了说明为什么需要这样做，考虑一个节点的影响，该节点能够在接口级别使用零UDP校验和。这将导致所有侦听UDP套接字的应用程序在未验证校验和的情况下接收数据报。这可能会对应用程序产生重大影响，因为该应用程序在设计时没有额外的健壮性，无法处理接收到的数据包，从而导致应用程序中的损坏、创建状态或破坏现有状态。
Therefore, a zero UDP checksum needs to be enabled only for individual ports using an explicit request by the application. In this case, applications using other ports would maintain the current IPv6 behavior, discarding incoming datagrams with a zero UDP checksum. These other applications would not be affected by this changed behavior. An application that allows the changed behavior should be aware of the risk of corruption and the increased level of misdirected traffic, and can be designed robustly to handle this risk.
因此，仅需要使用应用程序的显式请求为单个端口启用零UDP校验和。在这种情况下，使用其他端口的应用程序将保持当前的IPv6行为，丢弃UDP校验和为零的传入数据报。这些其他应用程序不会受到此更改行为的影响。允许更改行为的应用程序应该意识到损坏的风险和错误定向流量的增加，并且可以设计为稳健地处理此风险。
This section is an applicability statement that defines requirements and recommendations for the implementation of IPv6 nodes that support the use of a zero value in the checksum field of a UDP datagram.
本节是适用性声明，定义了支持在UDP数据报校验和字段中使用零值的IPv6节点的实施要求和建议。
All implementations that support the zero UDP checksum method MUST conform to the requirements defined below:
所有支持零UDP校验和方法的实现必须符合以下定义的要求：
1. An IPv6 sending node MAY use a calculated RFC 2460 checksum for all datagrams that it sends. This explicitly permits an interface that supports checksum off-loading to insert an updated UDP checksum value in all UDP datagrams that it forwards. Note, however, that sending a calculated checksum requires the receiver to also perform the checksum calculation. Checksum off-loading can normally be switched off for a particular interface to ensure that datagrams are sent with a zero UDP checksum.
1. IPv6发送节点可以对其发送的所有数据报使用计算出的RFC 2460校验和。这明确允许支持校验和卸载的接口在其转发的所有UDP数据报中插入更新的UDP校验和值。但是，请注意，发送计算出的校验和需要接收方也执行校验和计算。对于特定接口，通常可以关闭校验和卸载，以确保使用零UDP校验和发送数据报。
2. IPv6 nodes SHOULD, by default, NOT allow the zero UDP checksum method for transmission.
2. 默认情况下，IPv6节点不允许使用零UDP校验和方法进行传输。
3. IPv6 nodes MUST provide a way for the application/protocol to indicate the set of ports that will be enabled to send datagrams with a zero UDP checksum. This may be implemented by enabling a transport mode using a socket API call when the socket is established, or by a similar mechanism. It may also be implemented by enabling the method for a pre-assigned static port used by a specific tunnel protocol.
3. IPv6节点必须为应用程序/协议提供一种方式，以指示将启用的端口集，以发送UDP校验和为零的数据报。这可以通过在套接字建立时使用套接字API调用启用传输模式来实现，或者通过类似的机制来实现。它还可以通过启用特定隧道协议使用的预分配静态端口的方法来实现。
4. IPv6 nodes MUST provide a method to allow an application/ protocol to indicate that a particular UDP datagram is required to be sent with a UDP checksum. This needs to be allowed by the operating system at any time (e.g., to send keepalive datagrams), not just when a socket is established in zero checksum mode.
4. IPv6节点必须提供一种方法，允许应用程序/协议指示需要使用UDP校验和发送特定UDP数据报。这需要操作系统在任何时候允许（例如，发送keepalive数据报），而不仅仅是在零校验和模式下建立套接字时。
5. The default IPv6 node receiver behavior MUST be to discard all IPv6 packets carrying datagrams with a zero UDP checksum.
5. 默认IPv6节点接收器行为必须是丢弃所有携带UDP校验和为零的数据报的IPv6数据包。
6. IPv6 nodes MUST provide a way for the application/protocol to indicate the set of ports that will be enabled to receive datagrams with a zero UDP checksum. This may be implemented via a socket API call or by a similar mechanism. It may also be implemented by enabling the method for a pre-assigned static port used by a specific tunnel protocol.
6. IPv6节点必须为应用程序/协议提供一种方式，以指示将允许接收UDP校验和为零的数据报的端口集。这可以通过套接字API调用或类似机制实现。它还可以通过启用特定隧道协议使用的预分配静态端口的方法来实现。
7. IPv6 nodes supporting usage of zero UDP checksums MUST also allow reception using a calculated UDP checksum on all ports configured to allow zero UDP checksum usage. (The sending endpoint, e.g., the encapsulating ingress, may choose to compute the UDP checksum or may calculate it by default.) The receiving endpoint MUST use the reception method specified in RFC2460 when the checksum field is not zero.
7. 支持零UDP校验和使用的IPv6节点还必须允许在所有配置为允许零UDP校验和使用的端口上使用计算出的UDP校验和进行接收。（发送端点，例如封装入口，可以选择计算UDP校验和，或者默认情况下可以计算它。）当校验和字段不为零时，接收端点必须使用RFC2460中指定的接收方法。
8. RFC 2460 specifies that IPv6 nodes SHOULD log received datagrams with a zero UDP checksum. This remains the case for any datagram received on a port that does not explicitly enable processing of a zero UDP checksum. A port for which the zero UDP checksum has been enabled MUST NOT log the datagram solely because the checksum value is zero.
8. RFC2460指定IPv6节点应使用零UDP校验和记录收到的数据报。对于在未显式启用零UDP校验和处理的端口上接收的任何数据报，情况仍然如此。已启用零UDP校验和的端口不能仅因为校验和值为零而记录数据报。
9. IPv6 nodes MAY separately identify received UDP datagrams that are discarded with a zero UDP checksum. They SHOULD NOT add these to the standard log, because the endpoint has not been verified. This may be used to support other functions (such as a security policy).
9. IPv6节点可以单独标识接收到的UDP数据报，这些数据报使用零UDP校验和丢弃。他们不应该将这些添加到标准日志中，因为端点尚未验证。这可用于支持其他功能（如安全策略）。
10. IPv6 nodes that receive ICMPv6 messages that refer to packets with a zero UDP checksum MUST provide appropriate checks concerning the consistency of the reported packet to verify that the reported packet actually originated from the node, before acting upon the information (e.g., validating the address and port numbers in the ICMPv6 message body).
10. 接收引用UDP校验和为零的数据包的ICMPv6消息的IPv6节点必须提供有关所报告数据包一致性的适当检查，以验证所报告数据包实际上来自该节点，然后再根据信息采取行动（例如，验证ICMPv6消息体中的地址和端口号）。
This section is an applicability statement that identifies requirements and recommendations for protocols and tunnel encapsulations that are transported over an IPv6 transport flow (e.g., a tunnel) that does not perform a UDP checksum calculation to verify the integrity at the transport endpoints. Before deciding to use the zero UDP checksum and lose the integrity verification provided by non-zero checksumming, a protocol developer should seriously consider if they can use checksummed UDP packets or UDP-Lite [RFC3828], because IPv6 with a zero UDP checksum is not equivalent in behavior to IPv4 with zero UDP checksum.
本节是一个适用性声明，用于确定通过IPv6传输流（例如，隧道）传输的协议和隧道封装的要求和建议，该传输流不执行UDP校验和计算以验证传输端点的完整性。在决定使用零UDP校验和而失去由非零校验求提供的完整性验证之前，协议开发者应该认真考虑它们是否可以使用校验求UDP分组或UDP Lite [RCF38 28 ]，因为具有零UDP校验和的IPv6在行为上不等同于具有零UDP校验和的IPv4。
The requirements and recommendations for protocols and tunnel encapsulations using an IPv6 transport flow that does not perform a UDP checksum calculation to verify the integrity at the transport endpoints are:
使用不执行UDP校验和计算以验证传输端点完整性的IPv6传输流的协议和隧道封装的要求和建议如下：
1. Transported protocols that enable the use of zero UDP checksum MUST enable this only for a specific port or port range. This needs to be enabled at the sending and receiving endpoints for a UDP flow.
1. 允许使用零UDP校验和的传输协议必须仅对特定端口或端口范围启用此功能。这需要在UDP流的发送和接收端点启用。
2. An integrity mechanism is always RECOMMENDED at the transported protocol layer to ensure that corruption rates of the delivered payload are not increased (e.g., at the innermost packet of a UDP tunnel). A mechanism that isolates the causes of corruption (e.g., identifying misdelivery, IPv6 header corruption, or tunnel header corruption) is also expected to provide additional information about the status of the tunnel (e.g., to suggest a security attack).
2. 始终建议在传输协议层使用完整性机制，以确保交付的有效负载的损坏率不会增加（例如，在UDP隧道的最内层数据包处）。隔离损坏原因（例如，识别误发、IPv6标头损坏或隧道标头损坏）的机制也有望提供有关隧道状态的附加信息（例如，建议进行安全攻击）。
3. A transported protocol that encapsulates Internet Protocol (IPv4 or IPv6) packets MAY rely on the inner packet integrity checks, provided that the tunnel protocol will not significantly increase the rate of corruption of the inner IP packet. If a significantly increased corruption rate can occur, the tunnel protocol MUST provide an additional integrity verification mechanism. Early detection is desirable to avoid wasting unnecessary computation, transmission capacity, or storage for packets that will subsequently be discarded.
3. 封装Internet协议（IPv4或IPv6）数据包的传输协议可能依赖于内部数据包完整性检查，前提是隧道协议不会显著增加内部IP数据包的损坏率。如果损坏率可能显著增加，则隧道协议必须提供额外的完整性验证机制。早期检测有助于避免浪费不必要的计算、传输容量或存储空间，从而避免随后丢弃的数据包。
4. A transported protocol that supports the use of a zero UDP checksum MUST be designed so that corruption of any header information does not result in accumulation of incorrect state for the protocol.
4. 必须设计支持使用零UDP校验和的传输协议，以确保任何标头信息的损坏不会导致协议的错误状态累积。
5. A transported protocol with a non-tunnel payload or one that encapsulates non-IP packets MUST have a CRC or other mechanism for checking packet integrity, unless the non-IP packet is specifically designed for transmission over a lower layer that does not provide a packet integrity guarantee.
5. 具有非隧道有效载荷或封装非IP数据包的传输协议必须具有用于检查数据包完整性的CRC或其他机制，除非非IP数据包专门设计用于在不提供数据包完整性保证的较低层上传输。
6. A transported protocol with control feedback SHOULD be robust to changes in the network path, because the set of middleboxes on a path may vary during the life of an association. The UDP endpoints need to discover paths with middleboxes that drop packets with a zero UDP checksum. Therefore, transported protocols SHOULD send keepalive messages with a zero UDP checksum. An endpoint that discovers an appreciable loss rate for keepalive packets MAY terminate the UDP flow (e.g., a tunnel). Section 3.1.3 of RFC 5405 describes requirements for congestion control when using a UDP-based transport.
6. 具有控制反馈的传输协议应该对网络路径中的变化具有鲁棒性，因为在关联的生命周期中，路径上的中间盒集可能会发生变化。UDP端点需要发现具有中间盒的路径，这些中间盒丢弃UDP校验和为零的数据包。因此，传输的协议应该发送UDP校验和为零的keepalive消息。发现保留数据包的明显丢失率的端点可以终止UDP流（例如，隧道）。RFC 5405第3.1.3节描述了使用基于UDP的传输时的拥塞控制要求。
7. A protocol with control feedback that can fall back to using UDP with a calculated RFC 2460 checksum is expected to be more robust to changes in the network path. Therefore, keepalive messages SHOULD include both UDP datagrams with a checksum and datagrams with a zero UDP checksum. This will enable the remote endpoint to distinguish between a path failure and the dropping of datagrams with a zero UDP checksum.
7. 具有控制反馈的协议可以退回到使用UDP和计算出的RFC 2460校验和，预计该协议对网络路径的更改更为健壮。因此，keepalive消息应该同时包含校验和为零的UDP数据报和校验和为零的UDP数据报。这将使远程端点能够区分路径故障和UDP校验和为零的数据报丢弃。
8. A middlebox implementation MUST allow forwarding of an IPv6 UDP datagram with both a zero and a standard UDP checksum using the same UDP port.
8. 中间盒实现必须允许使用同一UDP端口转发具有零和标准UDP校验和的IPv6 UDP数据报。
9. A middlebox MAY configure a restricted set of specific port ranges that forward UDP datagrams with a zero UDP checksum. The middlebox MAY drop IPv6 datagrams with a zero UDP checksum that are outside a configured range.
9. 中间盒可以配置一组受限的特定端口范围，这些端口范围转发UDP校验和为零的UDP数据报。中间盒可能丢弃配置范围之外的UDP校验和为零的IPv6数据报。
10. When a middlebox forwards an IPv6 UDP flow containing datagrams with both a zero and a standard UDP checksum, the middlebox MUST NOT maintain separate state for flows, depending on the value of their UDP checksum field. (This requirement is necessary to enable a sender that always calculates a checksum to communicate via a middlebox with a remote endpoint that uses a zero UDP checksum.)
10. 当中间盒转发包含同时具有零和标准UDP校验和的数据报的IPv6 UDP流时，根据其UDP校验和字段的值，中间盒不得为流保持单独的状态。（为了使始终计算校验和的发送方能够通过中间盒与使用零UDP校验和的远程端点通信，此要求是必需的。）
Special considerations are required when designing a UDP tunnel protocol where the tunnel ingress or egress may be a router that may not have access to the packet payload. When the node is acting as a host (i.e., sending or receiving a packet addressed to itself), the checksum processing is similar to other hosts. However, when the node (e.g., a router) is acting as a tunnel ingress or egress that forwards a packet to or from a UDP tunnel, there may be restricted access to the packet payload. This prevents calculating (or verifying) a UDP checksum. In this case, the tunnel protocol may use a zero UDP checksum and must:
在设计UDP隧道协议时，需要特别考虑，其中隧道入口或出口可能是无法访问数据包有效负载的路由器。当节点充当主机（即，发送或接收发往自身的数据包）时，校验和处理与其他主机类似。然而，当节点（例如，路由器）充当将分组转发到UDP隧道或从UDP隧道转发分组的隧道入口或出口时，对分组有效载荷的访问可能受到限制。这会阻止计算（或验证）UDP校验和。在这种情况下，隧道协议可能使用零UDP校验和，并且必须：
o Ensure that tunnel ingress and tunnel egress router are both configured to use a zero UDP checksum. For example, this may include ensuring that hardware checksum off-loading is disabled.
o 确保隧道入口和隧道出口路由器都配置为使用零UDP校验和。例如，这可能包括确保禁用硬件校验和卸载。
o The tunnel operator must ensure that middleboxes on the network path are updated to support use of a zero UDP checksum.
o 隧道运营商必须确保更新网络路径上的中间盒，以支持使用零UDP校验和。
o A tunnel egress should implement appropriate security techniques to protect from overload, including source address filtering to prevent traffic injection by an attacker and rate-limiting of any packets that incur additional processing, such as UDP datagrams used for control functions that require verification of a
o 隧道出口应实施适当的安全技术以防止过载，包括源地址过滤以防止攻击者注入流量，以及对任何引起额外处理的数据包进行速率限制，如用于控制功能的UDP数据报，这些控制功能需要验证数据包
calculated checksum to verify the network path. Usage of common control traffic for multiple tunnels between a pair of nodes can assist in reducing the number of packets to be processed.
计算校验和以验证网络路径。对一对节点之间的多个隧道使用公共控制流量有助于减少要处理的数据包数量。
This document provides an applicability statement for the use of UDP transport checksums with IPv6.
本文档提供了在IPv6中使用UDP传输校验和的适用性声明。
It examines the role of the UDP transport checksum when used with IPv6 and presents a summary of the trade-offs in evaluating the safety of updating RFC 2460 to permit an IPv6 endpoint to use a zero UDP checksum field to indicate that no checksum is present.
它检查了UDP传输校验和在与IPv6一起使用时的作用，并总结了评估更新RFC 2460以允许IPv6端点使用零UDP校验和字段来指示不存在校验和的安全性时的权衡。
Application designers should first examine whether their transport goals may be met using standard UDP (with a calculated checksum) or UDP-Lite. The use of UDP with a zero UDP checksum has merits for some applications, such as tunnel encapsulation, and is widely used in IPv4. However, there are different dangers for IPv6. There is an increased risk of corruption and misdelivery when using zero UDP checksum in IPv6 compared to using IPv4 due to the lack of an IPv6 header checksum. Thus, application designers need to evaluate the risks of enabling use of a zero UDP checksum and consider a solution that at least provides the same delivery protection as for IPv4, for example, by utilizing UDP-Lite or by enabling the UDP checksum. The use of checksum off-loading may help alleviate the cost of checksum processing and permit use of a checksum using method defined in RFC 2460.
应用程序设计人员应首先检查是否可以使用标准UDP（带有计算出的校验和）或UDP Lite来满足其传输目标。使用具有零UDP校验和的UDP对于某些应用程序（如隧道封装）具有优点，并且在IPv4中广泛使用。然而，IPv6存在不同的危险。与使用IPv4相比，在IPv6中使用零UDP校验和时，由于缺少IPv6报头校验和，会增加损坏和错误传递的风险。因此，应用设计者需要评估使用零UDP校验和的风险，并考虑一种解决方案，该解决方案至少提供与IPv4相同的递送保护，例如，通过利用UDP Lite或启用UDP校验和。使用校验和卸载可能有助于降低校验和处理的成本，并允许使用RFC 2460中定义的使用校验和的方法。
Tunnel applications using UDP for encapsulation can, in many cases, use a zero UDP checksum without significant impact on the corruption rate. A well-designed tunnel application should include consistency checks to validate the header information encapsulated with a received packet. In most cases, tunnels encapsulating IP packets can rely on the integrity protection provided by the transported protocol (or tunneled inner packet). When correctly implemented, such an endpoint will not be negatively impacted by the omission of the transport-layer checksum. Recursive tunneling and fragmentation are potential issues that can raise corruption rates significantly, and they require careful consideration.
在许多情况下，使用UDP进行封装的隧道应用程序可以使用零UDP校验和，而不会对损坏率产生显著影响。设计良好的隧道应用程序应包括一致性检查，以验证用接收到的数据包封装的报头信息。在大多数情况下，封装IP数据包的隧道可以依赖于传输协议（或隧道内部数据包）提供的完整性保护。正确实现后，这样的端点不会因忽略传输层校验和而受到负面影响。递归隧道和碎片化是可能显著提高腐败率的潜在问题，需要仔细考虑。
Other UDP applications at the intended destination node or another node can be impacted if the nodes are allowed to receive datagrams that have a zero UDP checksum. It is important that already deployed applications are not impacted by a change at the transport layer. If these applications execute on nodes that implement RFC 2460, they will discard (and log) all datagrams with a zero UDP checksum. This is not an issue.
如果允许节点接收UDP校验和为零的数据报，则目标节点或其他节点上的其他UDP应用程序可能会受到影响。重要的是，已部署的应用程序不受传输层更改的影响。如果这些应用程序在实现RFC2460的节点上执行，它们将丢弃（并记录）所有UDP校验和为零的数据报。这不是问题。
In general, UDP-based applications need to employ a mechanism that allows a large percentage of the corrupted packets to be removed before they reach an application, to protect both the data stream of the application and the control plane of higher layer protocols. These checks are currently performed by the UDP checksum for IPv6 or by the reduced checksum for UDP-Lite when used with IPv6.
通常，基于UDP的应用程序需要采用一种机制，允许在损坏的数据包到达应用程序之前删除大部分数据包，以保护应用程序的数据流和更高层协议的控制平面。这些检查当前由IPv6的UDP校验和或与IPv6一起使用时UDP Lite的缩减校验和执行。
The transport of recursive tunneling and the use of fragmentation pose difficult issues that need to be considered in the design of tunnel protocols. There is an increased risk of an error in the innermost packet when fragmentation occurs across several layers of tunneling and several different reassembly processes are run without verification of correctness. This requires extra thought and careful consideration in the design of transported tunnels.
递归隧道的传输和分段的使用构成了隧道协议设计中需要考虑的难题。当跨多个隧道层发生碎片并且在未验证正确性的情况下运行多个不同的重新组装过程时，最内层数据包中的错误风险会增加。在运输隧道的设计中，这需要额外考虑和仔细考虑。
Any use of the updated method must consider the implications for firewalls, NATs, and other middleboxes. It is not expected that IPv6 NATs will handle IPv6 UDP datagrams in the same way that they handle IPv4 UDP datagrams. In many deployed cases, an update to support an IPv6 zero UDP checksum will be required. Firewalls are intended to be configured, and therefore, they may need to be explicitly updated to allow new services or protocols. Deployment of IPv6 middleboxes is not yet as prolific as it is in IPv4, and therefore, new devices are expected to follow the methods specified in this document.
任何更新方法的使用都必须考虑防火墙、NAT和其他中间框的含义。IPv6 NAT处理IPv6 UDP数据报的方式与处理IPv4 UDP数据报的方式不一样。在许多部署的情况下，需要更新以支持IPv6零UDP校验和。防火墙是要配置的，因此，它们可能需要显式更新以允许新的服务或协议。IPv6中间盒的部署还没有IPv4中的多，因此，新设备预计将遵循本文档中指定的方法。
Each application should consider the implications of choosing an IPv6 transport that uses a zero UDP checksum and should consider whether other standard methods may be more appropriate and may simplify application design.
每个应用程序应该考虑选择使用零UDP校验和的IPv6传输的影响，并且应该考虑其他标准方法是否更合适，并且可以简化应用程序设计。
Transport checksums provide the first stage of protection for the stack, although they cannot be considered authentication mechanisms. These checks are also desirable to ensure that packet counters correctly log actual activity, and they can be used to detect unusual behaviors.
传输校验和为堆栈提供第一阶段的保护，尽管它们不能被视为身份验证机制。这些检查还可以确保数据包计数器正确记录实际活动，并可用于检测异常行为。
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 an acceptable rate for transmission. This 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 that is forwarding zero checksum UDP packets and cause overload in the
根据硬件设计，具有零UDP校验和的隧道和计算校验和的隧道的处理要求可能不同。在决定是否启用隧道和确定可接受的传输速率时，可能需要考虑该处理开销。这可能会成为设计的安全风险，因为与具有非零校验和的数据报（如隧道出口）相比，这些设计可以处理数量显著更多的具有零UDP校验和的数据包。攻击者可能会尝试将非零校验和UDP数据包注入正在转发零校验和UDP数据包的隧道中，并导致数据包过载
processing of the non-zero checksums, e.g., if it happens in a router's slow path. Protection mechanisms should therefore 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.
非零校验和的处理，例如，如果它发生在路由器的慢路径上。因此，当存在这种威胁时，应采用保护机制。保护可能包括源地址过滤，以防止攻击者注入流量，以及限制非零校验和流量。后者可能会影响隧道协议的功能。
Transmission of IPv6 packets with a zero UDP checksum could reveal additional information to help an on-path attacker identify the operating system or configuration of a sending node. There is a need to probe the network path to determine whether the current path supports the use of IPv6 packets with a zero UDP checksum. The details of the probing mechanism may differ for different tunnel encapsulations, and if they are visible in the network (e.g., if not using IPsec in encryption mode), they could reveal additional information to help an on-path attacker identify the type of tunnel being used.
传输具有零UDP校验和的IPv6数据包可能会显示其他信息，以帮助路径上的攻击者识别发送节点的操作系统或配置。需要探测网络路径，以确定当前路径是否支持使用UDP校验和为零的IPv6数据包。对于不同的隧道封装，探测机制的细节可能会有所不同，如果它们在网络中可见（例如，如果在加密模式下未使用IPsec），它们可能会显示其他信息，以帮助路径上的攻击者识别正在使用的隧道类型。
IP-in-IP or GRE tunnels offer good traversal of middleboxes that have not been designed for security, e.g., firewalls. However, firewalls may be expected to be configured to block general tunnels, because they present a large attack surface. This applicability statement therefore permits this method to be enabled only for specific port ranges.
IP或GRE隧道中的IP可以很好地穿越非安全设计的中间盒，例如防火墙。但是，防火墙可能会被配置为阻止一般隧道，因为它们会造成较大的攻击面。因此，此适用性声明允许仅针对特定端口范围启用此方法。
When the zero UDP checksum mode is enabled for a range of ports, nodes and middleboxes must forward received UDP datagrams that have either a calculated checksum or a zero checksum.
当为一系列端口启用零UDP校验和模式时，节点和中间盒必须转发接收到的具有计算校验和或零校验和的UDP数据报。
We would like to thank Brian Haberman, Brian Carpenter, Margaret Wasserman, Lars Eggert, and others in the TSV directorate. Barry Leiba, Ronald Bonica, Pete Resnick, and Stewart Bryant helped to make this document one with greater applicability. Thanks to P.F. Chimento for careful review and editorial corrections.
我们要感谢Brian Haberman、Brian Carpenter、Margaret Wasserman、Lars Eggert以及TSV董事会的其他成员。Barry Leiba、Ronald Bonica、Pete Resnick和Stewart Bryant帮助使本文档更具适用性。感谢P.F.奇门托的仔细审查和编辑更正。
Thanks also to Remi Denis-Courmont, Pekka Savola, Glen Turner, and many others who contributed comments and ideas via the 6man, behave, lisp, and mboned lists.
还要感谢雷米·丹尼斯·库尔蒙、佩卡·萨沃拉、格伦·特纳以及其他通过6man、behave、lisp和mboned列表提供评论和想法的人。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[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月。
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, April 2013.
[RFC6935]Eubanks，M.，Chimento，P.，和M.Westerlund，“隧道数据包的IPv6和UDP校验和”，RFC 69352013年4月。
[AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, June 2012.
[AMT]Bumgardner，G.，“自动多播隧道”，正在进行的工作，2012年6月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988.
[RFC1071]Braden，R.，Borman，D.，Partridge，C.，和W.Plummer，“计算互联网校验和”，RFC 10711988年9月。
[RFC1141] Mallory, T. and A. Kullberg, "Incremental updating of the Internet checksum", RFC 1141, January 1990.
[RFC1141]Mallory，T.和A.Kullberg，“互联网校验和的增量更新”，RFC 114119990年1月。
[RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via Incremental Update", RFC 1624, May 1994.
[RFC1624]Rijsinghani，A.，“通过增量更新计算互联网校验和”，RFC1624，1994年5月。
[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月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]Karn，P.，Bormann，C.，Fairhurst，G.，Grossman，D.，路德维希，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月。
[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月。
[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月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963]Heffner，J.，Mathis，M.，和B.Chandler，“高数据速率下的IPv4重组错误”，RFC 4963，2007年7月。
[RFC5097] Renker, G. and G. Fairhurst, "MIB for the UDP-Lite protocol", RFC 5097, January 2008.
[RFC5097]Renker，G.和G.Fairhurst，“UDP Lite协议的MIB”，RFC 5097，2008年1月。
[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月。
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009.
[RFC5415]Calhoun，P.，Montemurro，M.，和D.Stanley，“无线接入点的控制和供应（CAPWAP）协议规范”，RFC 5415，2009年3月。
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009.
[RFC5722]Krishnan，S.，“重叠IPv6片段的处理”，RFC 5722，2009年12月。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, November 2011.
[RFC6437]Amante，S.，Carpenter，B.，Jiang，S.，和J.Rajahalme，“IPv6流标签规范”，RFC 6437，2011年11月。
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, November 2011.
[RFC6438]Carpenter，B.和S.Amante，“在隧道中使用IPv6流标签进行等成本多路径路由和链路聚合”，RFC 6438，2011年11月。
[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月。
[Sigcomm2000] Stone, J. and C. Partridge, "When the CRC and TCP Checksum Disagree", 2000, <http://conferences.sigcomm.org/sigcomm/2000/conf/ abstract/9-1.htm>.
[Sigcomm2000]Stone，J.和C.Partridge，“当CRC和TCP校验和不一致时”，2000年<http://conferences.sigcomm.org/sigcomm/2000/conf/ 摘要/9-1.htm>。
[TUNNELS] Touch, J. and M. Townsley, "Tunnels in the Internet Architecture", Work in Progress, March 2010.
[隧道]Touch，J.和M.Townsley，“互联网架构中的隧道”，正在进行的工作，2010年3月。
[UDPTT] Fairhurst, G., "The UDP Tunnel Transport mode", Work in Progress, February 2010.
[UDPTT]Fairhurst，G.，“UDP隧道传输模式”，正在进行的工作，2010年2月。
Appendix A. Evaluation of Proposal to Update RFC 2460 to Support Zero Checksum
附录A.更新RFC 2460以支持零校验和的提案评估
This informative appendix documents the evaluation of the proposal to update IPv6 [RFC2460] such that it provides the option that some nodes may suppress generation and checking of the UDP transport checksum. It also compares this proposal with other alternatives, and notes that for a particular application, some standard methods may be more appropriate than using IPv6 with a zero UDP checksum.
本资料性附录记录了对更新IPv6[RFC2460]的建议的评估，从而提供了一些节点可能会禁止生成和检查UDP传输校验和的选项。它还将此方案与其他备选方案进行了比较，并指出，对于特定的应用程序，某些标准方法可能比使用具有零UDP校验和的IPv6更合适。
There are several alternatives to the normal method for calculating the UDP checksum [RFC1071] that do not require a tunnel endpoint to inspect the entire packet when computing a checksum. These include:
除了计算UDP校验和[RFC1071]的常规方法外，还有几种替代方法，它们在计算校验和时不需要隧道端点来检查整个数据包。这些措施包括：
o IP-in-IP tunneling. Because this method completely dispenses with a transport protocol in the outer layer, it has reduced overhead and complexity, but also reduced functionality. There is no outer checksum over the packet, and also there are no ports to perform demultiplexing among different tunnel types. This reduces the available information upon which a load balancer may act.
o IP隧道中的IP。因为这种方法完全不需要外层的传输协议，所以它减少了开销和复杂性，但也减少了功能。数据包上没有外部校验和，也没有在不同隧道类型之间执行解复用的端口。这会减少负载平衡器可能会根据的可用信息。
o UDP-Lite with the checksum coverage set to only the header portion of a packet. This requires a pseudo-header checksum calculation only on the encapsulating packet header. The computed checksum value may be cached (before adding the Length field) for each flow/destination and subsequently combined with the Length of each packet to minimize per-packet processing. This value is combined with the UDP payload length for the pseudo-header. However, this length is expected to be known when performing packet forwarding.
o 校验和覆盖率仅设置为数据包头部分的UDP Lite。这只需要对封装的数据包报头进行伪报头校验和计算。可以为每个流/目的地缓存计算出的校验和值（在添加长度字段之前），并随后与每个分组的长度组合以最小化每个分组的处理。该值与伪报头的UDP有效负载长度相结合。然而，在执行数据包转发时，该长度预计是已知的。
o Delta computation of the checksum from an encapsulated checksum field. Because the checksum is a cumulative sum [RFC1624], an encapsulating header checksum can be derived from the new pseudo-header, the inner checksum, and the sum of the other network-layer fields not included in the pseudo-header of the encapsulated packet, in a manner resembling incremental checksum update [RFC1141]. This would not require access to the whole packet, but does require fields to be collected across the header and arithmetic operations to be performed on each packet. The method would work only for packets that contain a 2's complement transport checksum (i.e., it would not be appropriate for SCTP or when IP fragmentation is used).
o 从封装的校验和字段计算校验和的增量。由于校验和是累积和[RFC1624]，封装报头校验和可以以类似于增量校验和更新[RFC1141]的方式从新的伪报头、内部校验和以及未包括在封装包的伪报头中的其他网络层字段的和中导出。这不需要访问整个数据包，但需要跨报头收集字段并对每个数据包执行算术运算。该方法仅适用于包含2的补码传输校验和的数据包（即，它不适用于SCTP或使用IP分段时）。
o UDP has been modified to disable checksum processing (Zero UDP Checksum) [RFC6935]. This eliminates the need for a checksum calculation, but would require constraints on appropriate usage and updates to endpoints and middleboxes.
o UDP已修改为禁用校验和处理（零UDP校验和）[RFC6935]。这消除了校验和计算的需要，但需要对端点和中间盒的适当使用和更新进行限制。
o The proposed UDP Tunnel Transport [UDPTT] protocol suggested a method where UDP would be modified to derive the checksum only from the encapsulating packet protocol header. This value does not change between packets in a single flow. The value may be cached per flow/destination to minimize per-packet processing.
o 建议的UDP隧道传输[UDPTT]协议建议了一种方法，其中UDP将被修改为仅从封装的数据包协议头导出校验和。此值在单个流中的数据包之间不会更改。可以对每个流/目的地缓存该值，以最小化每个分组的处理。
o A method has been proposed that uses a new (to-be-defined) IPv6 Destination Options Header to provide an end-to-end validation check at the network layer. This would allow an endpoint to verify delivery to an appropriate endpoint, but would also require IPv6 nodes to correctly handle the additional header and would require changes to middlebox behavior (e.g., when used with a NAT that always adjusts the checksum value).
o 提出了一种使用新的（待定义的）IPv6目的地选项报头在网络层提供端到端验证检查的方法。这将允许端点验证到适当端点的传递，但也将要求IPv6节点正确处理附加标头，并要求更改中间盒行为（例如，与始终调整校验和值的NAT一起使用时）。
o There has been a proposal to simply ignore the UDP checksum value on reception at the tunnel egress, allowing a tunnel ingress to insert any value, correct or false. For tunnel usage, a non-standard checksum value may be used, forcing an RFC 2460 receiver to drop the packet. The main downside is that it would be impossible to identify a UDP datagram (in the network or an endpoint) that is treated in this way compared to a packet that has actually been corrupted.
o 有人建议在隧道出口接收时忽略UDP校验和值，允许隧道入口插入任何正确或错误的值。对于隧道使用，可使用非标准校验和值，迫使RFC 2460接收器丢弃数据包。主要缺点是，与实际已损坏的数据包相比，无法识别以这种方式处理的UDP数据报（在网络或端点中）。
These options are compared and discussed further in the following sections.
以下各节将对这些选项进行比较和进一步讨论。
This section compares the methods listed above to support datagram tunneling. It includes proposals for updating the behavior of UDP.
本节比较上面列出的支持数据报隧道的方法。它包括更新UDP行为的建议。
While this comparison focuses on applications that are expected to execute on routers, the distinction between a router and a host is not always clear, especially at the transport level. Systems (such as UNIX-based operating systems) routinely provide both functions. From a received packet, there is no way to identify the role of the receiving node.
虽然这种比较侧重于预期在路由器上执行的应用程序，但路由器和主机之间的区别并不总是很清楚，特别是在传输级别。系统（如基于UNIX的操作系统）通常提供这两种功能。从接收到的数据包中，无法识别接收节点的角色。
Regular UDP with a standard checksum or the delta-encoded optimization for creating correct checksums has the best possibility for successful traversal of a middlebox. No new support is required.
使用标准校验和或增量编码优化创建正确校验和的常规UDP最有可能成功遍历中间盒。不需要新的支持。
A method that ignores the UDP checksum on reception is expected to have a good probability of traversal, because most middleboxes perform an incremental checksum update. UDPTT would also be able to traverse a middlebox with this behavior. However, a middlebox on the path that attempts to verify a standard checksum will not forward packets using either of these methods, thus preventing traversal. A method that ignores the checksum has the additional downside that it prevents improvement of middlebox traversal, because there is no way to identify UDP datagrams that use the modified checksum behavior.
在接收时忽略UDP校验和的方法预期具有良好的遍历概率，因为大多数中间盒执行增量校验和更新。UDPTT还可以通过这种行为遍历中间盒。但是，路径上尝试验证标准校验和的中间盒将不会使用这些方法中的任何一种转发数据包，从而防止遍历。忽略校验和的方法还有另一个缺点，即它阻止了中间盒遍历的改进，因为无法识别使用修改的校验和行为的UDP数据报。
IP-in-IP or GRE tunnels offer good traversal of middleboxes that have not been designed for security, e.g., firewalls. However, firewalls may be expected to be configured to block general tunnels, because they present a large attack surface.
IP或GRE隧道中的IP可以很好地穿越非安全设计的中间盒，例如防火墙。但是，防火墙可能会被配置为阻止一般隧道，因为它们会造成较大的攻击面。
A new IPv6 Destination Options header will suffer traversal issues with middleboxes, especially firewalls and NATs, and will likely require them to be updated before the extension header is passed.
新的IPv6目标选项报头将遇到中间盒的遍历问题，特别是防火墙和NAT，并且可能需要在传递扩展报头之前更新它们。
Datagrams with a zero UDP checksum will not be passed by any middlebox that validates the checksum using RFC 2460 or updates the checksum field, such as NAT or firewalls. This would require an update to correctly handle a datagram with a zero UDP checksum.
UDP校验和为零的数据报将不会通过使用RFC 2460验证校验和或更新校验和字段（如NAT或防火墙）的任何中间盒传递。这需要更新以正确处理UDP校验和为零的数据报。
UDP-Lite will require an update of almost all types of middleboxes, because it requires support for a separate network-layer protocol number. Once enabled, the method to support incremental checksum updates would be identical to that for UDP, but different for checksum validation.
UDP Lite需要更新几乎所有类型的中间盒，因为它需要支持单独的网络层协议号。一旦启用，支持增量校验和更新的方法将与UDP相同，但校验和验证不同。
The usefulness of solutions for load balancers depends on the difference in entropy in the headers for different flows that can be included in a hash function. All the proposals that use the UDP protocol number have equal behavior. UDP-Lite has the potential for behavior that is equally as good as UDP. However, UDP-Lite is currently unlikely to be supported by deployed hashing mechanisms, which could cause a load balancer not to use the transport header in the computed hash. A load balancer that uses only the IP header will have low entropy, but this could be improved by including the IPv6 the flow label, provided that the tunnel ingress ensures that different flow labels are assigned to different flows. However, a transition to the common use of good quality flow labels is likely to take time to deploy.
负载平衡器解决方案的有用性取决于散列函数中包含的不同流的报头中的熵差异。所有使用UDP协议编号的方案具有相同的行为。UDP Lite具有与UDP一样好的行为潜力。但是，部署的哈希机制目前不太可能支持UDP Lite，这可能会导致负载平衡器在计算的哈希中不使用传输头。仅使用IP报头的负载平衡器将具有低熵，但如果隧道入口确保为不同的流分配不同的流标签，则可以通过将IPv6包含在流标签中来改进这一点。但是，向通用高质量流标签的过渡可能需要时间来部署。
IP-in-IP tunnels are often considered efficient, because they introduce very little processing and have low data overhead. The other proposals introduce a UDP-like header, which incurs an associated data overhead. Processing is minimized for the method that uses a zero UDP checksum and for the method that ignores the UDP checksum on reception, and processing is only slightly higher for UDPTT, the extension header, and UDP-Lite. The delta calculation scheme operates on a few more fields, but also introduces serious failure modes that can result in a need to calculate a checksum over the complete datagram. Regular UDP is clearly the most costly to process, always requiring checksum calculation over the entire datagram.
IP隧道中的IP通常被认为是有效的，因为它们只引入很少的处理，并且数据开销很低。其他方案引入了类似UDP的报头，这会产生相关的数据开销。对于使用零UDP校验和的方法和在接收时忽略UDP校验和的方法，处理被最小化，对于UDPTT、扩展标头和UDP Lite，处理只稍微高一点。增量计算方案在几个字段上运行，但也引入了严重的故障模式，这可能导致需要计算完整数据报的校验和。常规UDP显然是处理成本最高的，总是需要对整个数据报进行校验和计算。
It is important to note that the zero UDP checksum method, ignoring checksum on reception, the Option Header, UDPTT, and UDP-Lite will likely incur additional complexities in the application to incorporate a negotiation and validation mechanism.
需要注意的是，零UDP校验和方法（忽略接收时的校验和）、选项头、UDPTT和UDP Lite可能会在应用程序中产生额外的复杂性，以合并协商和验证机制。
The major factors influencing deployability of these solutions are a need to update both endpoints, a need for negotiation, and the need to update middleboxes. These are summarized below:
影响这些解决方案可部署性的主要因素是需要更新两个端点、需要协商以及需要更新中间盒。总结如下：
o The solution with the best deployability is regular UDP. This requires no changes and has good middlebox traversal characteristics.
o 具有最佳部署能力的解决方案是常规UDP。这不需要更改，并且具有良好的中间盒遍历特性。
o The next easiest to deploy is the delta checksum solution. This does not modify the protocol on the wire and needs changes only in the tunnel ingress.
o 下一个最容易部署的是增量校验和解决方案。这不会修改线路上的协议，只需要在隧道入口中进行更改。
o IP-in-IP tunnels should not require changes to the endpoints, but they raise issues regarding the traversal of firewalls and other security devices, which are expected to require updates.
o IP隧道中的IP不应要求对端点进行更改，但它们会引发有关防火墙和其他安全设备的遍历的问题，这些设备预计需要更新。
o Ignoring the checksum on reception will require changes at both endpoints. The never-ceasing risk of path failure requires additional checks to ensure that this solution is robust, and it will require changes or additions to the tunnel control protocol to negotiate support and validate the path.
o 忽略接收时的校验和将需要在两个端点进行更改。永不停止的路径故障风险需要额外的检查以确保此解决方案是健壮的，并且需要更改或添加隧道控制协议以协商支持和验证路径。
o The remaining solutions (including the zero UDP checksum method) offer similar deployability. UDP-Lite requires support at both endpoints and in middleboxes. UDPTT and the zero UDP checksum method, with or without an extension header, require support at
o 其余的解决方案（包括零UDP校验和方法）提供了类似的部署能力。UDP Lite需要在端点和中间盒中提供支持。UDPTT和零UDP校验和方法（带或不带扩展标头）需要在以下位置获得支持：
both endpoints and in middleboxes. UDP-Lite, UDPTT, and the zero UDP checksum method and the use of extension headers may also require changes or additions to the tunnel control protocol to negotiate support and path validation.
端点和中间盒中的。UDP Lite、UDPTT和零UDP校验和方法以及扩展头的使用也可能需要更改或添加隧道控制协议，以协商支持和路径验证。
The standard UDP checksum and the delta checksum can both provide some verification at the tunnel egress. This can significantly reduce the probability that a corrupted inner packet is forwarded. UDP-Lite, UDPTT, and the extension header all provide some verification against corruption, but they do not verify the inner packet. They provide only a strong indication that the delivered packet was intended for the tunnel egress and was correctly delimited.
标准UDP校验和和和增量校验和都可以在隧道出口处提供一些验证。这可以显著降低损坏的内部数据包被转发的概率。UDP Lite、UDPTT和扩展头都提供了一些针对损坏的验证，但它们不验证内部数据包。它们只提供了一个强有力的指示，表明交付的数据包是用于隧道出口的，并且被正确地分隔。
The methods using a zero UDP checksum, ignoring the UDP checksum on reception, and IP-and-IP encapsulation all provide no verification that a received datagram was intended to be processed by a specific tunnel egress or that the inner encapsulated packet was correct. Section 3.1 discusses experience using specific protocols in well-managed networks.
使用零UDP校验和、在接收时忽略UDP校验和以及IP和IP封装的方法都无法验证接收到的数据报是否打算由特定的隧道出口处理，或者内部封装的数据包是否正确。第3.1节讨论了在管理良好的网络中使用特定协议的经验。
The comparisons above may be summarized as, "there is no silver bullet that will slay all the issues". One has to select which downsides can best be lived with. Focusing on the existing solutions, they can be summarized as:
上面的比较可以总结为：“没有什么灵丹妙药可以解决所有问题”。人们必须选择哪种不利因素最适合接受。以现有解决方案为重点，可以概括为：
Regular UDP: The method defined in RFC 2460 has good middlebox traversal and load balancing and multiplexing, and requires a checksum in the outer headers to cover the whole packet.
常规UDP：RFC2460中定义的方法具有良好的中间盒遍历、负载平衡和多路复用，并且需要外部报头中的校验和覆盖整个数据包。
IP-in-IP: A low-complexity encapsulation that has limited middlebox traversal, no multiplexing support, and poor load-balancing support that could improve over time.
IP-in-IP：一种低复杂度的封装，具有有限的中间盒遍历、无多路复用支持和较差的负载平衡支持，可以随着时间的推移而改进。
UDP-Lite: A medium-complexity encapsulation that has good multiplexing support, limited middlebox traversal that may possibly improve over time, and poor load-balancing support that could improve over time, and that, in most cases, requires application-level negotiation to select the protocol and validation to confirm that the path forwards UDP-Lite.
UDP Lite：一种中等复杂度的封装，具有良好的多路复用支持、有限的中间盒遍历（可能随时间而改进）和较差的负载平衡支持（可能随时间而改进），并且在大多数情况下，需要应用程序级协商来选择协议，并验证路径是否转发UDP Lite。
Delta computation of a tunnel checksum: The delta checksum is an optimization in the processing of UDP, and, as such, it exhibits some of the drawbacks of using regular UDP.
隧道校验和的增量计算：增量校验和是UDP处理中的一种优化，因此，它显示了使用常规UDP的一些缺点。
The remaining proposals may be described in similar terms:
其余的提案可以用类似的术语描述：
Zero Checksum: A low-complexity encapsulation that has good multiplexing support, limited middlebox traversal that could improve over time, and good load-balancing support, and that, in most cases, requires application-level negotiation and validation to confirm that the path forwards a zero UDP checksum.
零校验和：一种低复杂度的封装，具有良好的多路复用支持、有限的中间盒遍历（可随时间改进）和良好的负载平衡支持，并且在大多数情况下，需要应用程序级协商和验证以确认路径转发零UDP校验和。
UDPTT: A medium-complexity encapsulation that has good multiplexing support, limited middlebox traversal that may possibly improve over time, and good load-balancing support, and that, in most cases, requires application-level negotiation to select the transport and validation to confirm the path forwards UDPTT datagrams.
UDPTT：一种中等复杂度的封装，具有良好的多路复用支持、有限的中间盒遍历（可能随时间而改进）和良好的负载平衡支持，并且在大多数情况下，需要应用程序级协商来选择传输和验证，以确认转发UDPTT数据报的路径。
IPv6 Destination Option IP-in-IP Tunneling: A medium-complexity encapsulation that has no multiplexing support, limited middlebox traversal, and poor load-balancing support that could improve over time, and that, in most cases, requires negotiation to confirm that the option is supported and validation to confirm the path forwards the option.
IP隧道中的IPv6目标选项IP：一种中等复杂度的封装，不支持多路复用、有限的中间盒遍历和较差的负载平衡支持，随着时间的推移可能会有所改善，在大多数情况下，需要协商以确认该选项是否受支持，并需要验证以确认路径转发该选项。
IPv6 Destination Option Combined with Zero UDP Checksum: A medium-complexity encapsulation that has good multiplexing support, limited load-balancing support that could improve over time, and that, in most cases, requires negotiation to confirm the option is supported and validation to confirm the path forwards the option.
IPv6目标选项与零UDP校验和相结合：一种中等复杂度的封装，具有良好的多路复用支持，有限的负载平衡支持，可以随时间而改进，并且在大多数情况下，需要协商以确认支持该选项，并需要验证以确认路径转发该选项。
Ignore the Checksum on Reception: A low-complexity encapsulation that has good multiplexing support, medium middlebox traversal that can never improve, and good load-balancing support, and that, in most cases, requires negotiation to confirm that the option is supported by the remote endpoint and validation to confirm the path forwards a zero UDP checksum.
忽略接收时的校验和：一种低复杂度的封装，具有良好的多路复用支持、永远无法改进的中间盒遍历和良好的负载平衡支持，并且在大多数情况下，需要协商以确认远程端点支持该选项，并需要验证以确认路径转发零UDP校验和。
There is no clear single optimum solution. If the most important need is to traverse middleboxes, the best choice is to stay with regular UDP and consider the optimizations that may be required to perform the checksumming. If one can live with limited middlebox traversal, if low complexity is necessary, and one does not require load balancing, IP-in-IP tunneling is the simplest. If one wants strengthened error detection, but with the currently limited middlebox traversal and load balancing, UDP-Lite is appropriate. Zero UDP checksum addresses another set of constraints: low complexity and a need for load balancing from the current Internet, provided that the usage can accept the currently limited support for middlebox traversal.
没有明确的单一最优解。如果最重要的需求是遍历中间框，最好的选择是保持常规UDP，并考虑执行校验和所需的优化。如果可以使用有限的中间盒遍历，如果需要低复杂性，并且不需要负载平衡，那么IP-in-IP隧道是最简单的。若您希望加强错误检测，但由于当前有限的中间盒遍历和负载平衡，UDP Lite是合适的。零UDP校验和解决了另一组约束：低复杂性和当前Internet负载平衡的需要，前提是使用可以接受当前对中间盒遍历的有限支持。
Techniques for load balancing and middlebox traversal do continue to evolve. Over a long time, developments in load balancing have good potential to improve. This time horizon is long, because it requires both load balancer and endpoint updates to get full benefit. The challenges of middlebox traversal are also expected to change with time as device capabilities evolve. Middleboxes are very prolific, with a larger proportion of end user ownership, and therefore may be expected to take a long time to evolve.
负载平衡和中间盒遍历技术仍在不断发展。长期以来，负载平衡的发展具有很好的改进潜力。这个时间范围很长，因为它需要负载平衡器和端点更新才能获得全部好处。随着设备功能的发展，中端箱遍历的挑战也将随着时间的推移而变化。中间包的数量非常多，最终用户所有权的比例更大，因此可能需要很长时间才能发展。
However, we note that the deployment of IPv6-capable middleboxes is still in its initial phase, and if a new method becomes standardized quickly, fewer boxes will be non-compliant.
然而，我们注意到，支持IPv6的中间盒的部署仍处于初始阶段，如果一种新方法很快变得标准化，那么不符合要求的中间盒就会减少。
Thus, the question of whether to permit use of datagrams with a zero UDP checksum for IPv6 under reasonable constraints is best viewed as a trade-off among a number of more subjective questions:
因此，在合理的约束条件下，是否允许在IPv6中使用UDP校验和为零的数据报的问题最好被视为一个权衡问题：
o Is there sufficient interest in using a zero UDP checksum with the given constraints (summarized below)?
o 在给定约束条件下使用零UDP校验和是否有足够的兴趣（总结如下）？
o Are there other avenues of change that will resolve the issue in a better way and sufficiently quickly ?
o 是否有其他的改变途径能够以更好的方式和足够快的速度解决这个问题？
o Do we accept the complexity cost of having one more solution in the future?
o 我们是否接受未来再提供一个解决方案的复杂性成本？
The analysis concludes that the IETF should carefully consider constraints on sanctioning the use of any new transport mode. The 6man working group of the IETF has determined that the answers to the above questions are sufficient to update IPv6 to standardize use of a zero UDP checksum for use by tunnel encapsulations for specific applications.
分析得出结论IETF应该仔细考虑限制使用任何新的运输模式的约束。IETF的6man工作组已确定，上述问题的答案足以更新IPv6，以标准化零UDP校验和的使用，供特定应用的隧道封装使用。
Each application should consider the implications of choosing an IPv6 transport that uses a zero UDP checksum. In many cases, standard methods may be more appropriate and may simplify application design. The use of checksum off-loading may help alleviate the checksum processing cost and permit use of a checksum using the method defined in RFC 2460.
每个应用程序都应该考虑选择使用零UDP校验和的IPv6传输的影响。在许多情况下，标准方法可能更合适，并可能简化应用程序设计。使用校验和卸载可能有助于降低校验和处理成本，并允许使用RFC 2460中定义的方法使用校验和。
Authors' Addresses
作者地址
Godred Fairhurst University of Aberdeen School of Engineering Aberdeen, AB24 3UE Scotland, UK
GoRead FelHurt阿伯丁大学工程学院阿伯丁，AB24 3UE苏格兰，英国
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry
Magnus Westerlund Ericsson Farogatan 6 Stockholm, SE-164 80 Sweden
Magnus Westerlund Ericsson Farogatan 6斯德哥尔摩，SE-164 80瑞典
Phone: +46 8 719 0000
EMail: magnus.westerlund@ericsson.com
Phone: +46 8 719 0000
EMail: magnus.westerlund@ericsson.com