この文書はRFC768の日本語訳です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 翻訳者はこの翻訳文書のメンテナンスを行わないので 翻訳内容に誤りがある場合は勝手に修正して下さい。 この文書の配布は元のＲＦＣ同様に無制限です。
RFC 768 J. Postel
ISI
28 August 1980
User Datagram Protocol
ユーザデータグラムプロトコル
----------------------
Introduction
はじめに
------------
This User Datagram Protocol (UDP) is defined to make available a
datagram mode of packet-switched computer communication in the
environment of an interconnected set of computer networks. This
protocol assumes that the Internet Protocol (IP) [1] is used as the
underlying protocol.
このユーザデータグラムプロトコル（ＵＤＰ）はコンピュータ・ネットワークの
相互に結び付けられた集合の環境でパケット−交換コンピュータ通信のデータグ
ラムモードを利用可能にするために定義される。このプロトコルはインターネッ
ト・プロトコル（ＩＰ）［１］が根本的なプロトコルとして用いられると想定す
る。
This protocol provides a procedure for application programs to send
messages to other programs with a minimum of protocol mechanism. The
protocol is transaction oriented, and delivery and duplicate protection
are not guaranteed. Applications requiring ordered reliable delivery of
streams of data should use the Transmission Control Protocol (TCP) [2].
このプロトコルはアプリケーションプログラムが最小限のプロトコルメカニズム
でメッセージを他のプログラムに送るために手順を供給する。プロトコルはトラ
ンザクション指向である、そして配達と重複保護が保証されない。データのスト
リームの順序づけられた信頼性が高い配送を必要としているアプリケーションが
送信制御プロトコル（ＴＣＰ）［２］を使うべきである。
Format
フォーマット
------
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| | |
| Length | Checksum |
+--------+--------+--------+--------+
|
| data octets ...
+---------------- ...
User Datagram Header Format
ユーザデータグラムヘッダーフォーマット
Fields
フィールド
------
Source Port is an optional field, when meaningful, it indicates the port
of the sending process, and may be assumed to be the port to which a
reply should be addressed in the absence of any other information. If
not used, a value of zero is inserted.
発信ポート（ＳｏｕｒｃｅＰｏｒｔ）はオプションのフィールドである、意味が
ある時、それは、送信プロセスのポートを示す、そして、その他の情報がない場
合に返事を返すべきポートと仮定されるかも知れない。もし使わないなら、ゼロ
の値が差し込まれる。
Destination Port has a meaning within the context of a particular
internet destination address.
着信ポート（ＤｅｓｔｉｎａｔｉｏｎＰｏｒｔ）が指定されたインターネット宛
先アドレスのもとで意味を持っている。
Length is the length in octets of this user datagram including this
header and the data. (This means the minimum value of the length is
eight.)
長さ（Ｌｅｎｇｔｈ）がこのヘッダーとデータを含めてこのユーザデータグラム
のオクテットで長である。（これは長さの最小値が８であることを意味する。）
Checksum is the 16-bit one's complement of the one's complement sum of a
pseudo header of information from the IP header, the UDP header, and the
data, padded with zero octets at the end (if necessary) to make a
multiple of two octets.
チェックサム（Ｃｈｅｃｋｓｕｍ）は、ＩＰヘッダーから作られる疑似ヘッダと
ＵＤＰヘッダーとデータと（もし必要であるなら）２の倍数オクテットにするた
めの終わりのゼロオクテットの、１６ビットの１の補数合計である。
The pseudo header conceptually prefixed to the UDP header contains the
source address, the destination address, the protocol, and the UDP
length. This information gives protection against misrouted datagrams.
This checksum procedure is the same as is used in TCP.
概念的にＵＤＰヘッダーの頭に付ける疑似ヘッダーは発信アドレス、宛先アドレ
ス、プロトコルとＵＤＰ長さを含んでいる。この情報は誤ったデータグラムに対
して保護を与える。このチェックサム手順はＴＣＰで使われるのと同じである。
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| source address |
+--------+--------+--------+--------+
| destination address |
+--------+--------+--------+--------+
| zero |protocol| UDP length |
+--------+--------+--------+--------+
If the computed checksum is zero, it is transmitted as all ones (the
equivalent in one's complement arithmetic). An all zero transmitted
checksum value means that the transmitter generated no checksum (for
debugging or for higher level protocols that don't care).
もし計算されたチェックサムがゼロであるなら、それはすべて１（１の補数算術
での同等物）として伝達される。オールゼロによって伝達されたチェックサム値
が（デバッグのため、あるいはチェックを必要としない上位プロトコルのために
）送信側がチェックサムを生み出さなかったことを意味する。
User Interface
ユーザ・インタフェース
--------------
A user interface should allow
ユーザ・インタフェースが許すべきである
the creation of new receive ports,
新しい着信ポートを作ることをる
receive operations on the receive ports that return the data octets
and an indication of source port and source address,
発信ポートと発信アドレス付きのデータオクテットを返す着信ポートの受信オ
ペレーション、
and an operation that allows a datagram to be sent, specifying the
data, source and destination ports and addresses to be sent.
発信と着信ポートと着信アドレスを指定してデータグラムに送ることをを許す
オペレーション。
IP Interface
ＩＰインタフェース
-------------
The UDP module must be able to determine the source and destination
internet addresses and the protocol field from the internet header. One
possible UDP/IP interface would return the whole internet datagram
including all of the internet header in response to a receive operation.
Such an interface would also allow the UDP to pass a full internet
datagram complete with header to the IP to send. The IP would verify
certain fields for consistency and compute the internet header checksum.
ＵＤＰモジュールはインターネットヘッダーから発信と着信インターネットアド
レスとプロトコルフィールドを決定することができなければならない。あるＵＤ
Ｐ／ＩＰインタフェースは受信オペレーションで、応答としてインターネットヘッ
ダーのすべてを含めてインターネットデータグラム全体を返すであろう。このよ
うなインタフェースは同じくＵＤＰに、ヘッダーを含む完全なインターネットデー
タグラムを、宛先ＩＰまで通過させることを許すであろう。ＩＰは整合性のため
にある特定のフィールドを照合して、そしてインターネットヘッダーチェックサ
ムを計算するであろう。
Protocol Application
プロトコルアプリケーション
--------------------
The major uses of this protocol is the Internet Name Server [3], and the
Trivial File Transfer [4].
このプロトコルの主な用途は、インターネットネームサーバ［３］と単純ファイ
ル転送（ＴｒｉｖｉａｌＦｉｌｅＴｒａｎｓｆｅｒ）［４］である。
Protocol Number
プロトコル番号
---------------
This is protocol 17 (21 octal) when used in the Internet Protocol.
Other protocol numbers are listed in [5].
これは、インターネット・プロトコルで使われる時、プロトコル１７（８進数で
２１）である。他のプロトコル番号が［５］でリストアップされる。
References
参考文献
----------
[1] Postel, J., "Internet Protocol," RFC 760, USC/Information
Sciences Institute, January 1980.
[2] Postel, J., "Transmission Control Protocol," RFC 761,
USC/Information Sciences Institute, January 1980.
[3] Postel, J., "Internet Name Server," USC/Information Sciences
Institute, IEN 116, August 1979.
[4] Sollins, K., "The TFTP Protocol," Massachusetts Institute of
Technology, IEN 133, January 1980.
[5] Postel, J., "Assigned Numbers," USC/Information Sciences
Institute, RFC 762, January 1980.