サイト内関連リンク：RFC 792 ICMP(日本語訳)/RFC 768 UDP(日本語訳)/RFC 1332 IPCP(日本語訳)/RFC 4301 IPsec(日本語訳)
原文：ftp://ftp.rfc-editor.org/in-notes/rfc791.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
ソーシャルブックマーク：
サイト内関連リンク：RFC 792 ICMP(日本語訳)/RFC 768 UDP(日本語訳)/RFC 1332 IPCP(日本語訳)/RFC 4301 IPsec(日本語訳)
DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION
September 1981
prepared for
Defense Advanced Research Projects Agency
Information Processing Techniques Office
1400 Wilson Boulevard
Arlington, Virginia 22209
by
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
This document specifies the DoD Standard Internet Protocol. This document is based on six earlier editions of the ARPA Internet Protocol Specification, and the present text draws heavily from them. There have been many contributors to this work both in terms of concepts and in terms of text. This edition revises aspects of addressing, error handling, option codes, and the security, precedence, compartments, and handling restriction features of the internet protocol. この文書は DoD 標準インターネットプロトコルを規定する。この文書は ARPA インターネットプロトコル仕様の既存の 6 つの文書を元にしており、文章の多くはそれらから引用されている。構想と文章とに関して、多くの貢献者がいた。このバージョンは、アドレッシング・エラー処理・オプションコードの解釈・セキュリティ・優先順位・インターネットプロトコルの制限機能の扱いを改定する。
Jon Postel
Editor
RFC: 791
Replaces: RFC 760
IENs 128, 123, 111,
80, 54, 44, 41, 28, 26
DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION
The Internet Protocol is designed for use in interconnected systems of packet-switched computer communication networks. Such a system has been called a "catenet" [1]. The internet protocol provides for transmitting blocks of data called datagrams from sources to destinations, where sources and destinations are hosts identified by fixed length addresses. The internet protocol also provides for fragmentation and reassembly of long datagrams, if necessary, for transmission through "small packet" networks. インターネットプロトコルは、パケット交換方式のコンピュータ通信ネットワークで相互接続しているシステムにおいて使用されることを目的に設計されている。このようなシステムは "catanet"[1] と呼ばれていた。インターネットプロトコルはデータグラムと呼ばれるデータブロックを送信元から宛先へと転送する方法を提供する。ここで送信元と宛先とは、固定長のアドレスによって識別されるホストである。またインターネットプロトコルは、"小さいパケット(small packet)" のネットワークを通して通信するために必要であれば、長いデータグラムを分割および再構築する方法も提供する。
The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks. There are no mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. The internet protocol can capitalize on the services of its supporting networks to provide various types and qualities of service. インターネットプロトコルは、ネットワークで相互接続されたシステムを通して送信者から受信者へとビットのかたまり(インターネットデータグラム)を配送するために必要とされる機能を提供するために、範囲が特に制限されている。エンドツーエンドのデータの信頼性を上げるためのメカニズム、フロー制御、順序付け、その他のホスト-ホスト間のプロトコルで一般的に見られるサービスはない。さまざまな種類/品質のサービスを提供するために、インターネットプロトコルは自身の提供するネットワークのサービスを利用することができる。
This protocol is called on by host-to-host protocols in an internet environment. This protocol calls on local network protocols to carry the internet datagram to the next gateway or destination host. このプロトコルはインターネット環境におけるホスト-ホスト間のプロトコルによって呼び出される。インターネットデータグラムを次のゲートウェイや宛先ホストへと運ぶために、このプロトコルはローカルネットワークプロトコルを呼び出す。
For example, a TCP module would call on the internet module to take a TCP segment (including the TCP header and user data) as the data portion of an internet datagram. The TCP module would provide the addresses and other parameters in the internet header to the internet module as arguments of the call. The internet module would then create an internet datagram and call on the local network interface to transmit the internet datagram. 例えば TCP モジュールは、インターネットデータグラムのデータ部として TCP セグメント(TCP のヘッダとユーザーデータとを含む)を置くために、インターネットモジュールを呼び出すだろう。その呼び出しの引数として、TCP モジュールはインターネットモジュールに対しインターネットヘッダ内のアドレスと他のパラメータとを提供するたろう。次にインターネットモジュールはインターネットデータグラムを生成し、そのインターネットデータグラムを転送するためにローカルネットワークのインターフェイスを呼び出すだろう。
In the ARPANET case, for example, the internet module would call on a local net module which would add the 1822 leader [2] to the internet datagram creating an ARPANET message to transmit to the IMP. The ARPANET address would be derived from the internet address by the local network interface and would be the address of some host in the ARPANET, that host might be a gateway to other networks. 例えば APRANET の場合、インターネットモジュールは、IMP へ転送される ARPANET メッセージを生成するインターネットデータグラムに 1822 leader [2] を追加するローカルネットモジュールを呼び出すだろう。ARPANET アドレスはローカルネットワークインターフェイスによってインターネットアドレスから取得され、APRANET 内のホストのアドレスになるだろう。そのホストは他のネットワークへのゲートウェイかもしれない。
The internet protocol implements two basic functions: addressing and fragmentation. インターネットプロトコルは 2 つの基本機能、アドレス指定とフラグメント化とを提供する。
The internet modules use the addresses carried in the internet header to transmit internet datagrams toward their destinations. The selection of a path for transmission is called routing. インターネットモジュールはインターネットデータグラムを宛先へと転送するために、インターネットヘッダ内にあるアドレスを使用する。転送のための経路選択はルーティングと呼ばれる。
The internet modules use fields in the internet header to fragment and reassemble internet datagrams when necessary for transmission through "small packet" networks. インターネットモジュールは、"小さいパケット(small packet)" のネットワークを通して通信するのに必要であれば、インターネットヘッダ内のフィールドを使用してインターネットデータグラムを分割・再構築する。
The model of operation is that an internet module resides in each host engaged in internet communication and in each gateway that interconnects networks. These modules share common rules for interpreting address fields and for fragmenting and assembling internet datagrams. In addition, these modules (especially in gateways) have procedures for making routing decisions and other functions. この動作のモデルは、インターネット通信に参加している各ホストとネットワークを相互接続する各ゲートウェイとに、インターネットモジュールが存在するというものである。それらのモジュールは、アドレスフィールドの解釈とインターネットデータグラムの分割・再構成とに関する一般的な規則を共有する。加えてこれらのモジュールは(特にゲートウェイにおいて)、ルーティングを決定するなどの機能を持つ。
The internet protocol treats each internet datagram as an independent entity unrelated to any other internet datagram. There are no connections or logical circuits (virtual or otherwise). インターネットプロトコルは各インターネットデータグラムを他のインターネットデータグラムとは無関係の独立した実体として扱う。関連も論理回路も存在しない(仮想でもそれ以外でも)。
The internet protocol uses four key mechanisms in providing its service: Type of Service, Time to Live, Options, and Header Checksum. インターネットプロトコルはサービスを提供するために 4 つの重要なメカニズムを使用する：サービス種別(Type of Service)、有効期間(Time to Live)、オプション(Options)、ヘッダチェックサム(Header Checksum)である。
The Type of Service is used to indicate the quality of the service desired. The type of service is an abstract or generalized set of parameters which characterize the service choices provided in the networks that make up the internet. This type of service indication is to be used by gateways to select the actual transmission parameters for a particular network, the network to be used for the next hop, or the next gateway when routing an internet datagram. サービス種別(Type of Service)は希望するサービス品質を示すために使用される。サービス種別は、インターネットを構成するネットワークにおいて提供されるサービスの選択を特徴づけるパラメータの、抽象的または汎用的な集合である。このサービス種別の指定は、ゲートウェイが特定のネットワークのための実際の転送パラメータや、次ホップに使用されるネットワーク、インターネットデータグラムをルーティングする場合の次のゲートウェイなどを選択するために使用される。
The Time to Live is an indication of an upper bound on the lifetime of an internet datagram. It is set by the sender of the datagram and reduced at the points along the route where it is processed. If the time to live reaches zero before the internet datagram reaches its destination, the internet datagram is destroyed. The time to live can be thought of as a self destruct time limit. 有効期間(Time to Live)はインターネットデータグラムの寿命の上限を表す。この値は送信者によってセットされ、経路上で処理されるたびに減らされていく。インターネットデータグラムが送信先に届く前に有効期間の値がゼロになった場合、そのインターネットデータグラムは破棄される。有効期間は自爆までのタイムリミットと考えることができる。
The Options provide for control functions needed or useful in some situations but unnecessary for the most common communications. The options include provisions for timestamps, security, and special routing. オプション(Options)は、ごく一般的な通信には不要だが一部の状況で必要とされる制御機能を提供する。このオプションにはタイムスタンプやセキュリティ、特殊なルーティングが含まれる。
The Header Checksum provides a verification that the information used in processing internet datagram has been transmitted correctly. The data may contain errors. If the header checksum fails, the internet datagram is discarded at once by the entity which detects the error. ヘッダチェックサム(Header Checksum)は、インターネットデータグラムの処理に使用された情報が正しく転送されたことの検証を提供する。データはエラーを含んでいる可能性がある。ヘッダチェックサムが間違っている場合、エラーを検出した実体によってそのインターネットデータグラムは即座に破棄される。
The internet protocol does not provide a reliable communication facility. There are no acknowledgments either end-to-end or hop-by-hop. There is no error control for data, only a header checksum. There are no retransmissions. There is no flow control. インターネットプロトコルは信頼できる通信機能を提供しない。エンドツーエンド(ent-to-end)でもホップバイホップ(hop-by-hop)でも受信確認は行われない。エラー制御は無く、あるのはヘッダチェックサムだけである。再送信もないし、フロー制御もない。
Errors detected may be reported via the Internet Control Message Protocol (ICMP) [3] which is implemented in the internet protocol module. 検出されたエラーは、インターネットプロトコルのモジュール内に実装された Internet Control Message Protocol (ICMP) [3] を通して報告されてよい。
The following diagram illustrates the place of the internet protocol in the protocol hierarchy: 以下の図は、プロトコル階層におけるインターネットプロトコルの位置付けを示している：
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | | TFTP| ... | ... |
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | UDP | ... | ... |
+-----+ +-----+ +-----+
| | |
+--------------------------+----+
| Internet Protocol & ICMP |
+--------------------------+----+
|
+---------------------------+
| Local Network Protocol |
+---------------------------+
Protocol Relationships
Figure 1.
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | | TFTP| ... | ... |
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | UDP | ... | ... |
+-----+ +-----+ +-----+
| | |
+--------------------------+----+
| Internet Protocol & ICMP |
+--------------------------+----+
|
+---------------------------+
| Local Network Protocol |
+---------------------------+
プロトコル関連図
図 1.
Internet protocol interfaces on one side to the higher level host-to-host protocols and on the other side to the local network protocol. In this context a "local network" may be a small network in a building or a large network such as the ARPANET. インターネットプロトコルは一方で上位レベルのホスト間プロトコルと接続し、もう一方でローカルネットワークプロトコルと接続している。この文脈における "ローカルネットワーク(local network)" は、ビルの中の小規模なネットワークから ARPANET のような大規模なネットワークまでを意味する。
The model of operation for transmitting a datagram from one application program to another is illustrated by the following scenario: あるアプリケーションから別のアプリケーションへとデータグラムを送信する場合の動作モデルは、以下のようなシナリオで説明される：
We suppose that this transmission will involve one intermediate gateway. この通信には中間ゲートウェイがひとつ含まれると仮定する。
The sending application program prepares its data and calls on its local internet module to send that data as a datagram and passes the destination address and other parameters as arguments of the call. 送信側アプリケーションプログラムはデータを準備し、それをデータグラムとして送信するために自身のローカルのインターネットモジュールを呼び出し、その引数として宛先アドレスなどのパラメータを渡す。
The internet module prepares a datagram header and attaches the data to it. The internet module determines a local network address for this internet address, in this case it is the address of a gateway. It sends this datagram and the local network address to the local network interface. インターネットモジュールはデータグラムのヘッダを準備し、それにデータを付加する。インターネットモジュールは、その宛先インターネットアドレスに必要となるローカルネットワークアドレスを判断する。このケースではこれはゲートウェイのアドレスになる。インターネットモジュールはデータグラムとローカルネットワークアドレスとをローカルネットワークインターフェイスに送信する。
The local network interface creates a local network header, and attaches the datagram to it, then sends the result via the local network. ローカルネットワークインターフェイスはローカルネットワークのヘッダを生成し、それにデータグラムを付加したデータをローカルネットワーク経由で送信する。
The datagram arrives at a gateway host wrapped in the local network header, the local network interface strips off this header, and turns the datagram over to the internet module. The internet module determines from the internet address that the datagram is to be forwarded to another host in a second network. The internet module determines a local net address for the destination host. It calls on the local network interface for that network to send the datagram. データグラムはローカルネットワークヘッダに包まれた状態でゲートウェイホストに到達する。ローカルネットワークインターフェイスはそのヘッダを取り除き、中のデータグラムをインターネットモジュールに引き渡す。インターネットモジュールはそのインターネットアドレスから、そのデータグラムが第二のネットワーク上の別のホストへと転送されるべきであることを知る。インターネットモジュールは宛先ホストのローカルネットアドレスを判断し、データグラムを送信するためにそのネットワークのためのローカルネットワークインターフェイスを呼び出す。
This local network interface creates a local network header and attaches the datagram sending the result to the destination host. ローカルネットワークインターフェイスはローカルネットワークのヘッダを生成し、それにデータグラムを付加し、宛先ホストに送信する。
At this destination host the datagram is stripped of the local net header by the local network interface and handed to the internet module. 宛先ホストにおいて、ローカルネットワークインターフェイスはローカルネットのヘッダを取り除き、データグラムをインターネットモジュールに引き渡す。
The internet module determines that the datagram is for an application program in this host. It passes the data to the application program in response to a system call, passing the source address and other parameters as results of the call. インターネットモジュールは、そのデータグラムがそのホスト上のアプリケーションに向けられたものであることを見つけ出す。インターネットモジュールはシステムコールに応えてアプリケーションプログラムにデータを渡し、呼び出しの結果として送信元アドレスなどのパラメータを引き渡す。
Application Application
Program Program
\ /
Internet Module Internet Module Internet Module
\ / \ /
LNI-1 LNI-1 LNI-2 LNI-2
\ / \ /
Local Network 1 Local Network 2
Transmission Path
Figure 2
アプリケーション アプリケーション
プログラム プログラム
| /
インターネット インターネット インターネット
モジュール モジュール モジュール
| / | /
LNI-1 LNI-1 LNI-2 LNI-2
| / | /
ローカルネットワーク 1 ローカルネットワーク 2
転送経路
図 2
The function or purpose of Internet Protocol is to move datagrams through an interconnected set of networks. This is done by passing the datagrams from one internet module to another until the destination is reached. The internet modules reside in hosts and gateways in the internet system. The datagrams are routed from one internet module to another through individual networks based on the interpretation of an internet address. Thus, one important mechanism of the internet protocol is the internet address. インターネットプロトコルの機能または目的は、相互接続されたネットワークの集合を通してデータグラムを移動させることである。これは、あるインターネットモジュールから別のインターネットモジュールへと、目的地に到達するまでデータグラムを引き渡していくことで実現される。インターネットモジュールはインターネットシステム内のホスト上やゲートウェイ上に存在する。データグラムはインターネットアドレスの解釈に基づき、個々のネットワークを通して、あるインターネットモジュールから別のインターネットモジュールへとルーティングされる。したがってインターネットプロトコルの重要なメカニズムのひとつは、インターネットアドレスである。
In the routing of messages from one internet module to another, datagrams may need to traverse a network whose maximum packet size is smaller than the size of the datagram. To overcome this difficulty, a fragmentation mechanism is provided in the internet protocol. あるインターネットモジュールから別のインターネットモジュールへとメッセージをルーティングするとき、最大パケットサイズがそのデータグラムのサイズより小さいネットワークを横断しなければならない可能性がある。この問題を解決するために、インターネットプロトコルはフラグメント化のメカニズムを提供する。
Gateways implement internet protocol to forward datagrams between networks. Gateways also implement the Gateway to Gateway Protocol (GGP) [7] to coordinate routing and other internet control information. ゲートウェイはネットワーク間でデータグラムを転送するためにインターネットプロトコルを実装する。またゲートウェイは、ルーティングや他のネットワーク間制御情報を調整するためにゲートウェイ間プロトコル(GGP) [7] も実装する。
In a gateway the higher level protocols need not be implemented and the GGP functions are added to the IP module. ゲートウェイ内に上位プロトコルを実装する必要はなく、GGP 機能は IP モジュールに追加される。
+-------------------------------+
| Internet Protocol & ICMP & GGP|
+-------------------------------+
| |
+---------------+ +---------------+
| Local Net | | Local Net |
+---------------+ +---------------+
Gateway Protocols
Figure 3.
+-------------------------------+
| Internet Protocol & ICMP & GGP|
+-------------------------------+
| |
+---------------+ +---------------+
| Local Net | | Local Net |
+---------------+ +---------------+
ゲートウェイプロトコル群
図 3
A summary of the contents of the internet header follows: インターネットヘッダの概要は以下の通り：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram Header
Figure 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL | Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
インターネットデータグラムのヘッダの例
図 4
Note that each tick mark represents one bit position. 1 目盛りが 1 ビットを表していることに注意してほしい。
Bits 0-2: Precedence.
Bit 3: 0 = Normal Delay, 1 = Low Delay.
Bits 4: 0 = Normal Throughput, 1 = High Throughput.
Bits 5: 0 = Normal Relibility, 1 = High Relibility.
Bit 6-7: Reserved for Future Use.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | |
| PRECEDENCE | D | T | R | 0 | 0 |
| | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Precedence
111 - Network Control
110 - Internetwork Control
101 - CRITIC/ECP
100 - Flash Override
011 - Flash
010 - Immediate
001 - Priority
000 - Routine
Bits 0-2: 優先度(Precedence)
Bit 3: 0 = 通常の遅延 1 = 低遅延
(Normal Delay) (Low Delay)
Bits 4: 0 = 通常のスループット 1 = 高スループット
(Normal Throughput) (High Throughput)
Bits 5: 0 = 通常の信頼性 1 = 高信頼性
(Normal Reliability) (High Reliability)
Bit 6-7: 将来のために予約済み
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | | | |
| PRECEDENCE | D | T | R | 0 | 0 |
| | | | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
優先度(Precedence)
111 - ネットワーク制御(Network Control)
110 - ネットワーク間制御(Internetwork Control)
101 - CRITIC/ECP
100 - 瞬時より優先(Flash Override)
011 - 瞬時(Flash)
010 - 即時(Immediate)
001 - 優先(Priority)
000 - 通常(Routine)
Bit 0: reserved, must be zero
Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment.
Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.
0 1 2
+---+---+---+
| | D | M |
| 0 | F | F |
+---+---+---+
Bit 0: 予約済み。ゼロでなければならない。
Bit 1: (DF) 0 = フラグメント化されてよい
(May Fragment)
1 = フラグメント化しない
(Don't Fragment)
Bit 2: (MF) 0 = 最後のフラグメント
(Last Fragment)
1 = 途中のフラグメント
(More Fragments)
0 1 2
+---+---+---+
| | D | M |
| 0 | F | F |
+---+---+---+
1 bit copied flag,
2 bits option class,
5 bits option number.
1 ビット コピーフラグ
2 ビット オプションクラス
5 ビット オプション番号
0 = not copied
1 = copied
0 = コピーされていない(not copied)
1 = コピーされている(copied)
0 = control
1 = reserved for future use
2 = debugging and measurement
3 = reserved for future use
0 = 制御
1 = 将来のために予約済み
2 = デバッグと計測
3 = 将来のために予約済み
CLASS NUMBER LENGTH DESCRIPTION
----- ------ ------ -----------
0 0 - End of Option list. This option occupies only
1 octet; it has no length octet.
0 1 - No Operation. This option occupies only 1
octet; it has no length octet.
0 2 11 Security. Used to carry Security,
Compartmentation, User Group (TCC), and
Handling Restriction Codes compatible with DOD
requirements.
0 3 var. Loose Source Routing. Used to route the
internet datagram based on information
supplied by the source.
0 9 var. Strict Source Routing. Used to route the
internet datagram based on information
supplied by the source.
0 7 var. Record Route. Used to trace the route an
internet datagram takes.
0 8 4 Stream ID. Used to carry the stream
identifier.
2 4 var. Internet Timestamp.
クラス 番号 長さ 説明
------ ------ ----- -----------
0 0 - オプションリスト終了。このオプションは
1 オクテットしか使用せず、長さを持たない。
0 1 - ノーオペレーション。このオプションは
1 オクテットしか使用せず、長さを持たない。
0 2 11 セキュリティ。DOD の要求事項と互換性のある
セキュリティ、区分、ユーザーグループ(TCC)、
取り扱い制限コードを送信するために使用される。
(訳注：DOD＝米国国防総省)
0 3 可変 ルーズソースルーティング。送信元の提供する
情報に基づいてインターネットデータグラムを
ルーティングするために使用される。
0 9 可変 ストリクトソースルーティング。送信元の提供
する情報に基づいてインターネットデータグラ
ムをルーティングするために使用される。
0 7 可変 経路記録。インターネットデータグラムが通っ
た経路を追跡するために使用される。
0 8 4 ストリーム ID。ストリーム識別子を送信するた
めに使用される。
2 4 可変 インターネットタイムスタンプ。
+--------+
|00000000|
+--------+
Type=0
+--------+
|00000000|
+--------+
タイプ=0
This option indicates the end of the option list. This might not coincide with the end of the internet header according to the internet header length. This is used at the end of all options, not the end of each option, and need only be used if the end of the options would not otherwise coincide with the end of the internet header. このオプションはオプションリストの終了を表す。これはインターネットヘッダ長から知ることのできるインターネットヘッダの終了と一致しない可能性がある。これは各オプションの終わりではなく、すべてのオプションの終端に使用され、オプションの終端がインターネットヘッダの終端と一致しない場合にのみ必要である。
May be copied, introduced, or deleted on fragmentation, or for any other reason. フラグメント化またはその他の理由でコピー・導入・削除されてよい。
+--------+
|00000001|
+--------+
Type=1
+--------+
|00000001|
+--------+
タイプ=1
This option may be used between options, for example, to align the beginning of a subsequent option on a 32 bit boundary. このオプションは、オプションの間に置くことで、例えば後続のオプションの開始位置を 32 ビット境界にそろえるために使用される。
May be copied, introduced, or deleted on fragmentation, or for any other reason. フラグメント化またはその他の理由でコピー・導入・削除されてよい。
This option provides a way for hosts to send security, compartmentation, handling restrictions, and TCC (closed user group) parameters. The format for this option is as follows: このオプションは、セキュリティ・区分・取り扱い制限・TCC(クローズドユーザーグループ)パラメータをホストが送信する方法を提供する。このオプションのフォーマットは以下の通り：
+--------+--------+---//---+---//---+---//---+---//---+
|10000010|00001011|SSS SSS|CCC CCC|HHH HHH| TCC |
+--------+--------+---//---+---//---+---//---+---//---+
Type=130 Length=11
+--------+--------+---//---+---//---+---//---+---//---+
|10000010|00001011|SSS SSS|CCC CCC|HHH HHH| TCC |
+--------+--------+---//---+---//---+---//---+---//---+
タイプ=130 レングス=11
00000000 00000000 - Unclassified
11110001 00110101 - Confidential
01111000 10011010 - EFTO
10111100 01001101 - MMMM
01011110 00100110 - PROG
10101111 00010011 - Restricted
11010111 10001000 - Secret
01101011 11000101 - Top Secret
00110101 11100010 - (Reserved for future use)
10011010 11110001 - (Reserved for future use)
01001101 01111000 - (Reserved for future use)
00100100 10111101 - (Reserved for future use)
00010011 01011110 - (Reserved for future use)
10001001 10101111 - (Reserved for future use)
11000100 11010110 - (Reserved for future use)
11100010 01101011 - (Reserved for future use)
00000000 00000000 - Unclassified(機密扱いではない)
11110001 00110101 - Confidential(秘密)
01111000 10011010 - EFTO
10111100 01001101 - MMMM
01011110 00100110 - PROG
10101111 00010011 - Restricted(部外秘)
11010111 10001000 - Secret(機密)
01101011 11000101 - Top Secret(極秘)
00110101 11100010 - (将来のために予約済み)
10011010 11110001 - (将来のために予約済み)
01001101 01111000 - (将来のために予約済み)
00100100 10111101 - (将来のために予約済み)
00010011 01011110 - (将来のために予約済み)
10001001 10101111 - (将来のために予約済み)
11000100 11010110 - (将来のために予約済み)
11100010 01101011 - (将来のために予約済み)
+--------+--------+--------+---------//--------+
|10000011| length | pointer| route data |
+--------+--------+--------+---------//--------+
Type=131
+--------+--------+--------+---------//--------+
|10000011|レングス|ポインタ| 経路情報 |
+--------+--------+--------+---------//--------+
タイプ=131
The loose source and record route (LSRR) option provides a means for the source of an internet datagram to supply routing information to be used by the gateways in forwarding the datagram to the destination, and to record the route information. ルーズソースルーティングおよび経路記録(LSRR)オプションは、インターネットデータグラムの送信元が、宛先へのデータグラム転送時にゲートウェイが使用し経路情報を記録するためルーティング情報を提供する。
The option begins with the option type code. The second octet is the option length which includes the option type code and the length octet, the pointer octet, and length-3 octets of route data. The third octet is the pointer into the route data indicating the octet which begins the next source address to be processed. The pointer is relative to this option, and the smallest legal value for the pointer is 4. このオプションはオプションタイプコードから始まる。第二オクテットはオプションの長さであり、これにはオプションタイプコード、レングス(length)オクテット、ポインタ(pointer)オクテット、(レングス - 3)の経路情報オクテットが含まれる。第三オクテットは、経路情報の中で次に処理されるべき送信元アドレスのオクテット位置を指すポインタである。ポインタはこのオプションからの相対的な値である。したがって正しい値であれば最小でも 4 となる。
A route data is composed of a series of internet addresses. Each internet address is 32 bits or 4 octets. If the pointer is greater than the length, the source route is empty (and the recorded route full) and the routing is to be based on the destination address field. 経路情報は一連のインターネットアドレスから構成される。各インターネットアドレスは 32 ビットまたは 4 オクテットである。ポインタがレングスよりも大きい場合、ソースルートは空(かつ経路記録が満杯)ということであり、ルーティングは宛先アドレスフィールドに基づいて行われる。
If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address replaces the source address just used, and pointer is increased by four. 宛先アドレスフィールドのアドレスに到達し、かつポインタがレングス以下の場合、ソースルート内の次アドレスは宛先アドレスフィールドのアドレスに置き換えられ、経路記録のアドレスは今使用した送信元アドレスに置き換えられ、ポインタは 4 だけ加算される。
The recorded route address is the internet module's own internet address as known in the environment into which this datagram is being forwarded. 経路記録に残されるアドレスは、このデータグラムが転送されてきた環境において知られているインターネットモジュール自身のインターネットアドレスである。
This procedure of replacing the source route with the recorded route (though it is in the reverse of the order it must be in to be used as a source route) means the option (and the IP header as a whole) remains a constant length as the datagram progresses through the internet. ソースルートを経路記録に置き換えるこの手順は(ソースルートとして使用するには順序を逆にしなければならないが)、ネットワーク間を通過してもこのオプション(および IP ヘッダ全体)の長さが変化しないことを意味する。
This option is a loose source route because the gateway or host IP is allowed to use any route of any number of other intermediate gateways to reach the next address in the route. ゲートウェイまたはホストの IP は、経路データ上の次のアドレスに到達するために、任意の数の中間ゲートウェイによる任意の経路を使用することが許される。そのため、このオプションはルーズソースルーティングである。
Must be copied on fragmentation. Appears at most once in a datagram. フラグメント化時にはコピーされなければならない。このオプションはひとつのデータグラムに高々一回だけ現れる。
+--------+--------+--------+---------//--------+
|10001001| length | pointer| route data |
+--------+--------+--------+---------//--------+
Type=137
+--------+--------+--------+---------//--------+
|10001001|レングス|ポインタ| 経路情報 |
+--------+--------+--------+---------//--------+
タイプ=137
The strict source and record route (SSRR) option provides a means for the source of an internet datagram to supply routing information to be used by the gateways in forwarding the datagram to the destination, and to record the route information. ストリクトソースルーティングおよび経路記録(SSRR)は、インターネットデータグラムの送信元が、宛先へのデータグラム転送時にゲートウェイが使用し経路情報を記録するためルーティング情報を提供する。
The option begins with the option type code. The second octet is the option length which includes the option type code and the length octet, the pointer octet, and length-3 octets of route data. The third octet is the pointer into the route data indicating the octet which begins the next source address to be processed. The pointer is relative to this option, and the smallest legal value for the pointer is 4. このオプションはオプションタイプコードで始まる。第二オクテットはオプションの長さであり、これにはオプションタイプコードとレングス(length)オクテット、(レングス - 3)の経路情報オクテットが含まれる。第三オクテットは、経路情報の中で次に処理されるべき送信元アドレスのオクテット位置を指すポインタである。ポインタはこのオプションからの相対的な値である。したがって正しい値であれば最小でも 4 となる。
A route data is composed of a series of internet addresses. Each internet address is 32 bits or 4 octets. If the pointer is greater than the length, the source route is empty (and the recorded route full) and the routing is to be based on the destination address field. 経路情報は一連のインターネットアドレスから構成される。各インターネットアドレスは 32 ビットまたは 4 オクテットである。ポインタがレングスより大きい場合、ソースルートは空(かつ経路記録が満杯)ということであり、ルーティングは宛先アドレスフィールドに基づいて行われる。
If the address in destination address field has been reached and the pointer is not greater than the length, the next address in the source route replaces the address in the destination address field, and the recorded route address replaces the source address just used, and pointer is increased by four. 宛先アドレスフィールドのアドレスに到達し、かつポインタがレングス以下の場合、ソースルート内の次アドレスは宛先アドレスフィールドのアドレスに置き換えられ、経路記録のアドレスは今使用した送信元アドレスに置き換えられ、ポインタは 4 だけ加算される。
The recorded route address is the internet module's own internet address as known in the environment into which this datagram is being forwarded. 経路記録に残されるアドレスは、このデータグラムが転送されてきた環境において知られているインターネットモジュール自身のインターネットアドレスである。
This procedure of replacing the source route with the recorded route (though it is in the reverse of the order it must be in to be used as a source route) means the option (and the IP header as a whole) remains a constant length as the datagram progresses through the internet. ソースルートを経路記録に置き換えるこの手順は(ソースルートとして使用するには順序を逆にしなければならないが)、ネットワーク間を通過してもこのオプション(および IP ヘッダ全体)の長さが変化しないことを意味する。
This option is a strict source route because the gateway or host IP must send the datagram directly to the next address in the source route through only the directly connected network indicated in the next address to reach the next gateway or host specified in the route. ゲートウェイまたはホストの IP は、経路データ上の次のゲートウェイまたはホストに到達するために、次アドレスに示される直結したネットワークだけを通して、ソースルート上の次のアドレスにデータグラムを直接送信しなければならない。そのため、このオプションはストリクトソースルーティングである。
Must be copied on fragmentation. Appears at most once in a datagram. フラグメント化時にはコピーされなければならない。このオプションはひとつのデータグラムに高々一回だけ現れる。
+--------+--------+--------+---------//--------+
|00000111| length | pointer| route data |
+--------+--------+--------+---------//--------+
Type=7
+--------+--------+--------+---------//--------+
|00000111|レングス|ポインタ| 経路情報 |
+--------+--------+--------+---------//--------+
タイプ=7
The record route option provides a means to record the route of an internet datagram. 経路記録オプションは、インターネットダイアグラムの経路を記録する手段を提供する。
The option begins with the option type code. The second octet is the option length which includes the option type code and the length octet, the pointer octet, and length-3 octets of route data. The third octet is the pointer into the route data indicating the octet which begins the next area to store a route address. The pointer is relative to this option, and the smallest legal value for the pointer is 4. このオプションはオプションタイプコードで始まる。第二オクテットはオプションの長さであり、これにはオプションタイプコードとレングス(length)オクテット、ポインタオクテット、(レングス - 3)の経路情報オクテットが含まれる。第三オクテットは経路アドレスを保存するための次の領域を指すポインタである。ポインタはオプションに対して相対的な値である。したがって正しい値であれば最小でも 4 となる。
A recorded route is composed of a series of internet addresses. Each internet address is 32 bits or 4 octets. If the pointer is greater than the length, the recorded route data area is full. The originating host must compose this option with a large enough route data area to hold all the address expected. The size of the option does not change due to adding addresses. The intitial contents of the route data area must be zero. 経路記録は一連のインターネットアドレスから構成される。各インターネットアドレスは 32 ビットまたは 4 オクテットである。ポインタがレングスより大きい場合、経路記録が満杯ということである。送信元ホストは、予想されるすべてのアドレスを保持するのに十分な経路情報領域を持たせてこのオプションを作成しなければならない。このオプションのサイズはアドレスの追加では変化しない。経路情報の初期値はゼロでなければならない。
When an internet module routes a datagram it checks to see if the record route option is present. If it is, it inserts its own internet address as known in the environment into which this datagram is being forwarded into the recorded route begining at the octet indicated by the pointer, and increments the pointer by four. データグラムを中継するとき、インターネットモジュールは経路記録オプションが付加されているかどうかを確認する。もし付加されていれば、インターネットモジュールは自身のインターネットアドレスをポインタで指定されたオクテット位置に挿入し、ポインタに 4 を加算する。ここで挿入されるインターネットアドレスは、データグラムが転送されてきた環境において知られているアドレスである。
If the route data area is already full (the pointer exceeds the length) the datagram is forwarded without inserting the address into the recorded route. If there is some room but not enough room for a full address to be inserted, the original datagram is considered to be in error and is discarded. In either case an ICMP parameter problem message may be sent to the source host [3]. 経路情報の領域が満杯の場合(つまりポインタ位置がレングスを超えている場合)、データグラムは転送されるが経路情報は記録されない。空き領域はあるもののアドレス全体を含めるには不足している場合、元のデータグラムはエラーと見なされ、破棄される。どちらの場合も送信元ホストに ICMP パラメータエラーメッセージが送信されてよい[3]。
Not copied on fragmentation, goes in first fragment only. Appears at most once in a datagram. フラグメント化時にコピーされず、先頭フラグメントにのみ現れる。このオプションはひとつのデータグラムに高々一回だけ現れる。
+--------+--------+--------+--------+
|10001000|00000010| Stream ID |
+--------+--------+--------+--------+
Type=136 Length=4
+--------+--------+--------+--------+
|10001000|00000010| ストリーム ID |
+--------+--------+--------+--------+
タイプ=136 レングス=4
(訳注：レングスの「00000010」は「00000100」の誤りと思われます。)
This option provides a way for the 16-bit SATNET stream identifier to be carried through networks that do not support the stream concept. このオプションは、ストリームの概念をサポートしないネットワークを通して、16 ビットの SATNET ストリーム識別子を伝達する方法を提供する。
Must be copied on fragmentation. Appears at most once in a datagram. フラグメント化時にコピーされなければならない。このオプションはひとつのデータグラムに高々一回だけ現れる。
+--------+--------+--------+--------+
|01000100| length | pointer|oflw|flg|
+--------+--------+--------+--------+
| internet address |
+--------+--------+--------+--------+
| timestamp |
+--------+--------+--------+--------+
| . |
.
.
Type = 68
+--------+--------+--------+--------+
|01000100|レングス|ポインタ|oflw|flg|
+--------+--------+--------+--------+
| インターネットアドレス |
+--------+--------+--------+--------+
| タイムスタンプ |
+--------+--------+--------+--------+
| . |
.
.
タイプ = 68
The Option Length is the number of octets in the option counting the type, length, pointer, and overflow/flag octets (maximum length 40). このオプションのレングスは、タイプ・レングス・ポインタ・オーバーフロー/フラグ(oflw|flg)のオクテット数である(最大長 40)。
The Pointer is the number of octets from the beginning of this option to the end of timestamps plus one (i.e., it points to the octet beginning the space for next timestamp). The smallest legal value is 5. The timestamp area is full when the pointer is greater than the length. ポインタは、このオプションの先頭からタイムスタンプの終端までのオクテット数に 1 を加えた値である(つまり次のタイムスタンプを置く領域の先頭を指す)。正常な場合の最小値は 5 である。ポインタの値がレングスよりも大きい場合、タイムスタンプの領域が満杯であることを表す。
The Overflow (oflw) [4 bits] is the number of IP modules that cannot register timestamps due to lack of space. オーバーフロー(oflw) [4 ビット]は、領域不足のためにタイムスタンプを登録できなかった IP モジュールの数である。
The Flag (flg) [4 bits] values are フラグ(flg) [4 ビット]の値は以下の通り：
The Timestamp is a right-justified, 32-bit timestamp in milliseconds since midnight UT. If the time is not available in milliseconds or cannot be provided with respect to midnight UT then any time may be inserted as a timestamp provided the high order bit of the timestamp field is set to one to indicate the use of a non-standard value. タイムスタンプは右詰めの 32 ビットタイムスタンプであり、UT の深夜零時からの経過ミリ秒を表す。ミリ秒単位を利用できない場合、または UT の深夜零時からの経過時間を提供できない場合、非標準の値が使用されていることを表すためにタイムスタンプフィールドの上位 1 ビットをセットすることを条件に、任意の時刻をタイムスタンプとして挿入することができる。
The originating host must compose this option with a large enough timestamp data area to hold all the timestamp information expected. The size of the option does not change due to adding timestamps. The intitial contents of the timestamp data area must be zero or internet address/zero pairs. 発信ホストは、予期されるすべてのタイムスタンプ情報を保持するのに十分な領域を持たせてこのオプションを生成しなければならない。このオプションのサイズがタイムスタンプの追加によって変更されることはない。タイムスタンプ情報の初期内容は、ゼロ、またはインターネットアドレス/ゼロの組でなければならない。
If the timestamp data area is already full (the pointer exceeds the length) the datagram is forwarded without inserting the timestamp, but the overflow count is incremented by one. タイムスタンプ用の領域がすでに一杯の場合(ポインタがレングスを超えている場合)、データグラムは転送されるが、タイムスタンプは挿入されず、オーバーフローカウントが 1 加算される。
If there is some room but not enough room for a full timestamp to be inserted, or the overflow count itself overflows, the original datagram is considered to be in error and is discarded. In either case an ICMP parameter problem message may be sent to the source host [3]. 空き領域はあるものの完全なタイムスタンプを挿入するには不足している場合、またはオーバーフローカウント自体がオーバーフローする場合、そのデータグラムはエラーと見なされ、破棄される。いずれの場合も、送信元ホストに ICMP パラメータ障害メッセージが送信されてよい[3]。
The timestamp option is not copied upon fragmentation. It is carried in the first fragment. Appears at most once in a datagram. タイムスタンプオプションはフラグメント化時にコピーされず、先頭のフラグメント内に含まれる。このオプションはひとつのデータグラムに高々一回だけ現れる。
The implementation of a protocol must be robust. Each implementation must expect to interoperate with others created by different individuals. While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior. That is, it must be careful to send well-formed datagrams, but must accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear). プロトコル実装は堅牢でなければならない。各実装は、様々な個人が作成した別の実装と相互運用できることを期待されるだろう。本仕様の目的はこのプロトコルを明確化することであるが、異なった解釈をされる可能性もある。一般に実装は、送信時の振る舞いは保守的で、受信時の振る舞いは寛容でなければならない。言い換えると、実装は的確なデータグラムを送信するべきであり、また解釈可能なデータグラムは全て受け入れるべきである(例えば、技術的にはエラーでも意図が明確であればエラーにしないべきである)。
The basic internet service is datagram oriented and provides for the fragmentation of datagrams at gateways, with reassembly taking place at the destination internet protocol module in the destination host. Of course, fragmentation and reassembly of datagrams within a network or by private agreement between the gateways of a network is also allowed since this is transparent to the internet protocols and the higher-level protocols. This transparent type of fragmentation and reassembly is termed "network-dependent" (or intranet) fragmentation and is not discussed further here. 基本的なインターネットサービスはデータグラム指向であり、ゲートウェイでのフラグメンテーションを提供し、宛先ホスト上のインターネットプロトコルモジュールで再構築される。もちろん、インターネットプロトコルおよび上位プロトコルに対して透過的である限り、ネットワーク内またはネットワークのゲートウェイ間のプライベートな合意によるデータグラムのフラグメンテーション・再構築は許される。この透過型のフラグメンテーション・再構築は "ネットワーク依存(network-dependent)" (または イントラネット) のフラグメンテーションと呼ばれるもので、ここではこれ以上議論しない。
Internet addresses distinguish sources and destinations to the host level and provide a protocol field as well. It is assumed that each protocol will provide for whatever multiplexing is necessary within a host. インターネットアドレスは送信元と宛先とをホストレベルで識別し、その上でプロトコルフィールドを提供する。各プロトコルはあるホスト内において必要とされるどのような多重化でも提供すると見なされる。
Address Formats:
High Order Bits Format Class
--------------- ------------------------------- -----
0 7 bits of net, 24 bits of host a
10 14 bits of net, 16 bits of host b
110 21 bits of net, 8 bits of host c
111 escape to extended addressing mode
アドレスフォーマット：
上位ビット フォーマット クラス
---------- ------------------------------------------ -----
0 7 ビットがネットワーク、24 ビットがホスト a
10 14 ビットがネットワーク、16 ビットがホスト b
110 21 ビットがネットワーク、 8 ビットがホスト c
111 拡張アドレッシングモードへのエスケープ
FO - Fragment Offset
IHL - Internet Header Length
DF - Don't Fragment flag
MF - More Fragments flag
TL - Total Length
OFO - Old Fragment Offset
OIHL - Old Internet Header Length
OMF - Old More Fragments flag
OTL - Old Total Length
NFB - Number of Fragment Blocks
MTU - Maximum Transmission Unit
FO - フラグメントオフセット(Fragment Offset)
IHL - インターネットヘッダ長
(Internet Header Length)
DF - ドントフラグメントフラグ
(Don't Fragment flag)
MF - モアフラグメントフラグ(More Fragments flag)
TL - 全長(Total Length)
OFO - 元のフラグメントオフセット
(Old Fragment Offset)
OIHL - 元のインターネットヘッダ長
(Old Internet Header Length)
OMF - 元のモアフラグメントフラグ
(Old More Fragments flag)
OTL - 元の全長(Old Total Length)
NFB - フラグメントブロック数
(Number of Fragment Blocks)
MTU - 最大転送単位(Maximum Transmission Unit)
IF TL =< MTU THEN Submit this datagram to the next step
in datagram processing ELSE IF DF = 1 THEN discard the
datagram ELSE
To produce the first fragment:
(1) Copy the original internet header;
(2) OIHL <- IHL; OTL <- TL; OFO <- FO; OMF <- MF;
(3) NFB <- (MTU-IHL*4)/8;
(4) Attach the first NFB*8 data octets;
(5) Correct the header:
MF <- 1; TL <- (IHL*4)+(NFB*8);
Recompute Checksum;
(6) Submit this fragment to the next step in
datagram processing;
To produce the second fragment:
(7) Selectively copy the internet header (some options
are not copied, see option definitions);
(8) Append the remaining data;
(9) Correct the header:
IHL <- (((OIHL*4)-(length of options not copied))+3)/4;
TL <- OTL - NFB*8 - (OIHL-IHL)*4);
FO <- OFO + NFB; MF <- OMF; Recompute Checksum;
(10) Submit this fragment to the fragmentation test; DONE.
IF TL =< MTU THEN このデータグラムをデータグラム
処理の次のステップに投入する ELSE IF DF = 1 THEN
そのデータグラムを破棄する ELSE
最初のフラグメントを生成する:
(1) 元のインターネットヘッダをコピーする;
(2) OIHL <- IHL; OTL <- TL; OFO <- FO; OMF <- MF;
(3) NFB <- (MTU-IHL*4)/8;
(4) 最初の NFB*8 オクテットをはめ込む;
(5) ヘッダを訂正する:
MF <- 1; TL <- (IHL*4)+(NFB*8);
チェックサムを再計算する;
(6) このフラグメントをデータグラム処理の次の
ステップに投入する;
二番目のフラグメントを生成する:
(7) インターネットヘッダを選択的にコピーする
(一部のオプションはコピーされない。
オプション定義を参照);
(8) 残りのデータを追加する;
(9) ヘッダを訂正する:
IHL <- (((OIHL*4)-(コピーされないオプション
の長さ))+3)/4;
TL <- OTL - NFB*8 - (OIHL-IHL)*4);
FO <- OFO + NFB; MF <- OMF; チェックサムを
再計算する;
(10) このフラグメントをフラグメントテストに投入する;
DONE.
FO - Fragment Offset
IHL - Internet Header Length
MF - More Fragments flag
TTL - Time To Live
NFB - Number of Fragment Blocks
TL - Total Length
TDL - Total Data Length
BUFID - Buffer Identifier
RCVBT - Fragment Received Bit Table
TLB - Timer Lower Bound
FO - フラグメントオフセット(Fragment Offset)
IHL - インターネットヘッダ長
(Internet Header Length)
MF - モアフラグメントフラグ(More Fragments flag)
TTL - 有効期間(Time To Live)
NFB - フラグメントブロック数
(Number of Fragment Blocks)
TL - 全長(Total Length)
TDL - データ全長(Total Data Length)
BUFID - バッファ識別子(Buffer Identifier)
RCVBT - フラグメント受信ビットテーブル
(Fragment Received Bit Table)
TLB - タイマー下限値(Timer Lower Bound)
(1) BUFID <-
source|destination|protocol|identification;
(2) IF FO = 0 AND MF = 0
(3) THEN IF buffer with BUFID is allocated
(4) THEN flush all reassembly for this BUFID;
(5) Submit datagram to next step; DONE.
(6) ELSE IF no buffer with BUFID is allocated
(7) THEN allocate reassembly resources
with BUFID;
TIMER <- TLB; TDL <- 0;
(8) put data from fragment into data buffer with
BUFID from octet FO*8 to
octet (TL-(IHL*4))+FO*8;
(9) set RCVBT bits from FO
to FO+((TL-(IHL*4)+7)/8);
(10) IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
(11) IF FO = 0 THEN put header in header buffer
(12) IF TDL # 0
(13) AND all RCVBT bits from 0
to (TDL+7)/8 are set
(14) THEN TL <- TDL+(IHL*4)
(15) Submit datagram to next step;
(16) free all reassembly resources
for this BUFID; DONE.
(17) TIMER <- MAX(TIMER,TTL);
(18) give up until next fragment or timer expires;
(19) timer expires: flush all reassembly with this BUFID; DONE.
(1) BUFID <- source|destination|protocol|identification;
(2) IF FO = 0 AND MF = 0
(3) THEN IF BUFID のバッファが割り当て済み
(4) THEN この BUFID のためのすべての
再構築を消去する;
(5) データグラムを次のステップに投入する;
DONE.
(6) ELSE IF BUFID のバッファが割り当てられていない
(7) THEN BUFID の再構築リソースを割り当てる;
TIMER <- TLB; TDL <- 0;
(8) フラグメントのデータを、BUFID の
データバッファのオクテット FO*8 から
オクテット (TL-(IHL*4))+FO*8 まで(to)置く;
(9) RCVBT ビットを FO から FO+((TL-(IHL*4)+7)/8
まで(to)セットする;
(10) IF MF = 0 THEN TDL <- TL-(IHL*4)+(FO*8)
(11) IF FO = 0 THEN ヘッダをヘッダバッファに置く
(12) IF TDL # 0
(13) AND 0 から (TDL+7)/8 まで(to)の全 RCVBT
ビットがセットされている
(14) THEN TL <- TDL+(IHL*4)
(15) データグラムを次のステップに
投入する;
(16) この BUFID のための再構築リソースを
全て開放する; DONE.
(17) TIMER <- MAX(TIMER,TTL);
(18) 次のフラグメントまたはタイマーの期限切れ
まで中断する;
(19) タイマーの期限切れ：この BUFID のすべての
再構築を消去する; DONE.
Precedence: 5
Delay: 0
Throughput: 1
Reliability: 1
優先順位(Precedence): 5
遅延(Delay): 0
スループット(Throughput): 1
信頼性(Reliability): 1
The functional description of user interfaces to the IP is, at best, fictional, since every operating system will have different facilities. Consequently, we must warn readers that different IP implementations may have different user interfaces. However, all IPs must provide a certain minimum set of services to guarantee that all IP implementations can support the same protocol hierarchy. This section specifies the functional interfaces required of all IP implementations. あらゆるオペレーティングシステムがさまざまな機能を持つため、IP に対するユーザーインターフェイスの機能的な説明は、よく言って作り話である。そのため私たちは読者に、異なる IP 実装は異なるユーザーインターフェイスを持つ可能性があることを警告しなければならない。しかしながら、すべての IP 実装が同じプロトコル階層をサポートできることを保証するために、すべての IP は最低限のサービス一式を提供しなければならない。このセクションは、すべての IP 実装に必須の機能インターフェイスを規定する。
Internet protocol interfaces on one side to the local network and on the other side to either a higher level protocol or an application program. In the following, the higher level protocol or application program (or even a gateway program) will be called the "user" since it is using the internet module. Since internet protocol is a datagram protocol, there is minimal memory or state maintained between datagram transmissions, and each call on the internet protocol module by the user supplies all information necessary for the IP to perform the service requested. インターネットプロトコルは、ローカルネットワーク側の一方と、上位レベルのプロトコルまたはアプリケーションプログラム側のもう一方とを接続する。上位レベルのプログラムまたはアプリケーションプログラム(またはたとえゲートウェイプログラムでも)はインターネットモジュールを使用(use)するため、以降それらを "ユーザー(user)" と呼ぶ。インターネットプロトコルはデータグラムプロトコルであり、データグラム転送の間に保持されるメモリと状態とは最小限であるため、ユーザーによるインターネットプロトコルモジュールの各呼び出しは、要求されたサービスを実行するのに IP が必要とするすべての情報を提供する。
An Example Upper Level Interface 上位レベルインターフェイスの例
The following two example calls satisfy the requirements for the user to internet protocol module communication ("=>" means returns): 以下の二つの呼び出しの例は、インターネットプロトコルモジュールの通信に対するユーザー要件を満たしている("=>" は戻りを意味する)：
SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)
where: ここで：
src = source address
dst = destination address
prot = protocol
TOS = type of service
TTL = time to live
BufPTR = buffer pointer
len = length of buffer
Id = Identifier
DF = Don't Fragment
opt = option data
result = response
OK = datagram sent ok
Error = error in arguments or local network error
src = 送信元アドレス
dst = 宛先アドレス
prot = プロトコル
TOS = サービス種別
TTL = 有効期間
BufPTR = バッファポインタ
len = バッファ長
Id = 識別子
DF = ドントフラグメント
opt = オプション情報
result = 応答
OK = データグラム送信完了
Error = 引数エラー、またはローカルネットワークエラー
Note that the precedence is included in the TOS and the security/compartment is passed as an option. 優先順位は TOS の中に含まれ、セキュリティ/区分はオプションとして渡されることに注意してほしい。
RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)
where: ここで：
BufPTR = buffer pointer
prot = protocol
result = response
OK = datagram received ok
Error = error in arguments
len = length of buffer
src = source address
dst = destination address
TOS = type of service
opt = option data
BufPTR = バッファポインタ
prot = プロトコル
result = 応答
OK = データグラム受信完了
Error = 引数エラー
len = バッファ長
src = 送信元アドレス
dst = 宛先アドレス
TOS = サービス種別
opt = オプション情報
When the user sends a datagram, it executes the SEND call supplying all the arguments. The internet protocol module, on receiving this call, checks the arguments and prepares and sends the message. If the arguments are good and the datagram is accepted by the local network, the call returns successfully. If either the arguments are bad, or the datagram is not accepted by the local network, the call returns unsuccessfully. On unsuccessful returns, a reasonable report must be made as to the cause of the problem, but the details of such reports are up to individual implementations. ユーザーがデータグラムを送信するとき、すべての引数を提供する SEND 呼び出しを実行する。その呼び出しを受けてインターネットプロトコルモジュールは引数を確認し、メッセージを準備し、送信する。引数が正しく、かつデータグラムがローカルネットワークに受け入れられた場合、その呼び出しは成功を返す。引数が不正、またはデータグラムがローカルネットワークに受け入れられなかった場合、その呼び出しはし失敗を返す。失敗が返される場合、問題の原因についての適切な報告が行われなければならないが、その報告の詳細は個々の実装次第である。
When a datagram arrives at the internet protocol module from the local network, either there is a pending RECV call from the user addressed or there is not. In the first case, the pending call is satisfied by passing the information from the datagram to the user. In the second case, the user addressed is notified of a pending datagram. If the user addressed does not exist, an ICMP error message is returned to the sender, and the data is discarded. ローカルネットワークからインターネットプロトコルモジュールにデータグラムが到着したとき、送信先のユーザーからの未解決の RECV 呼び出しが存在するか存在しないか、どちらかとなる。前者の場合、その未解決の呼び出しはその情報がデータグラムからユーザーに渡されることで解決される。後者の場合、送信先のユーザーは未解決のデータグラムを通知される。送信先のユーザーが存在しない場合、送信元に ICMP エラーメッセージが返され、データは破棄される。
The notification of a user may be via a pseudo interrupt or similar mechanism, as appropriate in the particular operating system environment of the implementation. ユーザーへの通知は、その実装の個々のオペレーティングシステム環境に応じて、擬似割り込みまたはそれに似たメカニズムであってもよい。
A user's RECV call may then either be immediately satisfied by a pending datagram, or the call may be pending until a datagram arrives. その後ユーザーの RECV 呼び出しは、未解決のデータグラムによって即座に解決されるか、データグラムの到着まで保留されてよい。
The source address is included in the send call in case the sending host has several addresses (multiple physical connections or logical addresses). The internet module must check to see that the source address is one of the legal address for this host. 送信側ホストが複数のアドレスを持つ(複数の物理接続または論理接続を持つ)場合、送信呼び出しに送信元アドレスが含まれる。インターネットモジュールは、その送信元アドレスがそのホストの有効なアドレスのひとつであることを確認しなければならない。
An implementation may also allow or require a call to the internet module to indicate interest in or reserve exclusive use of a class of datagrams (e.g., all those with a certain value in the protocol field). また実装は、あるクラスのデータグラム(例えばプロトコルフィールド内にある特定の値を持つすべてのデータグラム)の排他的使用に興味があること、またはそれを予約することを示すために、インターネットモジュールの呼び出しを許可、または必要としてよい。
This section functionally characterizes a USER/IP interface. The notation used is similar to most procedure of function calls in high level languages, but this usage is not meant to rule out trap type service calls (e.g., SVCs, UUOs, EMTs), or any other form of interprocess communication. このセクションは USER/IP インターフェイスの機能的特性を明らかにする。使用される表記法は高水準言語における関数呼び出しの手順に似ているが、この使用法はトラップ型のサービスコール(例えば SVC・UUO・EMT)、または他の形式のプロセス間通信を除外することを意図したものではない。
This is an example of the minimal data carrying internet datagram: これはインターネットデータグラムを運ぶ最小限のデータの例である。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 1 | header checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+
Example Internet Datagram
Figure 5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 | サービス種別 | 全長 = 21 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 = 111 |Flg=0|フラグメントオフセット=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 時間 = 123 |プロトコル = 1 | ヘッダチェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 送信元アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 宛先アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+
インターネットデータグラムの例
図 5.
Note that each tick mark represents one bit position. 各目盛りが 1 ビットを表していることに注意してほしい。
his is a internet datagram in version 4 of internet protocol; the internet header consists of five 32 bit words, and the total length of the datagram is 21 octets. This datagram is a complete datagram (not a fragment). これは IPv4 のインターネットデータグラムであり、インターネットヘッダは 32 ビットワードの 5 ワードから成り、データグラムの全長は 21 オクテットである。このデータグラムは完結したデータグラムである(つまりフラグメントではない)。
In this example, we show first a moderate size internet datagram (452 data octets), then two internet fragments that might result from the fragmentation of this datagram if the maximum sized transmission allowed were 280 octets. この例において私たちは、最初に中程度のサイズのインターネットデータグラム(452 データオクテット)を示す。次に、許可される最大転送サイズが 280 オクテットの場合に、そのデータオクテットのフラグメント化から生じるであろう二つのインターネットフラグメントを示す。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 472 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 6 | header checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram
Figure 6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 | サービス種別 | 全長 = 472 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 = 111 |Flg=0|フラグメントオフセット=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 時間 = 123 |プロトコル = 6 | ヘッダチェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 送信元アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 宛先アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
/ /
/ /
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
インターネットデータグラムの例
図 6.
Now the first fragment that results from splitting the datagram after 256 data octets. 次にこのデータグラムを 256 データオクテットで分割して生じるひとつ目のフラグメントを示す。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 276 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=1| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Fragment
Figure 7.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 | サービス種別 | 全長 = 276 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 = 111 |Flg=1|フラグメントオフセット=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 時間 = 119 |プロトコル = 6 | ヘッダチェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 送信元アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 宛先アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
/ /
/ /
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
インターネットフラグメントの例
図 7.
And the second fragment. 次に二番目のフラグメントを示す。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 |Type of Service| Total Length = 216 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 119 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Fragment
Figure 8.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 5 | サービス種別 | 全長 = 216 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 = 111 |Flg=0|フラグメントオフセット=32|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 時間 = 119 |プロトコル = 6 | ヘッダチェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 送信元アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 宛先アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
/ /
/ /
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
インターネットフラグメントの例
図 8.
Here, we show an example of a datagram containing options: オプションを含むデータグラムの例を示す：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 8 |Type of Service| Total Length = 576 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification = 111 |Flg=0| Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time = 123 | Protocol = 6 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = x | Opt. Len.= 3 | option value | Opt. Code = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Len. = 4 | option value | Opt. Code = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = y | Opt. Len. = 3 | option value | Opt. Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
\ \
\ \
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram
Figure 9.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |IHL= 8 | サービス種別 | 全長 = 576 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 識別子 = 111 |Flg=0|フラグメントオフセット=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 時間 = 123 |プロトコル = 6 | ヘッダチェックサム |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 送信元アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 宛先アドレス |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = x | Opt. Len.= 3 | オプション値 | Opt. Code = x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Len. = 4 | オプション値 | Opt. Code = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt. Code = y | Opt. Len. = 3 | オプション値 | Opt. Code = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
/ /
/ /
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| データ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
インターネットデータグラムの例
図 9.
The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. For example, in the following diagram the octets are transmitted in the order they are numbered. この文書で説明されているヘッダとデータとの転送順序は、オクテットレベルまで決定される。データグラムがオクテットの組を表すとき、それらのオクテットの転送順序は常に通常英語で読まれる場合の順序となる。例えば以下のデータグラムにおいて、各オクテットは番号付けされた順序で転送される。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transmission Order of Bytes
Figure 10.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
バイトの転送順序
図 10.
Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labeled 0 is the most significant bit. For example, the following diagram represents the value 170 (decimal). オクテットが数量を表す場合、常に図の最左ビットが高位または最上位ビットである。つまり、ラベル 0 のビットが最上位ビットである。例えば以下の図は値 170(10 進数) を表す。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Significance of Bits
Figure 11.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
ビットの重み
図 11.
Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first. 同じように複数オクテットのフィールドが数量を表す場合、常にそのフィールド全体の最左ビットが最上位ビットとなる。複数オクテットの数値が転送されるとき、最上位ビットから先に転送される。
[1] Cerf, V., "The Catenet Model for Internetworking," Information Processing Techniques Office, Defense Advanced Research Projects Agency, IEN 48, July 1978.
[2] Bolt Beranek and Newman, "Specification for the Interconnection of a Host and an IMP," BBN Technical Report 1822, Revised May 1978.
[3] Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification," RFC 792, USC/Information Sciences Institute, September 1981.
[4] Shoch, J., "Inter-Network Naming, Addressing, and Routing," COMPCON, IEEE Computer Society, Fall 1978.
[5] Postel, J., "Address Mappings," RFC 796, USC/Information Sciences Institute, September 1981.
[6] Shoch, J., "Packet Fragmentation in Inter-Network Protocols," Computer Networks, v. 3, n. 1, February 1979.
[7] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and Newman, August 1979.
[8] Postel, J., "Service Mappings," RFC 795, USC/Information Sciences Institute, September 1981.
[9] Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences Institute, September 1981.