[要約] RFC 3828は、UDP-Liteプロトコルに関する仕様を提供しており、データの信頼性と完全性を犠牲にすることなく、ネットワーク上の特定のアプリケーションに適した軽量なデータ転送を可能にします。目的は、UDPの柔軟性を保ちつつ、特定のアプリケーションの要件に合わせたデータ転送を実現することです。
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）The Internet Society（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:
このドキュメントでは、新しいトランスポートプロトコル、UDP-Lite（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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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ライトヘッダーを図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ライトヘッダーの最初のオクテットからカウントされるオクテットの数です。UDPライトヘッダーは、常にチェックサムでカバーする必要があります。この要件にもかかわらず、チェックサムのカバレッジは、UDPと同じ方法でUDP-Liteヘッダーの開始からオクテットで表されます。ゼロのチェックサムカバレッジは、UDPライトパケット全体がチェックサムでカバーされていることを示します。これは、チェックサムカバレッジフィールドの値が0または少なくとも8でなければならないことを意味します。チェックサムのカバレッジに関係なく、計算されたチェックサムフィールドには、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ビットの補完、チェックサムカバレッジによって指定されたオクテットの数（UDPライトヘッダーの最初のオクテットから始まる）、端にゼロオクテットで実質的にパッドで（必要に応じて）2オクテットの倍数を作成します[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 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ライトを使用するアプリケーションは、8のチェックサムカバレッジ値を使用する必要があります。Lite Checksumは、チェックサムカバレッジフィールドを含む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の擬似ヘッダーは、1つの方法でUDPの擬似ヘッダーとは異なります。擬似ヘッダーの長さフィールドの値は、UDPライトヘッダーからではなく、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モジュールは擬似ヘッダーを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モジュールは、受信者に配信されるUDP-LITEペイロードの長さが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.
UDP-Liteには、レシーバーがUDPまたはUDP-Liteが使用されているかどうかを識別できる別のIPプロトコル識別子136（UDPlite）が割り当てられています。一般に、UDP-Liteに気付いていない宛先エンドホストは、ICMP「プロトコルの到達不能」またはICMPV6 "ペイロードタイプ不明のエラーメッセージ（IPプロトコルタイプに応じて）を返します。UDP-LITE UNWAREシステムを検出するこの簡単な方法は、個別のプロトコル識別子を持つことの主な利点です。
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.
このセクションの残りの部分は、IPプロトコル識別子をUDPと共有するのではなく、UDP-Liteに個別の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.
Protocol Identifierを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実装に送信することであった場合、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ポートに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の整合性チェック（Cencapsulation Security Protocol、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 791、1981年9月。
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC-793] Postel、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] Braden、R.、Borman、D。、およびC. Partridge、「Internet Checksumのコンピューティング」、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] 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。and R. Hinden、「Internet Protocol、バージョン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。、「暗号化とインターネット」、1988年8月、Crypto '98の議事録。
[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、「インターネットの運用の暗号化モード」、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.
[H.264] Hannuksela、M.M.、Stockhammer、T.、Westerlund、M。、およびD. Singer、「H.264 Video for H.264 VideoのRTPペイロード形式」、Internet Draft、Work in Progress、2003年3月。
[ILBRC] S.V. Andersen, et. al., "Internet Low Bit Rate Codec", Work in Progress, March 2003.
[ilbrc] s.v.アンデルセン、他al。、「インターネット低ビットレートコーデック」、2003年3月、進行中の作業。
[ISO-14496] ISO/IEC International Standard 1446 (MPEG-4), "Information Technology Coding of Audio-Visual Objects", January 2000.
[ISO-14496] ISO/IEC International Standard 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.、Montenegro、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]ケント、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] 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。and Q. Xie、 "リアルタイム輸送プロトコル（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. Pink、「リアルタイムマルチメディアアプリケーションの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 Pelletierに感謝します。また、Steven Bellovin、Elisabetta Carrara、およびMats Naslundのセキュリティに関する考慮事項の章をレビューしてくれたこと、および言語レビューのためにPeter Erikssonに感謝します。
Lars-Ake Larzon Department of CS & EE Lulea University of Technology S-971 87 Lulea, Sweden
CS＆EEルレア工科大学S-971 87 LuleaのLars-Ake Larzon Department Sweden
EMail: lln@csee.ltu.se
Mikael Degermark Department of Computer Science The University of Arizona P.O. Box 210077 Tucson, AZ 85721-0077, USA
ミカエル・デジャーマークコンピュータサイエンス局アリゾナ大学P.O.Box 210077 Tucson、AZ 85721-0077、米国
EMail: micke@cs.arizona.edu
Stephen Pink The University of Arizona P.O. Box 210077 Tucson, AZ 85721-0077, USA
スティーブンピンクアリゾナ大学P.O.Box 210077 Tucson、AZ 85721-0077、米国
EMail: steve@cs.arizona.edu
Lars-Erik Jonsson Ericsson AB Box 920 S-971 28 Lulea, Sweden
Lars-Erik Jonsson Ericsson AB Box 920 S-971 28 Lulea、Sweden
EMail: lars-erik.jonsson@ericsson.com
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE, UK
ゴッドレッドフェアハースト工科大学アバディーン大学アバディーン大学、AB24 3UE、英国
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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。