RFC3828 日本語訳
3828 The Lightweight User Datagram Protocol (UDP-Lite). L-A. Larzon,M. Degermark, S. Pink, L-E. Jonsson, Ed., G. Fairhurst, Ed.. July 2004. (Format: TXT=27193 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
ワーキンググループL-Aをネットワークでつないでください。 Larzonはコメントのために以下を要求します。 3828年の技術カテゴリのルーレオ大学: 規格はM.デーゲルマルクS.を追跡します。アリゾナ大学L-Eを突いてください。 エドイェンソン、エドエリクソンG.Fairhurst、アバディーン2004年7月の大学
The Lightweight User Datagram Protocol (UDP-Lite)
ライト級ユーザー・データグラム・プロトコル(UDP-Lite)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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)(RFC768)と同様です)。 この特徴が使用されていないなら、UDP-LiteはUDPと意味的に同じです。
Larzon, et al. Standards Track [Page 1] RFC 3828 UDP-Lite Protocol July 2004
Larzon、他 標準化過程[1ページ]RFC3828UDP-Liteは2004年7月に議定書を作ります。
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語。 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 記述. . . . . . . . . . . . . . . . . . . . . 3 3.1について議定書の中で述べてください。 分野. . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2。 疑似ヘッダー。 . . . . . . . . . . . . . . . . . . . . . 5 3.3. HTTPサーバとNETSCAPE間のインタフェース。 . . . . . . . . . . . . . . . . . 5 3.4. IPインタフェース. . . . . . . . . . . . . . . . . . . . . . 6 3.5。 Jumbograms. . . . . . . . . . . . . . . . . . . . . . . 6 4。 層の問題. . . . . . . . . . . . . . . . . . 6 5を下ろしてください。 UDP. . . . . . . . . . . . . . . . . . . . 7 6との互換性。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 8 7. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 8 8. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1。 引用規格. . . . . . . . . . . . . . . . . . 9 8.2。 有益な参照. . . . . . . . . . . . . . . . . 9 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 10 10。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 11 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 12
1. Introduction
1. 序論
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]、インターネットLow Bit Rate Codec[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).
2番目に、IPトランスミッションを支持するすべてのリンクが強いリンクレイヤ保全チェック(例えば、CRC-32[RFC-3819])を使用するはずです、そして、IP交通にデフォルトでこれを使用しなければなりません。 基本的なリンクがそれを支持すると、あるタイプの交通(例えば、UDP-Lite)は要求されると部分的に破損しているIPパケットが進められることを許可する異なったリンクの振舞い[RFC-3819]の利益を得るかもしれません。 費用と遅れが十分低いポイントで作動するとき、いくつかのラジオ技術(例えば、[3GPP])がこのリンクの振舞いを支持します。 また、誤り傾向があるリンクがパケットの誤りの敏感な部分を意識しているなら、物理的なリンクがこれらの誤りの敏感なバイト(例えば、不平等なForward Error Correctionの使用)の不正の確率を減少させるために、より大きい保護を提供するのも、可能です。
Larzon, et al. Standards Track [Page 2] RFC 3828 UDP-Lite Protocol July 2004
Larzon、他 標準化過程[2ページ]RFC3828UDP-Liteは2004年7月に議定書を作ります。
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.
3番目に、中間層(すなわち、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の部分的なチェックサムは噛み付いている誤りに部分的に神経の鈍くペイロードを定義したがっているアプリケーションに余分な柔軟性を提供します。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-2119]で説明されるように本書では解釈されることであるべきですか?
3. Protocol Description
3. プロトコル記述
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に示されます。 形式はLength野原をChecksum Coverage分野に取り替えたという点においてUDPと異なっています。 TCP[RFC-793]のように同じ方法でIPモジュールでUDPパケット長の情報を提供できるので、これができます。
Larzon, et al. Standards Track [Page 3] RFC 3828 UDP-Lite Protocol July 2004
Larzon、他 標準化過程[3ページ]RFC3828UDP-Liteは2004年7月に議定書を作ります。
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+
0 15 16 31 +--------+--------+--------+--------+ | ソース| 目的地| | ポート| ポート| +--------+--------+--------+--------+ | チェックサム| | | 適用範囲| チェックサム| +--------+--------+--------+--------+ | | : 有効搭載量: | | +-----------------------------------+
Figure 1: UDP-Lite Header Format
図1: UDP-Liteヘッダー形式
3.1. Fields
3.1. 分野
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.
分野のSource PortとDestination Portは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.
チェックサムCoverageはUDP-Liteヘッダーの最初の八重奏から数えるチェックサムでカバーされている八重奏の数です。 いつもチェックサムでUDP-Liteヘッダーを覆っていなければなりません。 この要件にもかかわらず、同様に、Checksum CoverageはUDPのようにUDP-Liteヘッダーの始まりから八重奏で急送されます。 ゼロのChecksum Coverageは、全体のUDP-Liteパケットがチェックサムで覆われているのを示します。 これは、Checksum Coverage分野の値が0か少なくとも8でなければならないことを意味します。 受信機で1〜7のChecksum Coverage値があるUDP-Liteパケットを捨てなければなりません。Checksum Coverageの如何にかかわらず計算されたChecksum分野は疑似ヘッダーを含まなければなりません、IPヘッダーに基づいて(以下を見てください)。 また、Checksum Coverageが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).
Checksum分野はIPヘッダーで集められた情報の疑似ヘッダーの1の補数合計の16ビットの1の補数(Checksum Coverage(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
伝えられたチェックサムがすべてゼロであるはずがないので、パケットペイロードのノー・プロテクションを持ちたがっているUDP-Liteを使用するアプリケーションは8のChecksum Coverage値を使用するべきです。 これは異なります。
Larzon, et al. Standards Track [Page 4] RFC 3828 UDP-Lite Protocol July 2004
Larzon、他 標準化過程[4ページ]RFC3828UDP-Liteは2004年7月に議定書を作ります。
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プロトコルヘッダーを覆っているので、どれがChecksum Coverage分野を含んでいますか?
3.2. Pseudo Header
3.2. 疑似ヘッダー
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モジュールで提供された情報から疑似ヘッダーのLength分野の値を取ります。 この計算は、TCP[RFC-793]のように同じ方法で終わって、疑似ヘッダーのLength分野がIPペイロードにおけるUDP-Liteヘッダーとすべてのその後の八重奏を含んでいるのを含意します。
3.3. Application Interface
3.3. HTTPサーバとNETSCAPE間のインタフェース
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のように同じ操作を許すべきです。 これに加えて、それは送付アプリケーションがChecksum Coverage値をUDP-Liteモジュールに通過する方法を提供するべきです。 また、Checksum Coverage値を受信アプリケーションに通過するか、または適用範囲値が値より少ないアプリケーションブロックパケットの配信がアプリケーションで提供した受信を少なくともさせるそこでは、方法であるべきです。
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.
Checksum Coverage分野がUDP-Liteパケットの長さを合わせて、全体のパケットについて確かめるのを持っていることによってUDP-Liteのデフォルト動きがUDPをまねるように設定されるのは、RECOMMENDEDです。 噛み付いている誤り(例えば、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を使用するアプリケーションは、Checksum Coverage分野で位置を超えた受信データの正当性に関するどんな仮定も示させるべきでなくて、必要なら、それら自身の適切なバリディティチェックを導入するべきです。
Larzon, et al. Standards Track [Page 5] RFC 3828 UDP-Lite Protocol July 2004
Larzon、他 標準化過程[5ページ]RFC3828UDP-Liteは2004年7月に議定書を作ります。
3.4. IP Interface
3.4. IPインタフェース
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ヘッダーのLength分野から得られます)。
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ペイロードの長さによるので。
3.5. Jumbograms
3.5. Jumbograms
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.
Checksum Coverage分野は、16ビットであり、最大65535の八重奏のChecksum Coverage値を表すことができます。 これはIPパケットのための任意のチェックサム適用範囲を許容します、それらがJumbogramsでないなら。Jumbogramsに関して、チェックサムは全体のペイロード(Checksum Coverage分野に値ゼロがあるとき)か高々UDP-Liteパケットの初期の65535の八重奏のどちらかしかカバーできません。
4. Lower Layer Considerations
4. 下層問題
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ヘッダーのChecksum Coverage分野は誤りが検出される必要はないところに関するヒントとして使用されるかもしれません。 下層は、少なくともパケットの敏感な一部に発生する誤りを検出するのに、強い誤り検出メカニズム[RFC-3819]を使用して、破損しているパケットを捨てなければなりません。 敏感な部分はIPヘッダーの最初の八重奏とChecksum Coverage分野によって特定された最後の八重奏の間の八重奏から成ります。 その結果、敏感な部分は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がアプリケーションに相違が生じることに注意されるべきです、上で議論するように。 誤り傾向があるリンクの上に実装されると、リンクレイヤでの部分誤差検出に効果があるだけでしょう。
Larzon, et al. Standards Track [Page 6] RFC 3828 UDP-Lite Protocol July 2004
Larzon、他 標準化過程[6ページ]RFC3828UDP-Liteは2004年7月に議定書を作ります。
5. Compatibility with UDP
5. UDPとの互換性
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は割り当てられたa別々のIPプロトコル識別子、受信機がUDPかUDP-Liteが使用されているかどうか特定できる136歳(UDPLite)です。 一般に、UDP-Liteに気づかない目的地終わりのホストがICMPを返す、「」 ICMPv6「有効搭載量タイプ未知」手の届かないエラーメッセージについて議定書の中で述べてください(IPプロトコルタイプに頼っていて)。 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.
このセクションの残りは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.
UDPとプロトコル識別子を共有するつもりであったなら、UDPとUDP-Liteの間の相互運用性問題は知られていません。 明確に、ケースが全く潜在的に問題の多いパケットが疑わないアプリケーションに提供されるところにありません。 部分的なチェックサム適用範囲があるUDP-LiteペイロードをUDPアプリケーションに提供できません、そして、UDP-Liteを使用することでIPペイロードを部分的にいっぱいにするだけであるUDPパケットはアプリケーションに提供できません。
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-Lite実装がプロトコル識別子がUDPと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.
それ自身のIPプロトコル識別子をUDP-Liteに割り当ててあるので、UDP- Liteパケットの配送のこの可能性を疑わないUDPポートと考える必要は全くありません。
Larzon, et al. Standards Track [Page 7] RFC 3828 UDP-Lite Protocol July 2004
Larzon、他 標準化過程[7ページ]RFC3828UDP-Liteは2004年7月に議定書を作ります。
6. Security Considerations
6. セキュリティ問題
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保全チェック(カプセル化Securityプロトコル、超能力[RFC-2406]、またはAuthentication Header、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が超能力ペイロード暗号化と共に使用されるとき、リンクは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]を引き起こします。 究極の平文と、暗号文を解読することさえできないで、特に、攻撃者は予測できる変化を引き起こす場合があります。
7. IANA Considerations
7. IANA問題
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"です。 これはさまざまなプラットホームの向こう側に互換性を確実にします、「-」キャラクタがいくつかのプラットホームでプロトコル実体名の一部を形成しないかもしれないので。
Larzon, et al. Standards Track [Page 8] RFC 3828 UDP-Lite Protocol July 2004
Larzon、他 標準化過程[8ページ]RFC3828UDP-Liteは2004年7月に議定書を作ります。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC-768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[RFC-791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC-791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC-793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC-1071] Braden, R., Borman, D. and C. Partridge, "Computing the
Internet Checksum", RFC 1071, September 1988.
[RFC-1071] ブレーデンとR.とボーマンとD.とC.ヤマウズラ、「インターネットチェックサムを計算します」、RFC1071、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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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)仕様」、RFC2460、12月1998日
8.2. Informative References
8.2. 有益な参照
[Bellovin98] Bellovin, S.M., "Cryptography and the Internet", in
Proceedings of CRYPTO '98, August 1988.
[Bellovin98]Bellovinと、S.M.と、暗号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.
運転モード(2001年8月)に関する第2[BB01]Bellovin、S.とM.炎、「インターネットへの暗号の運転モード」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] 「仕様書グループサービスとシステム局面」。 「Service(QoS)概念とアーキテクチャの品質」、TS23.107V5.9.0、仕様書の第3Generation Partnership Project、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.
Progress(2003年3月)の[H.264]HannukselaとM.M.とStockhammerとT.とWesterlundとM.とD.Singer、「H.264 VideoのためのRTPペイロードFormat」、インターネットDraft、Work。
[ILBRC] S.V. Andersen, et. al., "Internet Low Bit Rate Codec",
Work in Progress, March 2003.
et[ILBRC]S.V.アンダーセン、アル、「インターネットの低いビット伝送速度コーデック」、Progress、3月2003日のWork
[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月。
Larzon, et al. Standards Track [Page 9] RFC 3828 UDP-Lite Protocol July 2004
Larzon、他 標準化過程[9ページ]RFC3828UDP-Liteは2004年7月に議定書を作ります。
[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がそうするかもしれません。
[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.
Karn(エド)(P.、ボルマン、C.、Fairhurst、G.、グロースマン、D.、ラドウィグ、R.、Mahdavi、J.、モンテネグロ、G.)が触れる[RFC-3819]、J.とL.木、「インターネットサブネットワークデザイナーのためのアドバイス」BCP89、RFC3819(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.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC3550、2003年7月。
[RFC-2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC-2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[RFC-2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC-2406]ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、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] シェーベリ、J.、Westerlund、M.、Lakeaniemi、A.、およびQ.シェ、「リアルタイムのトランスポート・プロトコル(RTP)有効搭載量形式とファイル記憶装置は適応型のマルチレート(AMR)の、そして、適応型のマルチレート広帯域(AMR-WB)にオーディオコーデックをフォーマットします」、RFC3267、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.
コミュニケーション(ICC)のIEEE国際会議、1999年の[LDP99]LarzonとL-A.とデーゲルマルクとM.とS.ピンク、「リアルタイムのマルチメディア応用のためのUDP Lite」という議事。
9. Acknowledgements
9. 承認
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、Elisabettaカラーラとマッツ・ジーターと、そして、言語レビューのためのピーター・エリクソンをありがとうございます、その結果、このドキュメントの明快を改良します。
Larzon, et al. Standards Track [Page 10] RFC 3828 UDP-Lite Protocol July 2004
Larzon、他 標準化過程[10ページ]RFC3828UDP-Liteは2004年7月に議定書を作ります。
10. Authors' Addresses
10. 作者のアドレス
Lars-Ake Larzon Department of CS & EE Lulea University of Technology S-971 87 Lulea, Sweden
Csのラース-Ake Larzon部と技術S-971 87ルーレオ(スウェーデン)のEEルーレオ大学
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
アリゾナ大学私書箱210077ツーソン、アリゾナ85721-0077、マイケルデーゲルマルクコンピュータサイエンス学部米国
EMail: micke@cs.arizona.edu
メール: micke@cs.arizona.edu
Stephen Pink The University of Arizona P.O. Box 210077 Tucson, AZ 85721-0077, USA
スティーブンPinkアリゾナ大学私書箱210077ツーソン、アリゾナ85721-0077、米国
EMail: steve@cs.arizona.edu
メール: steve@cs.arizona.edu
Lars-Erik Jonsson Ericsson AB Box 920 S-971 28 Lulea, Sweden
ラース-エリック・イェンソン・エリクソンAB Box920秒間-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
アバディーンアバディーンのGodred Fairhurst工学部大学、AB24 3UE、イギリス
EMail: gorry@erg.abdn.ac.uk
メール: gorry@erg.abdn.ac.uk
Larzon, et al. Standards Track [Page 11] RFC 3828 UDP-Lite Protocol July 2004
Larzon、他 標準化過程[11ページ]RFC3828UDP-Liteは2004年7月に議定書を作ります。
11. Full Copyright Statement
11. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Larzon, et al. Standards Track [Page 12]
Larzon、他 標準化過程[12ページ]
一覧
スポンサーリンク
