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)
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）（RFC 768）に類似している軽量ユーザーデータグラムプロトコル（UDP-Liteは）、説明するだけでなく、むしろ、配信、部分的に破損したペイロードを持っていることを好むエラーが発生しやすいネットワーク環境でアプリケーションを提供することができます廃棄されたよりも。この機能を使用しない場合は、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
This document describes a new transport protocol, UDP-Lite, (also known as UDPLite). This new protocol is based on three observations:
この文書は（もUDPLiteとして知られている）新しいトランスポートプロトコル、UDPLiteを、説明しています。この新しいプロトコルは、3つの観察に基づいています：
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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パケット長に関する情報はTCP [RFC-793]と同様にIPモジュールによって提供することができるので、これを行うことができます。
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はUDPで使用するためにIANAによって割り当てられたポート番号値の同じセットを使用しています。
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の場合と同じ方法で、UDP-Liteのヘッダの先頭からのオクテットで表現されます。ゼロのチェックサムカバー範囲は全体の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ヘッダから収集された情報の疑似ヘッダの1の補数和の16ビットの1の補数であり、チェックサム・カバレッジによって指定されたオクテットの数が（UDP-Liteのヘッダ内の最初のオクテットから始まります） 、事実上2つのオクテット[RFC-1071]の複数を作製するために端部（必要ならば）でゼロオクテットで埋め。計算前に、チェックサムフィールドはゼロに設定しなければなりません。計算されたチェックサムが0である場合、それはすべてのもの（1の補数演算に相当）として送信されます。
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 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.
送信されたチェックサムはすべてゼロにすることはできませんので、パケットのペイロードの保護がなくなりしたいUDP-Liteの使用するアプリケーションは、これが最小という点ではIPv4上のUDPの使用は異なっ8のチェックサムカバー範囲の値を使用する必要がありますUDP-ライトチェックサムは常にチェックサム・カバレッジ・フィールドを含む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-Liteのパケットの長さと一致し、パケット全体を検証することによってUDPを模倣するために設定することをお勧めします。ビットエラーのような部分的に鈍感ペイロードを定義したいアプリケーション（例えば、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モジュールは、（UDPLiteモジュールとしても知られる）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.
受信機に配信UDP-Liteのペイロードの長さは、IPペイロードの長さに依存するため、送信者のIPモジュールは、余分なオクテットとパッド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の実装に必要とされているので、類似点も、UDP-Liteとの実装を容易にします。
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.
UDPLiteは、受信機がUDPまたはUDPLiteが使用されているかどうかを識別することを可能にする別のIPプロトコル識別子、136（UDPLite）を、割り当てられています。 UDP-Liteとの認識していない先のエンドホストは、一般的には、ICMP「プロトコル到達不能」か（IPプロトコルの種類に応じて）ICMPv6の「ペイロードタイプ不明」のエラーメッセージが返されます。 UDP-Liteは気づかないシステムを検出するこの単純な方法は、別のプロトコル識別子を有することの主な利点です。
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とUDP-Liteの間には、既知の相互運用性の問題はありません。具体的には、潜在的に問題のパケットは、疑いを持たないアプリケーションに配信されることがありません。部分的なチェックサム適用範囲と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）受信機はUDP-Liteが有効であるかどうかを伝えるためにこのようなH.323、SIPまたはRTCPとしてシグナリング帯域外の使用。
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ポートにUDP-Liteのパケットの配達のこの可能性を検討する必要はありません。
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パケットのペイロードに（少なくとも）が印加されます。保護された領域内の任意のビットの破損は、UDP-Liteのパケットを破棄するIP受信機になります。
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.
新しいIPプロトコル番号、136はUDP-Liteのために割り当てられています。このプロトコル番号に関連付けられている名前は、「UDPLite」です。 「 - 」の文字がプロトコルエンティティ名の一部を形成しない場合がありますいくつかのプラットフォーム上でするので、これは、プラットフォームの幅広い互換性が保証されます。
[RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC-768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC-791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC-793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC-1071] Braden, R., Borman, D. and C. Partridge, "Computing the Internet Checksum", RFC 1071, September 1988.
[RFC-1071]ブレーデン、R.、ボーマン、D.およびC.ヤマウズラ、 "インターネットチェックサムの計算"、RFC 1071、1988年9月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[Bellovin98] Bellovin, S.M., "Cryptography and the Internet", in Proceedings of CRYPTO '98, August 1988.
[Bellovin98] Bellovin氏、S.M.、 "暗号とインターネット"、CRYPTO '98、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.ブレイズ、オペレーション、2001年8月のモードに関する第2回ワークショップNIST。
[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、技術仕様書第3世代パートナーシップ・プロジェクト、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.
[264] Hannuksela、M.M.、Stockhammer、T.、ウェスター、M.とD.歌手、 "H.264ビデオのためのRTPペイロードフォーマット"、インターネットドラフト、進歩、2003年3月での作業。
[ILBRC] S.V. Andersen, et. al., "Internet Low Bit Rate Codec", Work in Progress, March 2003.
【ILBRC] S.V.アンデルセン、ら。アル。、「インターネット低ビットレートコーデック」、進歩、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-264]は、ITU-T勧告H.264、2003年5月 "ITU-T勧告及びジョイントビデオ仕様の最終国際規格案案"。
[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]カーン、編、P.、ボルマン、C.、Fairhurst、G.、グロスマン、D.、ルートヴィヒ、R.、Mahdavi、J.、モンテネグロ、G.、タッチ、J.、およびL. 、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.、フレデリック、R.とV. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 3550、2003年7月。
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC-2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC-2406]ケント、S.とR.アトキンソン、 "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.、ウェスター、M.、Lakeaniemi、A.およびQ.謝、「リアルタイムトランスポートプロトコル（RTP）ペイロードフォーマットと適応マルチレート（AMR）と適応のためのストレージのファイル形式マルチレート広帯域（AMR-WB）オーディオコーデック」、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.ピンク、 "リアルタイムマルチメディアアプリケーションのためのUDPライト"、コミュニケーションの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ペルティエに感謝します。それによって、このドキュメントの明瞭度を改善する言語のレビューのためにも、セキュリティ上の考慮事項の章を見直すためのスティーブンBellovin氏、エリザベッタカララ、およびマッツ・ナズランドに、そしてピーター・エリクソンのおかげで、。
Lars-Ake Larzon Department of CS & EE Lulea University of Technology S-971 87 Lulea, Sweden
技術S-971 87ルーレオのCS＆EEルレオ大学、スウェーデンのラーシュ・オーケLarzon部門
EMail: lln@csee.ltu.se
メールアドレス：lln@csee.ltu.se
Mikael Degermark Department of Computer Science The University of Arizona P.O. Box 210077 Tucson, AZ 85721-0077, USA
コンピュータサイエンスのミカエルDegermark部門アリゾナ大学の私書箱ボックス210077ツーソン、AZ 85721から0077、USA
EMail: micke@cs.arizona.edu
メールアドレス：micke@cs.arizona.edu
Stephen Pink The University of Arizona P.O. Box 210077 Tucson, AZ 85721-0077, USA
スティーブン・ピンクアリゾナ大学の私書箱ボックス210077ツーソン、AZ 85721から0077、USA
EMail: steve@cs.arizona.edu
メールアドレス：steve@cs.arizona.edu
Lars-Erik Jonsson Ericsson AB Box 920 S-971 28 Lulea, Sweden
ラース・エリックジョンソン、エリクソンABボックス920のS-971 28ルーレオ、スウェーデン
EMail: lars-erik.jonsson@ericsson.com
メールアドレス：lars-erik.jonsson@ericsson.com
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE, UK
アバディーン、AB24 3UE、英国のエンジニアリング大学のGodred Fairhurst部門
EMail: gorry@erg.abdn.ac.uk
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。