Network Working Group L-A. Larzon
Request for Comments: 3828 Lulea University of Technology
Category: Standards Track M. Degermark
S. Pink
The University of Arizona
L-E. Jonsson, Ed.
Ericsson
G. Fairhurst, Ed.
University of Aberdeen
July 2004
Network Working Group L-A. Larzon
Request for Comments: 3828 Lulea University of Technology
Category: Standards Track M. Degermark
S. Pink
The University of Arizona
L-E. Jonsson, Ed.
Ericsson
G. Fairhurst, Ed.
University of Aberdeen
July 2004
The Lightweight User Datagram Protocol (UDP-Lite)
轻量级用户数据报协议（UDP Lite）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC 768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP.
本文档描述了轻量级用户数据报协议（UDP Lite），它与用户数据报协议（UDP）（RFC 768）类似，但也可以为容易出错的网络环境中的应用程序提供服务，这些网络环境中的应用程序更喜欢交付部分损坏的有效负载，而不是丢弃。如果未使用此功能，UDP Lite在语义上与UDP相同。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 3
3.1. Fields . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Pseudo Header. . . . . . . . . . . . . . . . . . . . . . 5
3.3. Application Interface. . . . . . . . . . . . . . . . . . 5
3.4. IP Interface . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Jumbograms . . . . . . . . . . . . . . . . . . . . . . . 6
4. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 6
5. Compatibility with UDP . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 3
3.1. Fields . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Pseudo Header. . . . . . . . . . . . . . . . . . . . . . 5
3.3. Application Interface. . . . . . . . . . . . . . . . . . 5
3.4. IP Interface . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Jumbograms . . . . . . . . . . . . . . . . . . . . . . . 6
4. Lower Layer Considerations . . . . . . . . . . . . . . . . . . 6
5. Compatibility with UDP . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12
This document describes a new transport protocol, UDP-Lite, (also known as UDPLite). This new protocol is based on three observations:
本文档描述了一种新的传输协议UDP Lite（也称为UDPLite）。该新方案基于三个观察结果：
First, there is a class of applications that benefit from having damaged data delivered rather than discarded by the network. A number of codecs for voice and video fall into this class (e.g., the AMR speech codec [RFC-3267], the Internet Low Bit Rate Codec [ILBRC], and error resilient H.263+ [ITU-H.263], H.264 [ITU-H.264; H.264], and MPEG-4 [ISO-14496] video codecs). These codecs may be designed to cope better with errors in the payload than with loss of entire packets.
首先，有一类应用程序受益于受损数据的交付，而不是被网络丢弃。许多语音和视频编解码器属于这一类（例如，AMR语音编解码器[RFC-3267]、互联网低比特率编解码器[ILBRC]和容错H.263+[ITU-H.263]、H.264[ITU-H.264；H.264]和MPEG-4[ISO-14496]视频编解码器）。这些编解码器的设计可以更好地处理有效负载中的错误，而不是处理整个数据包的丢失。
Second, all links that support IP transmission should use a strong link layer integrity check (e.g., CRC-32 [RFC-3819]), and this MUST be used by default for IP traffic. When the under-lying link supports it, certain types of traffic (e.g., UDP-Lite) may benefit from a different link behavior that permits partially damaged IP packets to be forwarded when requested [RFC-3819]. Several radio technologies (e.g., [3GPP]) support this link behavior when operating at a point where cost and delay are sufficiently low. If error-prone links are aware of the error sensitive portion of a packet, it is also possible for the physical link to provide greater protection to reduce the probability of corruption of these error sensitive bytes (e.g., the use of unequal Forward Error Correction).
其次，所有支持IP传输的链路都应使用强链路层完整性检查（例如，CRC-32[RFC-3819]），默认情况下，这必须用于IP通信。当地下链路支持它时，某些类型的通信量（例如UDP Lite）可能会受益于不同的链路行为，允许在请求时转发部分损坏的IP数据包[RFC-3819]。当在成本和延迟足够低的点上运行时，几种无线电技术（例如，[3GPP]）支持这种链路行为。如果容易出错的链路知道分组的错误敏感部分，则物理链路也可以提供更大的保护以降低这些错误敏感字节的损坏概率（例如，使用不平等的前向错误校正）。
Third, intermediate layers (i.e., IP and the transport layer protocols) should not prevent error-tolerant applications from running well in the presence of such links. IP is not a problem in this regard, since the IP header has no checksum that covers the IP payload. The generally available transport protocol best suited for these applications is UDP, since it has no overhead for retransmission of erroneous packets, in-order delivery, or error correction. In IPv4 [RFC-791], the UDP checksum covers either the entire packet or nothing at all. In IPv6 [RFC-2460], the UDP checksum is mandatory and must not be disabled. The IPv6 header does not have a header checksum and it was deemed necessary to always protect the IP addressing information by making the UDP checksum mandatory.
第三，中间层（即IP和传输层协议）不应阻止容错应用程序在存在此类链路的情况下正常运行。IP在这方面不是问题，因为IP报头没有覆盖IP有效负载的校验和。通常最适合这些应用程序的可用传输协议是UDP，因为它没有错误数据包的重传、顺序传递或错误纠正的开销。在IPv4[RFC-791]中，UDP校验和覆盖整个数据包或根本不覆盖任何内容。在IPv6[RFC-2460]中，UDP校验和是必需的，不能禁用。IPv6报头没有报头校验和，因此有必要始终通过强制UDP校验和来保护IP寻址信息。
A transport protocol is needed that conforms to the properties of link layers and applications described above [LDP99]. The error-detection mechanism of the transport layer must be able to protect vital information such as headers, but also to optionally ignore errors best dealt with by the application. The set of octets to be verified by the checksum is best specified by the sending application.
需要符合上述链路层和应用程序属性的传输协议[LDP99]。传输层的错误检测机制必须能够保护重要信息，如头，但也可以选择忽略应用程序最好处理的错误。由校验和验证的八位字节集最好由发送应用程序指定。
UDP-Lite provides a checksum with an optional partial coverage. When using this option, a packet is divided into a sensitive part (covered by the checksum) and an insensitive part (not covered by the checksum). Errors in the insensitive part will not cause the packet to be discarded by the transport layer at the receiving end host. When the checksum covers the entire packet, which should be the default, UDP-Lite is semantically identical to UDP.
UDP Lite提供带有可选部分覆盖的校验和。使用此选项时，数据包分为敏感部分（由校验和覆盖）和不敏感部分（不由校验和覆盖）。不敏感部分中的错误不会导致数据包被接收端主机的传输层丢弃。当校验和覆盖整个数据包时（默认情况下），UDP Lite在语义上与UDP相同。
Compared to UDP, the UDP-Lite partial checksum provides extra flexibility for applications that want to define the payload as partially insensitive to bit errors.
与UDP相比，UDP Lite部分校验和为希望将负载定义为对位错误部分不敏感的应用程序提供了额外的灵活性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
The UDP-Lite header is shown in figure 1. Its format differs from UDP in that the Length field has been replaced with a Checksum Coverage field. This can be done since information about UDP packet length can be provided by the IP module in the same manner as for TCP [RFC-793].
UDP Lite头如图1所示。其格式不同于UDP，因为长度字段已替换为校验和覆盖率字段。这是可以做到的，因为关于UDP数据包长度的信息可以由IP模块以与TCP相同的方式提供[RFC-793]。
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+
Figure 1: UDP-Lite Header Format
图1:UDP Lite头格式
The fields Source Port and Destination Port are defined as in the UDP specification [RFC-768]. UDP-Lite uses the same set of port number values assigned by the IANA for use by UDP.
源端口和目标端口字段在UDP规范[RFC-768]中定义。UDP Lite使用IANA为UDP指定的同一组端口号值。
Checksum Coverage is the number of octets, counting from the first octet of the UDP-Lite header, that are covered by the checksum. The UDP-Lite header MUST always be covered by the checksum. Despite this requirement, the Checksum Coverage is expressed in octets from the beginning of the UDP-Lite header in the same way as for UDP. A Checksum Coverage of zero indicates that the entire UDP-Lite packet is covered by the checksum. This means that the value of the Checksum Coverage field MUST be either 0 or at least 8. A UDP-Lite packet with a Checksum Coverage value of 1 to 7 MUST be discarded by the receiver. Irrespective of the Checksum Coverage, the computed Checksum field MUST include a pseudo-header, based on the IP header (see below). UDP-Lite packets with a Checksum Coverage greater than the IP length MUST also be discarded.
校验和覆盖率是校验和覆盖的八位字节数，从UDP Lite头的第一个八位字节开始计算。UDP Lite标头必须始终由校验和覆盖。尽管有此要求，校验和覆盖率从UDP Lite报头开始以八位字节表示，方式与UDP相同。校验和覆盖率为零表示校验和覆盖了整个UDP Lite数据包。这意味着校验和覆盖率字段的值必须为0或至少为8。接收机必须丢弃校验和覆盖率值为1到7的UDP Lite数据包。无论校验和覆盖范围如何，计算的校验和字段必须包括基于IP报头的伪报头（见下文）。校验和覆盖率大于IP长度的UDP Lite数据包也必须丢弃。
The Checksum field is the 16-bit one's complement of the one's complement sum of a pseudo-header of information collected from the IP header, the number of octets specified by the Checksum Coverage (starting at the first octet in the UDP-Lite header), virtually padded with a zero octet at the end (if necessary) to make a multiple of two octets [RFC-1071]. Prior to computation, the checksum field MUST be set to zero. If the computed checksum is 0, it is transmitted as all ones (the equivalent in one's complement arithmetic).
校验和字段是从IP报头收集的信息的伪报头的补码和的16位1的补码，是校验和覆盖率指定的八位字节数（从UDP Lite报头中的第一个八位字节开始），实际上在末尾用零八位字节填充（如有必要）以形成两个八位字节的倍数[RFC-1071]。在计算之前，校验和字段必须设置为零。如果计算的校验和为0，则将其作为所有的校验和（补码算法中的等效值）传输。
Since the transmitted checksum MUST NOT be all zeroes, an application using UDP-Lite that wishes to have no protection of the packet payload should use a Checksum Coverage value of 8. This differs
由于传输的校验和不能全部为零，因此使用UDP Lite的应用程序如果希望不保护数据包有效负载，则应使用校验和覆盖率值8。这是不同的
from the use of UDP over IPv4 in that the minimal UDP-Lite checksum always covers the UDP-Lite protocol header, which includes the Checksum Coverage field.
由于IPv4上使用UDP，最小UDP Lite校验和始终覆盖UDP Lite协议头，其中包括校验和覆盖范围字段。
UDP and UDP-Lite use the same conceptually prefixed pseudo header from the IP layer for the checksum. This pseudo header is different for IPv4 and IPv6. The pseudo header of UDP-Lite is different from the pseudo header of UDP in one way: The value of the Length field of the pseudo header is not taken from the UDP-Lite header, but rather from information provided by the IP module. This computation is done in the same manner as for TCP [RFC-793], and implies that the Length field of the pseudo header includes the UDP-Lite header and all subsequent octets in the IP payload.
UDP和UDP Lite使用来自IP层的相同概念前缀伪报头进行校验和。IPv4和IPv6的此伪标头不同。UDP Lite的伪报头与UDP的伪报头在一个方面不同：伪报头的长度字段的值不是取自UDP Lite报头，而是取自IP模块提供的信息。该计算以与TCP[RFC-793]相同的方式进行，并意味着伪报头的长度字段包括UDP Lite报头和IP有效负载中的所有后续八位字节。
An application interface should allow the same operations as for UDP. In addition to this, it should provide a way for the sending application to pass the Checksum Coverage value to the UDP-Lite module. There should also be a way to pass the Checksum Coverage value to the receiving application, or at least let the receiving application block delivery of packets with coverage values less than a value provided by the application.
应用程序接口应允许与UDP相同的操作。除此之外，它还应该为发送应用程序提供一种将校验和覆盖率值传递给UDP Lite模块的方法。还应该有一种方法将校验和覆盖值传递给接收应用程序，或者至少让接收应用程序阻止覆盖值小于应用程序提供的值的数据包的交付。
It is RECOMMENDED that the default behavior of UDP-Lite be set to mimic UDP by having the Checksum Coverage field match the length of the UDP-Lite packet and verify the entire packet. Applications that wish to define the payload as partially insensitive to bit errors (e.g., error tolerant codecs using RTP [RFC-3550]) should do this by an explicit system call on the sender side. Applications that wish to receive payloads that were only partially covered by a checksum should inform the receiving system by an explicit system call.
建议将UDP Lite的默认行为设置为模拟UDP，方法是使校验和覆盖率字段与UDP Lite数据包的长度匹配，并验证整个数据包。希望将有效负载定义为对位错误部分不敏感的应用程序（例如，使用RTP[RFC-3550]的容错编解码器）应通过发送方的显式系统调用来实现这一点。希望接收校验和仅部分覆盖的有效负载的应用程序应通过显式系统调用通知接收系统。
The characteristics of the links forming an Internet path may vary greatly. It is therefore difficult to make assumptions about the level or patterns of errors that may occur in the corruption insensitive part of the UDP-Lite payload. Applications that use UDP-Lite should not make any assumptions regarding the correctness of the received data beyond the position indicated by the Checksum Coverage field, and should, if necessary, introduce their own appropriate validity checks.
形成因特网路径的链路的特征可能有很大的不同。因此，很难对UDP Lite有效负载的损坏不敏感部分中可能出现的错误级别或模式做出假设。使用UDP Lite的应用程序不应对超出校验和覆盖率字段指示位置的接收数据的正确性做出任何假设，如有必要，应引入自己的适当有效性检查。
As for UDP, the IP module must provide the pseudo header to the UDP-Lite protocol module (known as the UDPLite module). The UDP-Lite pseudo header contains the IP addresses and protocol fields of the IP header, and also the length of the IP payload, which is derived from the Length field in the IP header.
对于UDP，IP模块必须向UDP Lite协议模块（称为UDPLite模块）提供伪报头。UDP Lite伪报头包含IP报头的IP地址和协议字段，以及从IP报头中的长度字段派生的IP有效负载的长度。
The sender IP module MUST NOT pad the IP payload with extra octets, since the length of the UDP-Lite payload delivered to the receiver depends on the length of the IP payload.
发送方IP模块不得使用额外的八位字节填充IP有效负载，因为传递给接收方的UDP Lite有效负载的长度取决于IP有效负载的长度。
The Checksum Coverage field is 16 bits and can represent a Checksum Coverage value of up to 65535 octets. This allows arbitrary checksum coverage for IP packets, unless they are Jumbograms. For Jumbograms, the checksum can cover either the entire payload (when the Checksum Coverage field has the value zero), or else at most the initial 65535 octets of the UDP-Lite packet.
校验和覆盖率字段为16位，最多可表示65535个八位字节的校验和覆盖率值。这允许对IP数据包进行任意校验和覆盖，除非它们是巨型程序。对于巨型程序，校验和可以覆盖整个有效负载（当校验和覆盖字段的值为零时），或者最多覆盖UDP Lite数据包的初始65535个八位字节。
Since UDP-Lite can deliver packets with damaged payloads to an application that wishes to receive them, frames carrying UDP-Lite packets need not be discarded by lower layer protocols when there are errors only in the insensitive part. For a link that supports partial error detection, the Checksum Coverage field in the UDP-Lite header MAY be used as a hint of where errors do not need to be detected. Lower layers MUST use a strong error detection mechanism [RFC-3819] to detect at least errors that occur in the sensitive part of the packet, and discard damaged packets. The sensitive part consists of the octets between the first octet of the IP header and the last octet identified by the Checksum Coverage field. The sensitive part would thus be treated in exactly the same way as for a UDP packet.
由于UDP Lite可以将带有损坏有效负载的数据包发送给希望接收这些数据包的应用程序，因此当只有不敏感部分出现错误时，承载UDP Lite数据包的帧不需要被较低层协议丢弃。对于支持部分错误检测的链接，UDP Lite标头中的校验和覆盖率字段可作为不需要检测错误的位置的提示。较低层必须使用强大的错误检测机制[RFC-3819]，至少检测数据包敏感部分发生的错误，并丢弃损坏的数据包。敏感部分由IP报头的第一个八位字节和校验和覆盖率字段标识的最后一个八位字节之间的八位字节组成。因此，敏感部分的处理方式与UDP数据包的处理方式完全相同。
Link layers that do not support partial error detection suitable for UDP-Lite, as described above, MUST detect errors in the entire UDP-Lite packet, and MUST discard damaged packets [RFC-3819]. The whole UDP-Lite packet is thus treated in exactly the same way as a UDP packet.
如上所述，不支持适用于UDP Lite的部分错误检测的链路层必须检测整个UDP Lite数据包中的错误，并且必须丢弃损坏的数据包[RFC-3819]。因此，整个UDP Lite数据包的处理方式与UDP数据包完全相同。
It should be noted that UDP-Lite would only make a difference to an application if partial error detection, based on the partial checksum feature of UDP-Lite, is implemented also by link layers, as discussed above. Partial error detection at the link layer would only make a difference when implemented over error-prone links.
应该注意的是，如上文所述，如果基于UDP Lite的部分校验和功能的部分错误检测也由链路层实现，则UDP Lite只会对应用程序产生影响。链路层的部分错误检测只有在容易出错的链路上实现时才会起作用。
UDP and UDP-Lite have similar syntax and semantics. Applications designed for UDP may therefore use UDP-Lite instead, and will by default receive the same full packet coverage. The similarities also ease implementation of UDP-Lite, since only minor modifications are needed to an existing UDP implementation.
UDP和UDP Lite具有相似的语法和语义。因此，为UDP设计的应用程序可以改用UDP Lite，并且默认情况下将接收相同的完整数据包覆盖率。这些相似之处还简化了UDP Lite的实现，因为只需对现有UDP实现进行少量修改。
UDP-Lite has been allocated a separate IP protocol identifier, 136 (UDPLite), that allows a receiver to identify whether UDP or UDP-Lite is used. A destination end host that is unaware of UDP-Lite will, in general, return an ICMP "Protocol Unreachable" or an ICMPv6 "Payload Type Unknown" error message (depending on the IP protocol type). This simple method of detecting UDP-Lite unaware systems is the primary benefit of having separate protocol identifiers.
UDP Lite被分配了一个单独的IP协议标识符136（UDPLite），它允许接收方识别是否使用UDP或UDP Lite。不知道UDP Lite的目标端主机通常会返回ICMP“协议不可访问”或ICMPv6“负载类型未知”错误消息（取决于IP协议类型）。这种检测UDP系统的简单方法是使用单独的协议标识符的主要好处。
The remainder of this section provides the rationale for allocating a separate IP protocol identifier for UDP-Lite, rather than sharing the IP protocol identifier with UDP.
本节的其余部分提供了为UDP Lite分配单独的IP协议标识符，而不是与UDP共享IP协议标识符的基本原理。
There are no known interoperability problems between UDP and UDP-Lite if they were to share the protocol identifier with UDP. Specifically, there is no case where a potentially problematic packet is delivered to an unsuspecting application; a UDP-Lite payload with partial checksum coverage cannot be delivered to UDP applications, and UDP packets that only partially fill the IP payload cannot be delivered to applications using UDP-Lite.
如果UDP和UDP Lite要与UDP共享协议标识符，则它们之间不存在已知的互操作性问题。具体地说，不存在将潜在有问题的包交付给不知情的应用程序的情况；具有部分校验和覆盖率的UDP Lite有效负载不能传递给UDP应用程序，并且只能部分填充IP有效负载的UDP数据包不能传递给使用UDP Lite的应用程序。
However, if the protocol identifier were to have been shared between UDP and UDP-Lite, and a UDP-Lite implementation was to send a UDP-Lite packet using a partial checksum to a UDP implementation, the UDP implementation would silently discard the packet, because a mismatching pseudo header would cause the UDP checksum to fail. Neither the sending nor the receiving application would be notified. Potential solutions to this could have been:
但是，如果协议标识符在UDP和UDP Lite之间共享，并且UDP Lite实现使用部分校验和向UDP实现发送UDP Lite数据包，则UDP实现将自动丢弃该数据包，因为不匹配的伪报头将导致UDP校验和失败。发送应用程序和接收应用程序都不会得到通知。可能的解决办法是：
1) explicit application in-band signaling (while not using the partial checksum coverage option) to enable the sender to learn whether the receiver is UDP-Lite enabled or not, or
1) 显式应用带内信令（不使用部分校验和覆盖选项），使发送方能够了解接收方是否启用UDP Lite，或
2) use of out-of-band signaling such as H.323, SIP, or RTCP to convey whether the receiver is UDP-Lite enabled.
2) 使用带外信令（如H.323、SIP或RTCP）来传达接收器是否启用UDP Lite。
Since UDP-Lite has been assigned its own IP protocol identifier, there is no need to consider this possibility of delivery of a UDP-Lite packet to an unsuspecting UDP port.
由于UDP Lite已经被分配了它自己的IP协议标识符，所以不需要考虑将UDP Lite包传送到不怀疑UDP端口的可能性。
The security impact of UDP-Lite is related to its interaction with authentication and encryption mechanisms. When the partial checksum option of UDP-Lite is enabled, the insensitive portion of a packet may change in transit. This is contrary to the idea behind most authentication mechanisms: authentication succeeds if the packet has not changed in transit. Unless authentication mechanisms that operate only on the sensitive part of packets are developed and used, authentication will always fail for UDP-Lite packets where the insensitive part has been damaged.
UDP Lite的安全影响与它与身份验证和加密机制的交互有关。当启用UDP Lite的部分校验和选项时，数据包的不敏感部分可能会在传输过程中发生变化。这与大多数身份验证机制背后的想法相反：如果数据包在传输过程中没有更改，则身份验证成功。除非开发和使用仅在数据包的敏感部分上运行的身份验证机制，否则对于不敏感部分已损坏的UDP Lite数据包，身份验证将始终失败。
The IPsec integrity check (Encapsulation Security Protocol, ESP [RFC-2406], or Authentication Header, AH [RFC-2402]) is applied (at least) to the entire IP packet payload. Corruption of any bit within the protected area will then result in the IP receiver discarding the UDP-Lite packet.
IPsec完整性检查（封装安全协议ESP[RFC-2406]或身份验证头AH[RFC-2402]）至少应用于整个IP数据包有效负载。受保护区域内的任何位损坏将导致IP接收器丢弃UDP Lite数据包。
When IPsec is used with ESP payload encryption, a link can not determine the specific transport protocol of a packet being forwarded by inspecting the IP packet payload. In this case, the link MUST provide a standard integrity check covering the entire IP packet and payload. UDP-Lite provides no benefit in this case.
当IPsec与ESP有效负载加密一起使用时，链路无法通过检查IP数据包有效负载来确定转发数据包的特定传输协议。在这种情况下，链路必须提供覆盖整个IP数据包和有效负载的标准完整性检查。UDP Lite在这种情况下没有任何好处。
Encryption (e.g., at the transport or application levels) may be used. If a few bits of an encrypted packet are damaged, the decryption transform will typically spread errors so that the packet becomes too damaged to be of use. Many encryption transforms today exhibit this behavior. There exist encryption transforms, and stream ciphers, which do not cause error propagation. Note that omitting an integrity check can, under certain circumstances, compromise confidentiality [Bellovin98]. Proper use of stream ciphers poses its own challenges [BB01]. In particular, an attacker can cause predictable changes to the ultimate plaintext, even without being able to decrypt the ciphertext.
可以使用加密（例如，在传输或应用级别）。如果加密数据包的一些位被损坏，解密转换通常会传播错误，从而使数据包损坏得无法使用。如今，许多加密转换都表现出这种行为。存在不会导致错误传播的加密转换和流密码。请注意，在某些情况下，省略完整性检查可能会损害机密性[Bellovin98]。流密码的正确使用带来了自身的挑战[BB01]。特别是，即使无法解密密文，攻击者也可以对最终明文进行可预测的更改。
A new IP protocol number, 136 has been assigned for UDP-Lite. The name associated with this protocol number is "UDPLite". This ensures compatibility across a wide range of platforms, since on some platforms the "-" character may not form part of a protocol entity name.
为UDP Lite分配了一个新的IP协议编号136。与此协议编号关联的名称为“UDPLite”。这确保了跨多种平台的兼容性，因为在某些平台上“-”字符可能不会构成协议实体名称的一部分。
[RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC-768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC-791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC-793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC-1071] Braden, R., Borman, D. and C. Partridge, "Computing the Internet Checksum", RFC 1071, September 1988.
[RFC-1071]Braden，R.，Borman，D.和C.Partridge，“计算互联网校验和”，RFC 10711988年9月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC-2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[Bellovin98] Bellovin, S.M., "Cryptography and the Internet", in Proceedings of CRYPTO '98, August 1988.
[Bellovin 98]Bellovin，S.M.，“密码学与互联网”，载于《1998年密码学会议录》，1988年8月。
[BB01] Bellovin, S. and M. Blaze, "Cryptographic Modes of Operation for the Internet", Second NIST Workshop on Modes of Operation, August 2001.
[BB01]Bellovin，S.和M.Blaze，“互联网的加密操作模式”，NIST第二次操作模式研讨会，2001年8月。
[3GPP] "Technical Specification Group Services and System Aspects; Quality of Service (QoS) concept and architecture", TS 23.107 V5.9.0, Technical Specification 3rd Generation Partnership Project, June 2003.
[3GPP]“技术规范组服务和系统方面；服务质量（QoS）概念和体系结构”，TS 23.107 V5.9.0，技术规范第三代合作伙伴项目，2003年6月。
[H.264] Hannuksela, M.M., Stockhammer, T., Westerlund, M. and D. Singer, "RTP payload Format for H.264 Video", Internet Draft, Work in Progress, March 2003.
[H.264]Hannuksela，M.M.，Stockhammer，T.，Westerlund，M.和D.Singer，“H.264视频的RTP有效载荷格式”，互联网草案，正在进行的工作，2003年3月。
[ILBRC] S.V. Andersen, et. al., "Internet Low Bit Rate Codec", Work in Progress, March 2003.
[ILBRC]S.V.Andersen等人，“互联网低比特率编解码器”，正在进行的工作，2003年3月。
[ISO-14496] ISO/IEC International Standard 1446 (MPEG-4), "Information Technology Coding of Audio-Visual Objects", January 2000.
[ISO-14496]ISO/IEC国际标准1446（MPEG-4），“视听对象的信息技术编码”，2000年1月。
[ITU-H.263] "Video Coding for Low Bit Rate Communication," ITU-T Recommendation H.263, January 1998.
[ITU-H.263]“低比特率通信的视频编码”，ITU-T建议H.263，1998年1月。
[ITU-H.264] "Draft ITU-T Recommendation and Final Draft International Standard of Joint Video Specification", ITU-T Recommendation H.264, May 2003.
[ITU-H.264]“ITU-T建议草案和联合视频规范国际标准最终草案”，ITU-T建议H.264，2003年5月。
[RFC-3819] Karn, Ed., 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.
[RFC-3819]Karn，Ed.，P.，Bormann，C.，Fairhurst，G.，Grossman，D.，Ludwig，R.，Mahdavi，J.，黑山，G.，Touch，J.和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月。
[RFC-3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[RFC-3550]Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 3550，2003年7月。
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC-2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC-2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC-3267] Sjoberg, J., Westerlund, M., Lakeaniemi, A. and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[RFC-3267]Sjoberg，J.，Westerlund，M.，Lakeaniemi，A.和Q.Xie，“自适应多速率（AMR）和自适应多速率宽带（AMR-WB）音频编解码器的实时传输协议（RTP）有效载荷格式和文件存储格式”，RFC 3267，2002年6月。
[LDP99] Larzon, L-A., Degermark, M. and S. Pink, "UDP Lite for Real-Time Multimedia Applications", Proceedings of the IEEE International Conference of Communications (ICC), 1999.
[LDP99]Larzon，L-A.，Degermark，M.和S.Pink，“实时多媒体应用的UDP Lite”，IEEE国际通信会议记录（ICC），1999年。
Thanks to Ghyslain Pelletier for significant technical and editorial comments. Thanks also to Steven Bellovin, Elisabetta Carrara, and Mats Naslund for reviewing the security considerations chapter, and to Peter Eriksson for a language review, thereby improving the clarity of this document.
感谢Ghyslain Pelletier的重要技术和编辑评论。还感谢Steven Bellovin、Elisabetta Carrara和Mats Naslund审查了安全注意事项一章，感谢Peter Erikson审查了语言，从而提高了本文档的清晰度。
Lars-Ake Larzon Department of CS & EE Lulea University of Technology S-971 87 Lulea, Sweden
LCS AK LARZON系CS和EE Lulea技术大学S.91 87 LuleA，瑞典
EMail: lln@csee.ltu.se
EMail: lln@csee.ltu.se
Mikael Degermark Department of Computer Science The University of Arizona P.O. Box 210077 Tucson, AZ 85721-0077, USA
亚利桑那大学计算机科学系MikelDeGeMar系，Tucson，AZ85021-10077，美国
EMail: micke@cs.arizona.edu
EMail: micke@cs.arizona.edu
Stephen Pink The University of Arizona P.O. Box 210077 Tucson, AZ 85721-0077, USA
Stephen Pink，亚利桑那大学邮政信箱210077 Tucson，AZ8521-10077，美国
EMail: steve@cs.arizona.edu
EMail: steve@cs.arizona.edu
Lars-Erik Jonsson Ericsson AB Box 920 S-971 28 Lulea, Sweden
Lars Erik Jonsson Ericsson AB信箱920 S-971 28 Lulea，瑞典
EMail: lars-erik.jonsson@ericsson.com
EMail: lars-erik.jonsson@ericsson.com
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE, UK
英国阿伯丁大学工程系阿伯丁分校
EMail: gorry@erg.abdn.ac.uk
EMail: gorry@erg.abdn.ac.uk
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。