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数据报的适用性声明



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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
1. Introduction
1. 介绍

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).


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.


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


checksum for IPv6. Therefore, in this document, we derive a set of constraints required to ensure safe deployment of a zero UDP checksum.


Finally, the document identifies some issues that require future consideration and possibly additional research.


1.1. Document Structure
1.1. 文件结构

Section 1 provides a background to key issues and introduces the use of UDP as a tunnel transport protocol.


Section 2 describes a set of standards-track datagram transport protocols that may be used to support tunnels.


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.


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.


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.


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.


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.


1.2. Terminology
1.2. 术语

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].


1.3. Use of UDP Tunnels
1.3. UDP隧道的使用

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.


1.3.1. Motivation for New Approaches
1.3.1. 新方法的动机

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.


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 希望使用端口号空间来实现负载共享。

1.3.2. Reducing Forwarding Costs
1.3.2. 降低运输成本

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.


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.


1.3.3. Need to Inspect the Entire Packet
1.3.3. 需要检查整个包吗

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.


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校验和不适合在无法访问整个数据包且不提供校验和卸载的路由器内使用。因此,在整个数据包上启用校验和计算可能会影响路由器的设计、性能、能耗和成本。

1.3.4. Interactions with Middleboxes
1.3.4. 与中间盒的交互

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的中间件的部署仍处于初始阶段。因此,可能是未更新的框的数量很快就成为部署的中间框的一个很小的百分比。

1.3.5. Support for Load Balancing
1.3.5. 支持负载平衡

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.


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.


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.


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.


2. Standards-Track Transports
2. 标准轨道运输

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.


2.1. UDP with Standard Checksum
2.1. 具有标准校验和的UDP

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使用指南。

2.2. UDP-Lite
2.2. 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)覆盖不敏感部分。

2.2.1. Using UDP-Lite as a Tunnel Encapsulation
2.2.1. 使用UDP Lite作为隧道封装

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在中间盒和端点中获得更好的支持。

2.3. General Tunnel Encapsulations
2.3. 一般隧道封装

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.


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.


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.


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-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.


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.


3. Issues Requiring Consideration
3. 需要审议的问题

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.


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.


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.


3.1. Effect of Packet Modification in the Network
3.1. 网络中分组修改的影响

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.


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:


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.


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.


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.


3.1.1. Corruption of the Destination IP Address Field
3.1.1. 目标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


the network layer. Detection of this corruption by a UDP receiver relies on the IPv6 pseudo-header that is incorporated in the transport checksum.


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节关于端口处理。)

3.1.2. Corruption of the Source IP Address Field
3.1.2. 源IP地址字段损坏

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.


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.


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.


3.1.3. Corruption of Port Information
3.1.3. 港口信息的腐败

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数据包的传输报头中携带的端口在传输过程中损坏,则数据包可能被传送到错误的应用程序进程(在目标机器上),响应或错误可能被发送到错误的应用程序进程(在目标机器上),或者两者都可能发生。

3.1.4. Delivery to an Unexpected Port
3.1.4. 传递到意外端口

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:


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:


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.


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


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.


3.1.5. Corruption of Fragmentation Information
3.1.5. 碎片信息的损坏

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:


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.


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].


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:


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.


3.2. Where Packet Corruption Occurs
3.2. 发生数据包损坏的位置

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.


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.


3.3. Validating the Network Path
3.3. 正在验证网络路径

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.


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.


3.4. Applicability of the Zero UDP Checksum Method
3.4. 零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


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.


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.


3.5. Impact on Non-Supporting Devices or Applications
3.5. 对非支持设备或应用程序的影响

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.


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.


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.


4. Constraints on Implementation of IPv6 Nodes Supporting Zero Checksum
4. 支持零校验和的IPv6节点的实现约束

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.


All implementations that support the zero UDP checksum method MUST conform to the requirements defined below:


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消息体中的地址和端口号)。

5. Requirements on Usage of the Zero UDP Checksum
5. 零UDP校验和的使用要求

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:


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:


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.


6. Summary
6. 总结

This document provides an applicability statement for the use of UDP transport checksums with IPv6.


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.


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.


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.


7. Security Considerations
7. 安全考虑

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


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.


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.


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.


8. Acknowledgments
8. 致谢

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.


9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[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月。

9.2. Informative References
9.2. 资料性引用

[AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, June 2012.


[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.


[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, < abstract/9-1.htm>.

[Sigcomm2000]Stone,J.和C.Partridge,“当CRC和TCP校验和不一致时”,2000年< 摘要/9-1.htm>。

[TUNNELS] Touch, J. and M. Townsley, "Tunnels in the Internet Architecture", Work in Progress, March 2010.


[UDPTT] Fairhurst, G., "The UDP Tunnel Transport mode", Work in Progress, February 2010.


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.


A.1. Alternatives to the Standard Checksum
A.1. 标准校验和的替代方案

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:


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.


A.2. Comparison of Alternative Methods
A.2. 替代方法的比较

This section compares the methods listed above to support datagram tunneling. It includes proposals for updating the behavior of 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.


A.2.1. Middlebox Traversal
A.2.1. 中间盒遍历

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.


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.


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.


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.


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相同,但校验和验证不同。

A.2.2. Load Balancing
A.2.2. 负载平衡

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包含在流标签中来改进这一点。但是,向通用高质量流标签的过渡可能需要时间来部署。

A.2.3. Ingress and Egress Performance Implications
A.2.3. 入口和出口性能影响

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可能会在应用程序中产生额外的复杂性,以合并协商和验证机制。

A.2.4. Deployability
A.2.4. 可部署性

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校验和方法以及扩展头的使用也可能需要更改或添加隧道控制协议,以协商支持和路径验证。

A.2.5. Corruption Detection Strength
A.2.5. 贪污侦查力量

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.


A.2.6. Comparison Summary
A.2.6. 比较摘要

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.


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.


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.


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.


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.


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.


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.


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.


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.


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:


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.


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苏格兰,英国


Magnus Westerlund Ericsson Farogatan 6 Stockholm, SE-164 80 Sweden

Magnus Westerlund Ericsson Farogatan 6斯德哥尔摩,SE-164 80瑞典

   Phone: +46 8 719 0000
   Phone: +46 8 719 0000