ネットワークワーキンググループ Internet Engineering Task Force RFC: 1122 R. Braden, Editor 1989年10月 インターネットホストの要件: 通信レイヤー Status of This Memo This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. Distribution of this document is unlimited. 概要 本文書は、インターネットホストソフトウェアの要件を定義、議論する対の RFCの一つである。本RFCは、通信プロトコルのレイヤー、具体的にリンク レイヤー、IPレイヤー、トランスポートレイヤーをカバーする。対のもう片方 のRFC 1123は、アプリケーションプロトコルとサポートプロトコルをカバー する。 目次 1. はじめに ................................................... 5 1.1 インターネットアーキテクチャー ......................... 6 1.1.1 インターネットホスト .............................. 6 1.1.2 アーキテクチャーの想定 ............................ 7 1.1.3 インターネットプロトコルスイート .................. 8 1.1.4 組み込みゲートウェイコード ........................ 10 1.2 一般的な考慮点 ......................................... 12 1.2.1 継続的なインターネットの発展 ...................... 12 1.2.2 ロバストネス原則 .................................. 12 1.2.3 エラーのロギング .................................. 13 1.2.4 環境設定 .......................................... 14 1.3 本文書の読み方 ......................................... 15 1.3.1 構成 .............................................. 15 1.3.2 要件 .............................................. 16 1.3.3 用語 .............................................. 17 1.4 Acknowledgments ........................................ 20 2. リンクレイヤー .............................................. 21 2.1 導入 ................................................... 21 Internet Engineering Task Force [Page 1] RFC1122 INTRODUCTION October 1989 2.2 プロトコルのウォークスルー ............................. 21 2.3 固有の課題 ............................................. 21 2.3.1 トレーラープロトコルのネゴシエーション ............ 21 2.3.2 ARP(アドレス解決プロトコル) ....................... 22 2.3.2.1 ARPキャッシュの妥当性検証 .................... 22 2.3.2.2 ARPパケットのキュー .......................... 24 2.3.3 イーサーネット及びIEEE 802のカプセル化 .......... 24 2.4 リンクレイヤー/インターネットレイヤー間のインターフェース 25 2.5 リンクレイヤーの要件の概要 ............................. 26 3. インターネットレイヤーのプロトコル群 ........................ 27 3.1 導入 .................................................... 27 3.2 プロトコルのウォークスルー ............................. 29 3.2.1 IP(インターネットプロトコル) ....................... 29 3.2.1.1 バージョン番号 ............................... 29 3.2.1.2 チェックサム ................................. 29 3.2.1.3 アドレス体系 ................................. 29 3.2.1.4 フラグメンテーションと再構成 ................. 32 3.2.1.5 識別番号 ..................................... 32 3.2.1.6 タイプオブサービス............................ 33 3.2.1.7 TTL(生存時間) ................................ 34 3.2.1.8 オプション ................................... 35 3.2.2 ICMP(インターネット制御メッセージプロトコル)........ 38 3.2.2.1 宛先到達不能 ................................. 39 3.2.2.2 リダイレクト ................................. 40 3.2.2.3 送信元抑制 ................................... 41 3.2.2.4 時間超過 ..................................... 41 3.2.2.5 パラメーター不正 ............................. 42 3.2.2.6 エコーリクエスト/リプライ .................... 42 3.2.2.7 情報リクエスト/リプライ ...................... 43 3.2.2.8 タイムスタンプリクエスト/リプライ ............ 43 3.2.2.9 アドレスマスクリクエスト/リプライ ............ 45 3.2.3 IGMP(インターネットグループ管理プロトコル) ........ 47 3.3 固有の課題 ............................................. 47 3.3.1 送信データグラムのルーティング .................... 47 3.3.1.1 宛先がローカルかリモートかの判定 ............. 47 3.3.1.2 ゲートウェイの選択 ........................... 48 3.3.1.3 ルートキャッシュ ............................. 49 3.3.1.4 停止ゲートウェイの検知 ....................... 51 3.3.1.5 新しいゲートウェイの選択 ..................... 55 3.3.1.6 初期設定 ..................................... 56 3.3.2 再構成 ............................................ 56 3.3.3 フラグメンテーション .............................. 58 3.3.4 ローカル側のマルチホーム接続 ...................... 60 3.3.4.1 導入 ......................................... 60 3.3.4.2 マルチホーム接続の要件 ....................... 61 3.3.4.3 送信元アドレスの選択 ......................... 64 3.3.5 ソースルート指定されたデータグラムの転送 .......... 65 Internet Engineering Task Force [Page 2] RFC1122 INTRODUCTION October 1989 3.3.6 ブロードキャスト .................................. 66 3.3.7 IPマルチキャスト通信 .............................. 67 3.3.8 エラー報告 ........................................ 69 3.4 インターネットレイヤー/トランスポートレイヤー間の インターフェース ..........................................69 3.5 インターネットレイヤーの要件の概要 ..................... 72 4. トランスポートプロトコル群 .................................. 77 4.1 UDP(ユーザーデータグラムプロトコル) .................... 77 4.1.1 導入 .............................................. 77 4.1.2 プロトコルのウォークスルー ........................ 77 4.1.3 固有の課題 ........................................ 77 4.1.3.1 ポート ....................................... 77 4.1.3.2 IPオプション ................................. 77 4.1.3.3 ICMPメッセージ ............................... 78 4.1.3.4 UDPチェックサム .............................. 78 4.1.3.5 UDPとマルチホーム接続 ........................ 79 4.1.3.6 無効なアドレス ............................... 79 4.1.4 UDP/アプリケーションレイヤー間のインターフェース .. 79 4.1.5 UDPの要件の概要 ................................... 80 4.2 TCP(トランスミッションコントロールプロトコル) .......... 82 4.2.1 導入 .............................................. 82 4.2.2 プロトコルのウォークスルー ........................ 82 4.2.2.1 ウェルノウンポート ........................... 82 4.2.2.2 PUSHフラグの使用 ............................. 82 4.2.2.3 ウインドウサイズ ............................. 83 4.2.2.4 緊急ポインター ............................... 84 4.2.2.5 TCPオプション ................................ 85 4.2.2.6 最大セグメントサイズオプション ............... 85 4.2.2.7 TCPチェックサム .............................. 86 4.2.2.8 TCP接続の状態遷移図 .......................... 86 4.2.2.9 初期シーケンス番号の選択 ..................... 87 4.2.2.10 同時オープンの試み .......................... 87 4.2.2.11 古い重複SYNからの回復 ....................... 87 4.2.2.12 RSTセグメント ............................... 87 4.2.2.13 接続のクローズ .............................. 87 4.2.2.14 データ通信 .................................. 89 4.2.2.15 再送タイムアウト ............................ 90 4.2.2.16 ウインドウの管理 ............................ 91 4.2.2.17 ゼロウインドウの調査 ........................ 92 4.2.2.18 受動的なOPENコール .......................... 92 4.2.2.19 TTL ......................................... 93 4.2.2.20 イベント処理 ................................ 93 4.2.2.21 キュー内で待機するセグメントに対する確認応答 94 4.2.3 固有の課題 ........................................ 95 4.2.3.1 再送タイムアウトの計算 ....................... 95 4.2.3.2 ACKセグメントをいつ送信するか ................ 96 4.2.3.3 ウインドウ更新をいつ送信するか ............... 97 4.2.3.4 データをいつ送信するか ....................... 98 Internet Engineering Task Force [Page 3] RFC1122 INTRODUCTION October 1989 4.2.3.5 TCP接続の障害 ................................ 100 4.2.3.6 TCP接続のキープアライブ ...................... 101 4.2.3.7 TCPとマルチホーム接続 ........................ 103 4.2.3.8 IPオプション ................................. 103 4.2.3.9 ICMPメッセージ ............................... 103 4.2.3.10 リモートアドレスの妥当性検証 ................ 104 4.2.3.11 TCPのトラフィックパターン ................... 104 4.2.3.12 効率 ........................................ 105 4.2.4 TCP/アプリケーションレイヤー間のインターフェース .. 106 4.2.4.1 非同期の通知 ................................. 106 4.2.4.2 タイプオブサービス ........................... 107 4.2.4.3 FLUSHコール .................................. 107 4.2.4.4 マルチホーム接続 ............................. 108 4.2.5 TCPの要件の概要 ................................... 108 5. REFERENCES ................................................. 112 Internet Engineering Task Force [Page 4] RFC1122 INTRODUCTION October 1989 1. はじめに 本文書は、インターネットプロトコルスイートのホストシステム実装の 要件を定義、議論する対のRFCの一つである。本RFCは、通信プロトコルの レイヤー、具体的にリンクレイヤー、IPレイヤー、トランスポートレイヤー をカバーする。対のもう片方のRFCである"インターネットホストの要件: アプリケーションとサポート"[INTRO:1]は、アプリケーションレイヤー プロトコルをカバーする。また、本文書は"インターネットゲートウェイ の要件"[INTRO:2]と併せて読まれるべきである。 これら一連の文書は、インターネット通信ソフトウェアのベンダー、 実装者、利用者らに対して指針を提供することを意図している。これらは、 インターネットの研究コミュニティやベンダーコミュニティのメンバーに よって寄与された多くの技術経験や知見の合意を表現するものである。 本RFCは、インターネットに接続されるホストが使用しなければならない 標準プロトコルを列挙する。また、参照により、これらのプロトコルの 現行仕様を記述するRFCや他の文書も組み入れている。更に、参照される 文書に含まれるエラーを修正し、実装者に向けて付加的な議論と指針を 追加する。 各プロトコルについて、本文書は要件、推奨、任意の選択肢等の明示的な 項目を含む。読者は、本文書記載の要件一覧がそれ単独では不完全である ことを理解しなければならない。インターネットホストに関する要件の すべては、主として標準プロトコルの仕様書で定義されたものに、本RFCに 含まれる修正、改正、補足が加わったものである。 RFCを注意深く読み、インターネットの技術コミュニティとある程度の やりとりを経た後に作成された、通信ソフトウェアの良質な工学的実践に 従う誠実なプロトコル実装は、本文書記載の要件と些細な点でしか違いが 生じないはずである。言い換えると、多くの場合、本文書の"要件"は標準 プロトコル文書において既に記載または暗示されているものであるから、 それらをここに組み入れるのは、ある意味で冗長である。それでも それらを本文書に組み入れた理由は、一部の過去の実装が誤った選択を 行い、相互運用性、パフォーマンス、ロバスト性のいずれかあるいは それらすべてに問題を生じさせたからである。 本文書は、多くの要件と推奨に関する議論と解説を含んでいる。要件の 単純な一覧を提供することは、以下の理由で危険だからである。 ・ 要求される幾つかの機能は他のものよりも重要であり、幾つかの 機能は任意である。 Internet Engineering Task Force [Page 5] RFC1122 INTRODUCTION October 1989 ・ 限定されたコンテキストのために設計された特定のベンダー製品が 標準と異なる仕様を採用する場合があることには正当な理由が あるかもしれない。 しかし、インターネットシステムの多様性と複雑性を踏まえた上で任意の ホストが相互運用するという一般的なゴールを達成するためには、本文書 記載の仕様が守られなければならない。現在の実装の大半がさまざまな形で、 あるものは軽微であるものは大幅に、これらの要件を満たすことに失敗して いるが、この仕様は我々がそこに向かわなければならない理想である。 これらの要件は、現在のインターネットアーキテクチャーのレベルに 基づいている。本文書は、付加的な明確化を提供したり、発展が続いている 仕様に関してその領域における付加的な情報を取り込むために、必要に 応じて更新されるだろう。 この導入セクションは、インターネットアーキテクチャーの手短な概要から 始まる。その理由は、それがホストに関係するからである。次にホスト ソフトウェアベンダーに一般的な勧告を与える。最後に、本文書の残りを 読み進めるにあたっての指針と、若干の用語を提供する。 1.1 インターネットアーキテクチャー インターネットアーキテクチャーと、それをサポートするプロトコル スイートに関する一般的背景と議論は、DDNプロトコルハンドブック [INTRO:3]で得られる。背景については、例えば[INTRO:9]、[INTRO:10]、 [INTRO:11]を参照せよ。参考文献[INTRO:5]はインターネットプロトコル 文書を取得する手順を記述しており、[INTRO:6]はインターネット プロトコル内で割り当てられた番号の一覧を含んでいる。 1.1.1 インターネットホスト ホストコンピューター、あるいは単に"ホスト"と記述されるものは、 通信サービスの最終的な消費者である。ホストは、一般にアプリ ケーションプログラムをユーザーの代わりに実行し、その支援の ためにネットワーク、インターネット通信サービスのどちらか あるいは両方を使用する。インターネットホストは、OSIプロトコル スイート[INTRO:13]で使用される"エンドシステム"の概念に相当する ものである。 インターネット通信システムは、インターネットプロトコルを使用する ホストコンピューター間の通信をサポートするパケット交換型ネット ワークが相互接続されたもので構成されている。ネットワークは、 インターネットコミュニティでは"ゲートウェイ"や"IPルーター"等と 呼ばれ、OSI[INTRO:13]の世界では"IS(Intermediate System)"と 呼ばれるパケット交換コンピューターを使用して相互接続される。 RFC"インターネットゲートウェイの要件"[INTRO:2]は、インターネット ゲートウェイに関する公式仕様を含んでいる。 Internet Engineering Task Force [Page 6] RFC1122 INTRODUCTION October 1989 先に述べたRFC[INTRO:2]と本文書及び対のもう片方の文書[INTRO:1] で、インターネットアーキテクチャーの現在の実現状況に対する ルールを定義する。 インターネットホストは、サイズ、速度、機能の幅が広い。サイズに 関しては、小型のマイクロコンピューターからワークステーション、 メインフレーム、スーパーコンピューターにまで及ぶ。機能に関しては、 (ターミナルサーバーのような)専用ホストから、多様なオンライン ネットワークサービス、典型的にはリモートログイン、ファイル転送、 電子メール等を含む包括的なサービスを提供するホストにまで及ぶ。 ホストが同じネットワークまたは違うネットワークへの二つ以上の インターフェースを持つ場合、そのホストは一般にマルチホーム であるという。"用語"については、セクション1.3.3を参照せよ。 (訳註: 本段落は Errata ID: 4446 を反映している)。 1.1.2 アーキテクチャーの想定 現行のインターネットアーキテクチャーは、通信システムに関する 一連の想定に基づいている。その想定の中でホストに最も関連する ものは以下の通りである。 (a) インターネットはネットワークのネットワークである 各ホストは、幾つかの特定のネットワークに直接接続される。 一方で、インターネットへの接続は概念的なものに過ぎない。 同じネットワーク上にある2台のホストは、遠く離れたネット ワーク上にあるホストと通信する場合と同じプロトコル群を 使用して相互に通信する。 (b) ゲートウェイは接続の状態情報を維持しない 通信システムのロバスト性を改善するため、ゲートウェイは状態を 持たないものとして設計されており、各IPデータグラムは、他の データグラムとは独立に転送される。そのため、ゲートウェイや ネットワークに影響する障害が発生しても、冗長なパスを開拓 してロバストなサービスを提供できるようになっている。 エンドツーエンドのフロー制御と信頼性のために要求される すべての状態情報は、ホスト側、具体的にトランスポートレイヤーや アプリケーションプログラムの中で実装される。従って、 すべての接続制御情報は、通信のエンドポイントと同じ場所に配置 されるので、エンドポイントの障害が発生した場合にしか消失 しない。 (c) ルーティングの複雑さはゲートウェイに留めるべきである ルーティングは複雑で難解な問題であり、その処理はホストでは なくゲートウェイによって行われるべきである。 Internet Engineering Task Force [Page 7] RFC1122 INTRODUCTION October 1989 重要な目的は、今後も避けがたいインターネットルーティング アーキテクチャーの発展によって生じる変更からホストソフト ウェアを隔離することである。 (d) システムは幅広いネットワークの変動に寛容でなければならない インターネットの設計の基本的な目標は、帯域、遅延、パケット 消失、パケット順序の変動、最大パケットサイズといったネット ワーク特性をそれぞれ幅広い度合で許容することである。もう 一つの目標は、個々のネットワーク、ゲートウェイ、ホストの 障害に対し、まだ利用可能な帯域を何であれ使用することで ロバスト性を提供することである。最後に、ゴールは完全な "オープンシステムの相互接続"である。具体的に、インターネット ホストは、他のあらゆるインターネットホストと多様なインター ネットパスを通してロバストかつ効率的に相互運用できなければ ならない。 ホスト実装者は、あまり意欲的でないゴールに向けて設計をする こともあった。例えば、LAN環境は通常インターネットよりは総じて 条件が緩やかである。LANはパケット消失率が低く、遅延も少なく、 パケットの順序入れ替えが起きることもない。一部のベンダーは、 シンプルなLAN環境でなら十分機能するが、一般的な相互運用では うまく動作しないホスト実装を配備してきた。そういったベンダー は、限定されたLANマーケットにおいてはそのような製品が経済的 なのだと正当化している。しかし、隔離されたLANが長期間隔離 されたままになることは滅多にない。それらはすぐに互いに ゲートウェイ接続され、組織規模のインターネットに接続され、 最終的にはグローバルインターネットシステムに接続される。結局、 顧客もベンダーも、不完全または標準を満たさないインターネット ソフトウェアからは便益を得られない。 本文書で詳細が記述される要件は、任意のインターネットパスを 介して完全な相互運用が行える、すべての機能をサポートする インターネットホストに向けて設計されている。 1.1.3 インターネットプロトコルスイート インターネットシステムを使用して通信を行うため、ホストはインター ネットプロトコルスイートを構成する階層化されたプロトコル一式 を実装しなければならない。典型的な場合、ホストは各レイヤーで 少なくとも一つのプロトコルを実装しなければならない。 インターネットアーキテクチャーで使用されるプロトコルレイヤーは 以下に示す通りである[INTRO:4]。 ・ アプリケーションレイヤー Internet Engineering Task Force [Page 8] RFC1122 INTRODUCTION October 1989 アプリケーションレイヤーは、インターネットプロトコル スイートの最上位レイヤーである。インターネットスイートは アプリケーションレイヤーを更に分割はしないが、インター ネットアプリケーションレイヤープロトコルの一部は内部に 幾つかのサブレイヤー構造を含む。インターネットスイートの アプリケーションレイヤーは、OSI参照モデルの上位二つの レイヤー、プレゼンテーションレイヤーとアプリケーション レイヤーの機能を本質的に統合したものである。 我々は、アプリケーションレイヤープロトコルを2種類に分類 する。一つはユーザーに直接サービスを提供するユーザー プロトコルで、もう一つは一般的なシステム機能を提供する サポートプロトコルである。ユーザープロトコルとサポート プロトコルに関する要件は、対のもう片方のRFC[INTRO:1]で 得られる。 最も一般的なインターネットユーザープロトコルは以下の通り である。 ・ Telnet (リモートログイン) ・ FTP (ファイル転送) ・ SMTP (電子メール配送) 他にも標準化された多数のユーザープロトコルが存在し[INTRO:4]、 プライベートユーザープロトコルも多数存在する。 サポートプロトコルはホスト名変換、ブート、管理等に使用 されるもので、SNMP、BOOTP、RARP、DNS(Domain Name System) プロトコル等を含む。 ・ トランスポートレイヤー トランスポートレイヤーは、エンドツーエンドの通信サービスを アプリケーションに提供する。現在、以下に示す二つの主要な トランスポートレイヤープロトコルが存在する。 ・ TCP(転送制御プロトコル) ・ UDP(ユーザーデータグラムプロトコル) TCPは、信頼性のあるコネクション指向型のトランスポート サービスで、エンドツーエンドの信頼性、順序に従う再整列、 フロー制御等を提供する。UDPはコネクションレスな("データ グラム")トランスポートサービスである。 他のトランスポートプロトコルも研究コミュニティによって 開発されてきており、公式な一連のインターネットトランス ポートプロトコルは将来拡張されるかもしれない。 トランスポートレイヤープロトコルはチャプター4で議論される。 Internet Engineering Task Force [Page 9] RFC1122 INTRODUCTION October 1989 ・ インターネットレイヤー すべてのインターネットトランスポートプロトコルは、送信元ホスト から宛先ホストまでデータを配送するために、インターネット プロトコル(IP)を使用する。IPはコネクションレスな、または データグラム型のインターネットワークサービスであり、エンド ツーエンドのデータ配送保証を提供しない。従って、IP データグラムは宛先ホストに到着する際に壊れていたり、重複 して届いたり、順序が入れ替わって届いたりする。あるいは全く 届かないこともある。IPよりも上のレイヤーは、信頼性のある 配送サービスが要求される場合に、それを提供する責任を持つ。 IPプロトコルは、アドレス体系、タイプオブサービスの指定、 フラグメンテーションと再構成、セキュリティ情報等の提供を含む。 IPプロトコルのデータグラム型の特性あるいはコネクションレス な特性は、インターネットアーキテクチャーの基本的かつ固有の 特性である。インターネットIPは、OSIコネクションレスネット ワークプロトコル[INTRO:12]のモデルであった。 ICMPは制御プロトコルで、IPの不可欠な部分と考えられているが、 アーキテクチャー的にはIPより上のレイヤーに位置している。つまり、 ICMPは自身のデータをエンドツーエンドで配送するにあたり、 TCPやUDPといったトランスポートプロトコルがそうするようにIPを 使用する。ICMPはエラー通知、ふくそう通知、第1ホップのゲート ウェイのリダイレクトを提供する。 IGMPはインターネットレイヤーのプロトコルで、IPマルチキャスト 通信の動的なホストグループ確立のために使用される。 インターネットレイヤーのプロトコルに属するIP、ICMP、IGMPは チャプター3で議論される。 ・ リンクレイヤー 直接接続されたネットワーク上で通信するために、ホストは そのネットワークとのインターフェース接続で使用される通信 プロトコルを実装しなければならない。その通信プロトコルを リンクレイヤープロトコルまたはメディアアクセスレイヤー プロトコルと呼ぶ。 多様な異なるネットワーク種別に対応する、幅広いリンク レイヤープロトコルが存在する。チャプター2を参照せよ。 1.1.4 組み込みゲートウェイコード 一部のインターネットホストソフトウェアは、組み込みゲートウェイ コードを含んでいる。 Internet Engineering Task Force [Page 10] RFC1122 INTRODUCTION October 1989 そのようなホストは、アプリケーションレイヤーの機能を実行する 一方で、パケットをゲートウェイのように転送することもできる。 そのような二つの機能を備えたシステムは、ゲートウェイの機能に ついてはゲートウェイの要件に関するRFC[INTRO:2]に従わなければ ならず、ホストの機能については本文書に従わなければならない。 すべての重複する事項は、二つの仕様で一致しているはずである。 組み込みゲートウェイ機能については、インターネットコミュニティ でも幅広い意見が存在する。主要な論点は以下の通りである。 ・ 賛成: ネットワーク接続が非公式なものであったり、隔離された インターネットであるようなローカルなネットワーク環境に おいては、既存のホストシステムをゲートウェイとして使用 できれば、便利であり経済的だろう。 組み込みゲートウェイ機能に関してはアーキテクチャー的な 論点も存在する。マルチホーム接続は当初予測されていたよりも はるかに一般的なものになっているが、マルチホーム接続は、 ホストに対してあたかもゲートウェイであるかのような ルーティングの意思決定を強制する。マルチホームなホストが 組み込みゲートウェイ機能を含んでいれば、ルーティングに 関する完全な知識を保持することになるので、より最適な ルーティングの意思決定ができるようになる。 ・ 反対: ゲートウェイアルゴリズム及びプロトコルは依然として 変更の途上であり、インターネットシステムがより大規模に成長 するにつれて今後も変更が続くだろう。一般的なゲートウェイ 機能をホストのIPレイヤーに取り込む試みは、ホストシステム の管理者にこれらの(頻繁に生じる)変更の追従を強いることに なる。また、ゲートウェイ実装をより大規模にプールすると、 変更の調整がより難しくなる。最後に、ゲートウェイのIPレイヤー はホストのIPレイヤーよりも若干複雑であるため、実装タスク と運用タスクがより複雑になる。 加えて、一部のホストの運用方式は、安定かつロバストな ゲートウェイサービスを提供するには不適切である。 これらの観点のどちらにも考慮すべき価値がある。結論を一つ引き出す ことができるだろう。つまり、ホストの管理者は、与えられたホスト をゲートウェイとして動作させるかどうかの制御を意識しなければ ならない。詳細な要件についてはセクション3.1を参照せよ。 Internet Engineering Task Force [Page 11] RFC1122 INTRODUCTION October 1989 1.2 一般的な考慮点 インターネットホストソフトウェアのベンダーが経験を通して学び 取った、そして新たなベンダーが真剣に考慮すべき重要な知見が 二つある。 1.2.1 継続的なインターネットの発展 インターネットが膨大な規模で成長したことで、データグラム ベースの大規模なパケット通信システムにおける管理とスケールの 問題が露呈した。これらの問題は対処中であり、結果として本文書 に記述される仕様も発展し続けるだろう。これらの変更は注意深く 立案され制御されるだろう。変更の立案にはベンダーとネットワーク 運用に責任を持つ組織が多数参加するからである。 開発、発展、改訂は、今日のコンピューターネットワークプロトコル の特徴であり、この状況は今後数年は持続する。ベンダーがインター ネットプロトコルスイート(あるいは他のどのようなプロトコル スイートであっても!)用のコンピューターの通信ソフトウェアを 開発しており、後に仕様変更に対応した保守、更新に失敗すると、 不幸な顧客の行列を残すことになるだろう。インターネットは大規模 な通信ネットワークであり、ユーザーは日常的にインターネットを 通して連絡を取っている。経験によれば、ベンダーソフトウェアの 欠陥に関する知識は、インターネット技術コミュニティを通して 短時間で伝播することが分かっている。 1.2.2 ロバストネス原則 プロトコルの各レイヤーにおいて、それを適用することでロバスト性 と相互運用性に莫大な便益をもたらし得る一般的なルールが存在する [IP:1]。それは以下のようなものである。 "受信するものに対しては寛容であれ。 送信するものに対しては保守的であれ" ソフトウエアは、想定されるエラーそれぞれについて、どんなに あり得なさそうであってもそのエラーに対処できるように書かれる べきである。遅かれ早かれ特定のエラーや属性の組み合わせを抱えた パケットが到着するので、ソフトウェアが準備をしておかなければ 混乱が生じる可能性がある。一般に、ネットワークは悪意ある エンティティに満ちており、彼らは考えられる最悪の効果を与える ように設計されたパケットを送信すると想定するのが最善である。 この想定は適切な保護の設計をもたらすだろう。とは言え、インター ネットにおける深刻な問題の大半は、低い確率で発生するイベントが きっかけとなり、予期できない仕組みによって生じてきた。人間の 悪意だけならば、大きく道を外れるような状況は決して生じない！ Internet Engineering Task Force [Page 12] RFC1122 INTRODUCTION October 1989 変更への適応性は、インターネットホストのソフトウェアのあらゆる レベルで設計に組み込まれていなければならない。単純な例として、 特定のヘッダーフィールドの値、例えばタイプフィールド、ポート 番号、エラーコード等の列挙を含むプロトコル仕様を考える。その 場合、この列挙は不完全だと想定されなければならない。従って、 プロトコル仕様が起こり得るエラーコードを四つ定義している場合、 ソフトウェアは五つめのエラーコードが現れた際に機能不全を起こしては ならない。未定義のコードのログを採ることは構わないが(後述）、 未定義のコードによって障害を生じさせてはならない。 原則の2文目も1文目と同じくらい重要である。他のホストのソフト ウェアには欠陥があり、プロトコル上正当ではあっても不明確な機能 は活用できないかもしれない。悪影響がどこかに生じるのを避けよう として、明確でシンプルなものからかけ離れてしまうことは賢明では ない。ここから引き出される結論は"作法を守らないホストに注意 せよ"である。ホストソフトウェアは、他の作法を守らないホストに よって生じる厄介な状況を切り抜けて存続するだけではなく、その ようなホストが共用の通信設備に引き起こすかもしれない混乱の規模 を限定するべく協調するように準備をしておくべきである。 1.2.3 エラーのロギング インターネットは非常に多様なホストとゲートウェイシステムを含む。 各ホスト、 ゲートウェイは多数のプロトコルとプロトコルレイヤーを 実装しており、そのうちの幾つかはインターネットプロトコルソフト ウェアにバグや仕様の欠陥を含んでいる。複雑性、多様性に加えて 機能を分散させた結果として、インターネットの問題診断はしばしば 非常に困難である。 ホスト実装が誤ったあるいは"おかしな"プロトコルイベントを ロギングするための注意深く設計された機能を保持していれば、 問題の診断が支援されるだろう。エラーのログを採る際に、可能な 限り多くの診断情報を含めることが重要である。特に、エラーを 生じさせたパケットのヘッダーを記録しておくとしばしば有益である。 しかし、エラーのロギングが極端な量のリソースを消耗させたり、 ホストの運用に干渉したりといったことのないように注意が 払われなければならない。 異常だが無害なプロトコルイベントがエラーのログファイルをあふれ させる傾向がある。これは"循環"ログを使用するか、既知の障害を 診断する間だけロギングを有効にすることで回避できる。重複する 連続したメッセージをフィルターしてカウントすると有益かもしれない。 うまく機能しそうに思える戦略の一つは次の通りである。(1)常に 異常をカウントし、管理プロトコルを通してそのカウント数にアクセス できるようにする([INTRO:1]参照)。 Internet Engineering Task Force [Page 13] RFC1122 INTRODUCTION October 1989 (2)非常に多岐に渡るイベントのロギングを選択的に有効にできる ようにする。例えば、"すべてを記録せよ"や"ホストXに関してすべてを 記録せよ"等を選択できたら恐らく便利だろう。 管理者が違えば、ホストで通常有効にしたいと考えるエラーロギング量 に関するポリシーも異なるかもしれないことに注意せよ。プロトコルの 異常に関して、ある者は"自分に被害がないのなら、それについては 知りたくない"と言う一方で、別の者は異常を検知して除去することに 対してより注意深く積極的な態度をとるだろう。 1.2.4 環境設定 インターネットプロトコルスイートのホスト実装が完全に自己設定 できるならば、それが理想だろう。それが実現すれば、すべての プロトコルスイートをROMに実装したり、シリコンに収めたりできる ようになる。結果としてディスクレスのワークステーションが簡素化 され、悩めるLAN管理者に加えてシステムベンダーにも多大な恩恵を もたらすだろう。我々はまだその理想に到達していない。実際の ところ、近づいてすらいない。 本文書の多くの場所で、パラメーターを設定可能なオプションにせよ という要件が見つかるだろう。そのような要件の背後には幾つかの 異なる理由がある。少数の事例では、現時点で最善の値が不確かで 合意に至っていないため、推奨値を将来更新する必要があるかもしれない ことがその理由となっている。別の事例の場合、パラメーター値が 実際のところ外部要素、例えばホストのサイズや通信負荷の分布、 近隣のネットワークの通信速度やトポロジーといったものに依存して おり、自己調整アルゴリズムが利用できないか、利用できても非効率 であることがその理由である。幾つかの事例では、管理上の要件の ためにパラメーター設定機能が求められることもある。 最後に、廃止された、あるいは不正確なプロトコル実装と通信する ために、幾つかの設定オプションが要求される。そのような実装は ソースコード無しで配付されており、不幸にしてインターネットの 多くの場所で生き残っている。正しいシステムをこれらの欠陥のある システムと共存させるために、管理者はしばしば正しいシステムを "誤った設定"にしなければならない。欠陥のあるシステムが退役して いくため、この問題は何もしなくても徐々に解消されていくだろうが、 ベンダーはこれを無視できない。 本文書で、パラメーターが設定可能でなければならないと記述する 場合、それは、その値をブート時に設定ファイルから明示的に読み 込めるよう求めるという意図ではない。我々は、実装者が各パラメーター のデフォルト値を設定しておくことを推奨する。従って設定 ファイルが必要になるのは、デフォルト値では不適切な特定の導入 状況で、それらを上書きする場合だけである。 Internet Engineering Task Force [Page 14] RFC1122 INTRODUCTION October 1989 つまり設定機能に関する要件は、たとえデフォルト値がバイナリー でしか保存されていないか、ROMベースの書き換えできない機器の中 にあるとしても、必要に応じて上書きが"可能である"ことの保証 である。 本文書は、幾つかの事例において、そのようなデフォルト値に対して 特定の値を要求している。設定項目が既存の欠陥のあるシステムへの 適応を制御している場合、デフォルト値の選択はセンシティブな問題 になる。インターネットが完全な相互運用性に向けてうまく収束して いくのであれば、実装に組み込まれるデフォルト値は公式プロトコルを 実装したものでなければならず、欠陥のある実装に適応するための "誤った設定"であってはならない。幾つかのベンダーは、マーケティング への配慮から誤った設定をデフォルトに選択してきたが、我々は標準 に従うデフォルト値を選択するようベンダーに要請する。 最後に、ベンダーはすべての設定パラメーターについて、上限値や効果に 関する適切な文書を提供する必要があることを注記しておく。 1.3 本文書の読み方 1.3.1 構成 プロトコル階層は、通常ネットワークソフトウェア実装を構成する 原則として使用されるが、本文書を構成する原則としても使用されて いる。ルールを記述するにあたり、実装はプロトコル階層を厳密に 反映しているものと想定する。従って、以下に続く三つの主要 セクションは、それぞれリンクレイヤー、インターネットレイヤー、 トランスポートレイヤーの要件を規定する。対のもう片方のRFC [INTRO:1]はアプリケーションレベルのソフトウェアをカバーする。 この階層化された構造は、簡潔さと明確さのために選択された。 しかし、厳密に階層分けするモデルは、プロトコルスイートにとっても 推奨される実装アプローチにとっても不完全である。異なるレイヤー に属するプロトコル同士は、複雑かつ時には微妙な方法で相互作用 するし、ある特定の機能にはしばしば複数のレイヤーが関与する。 実装には設計に関する選択が多数あり、その多くが厳密な階層分けの 創造的な"破壊"を伴う。各実装者は、参考文献[INTRO:7]及び [INTRO:8]を読むことを奨励する。 本文書は、TCP仕様[TCP:1]で使用されているような関数("プロシージャー コール")表記法を使用して、レイヤーとレイヤーの間の概念的な サービスインターフェースを記述する。ホスト実装は、これらの コールによって暗に示される論理的な情報の流れをサポート しなければならないが、コールそのものを文字通り実装する必要は ない。 Internet Engineering Task Force [Page 15] RFC1122 INTRODUCTION October 1989 例えば多くの実装は、トランスポートレイヤーとIPレイヤーの結び つきを反映して、これら二つのレイヤーが共通のデータ構造にアクセス できるようにしている。明示的なプロシージャーコールではなく、 むしろこれらのデータ構造こそが要求される情報の大半の受け渡しを 行う働きを提供するものとなっている。 一般に、本文書の各主要セクションは、以下のサブセクションで構成 される。 (1) 導入 (2) プロトコルのウォークスルー プロトコルの仕様文書をセクションごとに検討し、エラーを修正 し、不明確またはあいまいな可能性のある要件を提示し、より 明確な記述または説明を提供する。 (3) 固有の課題 ウォークスルーには含まれなかったプロトコル設計と実装に 関する課題を議論する。 (4) インターフェース 一つ上のレイヤーへのサービスインターフェースを議論する。 (5) 概要 そのセクションの要件の概要を含む。 本文書の多くの個々の話題の配下に、"【 議論 】"または"【 実装 】" とラベルされた説明的な資料が存在する。この資料は、その前に記述 されている要件の本文の明確化と説明を与えることを目的としている。 また、見込まれる将来の方向付けまたは開発について若干の提案も 含んでいる。実装の資料は、実装者が検討したいと思うかもしれない 推奨アプローチを含む。 概要セクションは、本文の手引き及び目次となることを意図して いるが、やむを得ずあいまいで不完全なものになっている。概要は、 このRFC全体から切り離した形では絶対に使用または参照されるべき ではない。 1.3.2 要件 本文書において、個々の固有の要件の重要性を定義するために使用 される語句は大文字で注記される。 Internet Engineering Task Force [Page 16] RFC1122 INTRODUCTION October 1989 それらの語句は以下の通りである。 ・ "しなければならない(MUST)" この語句または形容詞の"要求される(REQUIRED)"は、その項目が 仕様の絶対的な要件であることを意味する。 ・ "すべきである(SHOULD)" この語句または形容詞の"推奨される(RECOMMENDED)"は、特定の 状況ではその項目を無視する正当な理由が存在する場合もあるが、 その意味するところはすべて理解されるべきであり、異なるやり方 を選択する前に慎重に検討されるべきであることを意味する。 ・ "してもよい(MAY)" この語句または形容詞の"任意の(OPTIONAL)"は、この項目が 紛れもなく任意であることを意味する。例えば、あるベンダーは 特定の市場がそれを要求していたり製品を強化するという理由で その項目を含めるかもしれないし、別のベンダーは同じ項目を 除外するかもしれない。 ある実装が、実装しようとするプロトコルの一つ以上の"MUST"要件を 満たすことに失敗している場合、その実装はプロトコル準拠ではない。 プロトコルのすべての"MUST"及び"SHOULD"の要件を満たす実装は、 "無条件に準拠"であるという。一方、プロトコルの"MUST"要件はすべて 満たしているが、"SHOULD"要件をすべて満たしていない実装は"条件付き 準拠"であるという。 1.3.3 用語 本文書は、以下の技術用語を使用する。 セグメント セグメントは、TCPプロトコルにおけるエンドツーエンドの転送 単位である。セグメントは、TCPヘッダーとそれに続くアプリ ケーションデータで構成される。セグメントは、IPデータグラム 内にカプセル化されて転送される。 メッセージ 下位レイヤーのプロトコルの説明においては、メッセージとは トランスポートレイヤープロトコルの転送単位である。具体的 に、TCPセグメントはメッセージである。メッセージは、 トランスポートプロトコルヘッダーとそれに続くアプリケーション プロトコルデータで構成される。 Internet Engineering Task Force [Page 17] RFC1122 INTRODUCTION October 1989 インターネットを通してエンドツーエンドで転送されるために、 メッセージはデータグラム内にカプセル化されなければならない。 IPデータグラム IPデータグラムは、IPプロトコルにおけるエンドツーエンドの 転送単位である。IPデータグラムは、IPヘッダーとそれに続く トランスポートレイヤーデータ、言い換えると、IPヘッダーに メッセージが続くもので構成される。 インターネットレイヤーの説明(セクション3)においては、 指定のない"データグラム"という語はIPデータグラムを参照 すると理解されるべきである。 パケット パケットは、インターネットレイヤーとリンクレイヤーの間の インターフェースを通過するデータの単位である。パケットは IPヘッダーとデータを含む。パケットは完全なIPデータグラム であるかもしれないし、IPデータグラムのフラグメントかも しれない。 フレーム フレームは、リンクレイヤープロトコルの転送単位であり、 リンクヘッダーとそれに続くパケットで構成される。 接続ネットワーク ホストがインターフェース接続されるネットワークは、しばしば そのホストに対する"ローカルネットワーク"または"サブネット ワーク"として知られる。しかし、それらの用語は混乱を生じ させる可能性があるため、本文書では"接続ネットワーク"という 用語を使用する。 マルチホーム ホストが複数のIPアドレスを持つ場合、そのホストはマルチ ホームであるという。マルチホーム接続に関する議論については、 この後のセクション3.3.4を参照せよ。 物理ネットワークインターフェース これは接続ネットワークへの物理インターフェースであり、 (恐らく一意な)リンクアドレスを持つ。単一ホストに属する 複数の物理ネットワークインターフェースが同じリンクレイヤー アドレスを共有してもよいが、同じ物理ネットワーク上にある 異なるホストに対しては一意でなければならない。 論理(ネットワーク)インターフェース 論理(ネットワーク)インターフェースとは、一意なIPアドレス によって識別される接続ネットワークへの論理的パスであると 定義する。セクション3.3.4を参照せよ。 Internet Engineering Task Force [Page 18] RFC1122 INTRODUCTION October 1989 特定宛先アドレス 宛先アドレスがブロードキャストアドレスまたはマルチキャスト アドレスである場合も含めて、データグラムが実際に送信される 宛先のアドレス。セクション3.2.1.3を参照せよ。 パス 任意の時点で、特定の送信元ホストから特定の宛先ホストに 向けて送信されたすべてのIPデータグラムは、一般に同じ順番で ゲートウェイを通過していくだろう。我々は、その順番に対して "パス"という用語を使用する。パスは片方向であることに注意 せよ。とは言え、任意のホストのペアの間で、行きと帰りで 異なるパスになることは滅多にない。 MTU 最大転送単位、つまり転送可能な最も大きいパケットのサイズ。 フレーム、パケット、データグラム、メッセージ、セグメントといった 用語は、以下の概略図で説明される。 A. 接続ネットワーク上の転送 _______________________________________________ | ﾘﾝｸ | IPﾍｯﾀﾞｰ| (ﾃﾞｰﾀ) | |_ﾍｯﾀﾞｰ__|________|_____________________________| <---------- フレーム---------------------------> <---------- パケット------------------> B. IPフラグメンテーション前またはIPパケット再構成後 _______________________________________ | IPﾍｯﾀﾞｰ| ﾄﾗﾝｽﾎﾟｰﾄ | ｱﾌﾟﾘｹｰｼｮﾝ ﾃﾞｰﾀ | |________|____ﾍｯﾀﾞｰ__|__________________| <-------- データグラム ---------------> <-------- メッセージ --------> あるいは、TCPの場合 ______________________________________ | IPﾍｯﾀﾞｰ| TCPﾍｯﾀﾞｰ| ｱﾌﾟﾘｹｰｼｮﾝ ﾃﾞｰﾀ | |________|__________|__________________| <-------- データグラム ---------------> <-------- セグメント --------> Internet Engineering Task Force [Page 19] RFC1122 INTRODUCTION October 1989 1.4 Acknowledgments This document incorporates contributions and comments from a large group of Internet protocol experts, including representatives of university and research labs, vendors, and government agencies. It was assembled primarily by the Host Requirements Working Group of the Internet Engineering Task Force (IETF). The Editor would especially like to acknowledge the tireless dedication of the following people, who attended many long meetings and generated 3 million bytes of electronic mail over the past 18 months in pursuit of this document: Philip Almquist, Dave Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software). In addition, the following people made major contributions to the effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology), and Mike StJohns (DCA). The following also made significant contributions to particular areas: Eric Allman (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen (Toronto). We are grateful to all, including any contributors who may have been inadvertently omitted from this list. Internet Engineering Task Force [Page 20] RFC1122 LINK LAYER October 1989 2. リンクレイヤー 2.1 導入 すべてのインターネットシステムは、ホストもゲートウェイもリンク レイヤープロトコルに関しては同じ要件を持つ。これらの要件は、 "インターネットゲートウェイの要件"[INTRO:2]のチャプター3で 提供され、更に本セクションの資料によって増補される。 2.2 プロトコルのウォークスルー 無し。 2.3 固有の課題 2.3.1 トレーラープロトコルのネゴシエーション リンクレイヤーカプセル化のためのトレーラープロトコル[LINK:1]は 使用されてもよいが(MAY)、それはリンクレイヤーの通信に関与する 両端のシステム(ホストまたはゲートウェイ)がトレーラーを実装して いると確認された場合だけである。システムが宛先ごとにトレーラー プロトコルの使用を動的にネゴシエートしない場合、デフォルト設定 ではプロトコルを無効にしなければならない(MUST)。 【 議論 】 トレーラープロトコルはリンクレイヤーのカプセル化の技法で あり、物理ネットワーク上で送信されるパケットのデータ コンテンツの位置を変える。ある場合には、トレーラーは オペレーティングシステム内部でコピーされるデータ量を削減 することにより、上位レイヤープロトコルのスループットを 改善する。上位レイヤープロトコルはトレーラーの使用を意識 しないが、それが使用される場合、送信ホストと受信ホストは 両方ともプロトコルを理解しなければならない(MUST)。 トレーラーを不適切に使用すると、非常にややこしい症状になる 可能性がある。特定のサイズ属性を持つパケットだけがトレーラー でカプセル化されるが、一般的な場合、やりとりされるパケットの ごくわずかな割合しかそのような属性を持たない。従って、 トレーラーを使用するシステムが使用しないシステムとパケットの やりとりを行うと、あるパケットは消失するが、他のパケットは うまく配送されるということになる。 【 実装 】 イーサーネットにおいて、トレーラーでカプセル化されたパケット は、異なるイーサーネットタイプを使用する[LINK:1]。また、 トレーラーのネゴシエーションは、宛先システムのリンクレイヤー アドレスを発見するためにARPが使用される時点で実行される。 Internet Engineering Task Force [Page 21] RFC1122 LINK LAYER October 1989 具体的に、ARPメッセージの交換は通常のIPプロトコルタイプを 使用する通常のやり方で一旦完了する。しかし、トレーラーでの やりとりを望むホストは、"トレーラーARPリプライ"パケット、 つまりトレーラーカプセル化プロトコルタイプを指定するが、 それ以外の部分は通常のARPリプライと同じフォーマットを持つ リプライを追加で送信する。トレーラーを使用するように設定 されているホストがトレーラーARPリプライメッセージをリモート 機器から受信すると、その機器のARPキャッシュ対応エントリーに マークするなどして、トレーラーを理解する機器一覧に追加する ことができる。 トレーラーでカプセル化されたパケットを受信したいと望む ホストは、IP用の通常のARPメッセージ交換完了後、常に トレーラーARPリプライを送信する。従って、自身のIP プロトコルアドレスに対するARPリクエストを受信したホストは、 通常のIP ARPリプライに加えてトレーラーARPリプライも送信 する。一方で、IP ARPリクエストを送信したホストが対応する IP ARPリプライを受信した後に、トレーラーARPリプライを送信 することもある。このように、IP ARPメッセージの交換を行う リクエストホストまたは応答ホストのどちらか一方がトレーラー でカプセル化されたパケットの受信をリクエストすることが できる。 トレーラープロトコルタイプ用のARPリクエストを送信する のではなく、追加のトレーラーARPリプライパケットを使用する というこの方式は、仕様または常識のどれかに反する作法を 守らないホストがトレーラー用のARPリプライに対してIP用の ARPリプライで応答してしまうことにより、ARPパケットの交換 が延々と繰り返されるのを回避するために設計された。この 問題は、受信したIP ARPリプライが未解決のリクエストの回答 になっている場合にだけ、これはIP ARPリプライを受信した 時点でそのホストのハードウェアアドレスが未知である場合 があてはまるが、その場合にだけそのIP ARPリプライに応答 してトレーラーARPリプライを送信することによって回避される。 トレーラーARPリプライは、IP ARPリクエストに対応するIP ARP リプライと共に常に送信されてもよい。 2.3.2 ARP(アドレス解決プロトコル) 2.3.2.1 ARPキャッシュの妥当性検証 ARP[LINK:2]の実装は、期限切れのキャッシュエントリーを廃棄 する仕組みを提供しなければならない(MUST)。この仕組みが タイムアウトを使用する場合、タイムアウト値を設定できる ようにすべきである(SHOULD)。 また、ARPフラッディング(同じIPアドレスに向けて、高レートで ARPリクエストを繰り返し送信する行為)を防止する仕組みが組み 込まれていなければならない(MUST)。 Internet Engineering Task Force [Page 22] RFC1122 LINK LAYER October 1989 最大レートの推奨値は、一つの宛先に対して1秒あたり1メッセージ である。 【 議論 】 ARP仕様[LINK:2]は、ホストのイーサーネットアドレスが 変更された場合にキャッシュエントリーを無効にする タイムアウトの仕組みについて、提案はしているが要求は していない。プロキシーARPの普及([INTRO:2]のセクション2.4 参照)により、ホストのキャッシュエントリーが無効になる 可能性が劇的に増加している。従って、現在は何らかの ARPキャッシュ無効化の仕組みがホストに要求される。 プロキシーARPがない場合であっても、キャッシュされて しまったかもしれない何らかの不正なARPデータを自動的に 修正するために、期限を長めに設定したキャッシュのタイム アウトは有益である。 【 実装 】 期限切れのキャッシュエントリーを廃棄するために、四つの 仕組みが時には組み合わされて使用される。 (1) タイムアウト: たとえ使用中であっても、定期的に キャッシュエントリーをタイムアウトする。このタイム アウトは、キャッシュエントリーが"リフレッシュ" された場合には再起動されるべきであることに注意せよ (リフレッシュは、対象アドレスにかかわらず、システム からのARPブロードキャストの送信元アドレスを観測する ことで検知される)。プロキシーARPが使用されている 場合、タイムアウトは分のオーダーにする必要がある。 (2) ユニキャストポール: リモートホストに対してポイント ツーポイントARPリクエストを定期的に送信することで 能動的なポーリングを行い、N回連続してポーリングに 対するARPリプライが返されない場合、そのエントリーを 削除する。先と同様にタイムアウトは分のオーダーに すべきであり、一般的にNは2である。 (3) リンクレイヤーからの通知: リンクレイヤードライバー が配送の問題を検知した場合、対応するARPキャッシュ エントリーを廃棄する。 (4) 上位レイヤーからの通知: 配送の問題を通知するために、 インターネットレイヤーからリンクレイヤーへのコール を提供する。このコールの効能は、対応するキャッシュ エントリーを無効化することである。このコールは、 トランスポートレイヤーからインターネットレイヤーへの "ADVISE_DELIVPROB()"コールに似ている(セクション3.4 参照)。実際、ADVISE_DELIVPROBはARPキャッシュ エントリーを無効化するリンクレイヤーへの通知ルーチン を順次コールすることもある。 Internet Engineering Task Force [Page 23] RFC1122 LINK LAYER October 1989 アプローチ(1)と(2)は、分またはそれより短いオーダーの ARPキャッシュのタイムアウトを必要とする。プロキシーARP が存在しない場合、大規模なイーサーネット上では、この 短い周期のタイムアウトにより、著しいオーバーヘッド トラフィックが生じるかもしれない。従って、ARP キャッシュのタイムアウトを長くするようにホストを設定 する必要があるかもしれない。 2.3.2.2 ARPパケットのキュー リンクレイヤーは、未解決の同じIPアドレスに宛てられた パケット群について、少なくとも1個の(最新の)パケットを(廃棄 せずに)保持しておき、アドレスが解決された際にその保持して おいたパケットを転送すべきである(SHOULD)。 【 議論 】 この推奨に従わない場合、すべてのやりとりにおいて最初の パケットが消失する。上位レイヤープロトコルは、一般に 再送によってパケット消失に対処可能だが、パケット消失 はパフォーマンスに影響する。例えば、TCPのオープン リクエストが消失すると、最初のラウンドトリップタイム 評価値は水増しされたものになる。DNSのようなUDPベースの アプリケーションは、より深刻な影響を受ける。 2.3.3 イーサーネット及びIEEE 802のカプセル化 イーサーネット用のIPカプセル化はRFC 894[LINK:3]に記述されて おり、IEEE 802ネットワーク用のIPカプセル化はRFC 1042[LINK:4] に記述されている。RFC 1042は、[INTRO:2]のセクション3.4における 議論を詳細に解説し、置き換えるものである。 10Mbpsイーサーネットケーブルに接続されたすべてのインターネット ホストは、 ・ RFC 894のカプセル化を使用するパケットを送信及び受信 できなければならない(MUST)。 ・ RFC 894準拠のパケット群の中に混ざりこんだRFC 1042準拠の パケットを受信できるべきである(SHOULD)。 ・ RFC 1042のカプセル化を使用してパケットを送信できてもよい (MAY)。 RFC 894のカプセル化とRFC 1042のカプセル化の両方式の送信を実装 するインターネットホストは、どちらで送信するかを選択する設定 切り替え手段を提供しなければならない(MUST)。また、この切り替え のデフォルトはRFC 894でなければならない(MUST)。 Internet Engineering Task Force [Page 24] RFC1122 LINK LAYER October 1989 RFC 1042の標準IPカプセル化は、IEEEがIPのために予約した プロトコルID値(K1=6)を使用しないことに注意せよ。代わりに、 イーサータイプフィールドを保持するために使用可能な拡張("SNAP") を暗示する値(K1=170)を使用する。インターネットシステムは、 K1=6を使用して802パケットを送信してはならない(MUST NOT)。 イーサーネットネット及びIEEE 802で構成されたネットワークに おいては、インターネットアドレスからリンクレイヤーアドレスへの 変換は、ARPによって管理されなければならない(MUST)。 イーサーネットのMTUは1500で、802.3のMTUは1492である。 【 議論 】 IEEE 802.3仕様は、10Mbpsイーサーネットケーブル上における 運用を提供するが、運用において、イーサーネットフレームと IEEE 802.3フレームは物理的に混在可能である。受信者は、 802.3の長さ(Length)フィールドの値でイーサーネットフレーム と802.3フレームを区別できる。この2オクテットのフィールド は、イーサーネットフレームのヘッダーにおけるイーサータイプ フィールドと同じ位置にある。ここで、802.3の長さフィールド は1500以下だが、有効なイーサータイプ値はすべて1500よりも 大きい。 別の互換性の問題がリンクレイヤーブロードキャストで生じる。 単一種のフレームで送信されたブロードキャストは、別の種類の フレームしか受信できないホストからは見えない。 本セクション記載の要件は、同じケーブル上にある894準拠の システムと1042準拠のシステムの間で、可能な範囲で最大限の 直接的やりとりを提供するために設計された。894にしか対応 していないシステムが主流であるという現状をサポートする 一方で、1042準拠のシステムが一般的なものとなる、見込まれる 将来への容易な移行手段を提供することを意図している。 894にしか準拠していないシステムは、1042にしか準拠していない システムと直接的なやりとりはできないことに注意せよ。二つの システムが同じケーブル上の異なる論理ネットワークとして 構築されている場合、これらのシステムはIPゲートウェイを 介してしか通信できない。更に、デュアルフォーマット対応の ホストがどちらのフォーマットで送信するかを自動的に検出する ことは有益ではなく、可能ですらない。リンクレイヤーブロード キャストの問題が存在するからである。 2.4 リンクレイヤー/インターネットレイヤー間のインターフェース IPレイヤーとリンクレイヤー間のパケット受信インターフェースは、 到着したパケットがリンクレイヤーブロードキャスト宛であったかを 示すフラグを含まなければならない(MUST)。 Internet Engineering Task Force [Page 25] RFC1122 LINK LAYER October 1989 【 議論 】 IPレイヤーは、一般にリンクレイヤーアドレスを知らないが(異なる 各ネットワークメディアは、概して異なるアドレスフォーマットを 持つため)、ブロードキャスト機能を持つメディアのブロードキャスト アドレスは重要な特例である。セクション3.2.2の、特にブロード キャストストームに関連する"【 議論 】"の項を参照せよ。 IPレイヤーとリンクレイヤー間のパケット送信インターフェースは、 5ビットのTOSフィールドを含まなければならない(MUST)(セクション 3.2.1.6参照)。 リンクレイヤーは、宛先のARPキャッシュエントリーが存在しないという だけの理由でIPレイヤーに対して"宛先到達不能(Destination Unreachable)" エラーを通知してはならない(MUST NOT)。 2.5 リンクレイヤーの要件の概要 | | | | |S| | | | | | |H| | | | | | |O|M| | | |S| |U|U| | | |H| |L|S| | |M|O| |D|T|脚 | |U|U|M| | | | |S|L|A|N|N| | |T|D|Y|O|O|注 機 能 | ｾｸｼｮﾝ | | | |T|T| --------------------------------------------------|-------|-|-|-|-|-|-- | | | | | | | トレーラーによるカプセル化 |2.3.1 | | |x| | | ネゴシエーションを省いたデフォルトのトレーラー送信|2.3.1 | | | | |x| ARP |2.3.2 | | | | | | 期限切れキャッシュエントリーの廃棄 |2.3.2.1|x| | | | | ARPフラッドの防止 |2.3.2.1|x| | | | | キャッシュのタイムアウト値の設定 |2.3.2.1| |x| | | | 最低1個の(最新)未解決パケット保持 |2.3.2.2| |x| | | | イーサーネット及びIEEE 802のカプセル化 |2.3.3 | | | | | | ホストの要件 |2.3.3 | | | | | | RFC 894カプセル化されたパケット送受信 |2.3.3 |x| | | | | RFC 1042カプセル化されたパケットの受信 |2.3.3 | |x| | | | RFC 1042カプセル化されたパケットの送信 |2.3.3 | | |x| | | カプセル化切り替え選択のデフォルトはRFC 894 |2.3.3 |x| | | | | K1=6を使用したカプセル化 |2.3.3 | | | | |x| イーサーネット・IEEE 802ネットにおけるARPの使用 |2.3.3 |x| | | | | ﾘﾝｸﾚｲﾔｰからIPﾚｲﾔｰへのﾌﾞﾛｰﾄﾞｷｬｽﾄ通知 |2.4 |x| | | | | IPレイヤーからリンクレイヤーへのTOS受け渡し |2.4 |x| | | | | キャッシュエントリー不在を到達不能として処理 |2.4 | | | | |x| Internet Engineering Task Force [Page 26] RFC1122 INTERNET LAYER October 1989 3. インターネットレイヤーのプロトコル群 3.1 導入 ロバストネス原則 "受信するものに対しては寛容であれ。送信するものに 対しては保守的であれ"は、作法を守らない1台のホストが他の多数の ホストへのインターネットサービスを妨害できてしまうインターネット レイヤーでは特に重要である。 インターネットレイヤーで使用されるプロトコル標準は以下の通り である。 ・ RFC 791[IP:1]はIPプロトコルを定義し、インターネットの アーキテクチャーの導入を与える。 ・ RFC 792[IP:2]はICMPを定義する。これは、ルーティング、診断、 エラー通知機能をIPに提供するものである。ICMPメッセージは IPデータグラム内にカプセル化されるが、ICMP処理はIPレイヤーの 一部と考えられている(また、一般にIPレイヤーの一部として実装 される)。セクション3.2.2を参照せよ。 ・ RFC 950[IP:3]は、アドレス体系アーキテクチャーで必須のサブネット 拡張を定義する。 ・ RFC 1112[IP:4]はIGMP(インターネットグループ管理プロトコル)を 定義する。このプロトコルは、IPレベルでインターネット規模の マルチキャストをサポートするため、ホスト及びホスト/ゲート ウェイ間のインターフェースに推奨される拡張の一部として定義 されている。セクション3.2.3を参照せよ。 IPマルチキャストの対象は、インターネットホストの任意の グループだろう。IPマルチキャスト通信は、一部のネットワーク のリンクレイヤーマルチキャスト通信機能の自然な拡張として 設計されており、そのようなリンクレイヤーマルチキャスト通信 機能にローカルにアクセスする標準的な手段を提供する。 他の重要な参考文献は、本文書のセクション5に列挙されている。 ホストソフトウェアのインターネットレイヤーは、IPとICMPの両方を 実装しなければならない(MUST)。IGMPのサポートに関する要件については セクション3.3.7を参照せよ。 ホストのIPレイヤーは、次に示す二つの基本機能を持つ。(1)送出するIP データグラムの"次ホップ"に相当するゲートウェイまたはホストを選択する。 (2)到着したIPデータグラムを再構成する。また、IPレイヤーは(3)送出 するデータグラムの意図的なフラグメンテーションを実装してもよい。 最後に、IPレイヤーは(4)診断及びエラー通知機能を提供しなければ ならない。更なるインターネットの制御及び管理機能が開発されるに つれて、IPレイヤーの機能が将来的に幾分増強されることが期待される。 Internet Engineering Task Force [Page 27] RFC1122 INTERNET LAYER October 1989 標準的なデータグラムの場合、処理は単純である。到着したデータ グラムに対し、IPレイヤーは以下の処理を行う。 (1) 正しい形式であるかの検証 (2) ローカルホストに宛てられたものかの検証 (3) オプションの処理 (4) 必要に応じたデータグラムの再構成 (5) カプセル化されたメッセージの適切なトランスポートレイヤー プロトコルモジュールへの受け渡し 送出するデータグラムに対し、IPレイヤーは以下の処理を行う。 (1) トランスポートレイヤーに設定されなかったあらゆるフィールド の設定 (2) 接続ネットワーク上にある正しい第1ホップの選択 ("ルーティング"と呼ばれる処理) (3) フラグメンテーションが必要であり、かつ意図的なフラグ メンテーションが実装されている場合(セクション3.3.3参照)、 それを実行 (4) パケット(群)の適切なリンクレイヤードライバーへの受け渡し ホストが複数のIPアドレスを保持する場合、そのホストはマルチホーム と呼ばれる。マルチホーム接続はプロトコルスイートに相当な混乱と 複雑さをもたらす。この領域は、インターネットアーキテクチャーが すべての問題を解決するには遠く及ばない状況にある。マルチホーム接続 には、二つの異なる問題領域が存在する。 (1) ローカル側のマルチホーム接続：ホスト自身がマルチホーム。 (2) リモート側のマルチホーム接続：ローカルホストがリモートの マルチホームホストと通信する必要がある。 現時点において、リモート側のマルチホーム接続は、対のもう片方のRFC [INTRO:1]で議論されるように、アプリケーションレイヤーで対処され なければならない(MUST)。ホストは、本文書の特にセクション3.3.4で議論 されるように、ローカル側のマルチホーム接続をサポートしてもよい(MAY)。 他のホストに生成されたデータグラムを転送するあらゆるホストはゲート ウェイとして動作し、ゲートウェイの要件に関するRFC[INTRO:2]に明記 された仕様を満たさなければならない(MUST)。組み込みゲートウェイ コードを含むインターネットホストは、ゲートウェイ機能を無効にする 設定切り替え機能を持たなければならない(MUST)。 Internet Engineering Task Force [Page 28] RFC1122 INTERNET LAYER October 1989 切り替え設定のデフォルト値は、非ゲートウェイモードでなければならない (MUST)。このモードの場合、あるインターフェースに到着したデータグラム は、そのホストがシングルホームかマルチホームかにかかわらず、(ソース ルートオプションが設定されていない限り)別のホストまたはゲートウェイ には転送されない。ホストが二つ以上のインターフェースを持つ場合に、 ホストソフトウェアは自動的にゲートウェイモードに移行してはならない (MUST NOT)。機器の運用者はそのサービスを提供したくないかもしれないし、 あるいは提供する能力がないかもしれないからである。 以後の記述において、特定の事例で指定される動作に受信したデータグラム を"黙って破棄"するというものがある。これは、追加の処理無しにデータ グラムが破棄されること、またホストはデータグラム破棄に伴ういかなる ICMPエラーメッセージ(セクション3.2.2参照)も送信しないことを意味する。 しかし、問題の診断を行うために、ホストは黙って破棄されたデータグラム の内容を含むエラーのロギング機能を提供すべきである(SHOULD)(セクション 1.2.3参照)。またイベントを統計カウンターに記録すべきである(SHOULD)。 【 議論 】 誤りのあるデータグラムを黙って破棄するのは、一般に"ブロード キャストストーム"の防止を意図している。 3.2 プロトコルのウォークスルー 3.2.1 IP(インターネットプロトコル) 3.2.1.1 バージョン番号: RFC 791 セクション3.1 バージョン番号が4でないデータグラムは黙って破棄されなければ ならない(MUST)。 3.2.1.2 チェックサム: RFC 791 セクション3.1 ホストは、受信した全データグラムのIPヘッダーチェックサムを 検証し、不正なチェックサムを持つデータグラムはすべて黙って 破棄しなければならない(MUST)。 3.2.1.3 アドレス体系: RFC 791 セクション3.2 現在、クラスAからクラスEまで五つのIPアドレスクラスが存在する。 クラスDアドレスはIPマルチキャスト通信[IP:4]で使用されて おり、クラスEアドレスは実験的使用のために予約されている。 マルチキャスト(クラスD)アドレスは、ホストグループを表す 28ビットの論理アドレスで、永続的なものか一時的なものかの どちらかである。永続的マルチキャストアドレスはIANAに割り当て られるが、一時的アドレスは一時的なグループに対して動的に 割り当てられるものである。 Internet Engineering Task Force [Page 29] RFC1122 INTERNET LAYER October 1989 グループの構成員は、IGMP[IP:4]を使用して動的に決定される。 ここで、以下のIPアドレス表記法を使用して、クラスA、B、Cの IPアドレスに関する重要な特殊事例の概要を示す。 { <ネットワーク番号>, <ホスト番号> } または { <ネットワーク番号>, <サブネット番号>, <ホスト番号> } 加えて、ビットがすべて1に設定されたフィールドに"-1"という表記を 使用する。この表記は、アドレスマスクのビット1が連続的でなければ ならないことを意味するものではない。 (a) { 0, 0 } このネットワーク上のこのホスト。ホストが自分のIPアドレス を学習する初期設定手順の一環としてこのアドレスを送信元 アドレスに使用する場合を除き、このアドレスが送信されては ならない(MUST NOT)。 標準外の{0,0}の使用についてはセクション3.3.6も参照せよ。 (b) { 0, <ホスト番号> } このネットワーク上の指定されたホスト。ホストが自分の完全な IPアドレスを学習する初期設定手順の一環としてこのアドレスを 送信元アドレスに使用する場合を除き、このアドレスが送信 されてはならない(MUST NOT)。 (c) { -1, -1 } リミテッドブロードキャスト。送信元アドレスとして使用 されてはならない(MUST NOT)。 この宛先アドレスを持つデータグラムは、物理的な接続ネット ワーク上にあるすべてのホストに受信されるが、そのネット ワークの外には転送されない。 (d) { <ネットワーク番号>, -1 } 指定ネットワークへのディレクテッドブロードキャスト。 送信元アドレスとして使用されてはならない(MUST NOT)。 (e) { <ネットワーク番号>, <サブネット番号>, -1 } 指定サブネットへのディレクテッドブロードキャスト。 送信元アドレスとして使用されてはならない(MUST NOT)。 Internet Engineering Task Force [Page 30] RFC1122 INTERNET LAYER October 1989 (f) { <ネットワーク番号>, -1, -1 } サブネット化された指定ネットワークの全サブネットへの ディレクテッドブロードキャスト。送信元アドレスとして 使用されてはならない(MUST NOT)。 (g) { 127, <あらゆる値> } ホスト内部のループバックアドレス。この形式のアドレスが ホスト外部に現れることがあってはならない(MUST NOT)。 <ネットワーク番号>は管理組織によって割り当てられるので、 その値は全世界で一意なものとなる。 IPアドレスは、<ホスト番号>、<ネットワーク番号>、<サブネット番号> のいずれのフィールドにおいても、値0または-1を保持することは許容 されない(ただし、上に挙げた特殊な事例を除く)。これは、これらの 各フィールドが最低でも2ビット長になることを意味する。 ブロードキャストアドレスに関するより詳細な議論については、 セクション3.3.6を参照せよ。 ホストはIPのサブネット拡張[IP:3]をサポートしなければならない (MUST)。結果として、各ホストのローカルIPアドレスと関連付け られるアドレスマスクの形式は{-1, -1, 0}となる。セクション 3.2.2.9及び3.3.1.1を参照せよ。 ホストがデータグラムを何であれ送信する場合、送信元IPアドレス は、自身が保持するIPアドレスの一つ(ただしブロードキャスト アドレスまたはマルチキャストアドレスではないもの)でなければ ならない(MUST)。 ホストは、到着したデータグラムが自分宛でない場合、黙って破棄 しなければならない(MUST)。到着したデータグラムの宛先アドレス フィールドが以下のいずれかであれば、そのデータグラムは自分宛 である。 (1) ホストのIPアドレス(の一つ) (2) ホストの接続ネットワークで有効なIPブロードキャスト アドレス (3) データグラムが到着した物理インターフェースにおいて ホストが構成員になっているマルチキャストグループの アドレス ほとんどの場合、ブロードキャストアドレスまたはマルチキャスト アドレスに宛てられたデータグラムは、ホストのIPアドレスの一つに 宛てられたかのように処理される。 Internet Engineering Task Force [Page 31] RFC1122 INTERNET LAYER October 1989 ホストのローカルIPアドレスと等価なものとして"特定宛先アドレス" という用語を使用する。特定宛先アドレスは、IPヘッダー内の宛先 アドレスと定義される。ただし宛先アドレスがブロードキャスト アドレスまたはマルチキャストアドレスの場合、特定宛先はデータ グラムが到着した物理インターフェースに割り当てられたIPアドレス となる。 到着したデータグラムが本セクションのルールに照らして無効となる 送信元IPアドレスを含む場合、ホストは黙って破棄しなければ ならない(MUST)。この妥当性検証は、IPレイヤーかトランスポート レイヤーに属する各プロトコルのどちらかで実行できるだろう。 【 議論 】 誤った宛先のデータグラムは、ユニキャストデータグラムの リンクレイヤーブロードキャストか、誤って設定されたまたは 混乱したゲートウェイやホストによって発生している可能性 がある。 インターネットホストに関するアーキテクチャーのゴールは、 IPアドレスを特色のない32ビットの数にして、アルゴリズムが IPアドレスのフォーマットに関する知識を必要とする状況を 回避できるようにすることだった。そうしないと、IPアドレス のフォーマットや解釈に関する将来のあらゆる変更は、ホスト ソフトウェアの変更を要求することになってしまう。しかし、 ブロードキャストアドレス及びマルチキャストアドレスの 妥当性検証はこのゴールに違反する。他の幾つかの違反に ついては本文書の他の場所に記述されている。 実装者は、全サブネットへのディレクテッドブロードキャスト アドレス(f)に依存するアプリケーションは幾つかのネット ワークでは使用できないかもしれないことを認識すべきである。 全サブネットへのブロードキャストは、現時点でベンダー製 ゲートウェイで広く実装されていない。たとえ実装されたと しても、特定のネットワーク管理者はゲートウェイ設定で その機能を無効にするかもしれない。 3.2.1.4 フラグメンテーションと再構成: RFC 791 セクション3.2 インターネットモデルは、すべてのホストが再構成をサポートする ことを要求する。フラグメンテーションと再構成に関する要件に ついてはセクション3.3.2及び3.3.3を参照せよ。 3.2.1.5 識別番号: RFC 791 セクション3.2 以前に送信したデータグラムと同一のコピーを送信する場合、 ホストは任意で以前のデータグラムの識別番号フィールドの値を コピーでも維持してよい(MAY)。 Internet Engineering Task Force [Page 32] RFC1122 INTERNET LAYER October 1989 【 議論 】 一部のインターネットプロトコルの専門家達は、ホストが 以前に送信したデータグラムと同一のコピーを送信する場合、 新しいコピーはオリジナルと同じ識別番号を含むべきだという 意見を支持している。以下に示す次の二つの長所が示されて いる。(1)データグラムがフラグメンテーションされ、 フラグメントの幾つかが消失した場合、受信者はオリジナル とコピーのどちらのフラグメントからでも完全なデータグラム を再構成できる可能性がある。(2)ふくそうが生じている ゲートウェイは、IP識別番号フィールド(とフラグメント オフセットフィールド)を使用することで、キューから重複 データグラムを破棄できるかもしれない。 しかし、インターネット上で観測されたデータグラムの消失 パターンは、再送されたフラグメントが再構成時の欠落部を 埋める可能性を後押しするものではない。一方、他の仕組み (例えばTCPの再送時の再パケット化)は同一データグラムの 再送を抑制する傾向にある[IP:9]。従って、我々は同じ 識別番号フィールドの再送は有益ではないと考えている。 また、UDPのようなコネクションレスなトランスポート プロトコルは、同一のデータグラムで同じ識別番号値を維持 するためにアプリケーションプログラムとの協調が必要に なるだろう。 3.2.1.6 タイプオブサービス: RFC 791 セクション3.2 IPヘッダーの"タイプオブサービス"バイトは、二つのセクションに 分割される。一つは優先度フィールド(上位3ビット)で、もう一つは 慣習的に"タイプオブサービス"または"TOS"と呼ばれるフィールド (下位5ビット)である。本文書における"TOS"または"TOSフィールド" という用語は、すべて下位5ビットのみを参照するものである。 優先度フィールドは、インターネットプロトコルの国防総省(DoD) アプリケーションを対象としたものである。このフィールドで ゼロ以外の値を使用することは、本文書及びIP標準仕様の対象外 である。ベンダーは、IP優先度フィールドと他のプロトコルレイヤー への影響について、国防省通信局(DCA)に助言を求めるべきである。 しかしベンダーは、優先度を使用する場合、プロトコルレイヤー 間でTOSフィールドが渡されるのと全く同じ方法で優先度の値が 渡されることを要求される可能性が高いことに注意すべきである。 IPレイヤーは、送信される各データグラムのTOSフィールドを設定 する手段をトランスポートレイヤーに提供しなければならない (MUST)。デフォルトは全ビット0である。 Internet Engineering Task Force [Page 33] RFC1122 INTERNET LAYER October 1989 IPレイヤーは、受信したTOS値をトランスポートレイヤーに渡すべき である(SHOULD)。 RFC 795に含まれるTOSの特定リンクレイヤーへのマッピングは 実装されるべきではない(SHOULD NOT)。 【 議論 】 TOSフィールドはこれまであまり使用されてこなかったが、 近い将来、役割が増大することが期待される。TOSフィールド は、ゲートウェイ処理の二つの側面、すなわちルーティング アルゴリズムとキューイングアルゴリズムを制御するために 使用されることが期待されている。アプリケーション プログラムがTOS値を指定するための要件については [INTRO:1]のセクション2を参照せよ。 TOSフィールドは、リンクレイヤーサービスのセレクターに マップされている場合がある。例えば、異なるクラスのTCP トラフィック間で効率的にシリアル回線を共有するために これが適用されてきた。しかし、RFC 795で提言された マッピングは、1981年時点のインターネットに含まれていた ネットワークに対するものであり、現在では廃止されている。 3.2.1.7 TTL(生存時間): RFC 791 セクション3.2 ホストは、TTL値がゼロのデータグラムを送信してはならない (MUST NOT)。 ホストは、受信したデータグラムのTTLが2より小さいというだけの 理由でそのデータグラムを破棄してはならない(MUST NOT)。 IPレイヤーは、送信される各データグラムのTTLフィールドを設定 する手段をトランスポートレイヤーに提供しなければならない (MUST)。固定TTL値が使用される場合、その値は設定可能でなければ ならない(MUST)。現在の推奨値は、"割り当て済み番号資源(Assigned Numbers)" RFCで公開されるだろう。 【 議論 】 TTLフィールドには二つの機能がある。一つはTCPセグメントの 寿命を制限すること(RFC 793[TCP:1]のP.28参照)で、もう一つ はインターネットルーティングのループを終わらせること である。TTLは秒単位の時間だが、各ゲートウェイはTTL フィールドを少なくとも1減らすことを要求されることから、 ホップ数の属性も若干持っている。 その意図は、TTL期限切れのためにデータグラムがゲートウェイ に破棄されることはあっても、宛先ホストには破棄されない ようにすることである。しかし、データグラムを転送することで ゲートウェイとして動作するホストは、TTLに関するゲート ウェイのルールに従わなければならない。 Internet Engineering Task Force [Page 34] RFC1122 INTERNET LAYER October 1989 上位レイヤーのプロトコルは、何らかのインターネット リソースの"拡張スコープ"探索を実装するためにTTLを設定 したいと望むかもしれない。これは幾つかの診断ツールに使用 されており、例えばIPマルチキャスト通信を使用して任意の クラスの"最寄りの"サーバーの位置特定に役立つことが期待 される。また、特定のトランスポートプロトコルは、自身の TTLの上限をデータグラム生存時間の最大値に指定したいと 望むかもしれない。 固定値は、少なくともインターネットの"直径"、すなわち 考えられる最長のパスに対して十分に大きいものでなければ ならない。継続的なインターネットの成長を許容するために、 妥当な値は直径の約2倍である。 3.2.1.8 オプション: RFC 791 セクション3.2 転送されるIPデータグラムに含まれるIPオプションをトランス ポートレイヤーから指定する手段が存在しなければならない(MUST) (セクション3.4参照)。 受信したデータグラムに含まれるIPオプションは、(NOPまたは END-OF-LISTを除く)すべてがトランスポートレイヤー(データグラム がICMPメッセージである場合はICMP処理)に渡されなければならない (MUST)。IPレイヤーとトランスポートレイヤーは、それぞれ理解 できるIPオプションだけを解釈し、そうでないものは黙って無視 しなければならない(MUST)。 本文書の後のセクションで、ICMP、TCP、UDPそれぞれに要求される 固有のIPオプションサポートについて議論する。 【 議論 】 受信したIPオプションすべてをトランスポートレイヤーに渡す ことは、将来の新しいトランスポート関連のIPオプション導入 を容易にするために設計された意図的な"厳密なレイヤー区分 の侵害"である。各レイヤーは、自分の処理に関連するあらゆる オプションを選び出し、残りは無視する。これを行えるように、 NOPとEND-OF-LISTを除く全IPオプションは、自分自身の長さ の指定を含むことになっている。 本文書は、同じIPヘッダー内に含まれる複数のオプションを 受信者が処理する順序を定義しない。複数オプションを送信 するホストは、ソースルートオプションと組み合わされた場合 に、特定のオプションの意味にあいまいさがもたらされること を認識しなければならない。 【 実装 】 IPレイヤーは、オプション長が採り得る範囲外であったという 理由でクラッシュしてはならない。 Internet Engineering Task Force [Page 35] RFC1122 INTERNET LAYER October 1989 例えば、誤りのあるオプション長が幾つかのIP実装を無限 ループに陥れることが観測されている。 特定のIPオプションに関する要件をここに示す。 (a) セキュリティオプション 一部の環境では、すべてのデータグラムでセキュリティオプション が要求されるが、そのような要件は本文書及びIP標準仕様 の対象範囲外である。ただし、RFC 791及びRFC 1038に記述 されたセキュリティオプションは廃止されたことに注意せよ。 DoDアプリケーションについては、指針を得るためにベンダー は[IP:8]を調査すべきである。 (b) ストリーム識別オプション このオプションは廃止されたので、送信されるべきではなく (SHOULD NOT)、また受信時には黙って無視されなければ ならない(MUST)。 (c) ソースルートオプション ホストはソースルートの起動をサポートしなければならず (MUST)、またソースルートの最終的な宛先の役割を果たせ なければならない(MUST)。 完了したソースルート(ポインターが最終フィールドの先を 指している)を含むデータグラムをホストが受信した場合、 そのデータグラムは最終的な宛先に到達したことになる。受信 されたオプション(ルート記録)は、そのままトランスポート レイヤー(またはICMPメッセージ処理)に渡されなければならない (MUST)。このルート記録は反転され、応答データグラム用の 復路ソースルートを構成するために使用される(セクション4の IPオプションの議論を参照せよ)。復路ソースルートが構築 される際に、ルート記録が送信元ホストを含んでいたとしても、 正しく構成されなければならない(MUST)(この後の議論の事例(B) を参照せよ)。 二つ以上のソースルートオプションを含むIPヘッダーが送信 されてはならない(MUST NOT)。複数のソースルートオプション がルーティングに与える影響は実装依存である。 セクション3.3.5において、ソースルートの中間ホップとして 動作するホスト、つまりソースルート指定されたデータグラム を転送するホストに関するルールを提示している。 Internet Engineering Task Force [Page 36] RFC1122 INTERNET LAYER October 1989 【 議論 】 ソースルート指定されたデータグラムが フラグメンテーションされる場合、各フラグメントは ソースルートのコピーを含む。(ソースルートを含む) IPオプションの処理は再構成の前でなければならない ため、オリジナルのデータグラムは最終的な宛先に到達 するまで再構成されない。 ソースルート指定されたデータグラムは、ホストSから ゲートウェイG1、G2、...、Gnを経由してホストDに到達 するようなルートをたどるものとする。Sによって送信 されるデータグラムに含まれるソースルートオプション は、以下に示す(A)であるべきか(B)であるべきかに 関して、仕様には不明確な点があった。 (A): {>>G2, G3, ... Gn, D} <---- 適正 (B): {S, >>G2, G3, ... Gn, D} <---- 誤り (上記で >>はポインターを意味する)。(A)が送信 される場合、Dで受信されるデータグラムは、送信元IP アドレスがS、宛先IPアドレスがDで、オプション {G1, G2, ... Gn >>}を含むものになる。(B)が送信 される場合、Dで受信されるデータグラムは、送信元IP アドレス、宛先IPアドレスは先と同じものを含むが、 オプションは{S, G1, ...Gn >>}となる。つまり、起点の ホストがソースルートの第1ホップとなっている。 (d) ルート記録オプション ルート記録オプションの生成と処理の実装は任意(OPTIONAL) である。 (e) タイムスタンプオプション タイムスタンプオプションの生成と処理の実装は任意 (OPTIONAL)である。実装される場合、以下のルールが適用 される。 ・ 生成ホストは、タイムスタンプオプションのインターネット アドレスフィールドが事前に指定されていない場合、または 事前に指定された第1アドレス(first address)がそのホスト のインターフェースアドレスである場合、タイムスタンプを 記録しなければならない(MUST)。 Internet Engineering Task Force [Page 37] RFC1122 INTERNET LAYER October 1989 ・ 宛先ホストは、タイムスタンプオプションをトランス ポートレイヤーまたはICMPの処理に渡す前に、(可能で あれば)現在のタイムスタンプをオプションに追加 しなければならない(MUST)。 ・ タイムスタンプ値は、ICMPタイムスタンプメッセージ に関してセクション3.2.2.8で与えられるルールに 従わなければならない(MUST)。 3.2.2 ICMP(インターネット制御メッセージプロトコル) ICMPメッセージは、二つのクラスに分類される。 ・ ICMPエラーメッセージ 宛先到達不能(Destination Unreachable) (セクション3.2.2.1参照) リダイレクト(Redirect) (セクション3.2.2.2参照) 送信元抑制(Source Quench) (セクション3.2.2.3参照) 時間超過(Time Exceeded) (セクション3.2.2.4参照) パラメーター不正(Parameter Problem) (セクション3.2.2.5参照) ・ ICMP要求メッセージ エコー(Echo) (セクション3.2.2.6参照) 情報(Information) (セクション3.2.2.7参照) タイムスタンプ(Timestamp) (セクション3.2.2.8参照) アドレスマスク(Address Mask) (セクション3.2.2.9参照) 未知のタイプのICMPメッセージが受信された場合、黙って破棄され なければならない(MUST)。 各ICMPエラーメッセージは、エラーを引き起こしたデータグラムの インターネットヘッダーとデータの少なくとも先頭8オクテットを含む。 8オクテットを越えるものが送信されてもよい(MAY)。このヘッダーと データは、受信したデータグラムから変更されないままでなければ ならない(MUST)。 インターネットレイヤーがICMPエラーメッセージをトランスポート レイヤーに渡す必要がある場合、オリジナルヘッダーからIPプロトコル 番号を抽出し、それを使用してエラーに対処する適切なトランスポート プロトコルエンティティを選択しなければならない(MUST)。 ICMPエラーメッセージは、通常の(つまりゼロが設定された)TOSビット で送信されるべきである(SHOULD)。 Internet Engineering Task Force [Page 38] RFC1122 INTERNET LAYER October 1989 以下に示すどれを受信したとしても、ICMPエラーメッセージが送信 されてはならない(MUST NOT)。 ・ ICMPエラーメッセージ ・ IPブロードキャストアドレスまたはIPマルチキャストアドレス 宛のデータグラム ・ リンクレイヤーブロードキャストとして送信されたデータグラム ・ 先頭でないフラグメント ・ 送信元アドレスが単一ホストを定義しない、例えばビットがすべて ゼロのアドレス、ループバックアドレス、ブロードキャスト アドレス、マルチキャストアドレス、クラスEアドレス等が指定 されたデータグラム 【 重要な注意 】 これらの制限は、本文書の他の場所に記述されているICMPエラー メッセージ送信に関するあらゆる要件に優先する。 【 議論 】 これらのルールは、ホストがブロードキャストデータグラムに 応答してICMPエラーメッセージを返すことに起因する"ブロード キャストストーム"を防止する。例えば、存在しないポートに 宛てたUDPセグメントのブロードキャストは、その宛先ポートの クライアントを持たないすべての機器からのICMP宛先到達不能データ グラムの洪水を引き起こすかもしれない。大規模なイーサーネット では、その結果生じるコリジョンにより、ネットワークが一瞬 またはそれ以上の間役に立たない状態になる可能性がある。 接続ネットワーク上でブロードキャストされる各データグラム は、IPの宛先として有効なIPブロードキャストアドレスを持つ べきである(セクション3.3.6参照)。しかし、一部のホストは このルールに違反する。従って、ブロードキャストデータ グラムを確実に検知するため、ホストはIPブロードキャスト アドレスだけではなく、リンクレイヤーブロードキャストも 検査することが求められる。 【 実装 】 これは、リンクレイヤーブロードキャストデータグラムが受信 された際に、リンクレイヤーがIPレイヤーにその旨通知する ことを要求する。セクション2.4を参照せよ。 3.2.2.1 宛先到達不能: RFC 792 以下の追加コードをここで定義する。 6 = 未知の宛先ネットワーク Internet Engineering Task Force [Page 39] RFC1122 INTERNET LAYER October 1989 7 = 未知の宛先ホスト 8 = 送信元ホストが孤立 9 = 宛先ネットワークとの通信は管理上禁止 10 = 宛先ホストとの通信は管理上禁止 11 = 指定TOSではネットワークに到達不能 12 = 指定TOSではホストに到達不能 ホストは、以下の状況においては対応するコードの宛先到達不能 メッセージを生成すべきである(SHOULD)。 2 (プロトコル到達不能) 指定されたトランスポート プロトコルがサポートされていない場合 3 (ポート到達不能) 指定されたトランスポートプロトコル (例えばUDP)は通信相手にデータグラムを渡せなかったが、 それを送信者に通知するプロトコルの仕組みが存在しない 場合 受信された宛先到達不能メッセージは、トランスポートレイヤーに 通知されなければならない(MUST)。トランスポートレイヤーはその 情報を適切に使用すべきである(SHOULD)。例えば、セクション4.1.3.3、 4.2.3.9、4.2.4を参照せよ。ポートに到達不能であることを送信者 に通知する独自の仕組み(例えば、TCPはRSTセグメントを送信する) を持つトランスポートプロトコルであっても、同じ目的のICMPポート 到達不能を受理しなければならない(MUST)。 コード0(ネットワーク到達不能)、1(ホスト到達不能)、5(ソース ルート失敗)が指定された宛先到達不能メッセージは、ルーティング の過渡的状況から生じることもあるので、指定された宛先に到達不能 であるという証拠ではなく、単なるヒントとして解釈されなければ ならない[IP:11](MUST)。例えば、ゲートウェイ停止の証拠として 使用されてはならない(セクション3.3.1参照)(MUST NOT)。 3.2.2.2 リダイレクト: RFC 792 ホストは、ICMPリダイレクトメッセージを送信すべきではない (SHOULD NOT)。リダイレクトは、ゲートウェイのみが送信すべき である。 リダイレクトメッセージを受信したホストは、それに応じて自身の ルーティング情報を更新しなければならない(MUST)。 Internet Engineering Task Force [Page 40] RFC1122 INTERNET LAYER October 1989 各ホストは、ホストのリダイレクトとネットワークのリダイレクト の両方を受理し、セクション3.3.1.2に記述される通りに処理 する準備ができていなければならない(MUST)。 リダイレクトメッセージが指定する新しいゲートウェイアドレス が到着インターフェースと同じ(サブ)ネット上にない場合、 あるいはリダイレクトの送信元が指定された宛先への現時点の 第1ホップゲートウェイでない場合、そのリダイレクトは黙って 破棄されるべきである(SHOULD)[INTRO:2、付録A]。 3.2.2.3 送信元抑制: RFC 792 ホストは、再構成バッファーや他のリソースが不足して到着データ グラムを破棄せざるを得ない段階に近づきつつあるか、または到達 してしまった場合、送信元抑制メッセージを送信してもよい(MAY)。 送信元抑制をいつ送信するかに関する提言については、[INTRO:2]の セクション2.2.3を参照せよ。 送信元抑制メッセージが受信された場合、IPレイヤーは、それを トランスポートレイヤー(またはICMP処理)に通知しなければならない (MUST)。一般に、トランスポートレイヤーやアプリケーション レイヤーは、同じ宛先にひと続きのデータグラムを送信でき、 その実現に十分な状態情報を維持することが合理的に期待される どのプロトコルを対象とした送信元抑制であっても、それに応じる 仕組みを実装すべきである(SHOULD)。TCP及びUDPによる送信元 抑制の対応についてはセクション4を参照せよ。 【 議論 】 送信元抑制は、データグラムの配送パスに含まれる対象ホスト または幾つかのゲートウェイによって生成されるだろう。 送信元抑制を受信したホストは、一定期間転送レートを抑制 し、その後再び徐々に転送レートを増加させるべきである。 送信元抑制に応じる仕組みは、(TCPのようなコネクション指向 プロトコルの場合は)トランスポートレイヤーの中にあり、 (UDPの上に構築されたプロトコルの場合は)アプリケーション レイヤーの中にある。 データグラム送信レートを制御することで、IPレイヤーが 直接送信元抑制に応じる仕組みが提案されている[IP:14]。 しかし、この提案は現時点で実験的なものであり、現在 推奨されていない。 3.2.2.4 時間超過: RFC 792 到着した時間超過メッセージは、トランスポートレイヤーに渡され なければならない(MUST)。 Internet Engineering Task Force [Page 41] RFC1122 INTERNET LAYER October 1989 【 議論 】 TTLフィールドが満了となったためにゲートウェイがデータ グラムを破棄する場合、そのゲートウェイはコード0(転送中 TTL超過)を指定した時間超過メッセージを送信する。これは、 ゲートウェイのルーティングループが生じているか、初期 TTL値が小さすぎるかのどちらかであることを示している。 ホストは、データグラム再構成を未完了のままタイムアウト し、そのデータグラムを破棄した宛先ホストからコード1 (再構成タイムアウト)を指定した時間超過メッセージを受信 することがある。セクション3.3.2を参照せよ。将来、この メッセージの受信は、フラグメンテーション無しでパスに 送信可能な最大データグラムサイズを発見する何らかの "MTU探索"処理の一部になるかもしれない。 3.2.2.5 パラメーター不正: RFC 792 ホストは、パラメーター不正メッセージを生成すべきである (SHOULD)。到着したパラメーター不正メッセージはトランスポート レイヤーに渡されなければならず(MUST)、またユーザーに報告 されてもよい(MAY)。 【 議論 】 ICMPパラメーター不正メッセージは、他のICMPメッセージで 具体的にカバーされないあらゆる問題のために、送信元ホスト に送信される。パラメーター問題メッセージの受信は、一般に ローカルまたはリモートの何らかの実装エラーを示すもの である。 パラメーター不正メッセージの新しい変種をここで定義する。 コード1 = 必要なオプション欠落 【 議論 】 この変種は、現在軍事コミュニティにおいてセキュリティ オプション欠落を通知するために使用されている。 3.2.2.6 エコーリクエスト/リプライ: RFC 792 あらゆるホストは、エコーリクエストを受信し対応するエコー リプライを送信するICMPエコーサーバー機能を実装しなければ ならない(MUST)。また、ホストは、診断のためにエコーリクエスト を送信しエコーリプライを受信するためのアプリケーション レイヤーインターフェースも実装すべきである(SHOULD)。 IPブロードキャストアドレスまたはIPマルチキャストアドレスに 宛てられたICMPエコーリクエストは黙って破棄されてもよい(MAY)。 Internet Engineering Task Force [Page 42] RFC1122 INTERNET LAYER October 1989 【 議論 】 この中立的な規定は、ブロードキャストアドレス宛のICMPエコー は有益な診断機能を提供すると考える人々と、この機能を悪用 することであまりにも容易にパケットストームが作り出せて しまうと考える人々との間の熱意あふれる議論の結果である。 ICMPエコーリプライに含まれるIP送信元アドレスは、対応するICMP エコーリクエストメッセージの特定宛先アドレス(セクション3.2.1.3 で定義)と同じでなければならない(MUST)。 ICMPエコーリクエストで受信されたデータは、結果として生じる エコーリプライにすべてが含まれていなければならない(MUST)。 しかし、エコーリプライの送信が意図的なフラグメンテーション を要求する一方でそれが実装されていない場合、データグラムは 最大転送サイズに切り詰められた後に送信されなければならない (MUST)(セクション3.3.3参照)。 エコーリプライメッセージは、対応するエコーリクエストが IPレイヤーで生成されたものではないなら、ICMPユーザー インターフェースに渡されなければならない(MUST)。 ICMPエコーリクエストでルート記録オプション、タイムスタンプ オプションのどちらかあるいは両方が受信された場合、これらの オプションは現在のホストを含めるよう更新されるべきであり (SHOULD)、またエコーリプライメッセージのIPヘッダーに"切り詰め" 無しで含まれるべきである(SHOULD)。従って、ルート記録は、 往路復路全体を対象としたものになる。 ICMPエコーリクエストでソースルートオプションが受信された場合、 復路ルートは往路のルートが反転されたものでなければならず(MUST)、 そのような復路ルートがエコーリプライメッセージのソースルート オプションとして使用されなければならない(MUST)。 3.2.2.7 情報リクエスト/リプライ: RFC 792 ホストは、これらのメッセージを実装すべきではない(SHOULD NOT)。 【 議論 】 情報リクエスト/リプライのペアは、ディスクレスワーク ステーションのような自己設定システムをサポートすることを 意図したもので、ブート時にIPネットワーク番号を発見できる ようにするためのものであった。しかし、RARPプロトコル 及びBOOTPプロトコルは、ホストが自身のIPアドレスを発見 するためのより良い仕組みを提供している。 3.2.2.8 タイムスタンプリクエスト/リプライ: RFC 792 ホストは、タイムスタンプリクエスト及びタイムスタンプリプライ を実装してもよい(MAY)。それらが実装される場合、以下のルールに 従わなければならない(MUST)。 Internet Engineering Task Force [Page 43] RFC1122 INTERNET LAYER October 1989 ・ ICMPタイムスタンプサーバー機能は、タイムスタンプリクエスト メッセージを受信するごとにタイムスタンプリプライを返す。 この機能が実装される場合、遅延のばらつきが最小になるように 設計されるべきである(SHOULD)(例えば、ユーザープロセスの スケジューリングにおける遅延を回避するためにカーネル内で 実装する)。 タイムスタンプリクエストに関する以下の事例は、ICMPエコー リクエストの対応するルールに従って処理されるものとする。 ・ IPブロードキャストアドレスまたはIPマルチキャストアドレス に宛てられたICMPタイムスタンプリクエストメッセージは 黙って破棄されてもよい(MAY)。 ・ ICMPタイムスタンプリプライに含まれるIP送信元アドレスは、 対応するICMPタイムスタンプリクエストメッセージの特定宛先 アドレスと同じでなければならない(MUST)。 ・ ICMPタイムスタンプリクエストでソースルートオプションが受信 された場合、戻りルートは往路のルートが反転されたもので なければならず(MUST)、そのような復路ルートがタイムスタンプ リプライメッセージのソースルートオプションとして使用され なければならない(MUST)。 ・ ICMPタイムスタンプリクエストでルート記録オプション、タイム スタンプオプションのどちらかあるいは両方が受信された場合、 これらのオプションは現在のホストを含めるよう更新されるべき であり(SHOULD)、またタイムスタンプリプライメッセージの IPヘッダーに含まれるべきである(SHOULD)。 ・ タイムスタンプリプライメッセージは、ICMPユーザーインター フェースに渡されなければならない(MUST)。 タイムスタンプ値の推奨形式("標準値")は、世界時の午前0時を 起点とするミリ秒単位の値である。しかし、この値をミリ秒の精度 で提供することは困難だろう。例えば、多くのシステムで使用 されるクロックは、1秒間あたり50回または60回の周波数でしか 更新されない。従って、"標準値"には、以下に示す若干の 寛容さが容認される。 (a) "標準値"は少なくとも1秒間に15回は更新されなければ ならない(MUST)(つまり、たかだか下位6ビットの値は未定義 でもよい)。 (b) "標準値"の正確さは、管理者に設定されたCPUクロックの 正確さに近づけなければならない(MUST)。言い換えると、 誤差は数分以内でなければならない(MUST)。 Internet Engineering Task Force [Page 44] RFC1122 INTERNET LAYER October 1989 3.2.2.9 アドレスマスクリクエスト/リプライ: RFC 950 ホストは、自身のIPアドレスのアドレスマスクを判定するための 以下の手法のうち、最初のものをサポートしなければならず(MUST)、 三つすべてを実装してもよい(MAY)。 (1) 静的な設定情報を使用する。 (2) システム初期設定処理の副作用として、アドレスマスクを動的 に取得する([INTRO:1]参照)。 (3) ICMPアドレスマスクリクエストを送信し、ICMPアドレス マスクリプライを受信する。 特定のホストで使用される手法は、設定可能でなければならない (MUST)。 手法(3)が選択され、アドレスマスクメッセージが有効にされる 場合、 (a) ホストは、初期設定の際に、IPアドレスに対応する接続ネット ワーク上でアドレスマスクリクエストメッセージをブロード キャストしなければならない(MUST)。ホストがアドレスマスク リプライを直ちに受信しなかった場合、ごくわずかな回数 このメッセージを再送しなければならない(MUST)。 (b) ホストは、アドレスマスクリプライを受信するまでは、アドレス マスクはIPアドレスのアドレスクラスに適したものであると 想定すべきである(SHOULD)。言い換えると、接続ネットワークは サブネット化されていないと想定すべきである(SHOULD)。 (c) 特定のローカルIPアドレスを設定するにあたり、受信された 最初のアドレスマスクリプライメッセージが使用されなければ ならない(MUST)。これは、最初のアドレスマスクリプライ メッセージがたとえ"一方的な通知(unsolicited)"であっても あてはまる。そのような状況は、アドレスマスクリプライ メッセージがブロードキャストされており、ホストがアドレス マスクリクエストの再送を停止した後にメッセージが届く ような場合に生じる。アドレスマスクリプライによって マスクが一度設定されると、以後のアドレスマスクリプライ メッセージは(黙って)無視されなければならない(MUST)。 逆に、アドレスマスクメッセージが無効にされる場合、ICMP アドレスマスクリクエストは送信されず、ローカルIPアドレスに 宛てられたあらゆるICMPアドレスマスクリプライは、(黙って) 無視されなければならない(MUST)。 ホストは、インストールするあらゆるアドレスマスクに関して、 何らかの妥当性検査をすべきである(SHOULD)。 Internet Engineering Task Force [Page 45] RFC1122 INTERNET LAYER October 1989 この後の【 実装 】セクションも参照せよ。 システムは、自身がアドレスマスクの権威を持つエージェントでない 限り、アドレスマスクリプライを送信してはならない(MUST NOT)。 権威を持つエージェントは、ホストであるかもしれないしゲートウェイ であるかもしれないが、アドレスマスクエージェントとして明示的に 設定されていなければならない(MUST)。アドレスマスクリプライを 介したアドレスマスクの受信は、受信側に権威を与えるものではない ので、受信者がアドレスマスクリプライを発行する根拠として使用 されてはならない(MUST NOT)。 アドレスマスクが静的に設定されている場合、ホストがそのマスクに 関して権威を持つエージェントとして動作するかどうか、言い換えると、 ホストがそのマスクを使用してアドレスマスクリクエストメッセージ に回答するかどうかを決定する付加的な設定フラグが存在すべきである (SHOULD)。 ホストがエージェントとして設定されている場合、初期設定時には マスクに関するアドレスマスクリプライを適切なインターフェース でブロードキャストしなければならない(MUST)。 アドレスマスクリクエスト/リプライメッセージの使用に関する より詳細な情報については、[INTRO:1]の"システムの初期設定"を 参照せよ。 【 議論 】 無効なアドレスマスクを指定したアドレスマスクリプライを 不用意に送信するホストは、しばしば深刻な迷惑となっている。 これを防止するため、アドレスマスクリプライは、明示的な 管理作業によって選択された権威を持つエージェントによって のみ送信されるようにすべきである。 権威を持つエージェントがアドレスマスクリクエストメッセージ を受信すると、ユニキャストのアドレスマスクリプライを送信元 IPアドレスに送信する。送信元IPアドレスのネットワーク部分が ゼロの場合(セクション3.2.1.3の(a)及び(b)を参照せよ)、 リプライはブロードキャストされる。 アドレスマスクリクエストメッセージの応答が得られない場合、 ホストはエージェントが存在しないと想定し、サブネット化 されていないマスクを使用するが、エージェントは一時的に 到達不能になっているだけかもしれない。エージェントは、 初期設定時には常に一方的なアドレスマスクリプライをブロード キャストし、それまでに初期設定されたすべてのホストのマスクを 更新する。 【 実装 】 次に示すアドレスマスクの妥当性検査を提案する。 Internet Engineering Task Force [Page 46] RFC1122 INTERNET LAYER October 1989 まず、マスクがすべてビット1になっていないかを検査し、 次いで最上位8ビットがゼロか、さもなくばすべて1となって いるか等を検査すべきである。 3.2.3 IGMP(インターネットグループ管理プロトコル) IGMP[IP:4]は、単一ネットワーク上にあるホストとゲートウェイの間で、 特定のマルチキャストグループのメンバーシップを確立するために使用 されるプロトコルである。ゲートウェイは、この情報をマルチキャスト ルーティングプロトコルと組み合わせて使用し、インターネット全域に わたるマルチキャスト通信をサポートする。 現在のところ、IGMPの実装は任意(OPTIONAL)である。詳細はセクション 3.3.7を参照せよ。IGMPがなくても、ホストは依然として接続ネット ワーク上のローカルなマルチキャスト通信には参加することができる。 3.3 固有の課題 3.3.1 送信データグラムのルーティング IPレイヤーは、送信する各データグラムに対して正しい次ホップを選択 する。宛先が接続ネットワーク上にある場合、データグラムは宛先ホスト に直接送信されるが、そうでない場合、接続ネットワーク上のゲートウェイ にルーティングされなければならない。 3.3.1.1 宛先がローカルかリモートかの判定 宛先が接続ネットワーク上にあるかどうかを判定するために、以下の アルゴリズムが使用されなければならない([IP:3]参照)(MUST)。 (a) アドレスマスクは、送信者のIPアドレスのネットワーク番号 フィールドとサブネット番号フィールドを選択する32ビット のマスクとする。(マルチホームホストの場合、送信インター フェースのローカルIPアドレス固有のアドレスマスクとする)。 (b) アドレスマスクによって抽出されたIP宛先アドレスビットが 同じマスクによって抽出されたIP送信元アドレスビットと一致 する場合、宛先は対応する接続ネットワーク上に存在するので、 データグラムは宛先ホストに直接送信される。 (c) そうでない場合、宛先はゲートウェイを介してのみアクセス 可能である。ゲートウェイの選択は後ほど(セクション3.3.1.2) 記述される。 特別な宛先アドレスは以下のように対処される。 ・ リミテッドブロードキャストアドレスまたはマルチキャスト アドレスの場合、適切なインターフェースを介してリンク レイヤーにデータグラムをただ受け渡す。 Internet Engineering Task Force [Page 47] RFC1122 INTERNET LAYER October 1989 ・ (ネットワークまたはサブネットの)ディレクテッドブロード キャストの場合、データグラムに対して標準のルーティング アルゴリズムを使用できる。 ホストのIPレイヤーは、最小限のネットワーク環境、特にゲートウェイ が存在しない状況でも正しく動作しなければならない(MUST)。例えば、 ホストのIPレイヤーが初期設定のために最低一つのゲートウェイを発見 するよう要求している場合、そのホストは単一の切り離された ブロードキャストネットワーク上では動作できない。 3.3.1.2 ゲートウェイの選択 同じ宛先への一連のデータグラムを効率的にルーティングするため、 送信元ホストは、宛先と次ホップゲートウェイをマッピングする "ルートキャッシュ"を保持しなければならない(MUST)。ホストは、 データグラムをルーティングするため、このキャッシュを踏まえて 以下に示す基本アルゴリズムを使用する。このアルゴリズムは、 主要なルーティングの負荷をゲートウェイに負わせるように設計 されている[IP:11]。 (a) ルートキャッシュが特定の宛先に関する情報を保持していない 場合、ホストは"デフォルト"ゲートウェイを選択し、そこに データグラムを送信する。また、対応するルートキャッシュ エントリーも作成する。 (b) ゲートウェイが宛先への次ホップとして最善ではない場合、 そのゲートウェイはデータグラムを最善のゲートウェイに転送 し、送信元ホストにはICMPリダイレクトメッセージを返す。 (c) ホストがリダイレクトを受信すると、適切なルートキャッシュ エントリーの次ホップゲートウェイを更新するので、以後の 同じ宛先のデータグラムは、直ちに最善のゲートウェイに 向かうようになる。 一般に、宛先アドレスの適切なサブネットマスクはわからないので、 ネットワークリダイレクトメッセージはホストリダイレクトメッセージ と全く同じように扱われるべきである(SHOULD)。言い換えると、宛先 ホスト(だけ)に関するキャッシュエントリーが新しいゲートウェイに 更新される(か、宛先ホストに関するエントリーがない場合は生成 される)べきである(SHOULD)。 【 議論 】 この推奨は、ゲートウェイに関する要件[INTRO:2]に違反して、 サブネット化されたネットワークにネットワークリダイレクトを 誤って送信するゲートウェイからホストを保護するためのもの である。 Internet Engineering Task Force [Page 48] RFC1122 INTERNET LAYER October 1989 宛先ホストアドレスに関するルートキャッシュのエントリーがない (ことに加えて、宛先が接続ネットワーク上にない)場合、 IPレイヤーは、保持する"デフォルト"ゲートウェイの一覧表から ゲートウェイを選択しなければならない(MUST)。IPレイヤーは、複数 のデフォルトゲートウェイをサポートしなければならない(MUST)。 追加機能として、ホストのIPレイヤーは、"静的ルート"のテーブルを 実装してもよい(MAY)。そのような個々の静的ルートは、ICMP リダイレクトによって上書きできるかどうかを指定するフラグを 含んでいてもよい(MAY)。 【 議論 】 ホストは、一般に動作を開始するにあたり少なくとも一つ ゲートウェイを知っている必要がある。この情報は、設定 ファイルか、例えばBOOTPプロトコル([INTRO:1]参照)等の ホストの起動手順から取得することができる。 ホストは、新たに学習したゲートウェイを何であれ記録する ことにより、デフォルトゲートウェイの一覧表を補強できる ことが示唆されている。例えば、ホストはこれまでにリダイレクト で指示された新しいゲートウェイをそれぞれ記録することが できる。そのような機能は、一部の状況では恐らく有用だが、 他の事例(例えばゲートウェイがすべて同等ではない場合)では 問題を引き起こす可能性があり、推奨されない。 静的ルートは、通常、宛先ホストまたは宛先ネットワークから 特定の次ホップゲートウェイへの事前に設定されたマッピング である。これはタイプオブサービスにも依存するかもしれない (次セクション参照)。静的ルートは、例外的な状況に対処する ため、通常の自動ルーティングの仕組みを上書きするために システム管理者によって設定される。しかし、どのような静的 ルーティングの情報でも、設定の変更や機器の障害などが 起きると、障害の原因となる可能性がある。 3.3.1.3 ルートキャッシュ 各ルートキャッシュエントリーは、以下のフィールドを含む必要が ある。 (1) ローカルIPアドレス (マルチホームホストの場合) (2) 宛先IPアドレス (3) タイプオブサービス (4) 次ホップゲートウェイのIPアドレス フィールド(2)は、宛先ホストの完全なIPアドレスでもよいし、 宛先ネットワーク番号だけであってもよい(MAY) Internet Engineering Task Force [Page 49] RFC1122 INTERNET LAYER October 1989 フィールド(3)のTOSは含まれるべきである(SHOULD)。 キャッシュの検索処理におけるマルチホーム接続の影響に関する 議論は、セクション3.3.4.2を参照せよ。 【 議論 】 タイプオブサービスフィールドをルートキャッシュに組み込み、 ホストルートアルゴリズムでそれを考慮できるようにする ことは、タイプオブサービスに基づくルーティングが インターネットで一般的に使用される将来のために必要な 仕組みを提供するだろう。セクション3.2.1.6を参照せよ。 各ルートキャッシュエントリーは、インターネットパスの エンドポイントを定義する。ホストとエンドポイントを接続 するパスは任意の方法で動的に変化することもあるが、パス の転送特性は、典型的な単一のホスト-ホスト間のデータ転送 接続時間よりも長い期間にわたってほぼ一定のまま維持される 傾向がある。従って、ルートキャッシュのエントリー は、パスの特性に関するデータのキャッシュに適した場所 である。そのような特性の例として、フラグメンテーション されないデータグラムの最大サイズ(セクション3.3.3参照)や、 トランスポートプロトコルによって測定された平均ラウンド トリップ遅延などが考えられる。このデータは、一般に上位層 のプロトコル、例えばTCPや、UDPを使用するアプリケーション によって収集され使用される。この方式のパス特性のキャッシュ に関する実験が現在進行中である。 ルートキャッシュ検索にあたり、宛先ホストアドレスだけで 検索されるべきなのか、ホストアドレスとネットワークアドレス の両方を許容すべきなのかに関する合意は存在しない。 ホストアドレスのみの使用を支持する人々は、以下のように 主張している。 (1) セクション3.3.1.2で要求されるように、リダイレクト メッセージは一般に宛先ホストアドレスで検索される エントリーを生成するので、最も単純で最も一般的な 仕組みはホストアドレスを常に使用することである。 (2) 複雑にサブネット化された環境の場合、ネットワーク アドレスのアドレスマスクをIPレイヤーが常に知って いるとは限らない。 (3) ホストアドレスのみを使用することにより、宛先アドレス を純粋な32ビットの数字として扱うことができるように なる。これにより、将来、ホストに一切変更を加えること なくインターネットアーキテクチャーを容易に拡張する ことが可能となる。 Internet Engineering Task Force [Page 50] RFC1122 INTERNET LAYER October 1989 これに反対する意見は、ルートキャッシュ内で宛先ホスト アドレスとネットワークアドレスを混在させることで、 以下の事柄が可能になるというものである。 (1) メモリ空間を節約する。 (2) キャッシュとデフォルトルート、静的ルートのテーブルを 容易に組み合わせられることで、よりシンプルなデータ 構造をもたらす(後述)。 (3) 先に議論したパス特性をキャッシュするためのより便利な 場所を提供する。 【 実装 】 キャッシュは、一度に使用される可能性のある宛先ホストの 最大数をエントリーとして保持するのに十分な大きさを持つ 必要がある。 また、ルートキャッシュは置き換えるエントリーを選択する 際に使用される制御情報も含むかもしれない。これは例えば "最近使用された(recently used)"ことを示すビット、使用 回数、あるいは最後に使用された時点のタイムスタンプなどの 形式をとるだろう。診断目的のために制御情報にエントリー の最終変更時刻を含めることが推奨される。 実装は、転送されるデータグラムそれぞれに対してルート キャッシュを調査するオーバーヘッドを削減したいと望むかも しれない。これは、ハッシュテーブルを使用して検索を高速化 したり、コネクション指向のトランスポートプロトコルに 適切なキャッシュエントリーの"ヒント"や一時的ハンドルを 提供し、それを後続のデータグラムそれぞれと共にIPレイヤー に渡すようにすることで達成されるだろう。 これまでルートキャッシュ、デフォルトゲートウェイの一覧表、 及び静的ルートのテーブルは概念的に違うと記述してきたが、 実際には、それらは組み合わされて単一の"ルーティングテーブル" データ構造になることもある。 3.3.1.4 停止ゲートウェイの検知 IPレイヤーは、ルートキャッシュの中に列挙されている"次ホップ" ゲートウェイの障害を検知し、代替ゲートウェイを選択できなければ ならない(MUST)(セクション3.3.1.5参照)。 停止ゲートウェイの検知については、RFC 816[IP:11]である程度 詳細がカバーされている。 Internet Engineering Task Force [Page 51] RFC1122 INTERNET LAYER October 1989 今日までの経験は、幾つかの使用禁止パスを特定したり、有望な 技法を見出したりはしたが、全体的に満足できる完全なアルゴリズム を作り出せてはいない。 ・ 特定のゲートウェイは、それが機能しているという肯定的 な兆候がない場合、無期限に使用されるべきではない (SHOULD NOT)。 ・ "ping発行"(ICMPエコーリクエスト/エコーリプライのやりとり) のような能動的調査はコスト的に高価であり、十分スケール しない。特に、ホストは第1ホップゲートウェイの状態を 能動的に検査するにあたり、単純にゲートウェイに向けて 継続的なping発行をするという手段を選んではならない (MUST NOT)。 ・ ping発行がゲートウェイの状態を検証する唯一の有効な 方法であるとしても、トラフィックがゲートウェイに送信 中であり、かつゲートウェイが機能していることを示唆 する肯定的兆候が存在しない場合に限りping発行が実行 されなければならない(MUST)。 ・ ping発行を回避するため、インターネットレイヤーの上位、 下位のどちらかあるいは両方のレイヤーは、肯定的情報 (ゲートウェイ稼働中)、否定的情報(ゲートウェイ停止)の どちらかの情報が利用可能である場合、ルートキャッシュ のエントリーの状態に関する"助言"ができるようにすべき である(SHOULD)。 【 議論 】 実装が停止ゲートウェイを検知して再ルーティングする適切 な仕組みを保持していない場合、ゲートウェイの障害により、 データグラムが"ブラックホール"に吸い込まれて消えていく ように見える状態になる。この障害は、ユーザーを著しく 混乱させると同時に、ネットワーク担当者にとってデバッグ が困難なものである。 停止ゲートウェイ検知の仕組みは、ホスト、接続ネットワーク、 第1ホップゲートウェイのどれに対しても許容できない負荷を 生じさせてはならない。停止ゲートウェイ検知の適時性と許容 可能な負荷に関する厳密な制約は、ホストの役割に応じて若干の 違いがあるが、ホストは、一般に、トランスポートレイヤー 接続を途切れさせない程度に十分な速さで障害を起こした第1 ホップゲートウェイを検知し、代替ゲートウェイを選択できる 必要がある。 プロトコルスタックの他のレイヤーからの助言を渡す操作は レイヤー間のインターフェースを複雑にするが、停止ゲート ウェイ検知の望ましいアプローチである。 Internet Engineering Task Force [Page 52] RFC1122 INTERNET LAYER October 1989 助言は、IP/TCPアーキテクチャーのあらゆる部分からやってくる 可能性があるが、主としてトランスポートレイヤーとリンク レイヤーから来ると期待される。以下は、ゲートウェイに関する 助言の要因となるかもしれないものである。 ・ TCPや任意のコネクション指向型トランスポートプロトコル は、例えば度を越えた再送をきっかけとして否定的な 助言ができるはずである。 ・ TCPは、(新しい)データの受領確認がなされた際に肯定的 な助言をしてもよい。たとえルートが非対称であっても、 新しいデータに対するACKは、受領確認されたデータが 正常に転送されたはずであることを証明する。 ・ 特定のゲートウェイからのICMPリダイレクトメッセージは、 そのゲートウェイに関する肯定的な助言として使用される べきである。 ・ ホスト障害を確実に検知し報告するリンクレイヤー情報 (例えばARPANET宛先停止(Destination Dead)メッセージ) は否定的な助言として使用されるべきである。 ・ ARPの失敗またはARPマッピングの再検証の失敗は、対応 するIPアドレスに関する否定的な助言として使用される べきである。 ・ 特定のリンクレイヤーアドレスから到着したパケットは、 そのアドレスが生きている証拠である。しかし、この情報 をゲートウェイに関する助言に変換するには、リンク レイヤーアドレスからIPアドレスへのマッピングを行い、 その後そのIPアドレスをルートキャッシュに指し示される ゲートウェイと照合する必要がある。これは恐らく 極めて非効率である。 受信したデータグラムすべてについて肯定的な助言が与え られると、実装に許容できないオーバーヘッドをもたらす かもしれないことに注意せよ。 IPレイヤーへのすべてのインターフェースにおいて、必要な 引数を使用して助言が渡されることになるだろうが、一部の トランスポートプロトコル及びアプリケーションレイヤー プロトコルは、正しい助言を導出できない。常に肯定的な 助言、常に否定的な助言のどちらかは不適切な振る舞いの 原因となるので、これらのインターフェースは助言に関して 中立的な値を許容しなければならない。 一般に使用されてきているが推奨されていないもう１つの 停止ゲートウェイ検知方法が存在する。 Internet Engineering Task Force [Page 53] RFC1122 INTERNET LAYER October 1989 この技法は、ゲートウェイが互いにブロードキャスト通信 しあうIGP(インテリアゲートウェイプロトコル)をホストが 受動的に受信("通信傍受")することに依存する。この アプローチには、ゲートウェイが使用するかもしれないすべて のIGP([INTRO:2]参照)をホストが認識しなければならない という欠点がある。そのうえ、ブロードキャストネット ワーク上でしか動作しない。 現在のところ、ゲートウェイの調査が絶対に必要な場合に、 それを行う仕組みはping発行(ICMPエコーメッセージの使用) である。pingの成功は、アドレス指定されたインターフェース とそれに関連する機器が稼働していることを保証するが、 その機器がホストではなくゲートウェイであるということ は保証しない。通常の推論では、リダイレクトまたは他の 証拠によってその機器がゲートウェイであったことが示されて いる場合、pingの成功はその機器が稼働していることを意味 するので、現在もゲートウェイとして機能していると判断 する。しかし、ゲートウェイであれば転送またはリダイレクト したであろうパケットをホストは黙って破棄するので、この 想定は失敗することもあり得る。この問題を回避するため、 開発中の新しいICMPメッセージは"あなたはゲートウェイか？" と尋ねるものになる。 【 実装 】 以下の固有のアルゴリズムがこれまでに提案されている。 ・ ルートキャッシュに指し示される各ゲートウェイに "リルートタイマー"を関連付ける。タイマーを値Trに 初期設定する。この値は、トランスポート接続がタイム アウトする前に停止ゲートウェイを検知できる程度に 十分小さいものでなければならない。 ・ 肯定的な助言は、リルートタイマーをTrにリセットする。 否定的な助言は、リルートタイマーを減らすかゼロに する。 ・ IPレイヤーがデータグラムをルーティングするために特定の ゲートウェイを使用するたびに、対応するリルートタイマー を検査する。タイマーが満了していた(ゼロに達していた) 場合、IPレイヤーはゲートウェイにpingを送信し、その 直後にデータグラムを続けるようにする。 ・ 必要に応じて、ping(ICMPエコー)はN回まで再送信される。 N回の試行でping応答が受信されなかった場合、そのゲート ウェイは障害に陥ったものと見なされ、障害ゲートウェイ が指定されているすべてのキャッシュエントリーに対して 新しい第1ホップゲートウェイが選択される。 Internet Engineering Task Force [Page 54] RFC1122 INTERNET LAYER October 1989 Trの大きさと利用可能な助言の量は逆相関するものになる ことに注意せよ。Trは、以下を保証するために十分な大きさ にすべきである。 ・ どのようなping発行であっても、ホストからゲートウェイ に送信される全パケットに占める割合が低いレベル (例えば10%未満)になる。 ・ 上の項目を満たし、かつping発行の頻度が低い(例えば 3分ごと)。 推奨されるアルゴリズムは、ルートキャッシュのエントリー それ自体ではなくキャッシュエントリーに指し示される ゲートウェイに関係するため、ルートキャッシュの実装に 際して、2階層のデータ構造(恐らく、ARPキャッシュまたは 類似のキャッシュと協調するものになる)が望ましいだろう。 3.3.1.5 新しいゲートウェイの選択 障害ゲートウェイが現在のデフォルトではない場合、IPレイヤーは 直ちにデフォルトゲートウェイに切り替えることができる。 現在のデフォルトが障害に陥った場合、IPレイヤーは、障害の影響下 にあるルートに対して新しいルートを確立するために、異なる デフォルトゲートウェイを選択(二つ以上のデフォルトが既知であると 想定する)しなければならない(MUST)。 【 議論 】 ゲートウェイに障害が起きると、接続ネットワーク上にある 他のゲートウェイは、何らかのゲートウェイ間ルーティング プロトコルを通してその障害を学習する。しかし、それが 直ちに起きるわけではない。ゲートウェイルーティング プロトコルは通常、何らかの変化の収束に30-60秒を要する からである。代替ゲートウェイが障害に同意する前にホストが そのゲートウェイに切り替えると、新しい目標ゲートウェイは 恐らくデータグラムを障害ゲートウェイに転送し、ホストには 障害ゲートウェイを指し示すリダイレクトを送り返すだろう(!) 結果として、ゲートウェイの障害収束期間中はホストのルート キャッシュの内容が急激に変動する可能性がある。そのような 変動を防止するため、停止ゲートウェイの対処に関する論理は、 何らかのヒステリシスの仕組みを含むべきであるとの提案が なされている。しかし、経験はそのような変動によるいかなる 弊害も指摘していない。ゲートウェイのルーティング情報が 収束するまでホストがサービスを取り戻すことはあり得ない からである。 【 実装 】 新しいデフォルトゲートウェイ選択の実装方法の一つに、ホスト が保持する一覧表に含まれるデフォルトゲートウェイを単純に ラウンドロビンで選択するというものがある。 Internet Engineering Task Force [Page 55] RFC1122 INTERNET LAYER October 1989 別の方法は、ゲートウェイを優先度で順位付けしておき、現在の デフォルトゲートウェイが最高の優先度を持つものでない場合、 より高い優先順位のゲートウェイにゆっくりと"ping"を行い、 それらのサービスが復旧したら検知するというものである。 このping発行は、非常に低いレート、例えば毎秒0.005回にする こともできる。 3.3.1.6 初期設定 以下の情報は設定可能でなければならない(MUST)。 (1) (複数の)IPアドレス (2) (IPアドレス数と同数の)アドレスマスク (3) 優先度を含むデフォルトゲートウェイの一覧表 この設定データを手動で入力する方法が提供されなければならない (MUST)。更に、この情報を動的に決定できるさまざまな方法が使用可能 である。[INTRO:1]の"ホストの初期設定"セクションを参照せよ。 【 議論 】 一部のホスト実装は、どのようなゲートウェイが存在するか を学習するために、ブロードキャストネットワーク上でゲート ウェイプロトコルの"通信傍受"を行う。デフォルトゲート ウェイを探索する標準的な方法は開発中である。 3.3.2 再構成 IPレイヤーは、IPデータグラムの再構成を実装しなければならない (MUST)。 再構成可能な最大データグラムサイズをEMTU_R("Effective MTU to receive: 実効受信MTU")で示すものとする。これは"再構成バッファー サイズ"と呼ばれることもある。EMTU_Rは576以上でなければならず (MUST)、設定可能であるか無制限かのどちらかにすべきであり(SHOULD)、 接続ネットワークのMTU以上にすべきである(SHOULD)。 【 議論 】 一部のアプリケーションレイヤープロトコルは576を越える EMTU_R値を要求するため、EMTU_Rの上限を指定する固定値が コードに組み込まれるべきではない。 【 実装 】 実装は、各データグラムに対して連続的な再構成バッファーを 使用してもよいし、再構成データグラムサイズに関して明確な 制限を設けないより複雑なデータ構造を使用してもよい。 後者の場合、EMTU_Rは"無制限"であると言う。 Internet Engineering Task Force [Page 56] RFC1122 INTERNET LAYER October 1989 論理的には、各フラグメントを適切なオフセットでパケット バッファーに単純にコピーするだけで再構成は実行される。 連続する再送において、異なったパケット化を行っていても 同じ再構成IDを使用する場合、フラグメントが重なり合う かもしれないことに注意せよ。 再構成の扱いにくい部分は、データグラムのすべてのバイトが 再構成された瞬間を判定するための台帳処理である。我々は、 台帳処理のために追加のデータ空間を必要としないClarkの アルゴリズム[IP:10]を推奨する。しかし、[IP:10]に反して、 生成され得るICMP時間超過(再構成タイムアウト)メッセージ に含めるため、最初のフラグメントヘッダーは保存される 必要がある。 トランスポートレイヤーがMMS_R、つまりIPデータグラムに含まれて 受信及び再構成可能な最大メッセージサイズを学習できる仕組みが なければならない(MUST)(セクション3.4のGET_MAXSIZESコールを 参照せよ)。EMTU_Rが無制限でない場合、MMS_Rの値は以下の式で 与えられる。 MMS_R = EMTU_R - 20 なぜなら、IPヘッダーの最小サイズが20だからである。 再構成タイムアウトが設定されなければならない(MUST)。再構成タイム アウト値は、残存TTLから設定するのではなく、固定値にすべきである (SHOULD)。60秒から120秒の間に位置する値が推奨される。このタイム アウトが満了した場合、部分的に再構成されたデータグラムは破棄され なければならず(MUST)、また(オフセットゼロの先頭フラグメントが 受信されている場合)ICMP時間超過メッセージが送信元ホストに送信 されなければならない(MUST)。 【 議論 】 IP仕様は、IPヘッダーから得られた残存TTLを再構成タイムアウト とすべきだと述べている。しかし、ゲートウェイは一般にTTLを 経過時間ではなく単純にホップカウントとして扱うため、これは うまく機能しない。再構成タイムアウトが小さすぎると、データ グラムが不必要に破棄され、通信が失敗するかもしれない。 タイムアウトは、少なくともインターネットを横断する際の 一般的な最大遅延と同じ程度に大きい必要がある。現実的な 再構成タイムアウトの最小値は60秒だろう。 さまざまな宛先に対して、トランスポートプロトコルに測定された ラウンドトリップタイムをキャッシュとして保持しておき、 それらの値を使用して妥当な再構成タイムアウト値を動的に 決定することが提案されている。 Internet Engineering Task Force [Page 57] RFC1122 INTERNET LAYER October 1989 このアプローチのさらなる調査が必要である。 再構成タイムアウトの設定値が大きすぎると、受信ホストの バッファーリソース拘束時間が極めて長くなり、MSL(Maximum Segment Lifetime: 最大セグメント生存時間)[TCP:1]も必要以上 に大きくなる。MSLは、それぞれ異なる16ビットの識別番号 フィールド値を使用して、フラグメンテーションされたデータ グラムを送信できる最大レートを制御する。具体的に、MSLが 大きくなると最大レートは小さくなる。TCP仕様[TCP:1]は、 MSLに対して2分という値を独自に想定している。これにより 妥当な再構成タイムアウトの上限が設定される。 3.3.3 フラグメンテーション IPレイヤーは、送出するデータグラムを意図的にフラグメンテーション する仕組みを任意で実装してもよい(MAY)。 IP送信元アドレスとIP宛先アドレス、そして恐らくはTOSの特定の 組み合わせで送信される最大IPデータグラムサイズをEMTU_S ("Effective MTU for sending: 実効送信MTU")で示すものとする。 ホストは、トランスポートレイヤーがMMS_S、つまり与えられた{送信元、 宛先、TOS}のトリプレットに対して送信されるトランスポートレイヤー の最大メッセージサイズを学習できる仕組みを実装しなければならない (MUST)(セクション3.4のGET_MAXSIZESコールを参照せよ)。ローカルな フラグメンテーションが実行されない場合、MMS_Sの値は以下の式で与え られる。 MMS_S = EMTU_S - また、EMTU_Sはデータグラムの送信元アドレスに対応するネットワーク インターフェースのMTU以下でなければならない。式に含まれるは、IPが独自の目的やトランスポートレイヤーに挿入される あらゆるオプションのためにオプション空間を予約しない限り20になる ことに注意せよ。 ローカルなフラグメンテーションを実装しないホストは、トランス ポートレイヤー(TCPの場合)またはアプリケーションレイヤー(UDPの 場合)がIPレイヤーからMMS_Sを取得し、MMS_Sを越えるサイズのデータ グラムを送信しないことを保証しなければならない(MUST)。 一般に、ローカルなフラグメンテーションを回避し、パス上にある あらゆるゲートウェイでもフラグメンテーションを回避できる程度に 十分小さいEMTU_Sを選択することが望ましい。パスの最小MTUに関する 知識がない場合、IPレイヤーは、宛先アドレスが接続ネットワーク上 にない場合は常に576以下のEMTU_Sを使用し、接続ネットワーク上に ある場合は接続ネットワークのMTUを使用すべきである(SHOULD) Internet Engineering Task Force [Page 58] RFC1122 INTERNET LAYER October 1989 各物理インターフェースのMTUは設定可能でなければならない(MUST)。 ホストのIPレイヤー実装は、同じネットワーク内の異なるサブネット 上にある宛先に対しては接続ネットワークのMTUが使用されるが、 他のネットワークに対してはそのMTUが使用されないことを示す "All-Subnets-MTU"設定フラグを保持してもよい(MAY)。言い換える と、このフラグはEMTU_Sの選択にあたり、サブネットマスクではなく ネットワーククラスマスクが使用されるようにするものである。 マルチホームホストの場合、ネットワークインターフェースごとに "All-Subnets-MTU"フラグが必要となる。 【 議論 】 データ送信時に使用する正しいデータグラムサイズの選択は 複雑な話題である[IP:9]。 (a) 一般に、ホストは(ヘッダーとデータを含めて)576バイトを 越える大きさのIPデータグラムの受理を要求されないので、 ホストは、宛先ホストに関する明示的な知識や宛先ホストとの 事前調整なしに576バイトを越えるデータグラムを送信しては ならない。従って、MMS_Sはトランスポートプロトコルが 送信してもよいデータグラムサイズの上限に過ぎない。たとえ MMS_Sが556を越える場合であっても、宛先ホストに関する他の 知識がない場合、トランスポートレイヤーはメッセージを 556バイトに制限しなければならない。 (b) 一部のトランスポートプロトコル(例えばTCP)は、送信者に 対し、相手方が受信して再構成可能な最大データグラムに 関する情報を明示的に通知する方法を提供する[IP:7]。 IPレイヤーにはこれに相当する仕組みが存在しない。 576を越える大きさのEMTU_Rを想定するトランスポート プロトコル(セクション3.3.2参照)は、同じプロトコルを 実装する別のホストにより大きいサイズのデータグラムを 送信することができる。 (c) 理想的には、あらゆるフラグメンテーションを回避する ため、ホストは与えられた宛先に対して使用されるEMTU_Sを 宛先へのパス上にある全ネットワークの最小MTUに制限すべき である。IPフラグメンテーションは公式には正しい処理だが、 トランスポートプロトコルの深刻なパフォーマンス問題を 生じさせる可能性がある。セグメント内の単一フラグメント の消失により、全フラグメントが再送されなければならなく なるからである[IP:9]。 Internet Engineering Task Force [Page 59] RFC1122 INTERNET LAYER October 1989 インターネットを構成するほぼすべてのネットワークは、現在576以上 のMTUをサポートしているため、ローカルでないネットワークに送信 されるデータグラムには576を使用することを強く推奨する。 ホストは、オフセットゼロのデータグラムフラグメントを送信し、 受信者が再構成をタイムアウトして(再構成は原理上完了できない!) ICMP時間超過メッセージを返すのを待つことにより、与えられた パスのMTUを判定できるかもしれないことが示唆されている。 このメッセージは、受信側に残された最大のフラグメントの ヘッダーを含むだろう。より直接的な仕組みが現在実験中だが、 まだ採用されていない(例えばRFC 1063を参照せよ)。 3.3.4 ローカル側のマルチホーム接続 3.3.4.1 導入 マルチホームホストは複数のIPアドレスを持つ。それらは"論理 インターフェース"と考えられるだろう。これらの論理インター フェースは一つ以上の物理インターフェースに関連付けられて いてもよく、またそれらの物理インターフェースが接続される のは同じネットワークでも別のネットワークでも構わない。 以下にマルチホーム接続の重要な事例を幾つか示す。 (a) 複数の論理ネットワーク インターネットの設計者は、各物理ネットワークは単一の 一意なIPネットワーク(またはサブネット)番号を持つだろう と想定していた。しかし、この想定に違反し、物理的な接続 ネットワークごとに複数の論理ネットワークを持つLANを運用 すると便利であることにLAN管理者が気づくことがある。 そのような物理ネットワークに接続されたホストがN個の 異なる論理ネットワークそれぞれに宛てられたトラフィック を扱うように設定されている場合、そのホストはN個の論理 インターフェースを保持することになる。N個の論理インター フェースは単一の物理インターフェースを共有するかも しれないし、同じネットワークに接続された物理インター フェースをN個使用するかもしれない。 (b) 複数の論理ホスト ホストが複数のIPアドレスを持ち、それらすべてが同じ <ネットワーク番号>部(及び、存在する場合は同じ <サブネット番号>部)である場合、それらの論理インター フェースは"論理ホスト"と呼ばれる。これらの論理インター フェースは、単一の物理インターフェースを共有するかも しれないし、同じ物理ネットワークに接続されたそれぞれ 独立した物理インターフェースを使用するかもしれない。 Internet Engineering Task Force [Page 60] RFC1122 INTERNET LAYER October 1989 (c) 単純なマルチホーム接続 この場合、各論理インターフェースは、それぞれ独立した 物理インターフェースにマッピングされ、各物理インター フェースはそれぞれ異なる物理ネットワークに接続される。 "マルチホーム接続"という用語は、本来この事例にだけ適用 されていたが、現在ではより一般的に適用されている。 組み込みゲートウェイ機能を持つホストは、通常の場合 単純なマルチホーム接続の事例に分類される。しかし、 ホストは、組み込みゲートウェイ機能が無くても、つまり 片方の接続ネットワークからもう片方へとデータグラムを 転送しなくても、単純なマルチホーム接続となっている場合 があることに注意せよ。 この事例は、最も困難なルーティング問題を提起する。 インターフェースの選択(つまり第1ホップネットワークの 選択)がパフォーマンスやインターネットのリモート部への 到達性にさえ大きな影響を与える可能性がある。 最後に、マルチホーム接続"ではない"別の可能性について注記して おく。直接接続された機器間の通信の信頼性やスループットの向上を 目的として機器間に代替物理パスを提供するため、一つの論理インター フェースが複数の物理インターフェースに結び付けられている場合 がある。例えば、二つのシステムは複数のポイントツーポイントの リンクで接続されているかもしれない。これを"リンクレイヤー多重 (link-layer multiplexing)"と呼ぶ。リンクレイヤー多重が使用 されている場合、リンクレイヤーより上位に位置するプロトコルは、 複数の物理インターフェースが存在することを意識しない。その 場合、リンクレイヤードライバーが複数の物理インターフェース間 にまたがる多重化とパケットルーティングの責任を負う。 インターネットプロトコルアーキテクチャーでは、トランスポート プロトコルインスタンス("エンティティ")は自身のアドレスを 持たず、代わりに単一のインターネットプロトコル(IP)アドレス を使用する。これは、IPレイヤー、トランスポートレイヤー、 アプリケーションレイヤーすべてと、それらのレイヤー間のインター フェースに影響する。特に、アプリケーションソフトウェアは、 マルチホームホストの複数のIPアドレスを意識して使い分け なければならない場合がある。それ以外の場合は、IPアドレスの 選択をネットワークソフトウェアの中で行うことができる。 3.3.4.2 マルチホーム接続の要件 マルチホームホストからデータグラムを送信する際のIP送信元 アドレス選択には、以下の一般的なルールが適用される。 Internet Engineering Task Force [Page 61] RFC1122 INTERNET LAYER October 1989 (1) 受信したデータグラムの応答でデータグラムが送信される場合、 応答の送信元アドレスは、リクエストの特定宛先アドレスに すべきである(SHOULD)。上位レイヤーに関するより具体的な要件 については、[INTRO:1]のセクション4.1.3.5及び4.2.3.7に 加えて、"一般的な課題"セクションを参照せよ。 そうでない場合、送信元アドレスは選択されなければならない。 (2) アプリケーションは、接続またはリクエストの開始にあたり、 使用される送信元アドレスを明示的に指定できなければ ならない(MUST)。 (3) そのような指定がない場合、ネットワーキングソフトウェアは 送信元アドレスを選択しなければならない(MUST)。この選択で 使用されるルールは後ほど記述される。 マルチホーム接続に関連して、議論の的となる二つの主要な要件が 存在する。 (A) ホストは、受信した物理インターフェースに対応していない 宛先アドレスを持つ到着データグラムを黙って破棄してもよい (MAY)。 (B) ホストは、データグラムのIP送信元アドレスに対応する物理 インターフェースを通してのみ(ソースルート指定されていない) IPデータグラムを送信するように自身を制限してもよい(MAY)。 【 議論 】 インターネットホストの実装者は、マルチホーム接続に関する 二つの異なる概念モデルを使用してきた。以下の議論でその概略 が示される。本文書は、どちらのモデルが優れているかについて いかなる立場もとらない。どちらにも役割があるように思われる。 この両面性は、要件(A)と(B)が任意であることに反映されて いる。 ・ 強いESモデル 強いES(エンドシステム、つまりホスト)モデルは、 ホスト/ゲートウェイ(ES/IS)の区別を強調するため、 上記の要件(A)、(B)のMAYをMUSTに置き換える。この モデルは、どちらかと言えばマルチホームホストを 同じ物理ホスト内にある論理ホストの集合として モデル化するものである。 Internet Engineering Task Force [Page 62] RFC1122 INTERNET LAYER October 1989 要件(A)に関して、強いESモデルの支持者は、自動的な インターネットルーティングの仕組みは宛先アドレス に対応しない物理インターフェースにデータグラムを ルーティングできなかったと指摘している。 強いESモデルに従う場合、送出するデータグラムの ルート計算は以下のマッピングとなる。 route(送信元IPアドレス, 宛先IPアドレス, TOS) ⇒ ゲートウェイ ここで、対応する物理インターフェースから直接到達可能 なゲートウェイを選択するために、送信元アドレスが パラメーターとして含まれている。このモデルは、各IP 送信元アドレスに対して少なくとも一つ、できれば複数の デフォルトゲートウェイが存在することを必然的に要求 することに注意せよ。 ・ 弱いESモデル この見解はES/ISの区別を重視しないため、上記の要件 (A)、(B)のMAYをMUST NOTに置き換える。このモデルは、 ゲートウェイルーティングプロトコルの通信傍受を行う ホストにとってより自然なものであり、組み込みゲート ウェイ機能を保持するホストには必要なものである。 弱いESモデルは、リダイレクトの仕組みを失敗させる 原因となるかもしれない。宛先アドレスに対応しない 物理インターフェースからデータグラムが送信される 場合、第1ホップゲートウェイは、どこにリダイレクト を送信する必要があるかを理解できないだろう。 その一方で、ホストが組み込みゲートウェイ機能を保持 する場合、ホストはリダイレクトを待って適応しなく ても、自身でルーティング情報を持っている。 弱いESモデルの場合、送出するデータグラムのルート 計算は以下のマッピングとなる。 route(宛先IPアドレス, TOS) ⇒ ゲートウェイ, インターフェース Internet Engineering Task Force [Page 63] RFC1122 INTERNET LAYER October 1989 3.3.4.3 送信元アドレスの選択 【 議論 】 接続開始リクエスト(例えばTCP"SYN"セグメント)やデータ グラムサービスのリクエスト(例えばUDPベースの問い合わせ)を 送信する場合、マルチホームホストのトランスポートレイヤー は、どの送信元アドレスを使用するかを知っている必要がある。 アプリケーションが送信元アドレスを指定しない場合、トランス ポートレイヤーは、IPレイヤーに以下の概念的マッピングを 実行するよう依頼しなければならない。 GET_SRCADDR(リモートIPアドレス, TOS) ⇒ ローカルIPアドレス ここで、TOSはタイプオブサービス値(セクション3.2.1.6参照) で、結果は望ましい送信元アドレスである。このマッピングを 実装するため、以下のルールを提案する。 (a) ホストが直接接続されている(サブ)ネットの一つの上に リモートインターネットアドレスがある場合、対応する インターフェースがダウンしていると分かっている場合 を除き、対応する送信元アドレスが選択される。 (b) ネットワークインターフェースのどれかから指定された 宛先への利用可能ルートがあるかを検査するために、 ルートキャッシュが参照される。ルートが存在する場合、 そのインターフェースに対応するローカルIPアドレスが 選択される。 (c) 静的ルートのテーブルがあるならば(セクション3.3.1.2)、 同様に参照される。 (d) デフォルトゲートウェイの一覧表が参照される。これらの ゲートウェイが異なるインターフェースに割り当てられて いる場合、最も高い優先度を持つゲートウェイに対応する インターフェースが選択される。 将来は、与えられた宛先に対して使用されるべき最善の ネットワークに関して、マルチホームホストが接続された 全ネットワーク上にあるゲートウェイに助言を依頼する 定義された方法が存在しているかもしれない。 【 実装 】 この処理は、本質的にデータグラムルーティング(セクション 3.3.1参照)と同じであるため、ホストは二つの機能の実装を 組み合わせられる可能性があることに気づくだろう。 Internet Engineering Task Force [Page 64] RFC1122 INTERNET LAYER October 1989 3.3.5 ソースルート指定されたデータグラムの転送 後ほど与えられる制限を条件として、ホストはソースルートの中間 ホップとして動作する、つまりソースルート指定されたデータグラム を指定された次ホップに転送してもよい(MAY)。 しかし、このゲートウェイに似た機能の実行にあたり、ホストは ソースルート指定されたデータグラムを転送するゲートウェイに 適用される関連ルールすべて[INTRO:2]に従わなければならない(MUST)。 これは以下の固有の規定を含む。これらは、本文書の前の方で 与えられた対応するホストの規定を上書きする。 (A) TTL (セクション3.2.1.7参照) TTLフィールドはデクリメントされなければならず(MUST)、また データグラムは[INTRO:2]のゲートウェイの規定に従って破棄 されなければならない(MUST)。 (B) ICMP宛先到達不能(セクション3.2.2.1参照) ホストは、以下のコードを指定した宛先到達不能メッセージを 生成できなければならない(MUST)。 4 (フラグメンテーションが要求されたがDFが設定されて いる) ソースルート指定されたデータグラムをフラグ メンテーションして目標ネットワークに適合させること ができない場合 5 (ソースルート失敗) 例えば、ルーティングの問題や、 厳密なソースルート指定の次ホップが接続ネットワーク上 にない等の理由で、ソースルート指定されたデータグラム を転送できない場合。 (C) IP送信元アドレス(セクション3.2.1.3参照) 転送中のソースルート指定されたデータグラムは、転送ホスト のIPアドレスの一つではない送信元アドレスを持ってもよい (MAY)(通常はそのようになる)。 (D) ルート記録オプション(セクション3.2.1.8d参照) ルート記録オプションを含むソースルート指定されたデータ グラムを転送するホストは、オプション空間にまだ空きがある ならば、オプションを更新しなければならない(MUST)。 (E) タイムスタンプオプション(セクション3.2.1.8e参照) タイムスタンプオプションを含むソースルート指定されたデータ グラムを転送するホストは、そのオプションのルールに従って Internet Engineering Task Force [Page 65] RFC1122 INTERNET LAYER October 1989 オプションに現時点のタイムスタンプを追加しなければならない (MUST)。 ソースルート指定されたデータグラムを転送するホストを制限する ルールを定義するにあたり、次の用語を使用する。データグラムが 到着した物理インターフェースと同じインターフェースを経由した 先にネクストホップがある場合、"ローカルなソースルーティング" であると言い、そうでない場合は"非ローカルなソースルーティング" であると言う。 ・ ホストは、無制限にローカルなソースルーティングを実行する ことができる。 ・ 非ローカルなソースルーティングをサポートするホストは、転送 を無効にする設定切り替え機能を持たなければならず(MUST)、 切り替え設定のデフォルトは無効でなければならない(MUST)。 ・ ホストは、非ローカルな転送を制限するポリシーフィルター設定 に関するゲートウェイ要件[INTRO:2]すべてを満たさなければ ならない(MUST)。 ソースルート未完了のデータグラムをホストが受信し、何らかの理由 でそれを転送しない場合、データグラム自体がICMPエラーメッセージ でない限り、そのホストはICMP宛先到達不能(コード5、ソースルート 失敗)メッセージを返すべきである(SHOULD)。 3.3.6 ブロードキャスト セクション3.2.1.3において、以下に示す四つの標準的なIPブロード キャスト形式が定義された。 リミテッドブロードキャスト: {-1, -1} ディレクテッドブロードキャスト: {<ネットワーク番号>,-1} サブネットへのディレクテッドブロードキャスト: {<ネットワーク番号>,<サブネット番号>,-1} 全サブネットへのディレクテッドブロードキャスト: {<ネットワーク番号>,-1,-1} ホストは、到着データグラムの宛先アドレスにおいて、これらの 形式をどれであっても認識できなければならない(MUST)。 -1を0に置き換えた非標準のブロードキャストアドレス形式を使用 するホストのクラス(*)が存在する。 _________________________ (*)4.2BSD Unix及びその派生。ただし4.3BSDは該当しない。 Internet Engineering Task Force [Page 66] RFC1122 INTERNET LAYER October 1989 すべてのホストは、到着データグラムの宛先アドレスとしてこれらの 非標準のブロードキャストアドレスをどれであっても理解し受理 すべきである(SHOULD)。ホストは、各物理インターフェースで使用 されるブロードキャストアドレスが0形式か-1形式かを選択できる 設定オプションを任意で保持してもよい(MAY)が、オプションの デフォルトは標準(-1)形式にすべきである(SHOULD)。 ホストがリンクレイヤーブロードキャストアドレスにデータグラム を送信する場合、IP宛先アドレスは、正式なIPブロードキャスト アドレスかIPマルチキャストアドレスでなければならない(MUST)。 ホストは、リンクレイヤーブロードキャストを介して受信された データグラム(セクション2.4参照)が、宛先としてIPマルチキャスト アドレスまたはIPブロードキャストアドレスを指定されていない 場合、そのデータグラムを黙って破棄すべきである(SHOULD)。 ホストは、接続ネットワークにブロードキャストする際には リミテッドブロードキャストアドレスを使用すべきである(SHOULD)。 【 議論 】 ディレクテッドブロードキャストアドレスの代わりにリミテッド ブロードキャストアドレスを使用することにより、システムの ロバスト性を改善できる可能性がある。多くの場合、問題は、 多様なブロードキャストアドレス(セクション3.2.1.3参照)を 理解しない機器や、使用中のブロードキャストアドレスについて 異なる意見を持つ機器によって引き起こされる。後者の典型的な 例は、サブネット化を理解しないにもかかわらずサブネット化 されたネットワークに接続されている機器である。接続ネット ワークにサブネットブロードキャストを送信すると、それらの 機器は、他のホスト宛メッセージだと判断するので混乱させる ことになるだろう。 リミテッドブロードキャストアドレス宛のデータグラムは、マルチ ホームホストのインターフェースすべてから送信されるべきかに ついて議論が行われてきている。本仕様は、この課題に関して いかなる立場もとらない。 3.3.7 IPマルチキャスト通信 ホストは、クラスDのIPアドレスからリンクレイヤーアドレスへの マッピング(後述)が指定されている接続ネットワークすべてにおいて、 ローカルIPマルチキャスト通信をサポートすべきである(SHOULD)。 ローカルIPマルチキャスト通信のサポートは、マルチキャストデータ グラムの送信、マルチキャストグループへの参加、マルチキャスト データグラムの受信、マルチキャストグループからの離脱を含む。 これは、IGMPプロトコルを除く[IP:4]のすべてをサポートすることを 暗に意味している。IGMPのサポートは任意(OPTIONAL)である。 Internet Engineering Task Force [Page 67] RFC1122 INTERNET LAYER October 1989 【 議論 】 IGMPは、マルチキャストルーティング機能を持つゲートウェイ に対し、複数のネットワークにまたがるIPマルチキャスト通信を サポートするために必要な情報を提供する。現時点では、マルチ キャストルーティングゲートウェイは実験段階にあり、広く 利用可能な状況ではない。マルチキャストルーティングゲート ウェイを持たないネットワークに接続されたホスト、または 他ネットワーク上で生成されたマルチキャストデータグラムを 受信する必要のないホストにとって、IGMPは何の意味もない ので、現在のところ任意となっている。しかし、ローカル ブロードキャストアドレス体系の望ましい代替手段として ローカルネットワークマルチキャストアドレス体系へのアクセス をIPレイヤーに提供するため、[IP:4]の他の部分については 現在推奨とされている。IGMPは、マルチキャストルーティング ゲートウェイが広く利用可能になるだろう将来のある時点で 推奨になると予想される。 IGMPが実装されていない場合であっても、ホストは、IPレイヤーが 初期設定される際に"全ホスト"グループ(224.0.0.1)に参加し、IPレイヤー が機能している限りメンバーに残るべきである(SHOULD)。 【 議論 】 IGMPが実装されていなくても、"全ホスト"グループへの参加に より、厳密にローカルに使用されるマルチキャスト通信、例えば ゲートウェイ探索プロトコルをサポートできるだろう。 IPクラスDアドレスからローカルアドレスへのマッピングは、現在、 以下のタイプのネットワークに対して規定されている。 ・ イーサーネット/IEEE 802.3。[IP:4]で定義されている。 ・ ブロードキャストアドレス体系はサポートするが、マルチ キャストアドレス体系をサポートしないあらゆるネットワーク。 すべてのIPクラスDアドレスは、ローカルブロードキャスト アドレスにマップされる。 ・ あらゆるタイプのポイントツーポイントリンク(例えばSLIPや HDLCリンク)。マッピングは不要。すべてのIPマルチキャスト データグラムは、ローカルなフレームに入れられてそのまま 送信される。 他のタイプのネットワークに対するマッピングも将来規定される だろう。 ホストは、ホストの接続ネットワークのうちどれがIPマルチキャスト アドレス体系をサポートしているかを上位レイヤープロトコルまたは アプリケーションが判定できる手法を提供すべきである(SHOULD)。 Internet Engineering Task Force [Page 68] RFC1122 INTERNET LAYER October 1989 3.3.8 エラー報告 ホストは、ICMPエラーメッセージの返信が明確に禁止されている場合 を除き、それが現実的である場合は常にエラー検知時にICMPエラー データグラムを返さなければならない(MUST)。 【 議論 】 データグラムネットワークでよく見られる現象に"ブラックホール 病"というものがある。この状況に陥ると、データグラムが送信 されても何も戻らない。エラーデータグラムが何も戻らないと、 ユーザーは問題を把握することが困難になる。 3.4 インターネットレイヤー/トランスポートレイヤー間のインターフェース IPレイヤーとトランスポートレイヤー間のインターフェースは、オプション、 タイプオブサービス、TTLを含むIPレイヤーの仕組みすべてへの完全な アクセスを提供しなければならない(MUST)。トランスポートレイヤーは、 これらのインターフェースパラメーターを設定する仕組みを保持するか、 アプリケーションに指定されたそれらのパラメーターをIPレイヤーに渡す パスを提供するかのどちらかでなければならない(MUST)。 【 議論 】 アプリケーションは、これらの仕組みが適用可能な状況ならば、 たとえそれがインターネットで現在有効ではない仕組み(例えばTOS) であっても使用するよう要請される。そのようにすることで、 ホストソフトウェアの大幅な変更をすることなく、これらの仕組み が有効になった際に直ちに役立たせることができるようになる。 ここで、トランスポートレイヤーとIPレイヤー間の概念的インターフェース を一連のプロシージャーコールとして記述する。これは、RFC 791[IP:1] のセクション3.3にある情報の拡張である。 ・ データグラムの送信 SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result ) パラメーターはRFC 791で定義されている。Idパラメーターを渡すか は任意である。セクション3.2.1.5を参照せよ。 ・ データグラムの受信 RECV(BufPTR, prot => result, src, dst, SpecDest, TOS, len, opt) Internet Engineering Task Force [Page 69] RFC1122 INTERNET LAYER October 1989 以下のものを除き、すべてのパラメーターはRFC 791で定義されている。 SpecDest = データグラムの特定宛先アドレス (セクション3.2.1.3で定義) 結果として得られるパラメーターのdstは、データグラムの宛先アドレス を含む。これはブロードキャストアドレスまたはマルチキャストアドレス かもしれないため、SpecDestパラメーター(RFC 791では未提示)が 渡されなければならない(MUST)。パラメーターoptはデータグラムで 受信された全IPオプションを含む。これらもまたトランスポート レイヤーに渡されなければならない(MUST)。 ・ 送信元アドレスの選択 GET_SRCADDR(remote, TOS) -> local remote = リモートIPアドレス TOS = タイプオブサービス local = ローカルIPアドレス セクション3.3.4.3を参照せよ。 ・ 最大データグラムサイズの発見 GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S MMS_R = トランスポートメッセージの最大受信サイズ MMS_S = トランスポートメッセージの最大送信サイズ (local、remote、TOSは上で定義) セクション3.3.2及び3.3.3を参照せよ。 ・ 配送成功のための助言 ADVISE_DELIVPROB(sense, local, remote, TOS) パラメーターsenseは、肯定的または否定的な助言が与えられよう としているかを示す1ビットのフラグである。セクション3.3.1.4 の議論を参照せよ。他のパラメーターは以前に定義されている。 ・ ICMPメッセージの送信 SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt) -> result Internet Engineering Task Force [Page 70] RFC1122 INTERNET LAYER October 1989 (パラメーターはRFC 791で定義)。 Idパラメーターを渡すかは任意である。セクション3.2.1.5を参照 せよ。トランスポート層は、特定のICMPメッセージ、具体的にポート 到達不能やあらゆる要求メッセージを送信できなければならない (MUST)。当然ながら、この関数はSEND()コールの特殊な場合と 考えらえるが、明確化のために別々に記述している。 ・ ICMPメッセージの受信 RECV_ICMP(BufPTR ) -> result, src, dst, len, opt (パラメーターはRFC 791で定義)。 IPレイヤーは、特定のICMPメッセージを適切なトランスポート レイヤールーチンに渡さなければならない(MUST)。当然ながら、 この関数はRECV()コールの特殊な場合と考えらえるが、明確化 のために別々に記述している。 ICMPエラーメッセージの場合、上位レイヤーに渡されるデータは、 そのICMPエラーメッセージに保存されていたオリジナルの インターネットヘッダーとオリジナルメッセージの全オクテットを 含まなければならない(MUST)。このデータは、接続状況の情報が 存在する場合に、トランスポートレイヤーがそれを見つけるために 使用される。 具体的に、以下のICMPメッセージが上位レイヤーに渡される。 ・ 宛先到達不能 ・ 送信元抑制 ・ エコーリプライ(エコーリクエストがIPレイヤーで生成されて いない限り、ICMPユーザーインターフェースに渡される) ・ タイムスタンプリプライ(ICMPユーザーインターフェースに 渡される) ・ 時間超過 【 議論 】 将来、IPレイヤーとトランスポートレイヤー間でパスデータの受け渡し をするため(セクション3.3.1.3参照)、このインターフェースに追加が 行われるかもしれない。 Internet Engineering Task Force [Page 71] RFC1122 INTERNET LAYER October 1989 3.5 インターネットレイヤーの要件の概要 | | | | |S| | | | | | |H| | | | | | |O|M| | | |S| |U|U| | | |H| |L|S| | |M|O| |D|T|脚 | |U|U|M| | | | |S|L|A|N|N| | |T|D|Y|O|O|注 機 能 | ｾｸｼｮﾝ | | | |T|T| -------------------------------------------------|--------|-|-|-|-|-|-- | | | | | | | IPとICMP両方の実装 |3.1 |x| | | | | ｱﾌﾟﾘｹｰｼｮﾝﾚｲﾔｰによるﾘﾓｰﾄ側のﾏﾙﾁﾎｰﾑ接続の対処 |3.1 |x| | | | | ローカル側のマルチホーム接続のサポート |3.1 | | |x| | | データグラムを転送する場合ゲートウェイ仕様に準拠 |3.1 |x| | | | | 組み込みゲートウェイ用の切り替え設定 |3.1 |x| | | | |1 設定のデフォルトは非ゲートウェイモード |3.1 |x| | | | |1 ｲﾝﾀｰﾌｪｰｽ数に応じて自動でｹﾞｰﾄｳｪｲﾓｰﾄﾞに設定 |3.1 | | | | |x|1 破棄されたデータグラムのロギングを可能にする |3.1 | |x| | | | カウンターに記録 |3.1 | |x| | | | | | | | | | | バージョンが4でない場合は黙って破棄 |3.2.1.1 |x| | | | | IPﾁｪｯｸｻﾑを検証し、不正なﾃﾞｰﾀｸﾞﾗﾑは黙って破棄 |3.2.1.2 |x| | | | | アドレス体系: | | | | | | | サブネットアドレス体系(RFC 950) |3.2.1.3 |x| | | | | 送信元ｱﾄﾞﾚｽはﾎｽﾄ自身のIPｱﾄﾞﾚｽでなければならない|3.2.1.3 |x| | | | | 不正な宛先アドレスのデータグラムを黙って破棄 |3.2.1.3 |x| | | | | 不正な送信元アドレスのデータグラムを黙って破棄 |3.2.1.3 |x| | | | | 再構成のサポート |3.2.1.4 |x| | | | | 同一のデータグラムで同じIdフィールドを維持 |3.2.1.5 | | |x| | | | | | | | | | TOS: | | | | | | | トランスポートレイヤーがTOSを設定可能 |3.2.1.6 |x| | | | | 受信したTOSをトランスポートレイヤーに渡す |3.2.1.6 | |x| | | | TOSに対してRFC 795規定のﾘﾝｸﾚｲﾔｰﾏｯﾋﾟﾝｸﾞを使用 |3.2.1.6 | | | |x| | TTL: | | | | | | | TTLが0のパケット送信 |3.2.1.7 | | | | |x| TTL < 2の受信パケットを破棄 |3.2.1.7 | | | | |x| トランスポートレイヤーがTTLを設定可能 |3.2.1.7 |x| | | | | 固定TTL値使用時、その値が設定可能 |3.2.1.7 |x| | | | | | | | | | | | IPオプション: | | | | | | | トランスポートレイヤーがIPオプションを送信可能 |3.2.1.8 |x| | | | | 受信した全IPオプションを上位レイヤーに渡す |3.2.1.8 |x| | | | | Internet Engineering Task Force [Page 72] RFC1122 INTERNET LAYER October 1989 IPレイヤーは未知のオプションを黙って無視 |3.2.1.8 |x| | | | | セキュリティオプション |3.2.1.8a| | |x| | | ストリーム識別オプションの送信 |3.2.1.8b| | | |x| | ストリーム識別オプションを黙って無視 |3.2.1.8b|x| | | | | ルート記録オプション |3.2.1.8d| | |x| | | タイムスタンプオプション |3.2.1.8e| | |x| | | ソースルートオプション: | | | | | | | ソースルートオプションの起動と完了 |3.2.1.8c|x| | | | | ｿｰｽﾙｰﾄ完了したﾃﾞｰﾀｸﾞﾗﾑをﾄﾗﾝｽﾎﾟｰﾄﾚｲﾔｰに渡す |3.2.1.8c|x| | | | | 正しい(冗長でない)復路ルートの構築 |3.2.1.8c|x| | | | | 複数ｿｰｽﾙｰﾄｵﾌﾟｼｮﾝを一つのﾍｯﾀﾞｰ内で送信 |3.2.1.8c| | | | |x| | | | | | | | ICMP: | | | | | | | 未知のタイプのICMPメッセージを黙って破棄 |3.2.2 |x| | | | | ｵﾘｼﾞﾅﾙﾃﾞｰﾀｸﾞﾗﾑを8ｵｸﾃｯﾄを越えて含める |3.2.2 | | |x| | | 受信したものと同じオクテットを含める |3.2.2 |x| | | | | 適切なﾄﾗﾝｽﾎﾟｰﾄﾌﾟﾛﾄｺﾙを選択してICMPｴﾗｰを渡す |3.2.2 |x| | | | | TOS=0に設定したICMPエラーメッセージの送信 |3.2.2 | |x| | | | ICMPエラーメッセージの送信理由 | | | | | | | - ICMPエラーメッセージ |3.2.2 | | | | |x| - IPブロードキャストまたはIPマルチキャスト |3.2.2 | | | | |x| - リンクレイヤーブロードキャスト |3.2.2 | | | | |x| - 先頭でないフラグメント |3.2.2 | | | | |x| - 一意でない送信元アドレスのデータグラム |3.2.2 | | | | |x| (禁止されていない場合)ICMPｴﾗｰﾒｯｾｰｼﾞを返す |3.3.8 |x| | | | | | | | | | | | 宛先到達不能: | | | | | | | 宛先到達不能(コード2/3)の生成 |3.2.2.1 | |x| | | | ICMP宛先到達不能を上位レイヤーに渡す |3.2.2.1 |x| | | | | 上位レイヤーが宛先到達不能に基づいて動作 |3.2.2.1 | |x| | | | 宛先到達不能をヒントとしてのみ解釈 |3.2.2.1 |x| | | | | リダイレクト: | | | | | | | ホストがリダイレクトを送信 |3.2.2.2 | | | |x| | リダイレクト受信時にルートキャッシュ更新 |3.2.2.2 |x| | | | | ﾎｽﾄﾘﾀﾞｲﾚｸﾄとﾈｯﾄﾜｰｸﾘﾀﾞｲﾚｸﾄ両方への対応 |3.2.2.2 |x| | | | | 仕様に違反するリダイレクトの破棄 |3.2.2.2 | |x| | | | 送信元抑制: | | | | | | | バッファー超過時に送信元抑制送信 |3.2.2.3 | | |x| | | 送信元抑制を上位レイヤーに渡す |3.2.2.3 |x| | | | | 上位レイヤーが送信元抑制に基づいて動作 |3.2.2.3 | |x| | | | 時間超過: 上位レイヤーに渡す |3.2.2.4 |x| | | | | パラメーター不正: | | | | | | | パラメーター不正メッセージの送信 |3.2.2.5 | |x| | | | パラメーター不正を上位レイヤーに渡す |3.2.2.5 |x| | | | | パラメーター不正をユーザーに通知 |3.2.2.5 | | |x| | | | | | | | | | ICMPエコーリクエスト/リプライ: | | | | | | | エコーサーバー |3.2.2.6 |x| | | | | Internet Engineering Task Force [Page 73] RFC1122 INTERNET LAYER October 1989 エコークライアント |3.2.2.6 | |x| | | | ﾌﾞﾛｰﾄﾞｷｬｽﾄｱﾄﾞﾚｽ宛ｴｺｰﾘｸｴｽﾄの破棄 |3.2.2.6 | | |x| | | ﾏﾙﾁｷｬｽﾄｱﾄﾞﾚｽ宛ｴｺｰﾘｸｴｽﾄの破棄 |3.2.2.6 | | |x| | | ｴｺｰﾘﾌﾟﾗｲの送信元ｱﾄﾞﾚｽとして特定宛先ｱﾄﾞﾚｽ使用 |3.2.2.6 |x| | | | | エコーリプライで同じデータを送信 |3.2.2.6 |x| | | | | エコーリプライを上位レイヤーに渡す |3.2.2.6 |x| | | | | ルート記録、タイムスタンプオプションを反映 |3.2.2.6 | |x| | | | ソースルートオプションを反転して反映 |3.2.2.6 |x| | | | | | | | | | | | ICMP情報リクエスト/リプライ: |3.2.2.7 | | | |x| | ICMPタイムスタンプリクエスト/リプライ: |3.2.2.8 | | |x| | | 遅延のばらつき最小化 |3.2.2.8 | |x| | | |1 ﾌﾞﾛｰﾄﾞｷｬｽﾄｱﾄﾞﾚｽ宛ﾀｲﾑｽﾀﾝﾌﾟを黙って破棄 |3.2.2.8 | | |x| | |1 ﾏﾙﾁｷｬｽﾄｱﾄﾞﾚｽ宛ﾀｲﾑｽﾀﾝﾌﾟを黙って破棄 |3.2.2.8 | | |x| | |1 ﾀｲﾑｽﾀﾝﾌﾟﾘﾌﾟﾗｲの送信元として特定宛先ｱﾄﾞﾚｽ使用 |3.2.2.8 |x| | | | |1 ルート記録、タイムスタンプオプションを反映 |3.2.2.6 | |x| | | |1 ソースルートオプションを反転して反映 |3.2.2.8 |x| | | | |1 タイムスタンプリプライを上位レイヤーに渡す |3.2.2.8 |x| | | | |1 "標準値"に関するルールに従う |3.2.2.8 |x| | | | |1 | | | | | | | ICMPアドレスマスクリクエスト/リプライ: | | | | | | | アドレスマスクの情報源を設定可能 |3.2.2.9 |x| | | | | 静的な設定情報からのｱﾄﾞﾚｽﾏｽｸ取得ｻﾎﾟｰﾄ |3.2.2.9 |x| | | | | ｼｽﾃﾑ初期設定の間に動的にｱﾄﾞﾚｽﾏｽｸ取得 |3.2.2.9 | | |x| | | ICMPｱﾄﾞﾚｽﾏｽｸﾘｸｴｽﾄ/ﾘﾌﾟﾗｲを介してｱﾄﾞﾚｽﾏｽｸを取得|3.2.2.9 | | |x| | | ﾘﾌﾟﾗｲが得られない場合ｱﾄﾞﾚｽﾏｽｸﾘｸｴｽﾄを再送 |3.2.2.9 |x| | | | |3 ﾘﾌﾟﾗｲが得られない場合ﾃﾞﾌｫﾙﾄﾏｽｸを想定 |3.2.2.9 | |x| | | |3 最初のﾘﾌﾟﾗｲだけを使ってｱﾄﾞﾚｽﾏｽｸを更新 |3.2.2.9 |x| | | | |3 アドレスマスクに対する妥当性検査 |3.2.2.9 | |x| | | | 権威を持たずにｱﾄﾞﾚｽﾏｽｸﾘﾌﾟﾗｲﾒｯｾｰｼﾞを送信 |3.2.2.9 | | | | |x| エージェントであると明示的に設定 |3.2.2.9 |x| | | | | 静的設定時、ｱﾄﾞﾚｽﾏｽｸの権威を持つかの決定ﾌﾗｸﾞ |3.2.2.9 | |x| | | | ｼｽﾃﾑ初期設定時にｱﾄﾞﾚｽﾏｽｸﾘﾌﾟﾗｲをﾌﾞﾛｰﾄﾞｷｬｽﾄ |3.2.2.9 |x| | | | |3 | | | | | | | 送信データグラムのルーティング: | | | | | | | ローカル/リモートの判定でアドレスマスク使用 |3.3.1.1 |x| | | | | 接続ネットワーク上にゲートウェイが無くても動作 |3.3.1.1 |x| | | | | 次ホップゲートウェイの"ルートキャッシュ"保持 |3.3.1.2 |x| | | | | ﾎｽﾄﾘﾀﾞｲﾚｸﾄとﾈｯﾄﾜｰｸﾘﾀﾞｲﾚｸﾄを同じに扱う |3.3.1.2 | |x| | | | ｷｬｯｼｭｴﾝﾄﾘｰが無ければﾃﾞﾌｫﾙﾄｹﾞｰﾄｳｪｲを使用 |3.3.1.2 |x| | | | | 複数のデフォルトゲートウェイをサポート |3.3.1.2 |x| | | | | 静的ルートのテーブル提供 |3.3.1.2 | | |x| | | ﾘﾀﾞｲﾚｸﾄによってﾙｰﾄを上書き可能かの指定ﾌﾗｸﾞ |3.3.1.2 | | |x| | | ﾙｰﾄｷｬｯｼｭをﾈｯﾄｱﾄﾞﾚｽではなくﾎｽﾄｱﾄﾞﾚｽで検索 |3.3.1.3 | | |x| | | ルートキャッシュにTOSを含める |3.3.1.3 | |x| | | | | | | | | | | 次ホップゲートウェイの障害を検知可能 |3.3.1.4 |x| | | | | ルートは永久に良好だと想定 |3.3.1.4 | | | |x| | Internet Engineering Task Force [Page 74] RFC1122 INTERNET LAYER October 1989 ゲートウェイに継続的にping発行 |3.3.1.4 | | | | |x| トラフィック送信中にだけping発行 |3.3.1.4 |x| | | | | 肯定的兆候がない場合にだけping発行 |3.3.1.4 |x| | | | | 上位レイヤー及び下位レイヤーが助言を与える |3.3.1.4 | |x| | | | 障害ﾃﾞﾌｫﾙﾄｹﾞｰﾄｳｪｲから別のものへの切り替え |3.3.1.5 |x| | | | | 手動で設定情報を入力する方法 |3.3.1.6 |x| | | | | | | | | | | | 再構成とフラグメンテーション: | | | | | | | 到着データグラムを再構成可能 |3.3.2 |x| | | | | 対象データグラムの最低値は576バイト |3.3.2 | |x| | | | EMTU_Rは設定可能か無制限 |3.3.2 | |x| | | | トランスポートレイヤーはMMS_Rを学習可能 |3.3.2 |x| | | | | 再構成タイムアウト時ICMP時間超過を送信 |3.3.2 |x| | | | | 再構成タイムアウトを固定値にする |3.3.2 | |x| | | | | | | | | | | MMS_Sを上位レイヤーに渡す |3.3.3 |x| | | | | 送出パケットをローカルにフラグメンテーション |3.3.3 | | |x| | | さもなくばMMS_Sより大きいものを送信しない |3.3.3 |x| | | | | MTU情報不在時接続ﾈｯﾄﾜｰｸ外の宛先に最大576で送信 |3.3.3 | |x| | | | All-Subnets-MTU設定フラグ |3.3.3 | | |x| | | | | | | | | | マルチホーム接続: | | | | | | | ﾘｸｴｽﾄの特定宛先ｱﾄﾞﾚｽと同じｱﾄﾞﾚｽでﾘﾌﾟﾗｲ |3.3.4.2 | |x| | | | アプリケーションがローカルIPアドレスを選択可能 |3.3.4.2 |x| | | | | "誤った"ｲﾝﾀｰﾌｪｰｽに到着したﾃﾞｰﾀｸﾞﾗﾑを黙って破棄 |3.3.4.2 | | |x| | | "正しい"ｲﾝﾀｰﾌｪｰｽからのみﾃﾞｰﾀｸﾞﾗﾑを送信 |3.3.4.2 | | |x| | |4 | | | | | | | ソースルート指定されたデータグラムの転送: | | | | | | | ソースルートオプションを持つデータグラムを転送 |3.3.5 | | |x| | |1 対応するゲートウェイのルールに従う |3.3.5 |x| | | | |1 ゲートウェイのルールに従ってTTLを更新 |3.3.5 |x| | | | |1 ICMPエラーコード4、5を生成可能 |3.3.5 |x| | | | |1 ローカルホストではないIP送信元アドレス |3.3.5 | | |x| | |1 タイムスタンプ、ルート記録両オプション更新 |3.3.5 |x| | | | |1 非ローカルなソースルーティングの切り替え設定 |3.3.5 |x| | | | |1 デフォルトは無効 |3.3.5 |x| | | | |1 非ﾛｰｶﾙなｿｰｽﾙｰﾃｨﾝｸﾞのｹﾞｰﾄｳｪｲｱｸｾｽﾙｰﾙを満たす |3.3.5 |x| | | | |1 転送しない場合、宛先到達不能(コード5)を送信 |3.3.5 | |x| | | |2 | | | | | | | ブロードキャスト: | | | | | | | IP送信元ｱﾄﾞﾚｽとしてﾌﾞﾛｰﾄﾞｷｬｽﾄｱﾄﾞﾚｽを使用 |3.2.1.3 | | | | |x| 0形式または-1形式のブロードキャストを受信 |3.3.6 | |x| | | | 送信するﾌﾞﾛｰﾄﾞｷｬｽﾄが0形式か-1形式かの設定ｵﾌﾟｼｮﾝ|3.3.6 | | |x| | | デフォルトは-1形式のブロードキャスト |3.3.6 | |x| | | | すべてのブロードキャストアドレス形式を認識 |3.3.6 |x| | | | | ﾘﾝｸﾚｲﾔﾌﾞﾛｰﾄﾞｷｬｽﾄでIPﾌﾞﾛｰﾄﾞｷｬｽﾄ/ﾏﾙﾁｷｬｽﾄｱﾄﾞﾚｽ使用|3.3.6 |x| | | | | ﾘﾝｸﾚｲﾔｰのみﾌﾞﾛｰﾄﾞｷｬｽﾄ指定のﾃﾞｰﾀｸﾞﾗﾑを黙って破棄|3.3.6 | |x| | | | 接続ﾈｯﾄﾜｰｸにはﾘﾐﾃｯﾄﾞﾌﾞﾛｰﾄﾞｷｬｽﾄｱﾄﾞﾚｽを使用 |3.3.6 | |x| | | | Internet Engineering Task Force [Page 75] RFC1122 INTERNET LAYER October 1989 | | | | | | | マルチキャスト: | | | | | | | ﾛｰｶﾙIPﾏﾙﾁｷｬｽﾄ通信(RFC 1112)のｻﾎﾟｰﾄ |3.3.7 | |x| | | | IGMP(RFC 1112)のサポート |3.3.7 | | |x| | | 起動時に全ホストグループに参加 |3.3.7 | |x| | | | 上位ﾚｲﾔｰがｲﾝﾀｰﾌｪｰｽのﾏﾙﾁｷｬｽﾄ機能の有無を学習可能|3.3.7 | |x| | | | | | | | | | | インターフェース: | | | | | | | トランスポートレイヤーがIPの全機能を使用可能 |3.4 |x| | | | | ｲﾝﾀｰﾌｪｰｽの識別情報をﾄﾗﾝｽﾎﾟｰﾄﾚｲﾔｰに渡す |3.4 |x| | | | | 全IPオプションをトランスポートレイヤーに渡す |3.4 |x| | | | | ﾄﾗﾝｽﾎﾟｰﾄﾚｲﾔｰが特定のICMPﾒｯｾｰｼﾞを送信可能 |3.4 |x| | | | | 特定のICMPﾒｯｾｰｼﾞをﾄﾗﾝｽﾎﾟｰﾄﾚｲﾔｰに渡す |3.4 |x| | | | | オリジナルIPヘッダーと8オクテット以上を含む |3.4 |x| | | | | 高いビルでもひとっ飛びできる |3.5 | |x| | | | 脚注: (1) 機能が実装されている場合のみ (2) データグラムがICMPエラーメッセージの場合、この要件は無効 (3) 機能が実装されており、かつ設定が"有効"となっている場合のみ (4) 組み込みゲートウェイ機能を保持していないか、ソースルート指定されて いない場合 Internet Engineering Task Force [Page 76] RFC1122 TRANSPORT LAYER -- UDP October 1989 4. トランスポートプロトコル群 4.1 UDP(ユーザーデータグラムプロトコル) 4.1.1 導入 ユーザーデータグラムプロトコルUDP[UDP:1]は、最小限のトランス ポートサービス、つまり配送保証のないデータグラム配送を提供する。 また、アプリケーションに対してIPレイヤーのデータグラムサービス への直接的なアクセスを提供する。UDPは、TCPのサービスレベルを必要 としないアプリケーションや、TCPからは利用できない通信サービス (例えばマルチキャスト配送やブロードキャスト配送)の使用を希望 するアプリケーションによって使用される。 UDPはほとんど効能のないプロトコルである。UDPがIP上で提供する 唯一のサービスは、データのチェックサム機能とポート番号による 多重化である。従って、UDP上で動作するアプリケーション プログラムは、コネクション指向プロトコルなら対処されるであろう エンドツーエンドの通信に関する問題、具体的に信頼性のある配送 のための再送、パケット化と再構成、フロー制御、ふくそう回避 などの問題に対して、必要に応じて直接取り組まなければならない。 IPとTCPのかなり複雑な結びつきは、UDPとUDPを使用する多数の アプリケーションの結びつきに投射されるだろう。 4.1.2 プロトコルのウォークスルー UDPの仕様に既知のエラーは存在しない。 4.1.3 固有の課題 4.1.3.1 ポート UDPのウェルノウンポートは、TCPウェルノウンポートと同じルール に従う。セクション4.2.2.1を参照せよ。 待機中のLISTENコールがないUDPポート宛のデータグラムが到着 した場合、UDPはICMPポート到達不能メッセージを送信すべき である(SHOULD)。 4.1.3.2 IPオプション UDPは、IPレイヤーから受け取ったあらゆるIPオプションを透過的 にアプリケーションレイヤーに渡さなければならない(MUST)。 アプリケーションは、UDPデータグラムで送信されるIPオプションを 指定できなければならず(MUST)、UDPはそれらのオプションをIP レイヤーに渡さなければならない(MUST)。 Internet Engineering Task Force [Page 77] RFC1122 TRANSPORT LAYER -- UDP October 1989 【 議論 】 現在、UDPを経由して渡される必要のあるオプションは、ソース ルート、ルート記録、タイムスタンプだけである。しかし、 将来新しいオプションが定義されるかもしれないので、UDPは、 アプリケーションに渡す、またはアプリケーションから受け取る オプションのフォーマットや内容についてどのような想定も する必要はないし、またすべきでもない。ただし、IPレイヤー のセキュリティオプションはこの例外となるかもしれない。 UDPに基づくアプリケーションは、リクエストデータグラム からソースルートを取得し、対応する応答の送信のために 反転したルートを提供する必要があるだろう。 4.1.3.3 ICMPメッセージ UDPは、IPレイヤーから受け取ったすべてのICMPエラーメッセージを アプリケーションレイヤーに渡さなければならない(MUST)。 少なくとも概念上は、これはERROR_REPORTルーチンのアップ コールで達成されるだろう(セクション4.2.4.1参照)。 【 議論 】 UDPデータグラム送信に起因するICMPエラーメッセージは、 非同期に受信されることに注意せよ。ICMPエラーメッセージ 受信を希望するUDPベースのアプリケーションは、これらの メッセージが到着した際に、メッセージの受け取り先を選定 するために必要な状態を維持する責任を持つ。例えば、 アプリケーションは、この目的のために保留中の受信処理を 維持するだろう。また、アプリケーションは、同じポートを 以前に使用した通信が原因でICMPエラーメッセージが生じ、 それが遅れて到着したことで引き起こされる混乱を回避する 責任も持つ。 4.1.3.4 UDPチェックサム ホストは、UDPチェックサムを生成、妥当性検証する機能を実装 しなければならない(MUST)。アプリケーションは、UDPチェックサム が生成されるかどうかを任意で制御できるようにしてもよいが(MAY)、 デフォルトはチェックサム生成でなければならない(MUST)。 チェックサムの値がゼロ以外で、かつ無効な値を持つUDPデータ グラムが受信された場合、UDPはそのデータグラムを黙って破棄 しなければならない(MUST)。アプリケーションは、チェックサム のないUDPデータグラムが破棄されるべきかアプリケーションに 渡されるべきかを任意で制御できるようにしてもよい(MAY)。 【 議論 】 通常はローカルエリアネットワークの中だけでしか稼働しない 一部のアプリケーションは、効率化のためにチェックサム無効 を選択してきた。 Internet Engineering Task Force [Page 78] RFC1122 TRANSPORT LAYER -- UDP October 1989 その結果、エラーが検知されなかった多数の事例が報告されて いる。UDPチェックサムを常に無効にすることを推奨できるのか は議論の分かれるところである。 【 実装 】 UDPチェックサムには一般的な実装エラーがある。TCPチェック サムと異なり、UDPチェックサムは任意である。チェックサム の不在を示す場合、UDPヘッダーのチェックサムフィールドの 値はゼロで送信される。送信者が実際にUDPのチェックサム 計算をした結果ゼロになった場合、送信者はチェックサムを すべて1(65535)にして送信しなければならない。1の補数演算では ゼロと65535は等価なので、受信側の特別な対応は不要である。 4.1.3.5 UDPとマルチホーム接続 UDPデータグラムが受信された場合、その特定宛先アドレスは アプリケーションレイヤーに渡されなければならない(MUST)。 アプリケーションプログラムは、UDPデータグラムの送信で使用 されるIP送信元アドレスを指定するか、未指定のまま(この場合 ネットワーキングソフトウェアが適切な送信元アドレスを選択 する)にできなければならない(MUST)。選択された送信元アドレス をアプリケーションレイヤーに通知する手段があるべきである (SHOULD)(例えばアプリケーションがそれ以後対応するインター フェースからのみ応答データグラムを受信できるようにする ため)。 【 議論 】 UDPを使用するリクエスト/応答型のアプリケーションは、 リクエストの特定宛先アドレスと同じ送信元アドレスを応答 で使用すべきである。[INTRO:1]の"一般的な課題"セクション を参照せよ。 4.1.3.6 無効なアドレス 無効なIP送信元アドレス(例えばブロードキャストアドレスやマルチ キャストアドレス)を持つUDPデータグラムは、UDPかIPレイヤーに よって破棄されなければならない(セクション3.2.1.3参照)。 ホストがUDPデータグラムを送信する場合、送信元アドレスはホスト のIPアドレス(群の一つ)でなければならない(MUST)。 4.1.4 UDP/アプリケーションレイヤー間のインターフェース アプリケーションからUDPへのインターフェースは、本文書のセクション 3.4に記述されているIP/トランスポート間のインターフェースのすべての サービスを提供しなければならない(MUST)。 Internet Engineering Task Force [Page 79] RFC1122 TRANSPORT LAYER -- UDP October 1989 従って、UDPを使用するアプリケーションは、セクション3.4に 記述されているGET_SRCADDR()、GET_MAXSIZES()、ADVISE_DELIVPROB()、 RECV_ICMP()といったコールすべての機能を必要とする。例えば、 GET_MAXSIZES()を使用することで、特定の{インターフェース,リモート ホスト,TOS}のトリプレットに関するUDPデータグラムの実効最大サイズ を学習できる。 アプリケーションレイヤーのプログラムは、送信するUDPデータグラムの IPオプションだけでなくTTL値及びTOS値も設定できなければならない (MUST)。また、これらの値は透過的にIPレイヤーに渡されなければ ならない。UDPは受信したTOSをアプリケーションレイヤーに渡しても よい(MAY)。 4.1.5 UDPの要件の概要 | | | | |S| | | | | | |H| | | | | | |O|M| | | |S| |U|U| | | |H| |L|S| | |M|O| |D|T|脚 | |U|U|M| | | | |S|L|A|N|N| | |T|D|Y|O|O|注 機 能 | ｾｸｼｮﾝ | | | |T|T| -------------------------------------------------|--------|-|-|-|-|-|-- | | | | | | | UDP | | | | | | | -------------------------------------------------|--------|-|-|-|-|-|-- | | | | | | | UDPがICMPポート到達不能を送信 |4.1.3.1 | |x| | | | | | | | | | | UDPにおけるIPオプションの処理 | | | | | | | - 受け取ったIPｵﾌﾟｼｮﾝをｱﾌﾟﾘｹｰｼｮﾝﾚｲﾔｰに渡す |4.1.3.2 |x| | | | | - ｱﾌﾟﾘｹｰｼｮﾝﾚｲﾔｰが送信時にIPｵﾌﾟｼｮﾝを指定可能 |4.1.3.2 |x| | | | | - UDPがIPオプションをIPレイヤーに渡す |4.1.3.2 |x| | | | | | | | | | | | ICMPメッセージをアプリケーションレイヤーに渡す |4.1.3.3 |x| | | | | | | | | | | | UDPチェックサム: | | | | | | | - チェックサムの生成/検査が可能 |4.1.3.4 |x| | | | | - 不正なチェックサムを黙って破棄 |4.1.3.4 |x| | | | | - 送信者がチェックサムを生成しないオプション設定|4.1.3.4 | | |x| | | - デフォルトはチェックサム生成 |4.1.3.4 |x| | | | | - 受信者がﾁｪｯｸｻﾑ検査を必要とするｵﾌﾟｼｮﾝ設定 |4.1.3.4 | | |x| | | | | | | | | | UDPとマルチホーム接続 | | | | | | | - 特定宛先ｱﾄﾞﾚｽをｱﾌﾟﾘｹｰｼｮﾝﾚｲﾔｰに渡す |4.1.3.5 |x| | | | | Internet Engineering Task Force [Page 80] RFC1122 TRANSPORT LAYER -- UDP October 1989 - ｱﾌﾟﾘｹｰｼｮﾝﾚｲﾔｰがﾛｰｶﾙIPｱﾄﾞﾚｽを指定可能 |4.1.3.5 |x| | | | | - ｱﾌﾟﾘｹｰｼｮﾝﾚｲﾔｰがﾛｰｶﾙIPｱﾄﾞﾚｽは不確定と指定可能 |4.1.3.5 |x| | | | | - ｱﾌﾟﾘｹｰｼｮﾝﾚｲﾔｰが使用中のﾛｰｶﾙIPｱﾄﾞﾚｽを通知される|4.1.3.5 | |x| | | | | | | | | | | 不正なIP送信元アドレスはUDP/IPが黙って破棄 |4.1.3.6 |x| | | | | 有効なIP送信元アドレスのみ送信 |4.1.3.6 |x| | | | | UDPのｱﾌﾟﾘｹｰｼｮﾝ用ｲﾝﾀｰﾌｪｰｽｻｰﾋﾞｽ | | | | | | | ｾｸｼｮﾝ3.4のIPｲﾝﾀｰﾌｪｰｽすべてをｱﾌﾟﾘｹｰｼｮﾝに提供 |4.1.4 |x| | | | | - ﾃﾞｰﾀｸﾞﾗﾑ送信時TTL、TOS、IPｵﾌﾟｼｮﾝを指定可能 |4.1.4 |x| | | | | - 受け取ったTOSをアプリケーションレイヤーに渡す |4.1.4 | | |x| | | Internet Engineering Task Force [Page 81] RFC1122 TRANSPORT LAYER -- TCP October 1989 4.2 TCP(トランスミッションコントロールプロトコル) 4.2.1 導入 TCP(トランスミッションコントロールプロトコル)[TCP:1]は、 インターネットスイートのための主要な仮想回線(virtual-circuit) トランスポートプロトコルである。TCPは、信頼性があり、順序を 維持する全二重のオクテット(8ビットバイト)ストリーム配送を提供 する。TCPは、メール(SMTP)、ファイル転送(FTP)、仮想端末サービス (Telnet)といった信頼性のあるコネクション指向トランスポート サービスを必要とするアプリケーションに使用される。これらの アプリケーションレイヤープロトコルに関する要件は[INTRO:1]に 記述されている。 4.2.2 プロトコルのウォークスルー 4.2.2.1 ウェルノウンポート: RFC 793 セクション2.7 【 議論 】 TCPは、0～255の範囲のポート番号を"ウエルノウン"ポート のために予約している。これらはインターネット全域で標準化 されたサービスにアクセスするために使用される。ポート番号 空間の残りは、アプリケーションプロセスに自由に割り当て 可能である。現時点のウェルノウンポートの定義は、"割り当て 済み番号資源(Assigned Numbers)"と題されたRFC[INTRO:6]に 列挙されている。新しいウェルノウンポートを定義するために 必要な条件は、新しい実装が可能な程度に十分詳細に記述 された、提案サービスを文書化したRFCである。 一部のシステムは、TCPポート番号空間に第3の区分を追加する ことでこの概念を拡張している。この区分は予約済みポート (reserved port)と呼ばれ、一般にオペレーティングシステム 固有のサービスのために使用される。例えば、予約済みポート は256からシステム依存の何らかの上限値の間に位置するもの になるだろう。一部のシステムでは更に、ウェルノウンポート や予約済みポートを使用するTCPコネクションのオープンを特権 ユーザーだけに許可することで、これらのポートを保護する ことを選択している。これは、ホストが自分以外の全ホストも 同じ方法で小さい番号のポートを保護していると想定できない 限り、完全に妥当である。 4.2.2.2 PUSHフラグの使用: RFC 793 セクション2.8 アプリケーションがPUSHフラグを設定せずにひと続きのSENDコール を発行した場合、TCPはそれらを送信せずに内部的にデータを集約 してもよい(MAY)。同様に、PSHビットが設定されていないひと続き のセグメントが受信された場合、TCPはそれらを受信アプリケーション に渡さずに内部的にキューに入れてもよい(MAY)。 Internet Engineering Task Force [Page 82] RFC1122 TRANSPORT LAYER -- TCP October 1989 PSHビットはレコードマーカーではなく、セグメント境界とは独立 である。送信者は、データをパケット化する際に可能な限り大きい セグメントを送信するため、連続するPSHビットを畳み込むべき である(SHOULD)。 TCPは、SENDコールでPUSHフラグを実装してもよい(MAY)。PUSH フラグが実装されていない場合、送信TCPは、(1)データを無期限 にバッファー保存してはならず、(2)最後にバッファーに入れられた セグメント(つまりそれ以降のキューの中に送信されるべきデータ が存在しない場所)のPSHビットを設定しなければならない(MUST)。 RFC 793の48ページ、50ページ、74ページの議論は、受信されたPUSH フラグはアプリケーションレイヤーに渡されなければならないという 誤った示唆をしている。受信されたPUSHフラグをアプリケーション レイヤーに渡すかは現在任意(OPTIONAL)となっている。 アプリケーションプログラムは、通信のデッドロックを回避する ためにデータを強制的に配送する必要がある場合はいつでも、SEND コールにおけるPUSHフラグの設定を必然的に求められる。しかし、 TCPは、パフォーマンスを改善するため、可能な場合は常に最大サイズ のセグメントを送信すべきである(SHOULD)(セクション4.2.3.4参照)。 【 議論 】 SENDコールでPUSHフラグが実装されていない場合、つまり アプリケーション/TCP間のインターフェースが純粋な ストリーミングモデルを使用している場合、あらゆる小さい データセグメントを集約して妥当なサイズのセグメントを 形成する責任は、部分的にアプリケーションレイヤーに 課される。 一般に、対話型アプリケーションプロトコルは、少なくとも 各コマンドまたは連続的応答の最後のSENDコールでPUSHフラグ を設定しなければならない。FTPのようなバルク転送プロトコル は、ファイルの最終セグメントに到達した場合またはバッファー のデッドロック防止のために必要な場合にPUSHフラグを設定 すべきである。 受信側では、PSHビットはバッファーに入れられたデータを (たとえバッファー容量より少ないデータしか受信していなく ても)アプリケーションに配送するよう強制する。逆に、PSH ビットの欠落を利用することで、アプリケーションプロセス を不必要に起こすのを回避することができる。これは大規模 なダイムシェアリングホストに関する重要なパフォーマンス 最適化になり得る。受信アプリケーションにPSHビットを渡す ことで、アプリケーション内で同様の最適化が可能となる。 4.2.2.3 ウインドウサイズ: RFC 793 セクション3.1 ウインドウサイズは符号無しの数として扱わなければならない(MUST)。 Internet Engineering Task Force [Page 83] RFC1122 TRANSPORT LAYER -- TCP October 1989 さもないと大きいウインドウサイズは負のウインドウのように 見えてしまうので、TCPは動作しなくなる。実装は、転送制御 ブロック(connection record)内の送信ウインドウ、受信 ウインドウのサイズ用にそれぞれ32ビットのフィールドを予約 し、ウインドウ計算すべてを32ビットで行うことが推奨される (RECOMMENDED)。 【 議論 】 TCPヘッダーのウインドウフィールドは、高速で遅延の大きい パスに対しては小さすぎることが知られている。ウインドウ サイズを拡大するための実験的なTCPオプションが定義されて いる。例えば[TCP:11]を参照せよ。このような拡張の採用を 見越して、TCP実装者はウインドウサイズを32ビットとして 扱うべきである。 4.2.2.4 緊急ポインター: RFC 793 セクション3.1 二つめの文は誤りである。緊急ポインターは緊急データオクテット列 の"最終"オクテットのシーケンス番号を指す("最終"+1ではない)。 56ページの記述(最後の文)は正しい。 TCPは、どのような長さの緊急データオクテット列でもサポート しなければならない(MUST)。 TCPは、以前に保留中の緊急データがない状態で緊急ポインターを 受信した場合、あるいは緊急ポインターがデータストリームの先 にある場合は常に、非同期にアプリケーションレイヤーに通知 しなければならない(MUST)。今後接続から読み込まれる緊急データ 量をアプリケーションが取得する方法が無ければならない(MUST)。 少なくとも、まだ読み込むべき緊急データが残されているかどうか をアプリケーションが判定できる方法が無ければならない(MUST)。 【 議論 】 緊急通知の仕組みは、どのようなアプリケーションにも使用 できるが、通常はTelnetプログラムへの"割り込み"タイプの コマンドを送信するために使用される。([INTRO:1]の "TelnetのSynch手順の使用"を参照せよ)。 非同期または"接続とは別チャネル(out-of-band)"の通知に より、アプリケーションは、TCP接続からデータを読み込む "緊急モード"に移行することができる。これにより、通常の 入力バッファーが未処理のデータでいっぱいのアプリケーション に制御コマンドを送信することができるようになる。 【 実装 】 セクション4.2.4.1に記述される汎用のERROR_REPORT()アップ コールは、緊急データ到着をアプリケーションに通知する 仕組みの候補である。 Internet Engineering Task Force [Page 84] RFC1122 TRANSPORT LAYER -- TCP October 1989 4.2.2.5 TCPオプション: RFC 793 セクション3.1 TCPは、どのようなセグメントに含まれるTCPオプションであっても 受理できなければならない(MUST)。TCPは、自身が実装していない どのようなTCPオプションも、そのオプションが長さフィールドを 持つならば(将来定義されるTCPオプションはすべて長さフィールドを 持つ)エラー無しで無視しなければならない(MUST)。TCPは、不正な オプション長(例えばゼロ)をクラッシュせずに処理する準備が できていなければならない(MUST)。この場合、推奨される手順は、 接続をリセットし、理由をログに残すことである。 4.2.2.6 最大セグメントサイズオプション: RFC 793 セクション3.1 TCPは、送信、受信の両方で最大セグメントサイズオプション [TCP:4]を実装しなければならない(MUST)。 TCPは、自身の受信可能なMSSがデフォルトの536と異なる場合、 SYNセグメントごとにMSS(最大セグメントサイズ)オプションを 送信すべきである(SHOULD)。また、MSSを常に送信するように してもよい(MAY)。 接続の構築時にMSSオプションが受信されなかった場合、TCPは、 送信MSSとしてデフォルトの536(576-40)を想定しなければならない (MUST)[TCP:4]。 TCPが実際に送信する最大セグメントサイズ、"実効送信MSS"は、 送信MSS(リモートホストで利用可能な再構成バッファーサイズを 反映)とIPレイヤーに許可された最大サイズのうち小さい方の値 でなければならない(MUST)。 Eff.snd.MSS = min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize ここで、 ・ SendMSSは、リモートホストから受信したMSS値か、MSSオプション が受信されない場合はデフォルトの536である。 ・ MMS_Sは、TCPが送信してよいトランスポートレイヤーメッセージ の最大サイズである。 ・ TCPhdrsizeはTCPヘッダーのサイズである。これは通常20だが、 TCPオプションが送信される場合は大きくなることがある。 ・ IPoptionsizeは、TCPが現在のメッセージと共にIPレイヤーに 渡すあらゆるIPオプションのサイズである。 Internet Engineering Task Force [Page 85] RFC1122 TRANSPORT LAYER -- TCP October 1989 MSSオプションで送信されるMSS値は、以下の式以下でなければ ならない。 MMS_R - 20 ここで、MMS_Rは、受信(及び再構成)が可能なトランスポート レイヤーメッセージの最大サイズである。TCPは、MMS_R及びMMS_S をIPレイヤーから取得する。セクション3.4の汎用コール GET_MAXSIZESを参照せよ。 【 議論 】 TCPセグメントサイズの選択はパフォーマンスに大きな影響を 与える。セグメントをより大きくすると、ヘッダーサイズと データグラムごとの処理オーバーヘッドをより多くのデータ バイトで解消するので、スループットが向上する。しかし、 パケットが大きすぎてIPフラグメンテーションが生じると、 どのフラグメントが消失しても効率は急激に低下する[IP:9] 一部のTCP実装は、宛先ホストが接続ネットワーク上にない 場合にのみMSSオプションを送信する。しかし、一般にTCP レイヤーはこの決定を行うのに適した情報を持っていない かもしれないので、インターネットパスに対する適切なMTUを 決定する作業はIPレイヤーに任せる方が望ましい。 従って、TCPは(536でない場合は)常にオプションを送信 し、IPレイヤーはセクション3.3.3及び3.4の規定どおりに MMS_Rを決定することを推奨する。そのようにすれば、MTUを 測定するために提案されているIPレイヤーの仕組みは、TCP を変更することなくIPレイヤーだけを変更するだろう。 4.2.2.7 TCPチェックサム: RFC 793 セクション3.1 UDPチェックサム(セクション4.1.3.4参照)とは異なり、TCPチェック サムは決して任意ではない。送信者はチェックサムを生成しなければ ならず(MUST)、受信者はチェックサムを検査しなければならない (MUST)。 4.2.2.8 TCP接続の状態遷移図: RFC 793 セクション3.2の23ページ この図には、以下に示すように幾つかの問題がある。 (a) SYN-SENTからSYN-RCVDに向かう矢印は、68ページの記述や図8 と一致させるために、"snd SYN,ACK"とラベル付けされるべき である。 (b) 受動オープンの後にRSTを受信するという条件に対応する、 SYN-RCVD状態からLISTEN状態に向かう矢印が発生し得る (70ページの記述参照)。 Internet Engineering Task Force [Page 86] RFC1122 TRANSPORT LAYER -- TCP October 1989 (c) FIN-WAIT-1からTIME-WAITに直接移行することもあり得る (仕様の75ページ参照)。 4.2.2.9 初期シーケンス番号の選択: RFC 793 セクション3.3の 27ページ TCPは、仕様で定められたクロックに基づく初期シーケンス番号 の選択方法を使用しなければならない(MUST)。 4.2.2.10 同時オープンの試み: RFC 793 セクション3.4の32ページ 図8には誤りがある。7行目のパケットは5行目と同じになるべき である。 TCPは、同時オープンの試みをサポートしなければならない(MUST)。 【 議論 】 二つのアプリケーションが互いに同時に接続しようと試みると、 接続は二つではなく一つしか生成されない。このことは、時折 実装者を驚かせる。これは意図的な設計上の決定であった。 これを"修正"しようとしてはならない。 4.2.2.11 古い重複SYNからの回復: RFC 793 セクション3.4の33ページ TCP実装は、接続がSYN_RCVD状態に到達したのは、受動的なOPENの 結果だったのか、能動的なOPENの結果だったのかを記録して おかなければならない(MUST)ことに注意せよ。 4.2.2.12 RSTセグメント: RFC 793 セクション3.4 TCPは、受信されるRSTセグメントがデータを保持するのを許容 すべきである(SHOULD)。 【 議論 】 RSTの原因を説明するエンコードされたASCIIテキストをRST セグメントに含められるようにすることが提案されている。 そのようなデータに関する標準はまだ確立されていない。 4.2.2.13 接続のクローズ: RFC 793 セクション3.5 TCP接続は、次の二つの方法で終了する、(1)FINハンドシェイクを 使用する通常のクローズ手順、(2)一つ以上のRSTセグメントが送信 され接続状態が直ちに破棄される"アボート"。TCP接続がリモート サイトによってクローズされる場合、ローカルアプリケーション は、接続が通常どおりクローズされたのかアボートされたのかを 通知されなければならない(MUST)。 Internet Engineering Task Force [Page 87] RFC1122 TRANSPORT LAYER -- TCP October 1989 通常のTCPクローズ手順は、バッファーに残されたデータを信頼性 のある方法で双方向に配送する。TCP接続の二つの向きは独立して クローズされるため、接続が"ハーフクローズ"、つまり片方向だけ がクローズされ、ハーフクローズされた接続のオープン側の向き では、ホストがデータ送信の継続を許可される状態になることも あり得る。 ホストは、CLOSEをコールしたアプリケーションが接続からの データ読み込みを継続できないようにするため、"半二重"なTCP クローズ手順を実装してもよい(MAY)。そのようなホストに おいて、TCPに受信データが保留されている間にCLOSEコールが 発行された場合、またはCLOSEがコールされた後に新しいデータ が受信された場合、そのホストのTCPは、データが消失したこと を示すためにRSTを送信すべきである(SHOULD)。 接続が能動的にクローズされる場合、TIME-WAIT状態で2xMSL(Maximum Segment Lifetime: 最大セグメント生存時間)の間待機しなければ ならない(MUST)。ただし、以下の条件が満たされるのであれば、 TIME-WAIT状態から直ちに接続を再オープンすることを意図した リモートTCPからの新しいSYNを受理してもよい(MAY)。 (1) 新しい接続の初期シーケンス番号として、前の接続終了まで に使用されたシーケンス番号の最大値よりも大きい値を割り 当てる。 (2) SYNが古い重複セグメントだと判明した場合、TIME-WAIT状態 に戻る。 【 議論 】 TCPの全二重でデータを保全するクローズは、類似のISO トランスポートプロトコルTP4には含まれていない機能 である。 一部のシステムでは、ハーフクローズな接続を実装して いない。恐らく、特定のオペレーティングシステムのI/O モデルに適合しないからだろう。これらのシステムでは、 アプリケーションが一旦CLOSEをコールしてしまうと、接続 から入力データを読み込めなくなる。これは"半二重"な TCPクローズ手順と呼ばれる。 TCPの円滑なクローズアルゴリズムは、2xMSLのタイムアウト 期間、すなわち4分間、(少なくとも)接続の片側で接続状態が 定義されたまま残ることを要求する。この期間中は、接続を 定義する(リモートソケット，ローカルソケット)のペアは 使用中であり、再利用できない。 Internet Engineering Task Force [Page 88] RFC1122 TRANSPORT LAYER -- TCP October 1989 特定のポートペアが拘束される期間を短縮するため、一部の TCPは、TIME-WAIT状態で新しいSYNを受理できるようにして いる。 4.2.2.14 データ通信: RFC 793 セクション3.7の40ページ RFC 793が書かれて以来、効率的なデータ通信を達成するために TCPアルゴリズムで多大な作業が行われてきた。本文書の後の セクションで、いつデータを送信するか(セクション4.2.3.4)、 いつ確認応答を送信するか(セクション4.2.3.2)、いつウインドウ を更新するか(セクション4.2.3.4)を決定するための必須のTCP アルゴリズム及び推奨されるTCPアルゴリズムを記述している。 【 議論 】 重要なパフォーマンスに関する課題の一つは、"シリー ウインドウシンドローム"または"SWS"である[TCP:5]。これは、 ウインドウがわずかずつしか増加しないパターンが定着して しまうことにより、TCPパフォーマンスが極めて低下する というものである。SWSを回避するためのアルゴリズムは、 送信側(セクション4.2.3.4)、受信側(セクション4.2.3.3) の両方が後ほど記述される。 手短に言うと、SWSは、どのような大きさであれ新しい バッファー空間が利用可能になったら常にウインドウ右端を 先に進める受信者と、それがどんなに小さくてもウインドウ の増加分を使用してより多くのデータを送信する送信者に よって引き起こされる[TCP:5]。その結果、送信者と受信者 がどちらも接続用の大きいバッファー空間を保持していても、 小さいデータセグメントを送信するパターンが定着して しまう可能性がある。SWSは、大量のデータを転送中にしか 発生し得ない。接続が休止状態になればこの問題は消失する からである。SWSは典型的で単純なウインドウ管理の実装に よって引き起こされるが、後に与えられる送信側と受信側の アルゴリズムはこれを回避する。 もう一つの重要なTCPパフォーマンスの課題として、一部の アプリケーション、特に文字単位のやりとりをするリモート ログインは、1オクテットのデータセグメントのストリームを 送信しがちであることが挙げられる。デッドロックを回避 するため、そのようなアプリケーションから発行される個々の TCP SENDコールは、アプリケーションによって明示的に、 またはTCPによって暗に、"プッシュ"されなければならない。 結果として、それぞれ1オクテットのデータしか含まないTCP セグメントのストリームが生じるかもしれない。これは インターネットの利用を非効率にし、インターネットの ふくそうの一因となる。セクション4.2.3.4に記述される Nagleアルゴリズムは、この問題に対する簡単で効果的な 解決法を提供する。 Internet Engineering Task Force [Page 89] RFC1122 TRANSPORT LAYER -- TCP October 1989 このアルゴリズムは、Telnet接続上で文字をまとめて ひと固まりにする効果を持つ。これは単一文字のエコーに 慣れたユーザーを初めは驚かせるかもしれないが、ユーザー 側の受け入れで問題は起きていない。 Nagleアルゴリズムと送信側SWS回避アルゴリズムは、 パフォーマンス改善において互いに補完的な役割を果たすこと に注意せよ。Nagleアルゴリズムは、送信されるデータがわずか しか増加していない場合、小さいセグメントの送信を防止する。 これに対し、SWS回避アルゴリズムは、ウインドウ右端がわずか しか進まないことに起因する小さいセグメントの発生を防止 する。 不注意な実装は、受信したデータセグメントごとに二つ以上の 確認応答を送信する可能性がある。例として、受信者は各データ セグメントに直ちに確認応答するものとする。アプリケーション プログラムが確認応答送信後にデータを消費し、利用可能な 受信バッファー空間が再び増加した場合、受信者は送信者の ウインドウを更新するために二つめの確認応答セグメントを 送信するかもしれない。リモートログインサービスのために Telnetプロトコルを使用するTCP接続上で単一文字セグメント がやりとりされると、極端な状況が発生する。一部の実装では、 到着する各1文字セグメントが三つの応答セグメントを生成する ことが観測されている。それぞれ(1)確認応答、(2)ウインドウ が1バイト増加した通知、(3)エコーされる文字に対応する。 4.2.2.15 再送タイムアウト: RFC 793 セクション3.7の41ページ RFC 793で提案された再送タイムアウトを計算するアルゴリズム は、現在では不適切であることが知られている。セクション 4.2.3.1を参照せよ。 Jacobsonによる、インターネットのふくそうとTCPの再送の安定性 に関する最近の研究[TCP:7]は、"スロースタート"と"ふくそう 回避"を組み合わせた転送アルゴリズムを産み出した。TCPはこの アルゴリズムを実装しなければならない(MUST)。 再送されるパケットがオリジナルパケットと同一である場合 (これはデータ境界が変更されていないだけではなく、ヘッダー のウインドウフィールド、ACKフィールドも変更されていない ことを意味する)、同じIP識別番号フィールドが使用されても よい(MAY)(セクション3.2.1.5参照)。 【 実装 】 一部のTCP実装者は、データストリームの"パケット化"、 つまりセグメントが初めに送信される際にセグメント境界を 選定し、確認応答されるまでそれらのセグメントを"再送 キュー"に入れておくことを選択してきた。 Internet Engineering Task Force [Page 90] RFC1122 TRANSPORT LAYER -- TCP October 1989 (より単純なものになると思われる)別の設計は、データが 転送または再送されるその時までパケット化を延期する。 従ってセグメント再送キューは存在しない。 セグメント再送キューを持つ実装の場合、初めの再送 タイムアウトが発生した際に、確認応答を待っている 複数セグメントを再パケット化することでTCPパフォーマンス が向上する可能性がある。言い換えると、未処理の複数 セグメントのうち適したものを結合して最大サイズの セグメント一つにし、新しいIP識別番号の値を割り当てる ということである。TCPは、この結合されたセグメントを 確認応答されるまで再送キュー内に維持する。ただし、再送 キュー内の先頭二つのセグメントを合算すると最大サイズの セグメント一つの大きさを越える場合、TCPは、最初の セグメントだけをオリジナルのIP識別番号フィールドで 再送する。 4.2.2.16 ウインドウの管理: RFC 793 セクション3.7の41ページ 受信側TCPは、ウインドウを縮める、つまりウインドウの右端を 左方向に動かすべきではない(SHOULD NOT)。しかし送信側TCPは、 ウインドウの縮小と、それによって生じるかもしれない"使用 可能ウインドウ"(セクション4.2.3.4参照)が負の値になる状況 に対して堅牢でなければならない(MUST)。 そのような状況が生じた場合、送信者は新しいデータを送信すべき ではない(SHOULD NOT)。しかし、SND.UNAからSND.UNA+SND.WNDの間 にある確認応答されていない古いデータは通常どおり再送すべき である(SHOULD)。送信者は、SND.UNA+SND.WNDの先にある古いデータ を再送してもよいが(MAY)、ウインドウ右端を越えたデータが確認応答 されなくても接続をタイムアウトすべきではない(SHOULD NOT)。 ウインドウがゼロに縮小した場合、TCPはそれを標準的な方法で調査 しなければならない(MUST)(次セクション参照)。 【 議論 】 多くのTCP実装は、データより大きいウインドウに対してデータ を送信した後に、ウインドウが右側から縮小すると混乱する。 TCPは、データグラムの到着順序入れ替えがあっても最新の ウインドウ更新を選択するための発見的手法を持つことに注意 せよ。その結果、以前に提示されたものよりも小さいウインドウ のウインドウ更新は、シーケンス番号も確認応答番号も増加して いなければ無視されるかもしれない。 Internet Engineering Task Force [Page 91] RFC1122 TRANSPORT LAYER -- TCP October 1989 4.2.2.17 ゼロウインドウの調査: RFC 793 セクション3.7の42ページ (提示された)ゼロウインドウの調査はサポートされなければ ならない(MUST)。 受信側TCPは、送信側TCPに提示される自身の受信ウインドウを 無期限にクローズにしたまま、つまりゼロウインドウのままに してもよい(MAY)。受信側TCPが調査セグメントに応答して確認 応答を送信し続ける限り、送信側TCPは接続がオープンな状態に 留まることを許容しなければならない(MUST)。 【 議論 】 データを含まないACK(確認応答)セグメントは、TCPによる 確実な送信がなされないことに留意することは極めて重要 である。ゼロウインドウの調査がサポートされない場合、 ウインドウを再オープンするACKセグメントが消失すると、 接続が永久にハングアップしてしまうかもしれない。 受信側アプリケーションがTCPからのデータ取得を停止する と、大抵の場合ゼロウインドウのオープンに遅延が生じる。 例えば、プリンター用紙が無くなったために停止した プリンターデーモンアプリケーションを考えてみよ。 送信ホストは、再送タイムアウト期間中(セクション4.2.2.15参照) ずっとゼロウインドウのままであった場合、最初のゼロウインドウ 調査を送信すべきであり(SHOULD)、継続的な調査の間隔は、指数的 に増加させるべきである(SHOULD)。 【 議論 】 この手順は、ゼロウインドウ状態の原因がウインドウを オープンする更新を含むACKセグメント消失である場合に、 遅延を最小にする。ここでは規定されない何らかの最大間隔 を上限とした指数的バックオフが推奨される。この手順は 再送アルゴリズムの手順と似ており、実装で二つの手順を 統合することも可能かもしれない。 4.2.2.18 受動的なOPENコール: RFC 793 セクション3.8 すべての受動的なOPENコールは、LISTEN状態で新しい転送制御ブロック (connection record)を生成するか、エラーを返すかのどちらかの 結果となる。以前に生成されたどの転送制御ブロックに対しても 影響を及ぼしてはならない(MUST NOT)。 複数ユーザーを同時にサポートするTCPは、ある転送制御ブロック (connection block)がSYN-SENTまたはSYN-RECEIVED状態のローカル ポートを保持していても、アプリケーションが同じポートで待機 することを機能上許容するようなOPENコールを提供しなければ ならない(MUST)。 Internet Engineering Task Force [Page 92] RFC1122 TRANSPORT LAYER -- TCP October 1989 【 議論 】 幾つかのアプリケーション(例えばSMTPサーバー)は、ほぼ同時 になされる複数の接続の試みに対処しなければならないこと がある。以前の接続の試みが3ウェイハンドシェイクを通過 しつつあるのとほぼ同じ時間に、新しい接続のために同じ ポートで待機する何らかの手段をアプリケーションに提供 することにより、接続の試みが失敗する確率が低くなる。 【 実装 】 同時オープンの仕様を満たす容認可能な実装は、複数の 受動的なOPENコールを許容するか、または単一の受動的な OPENコールからLISTEN状態の複数の接続を"複製する (cloning)"ことを許容するものになるだろう。 4.2.2.19 TTL: RFC 793 セクション3.9の52ページ RFC 793は、TCPからIPレイヤーに対してTTL=60でTCPセグメントを 送信するようリクエストすべきであると規定した。これは廃止と なっている。TCPセグメントを送信するために使用されるTTL値は 設定可能でなければならない(MUST)。議論についてはセクション 3.2.1.7を参照せよ。 4.2.2.20 イベント処理: RFC 793 セクション3.9 厳密に要求されてはいないが、TCPは、順番どおりでないTCP セグメントをキューに入れられるようにすべきである(SHOULD)。 70ページの第1段落の最後の文にある"may"を"should"に変更する。 (訳注:対象の文は"Segments with higher begining sequence numbers may be held for later processing.")。 【 議論 】 一部の小規模ホストの実装は、バッファー空間が限られるため、 セグメントのキュー管理を省略してきた。この省略はTCPの スループットに悪影響を与えると予想される。単一セグメント が消失すると、以後のすべてのセグメントが"順番から外れたもの" に見えるようになってしまうからである。 一般に、受信セグメントの処理は、可能な場合は常にACKセグメント を集約するように実装されなければならない(MUST)。例えば、TCPが キューに入れられた一連のセグメントを処理している場合、どのような ACKセグメントであれ、それを送信する前にキュー内のセグメントすべて を処理しなければならない(MUST)。 RFC 793のイベント処理に関するセクション(訳注: セクション3.9)の 詳細なエラー訂正と注記を以下に示す。 (a) CLOSEコール。CLOSE-WAIT状態の場合(61ページ): LAST-ACK 状態に遷移する。CLOSINGにではない。 Internet Engineering Task Force [Page 93] RFC1122 TRANSPORT LAYER -- TCP October 1989 (b) LISTEN状態でのSYNの検査(65～66ページ): SYNビットは設定 されているが、セグメントのセキュリティ/コンパートメント または優先度が誤っている場合、リセットが送信される。 その文章の中に誤った形式のリセットが示されている。以下の ようになるべきである。 (c) SYN-SENT状態でのSYNの検査(68ページ): 接続がESTABLISHED 状態に遷移したら、以下の変数が設定されなければならない。 SND.WND <- SEG.WND SND.WL1 <- SEG.SEQ SND.WL2 <- SEG.ACK (d) セキュリティと優先度の検査(71ページ): 最初の見出し "ESTABLISHED状態"は、SYN-RECEIVED以外のすべての状態の一覧、 つまり、ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、 CLOSING、LAST-ACK、TIME-WAITになるべきである。 (e) SYNビットの検査(71ページ): 見出しの直後に以下の文章を挿入。 "SYN-RECEIVED状態で、かつ接続が受動的なOPENで開始された ものである場合、この接続の状態をLISTEN状態に戻して元の 処理に帰る。そうでない場合、..."。 (f) ACKフィールドの検査。SYN-RECEIVED状態の場合(72ページ): 接続がESTABLISHED状態に遷移した場合、(c)に列挙されている 変数が設定されなければならない。 (g) ACKフィールドの検査。ESTABLISHED状態の場合(72ページ): ACKが重複と判定されるのは、SEG.ACK =< SND.UNA の場合 である(原文は = が省略されている)。同様に、ウインドウ が更新されるべき条件は、SND.UNA =< SEG.ACK =< SND.NXT である。 (h) ユーザータイムアウト(77ページ): TCPに強制的な接続クローズをさせるよりは、アプリケーション にタイムアウトを通知する方がいいだろう。ただし、本文書 のセクション4.2.3.5も参照せよ。 4.2.2.21 キュー内で待機するセグメントに対する確認応答: RFC 793 セクション3.9 TCPは、ウインドウ内だがウインドウ左端ではない有効なセグメント が到着した場合に、RCV.NXTを確認するACKセグメントを送信しても よい(MAY)。 Internet Engineering Task Force [Page 94] RFC1122 TRANSPORT LAYER -- TCP October 1989 【 議論 】 RFC 793(74ページ参照)は、順番どおりでないセグメントが 受信された場合、つまりSEG.SEQとRCV.NXTが同じでない場合 に、ACKセグメントが送信されるべきか否かについてあいまい であった。 順番どおりでないセグメントにACKを返す理由の一つは、"Fast Retransmit"として知られる実験的アルゴリズムをサポート することだろう。このアルゴリズムを使用する場合、送信者は、 再送タイマーが満了する前にセグメントが消失したと推定 するために"冗長な"ACKを使用する。具体的に、SEG.ACKと 同じ値を持ち、同じウインドウ右端が設定されたACKが受信 された回数をカウントする。そのようなACKの受信回数が しきい値を越えた場合、SEG.ACKで始まるオクテットを含む セグメントは消失したと見なされ、タイムアウトを待つこと なく再送される。このしきい値は、インターネット内で セグメントの順番入れ替えが発生する見込みの最大値を補償 するように選択される。Fast Retransmitアルゴリズムがどの 程度有用かを判定できるほど十分な運用経験はまだ得られて いない。 4.2.3 固有の課題 4.2.3.1 再送タイムアウトの計算 ホストのTCPは、再送タイムアウト("RTO")を計算するためにKarn のアルゴリズム及びJacobsonのアルゴリズムを実装しなければ ならない(MUST)。 ・ 平滑化ラウンドトリップタイム("RTT")の計算で使用される Jacobsonのアルゴリズムは、分散という単純な尺度を取り 入れている[TCP:7]。 ・ RTT測定値の選択で使用されるKarnのアルゴリズムは、 あいまいなラウンドトリップタイムが平滑化ラウンドトリップ タイムの計算を誤らせないことを保証する[TCP:6]。 また、この実装は、同じセグメントに関する一連の(連続で生じる) RTO値を"指数的バックオフ"させる機能も含まなければならない (MUST)。SYNセグメントの再送には、データセグメントと同じ アルゴリズムを使用すべきである(SHOULD)。 【 議論 】 RFC 793で規定されているRTO計算には、既知の問題が二つ存在 していた。第1に、再送がある場合RTTの正確な測定が困難で あること、第2に、RTT値の分散が小さく一定であるという 誤った想定をしていたため、平滑化ラウンドトリップタイム を計算するアルゴリズムが不適切だったことである[TCP:7]。 Internet Engineering Task Force [Page 95] RFC1122 TRANSPORT LAYER -- TCP October 1989 これらの問題は、それぞれKarnのアルゴリズムとJacobsonの アルゴリズムによって解決された。 これらの改善策の使用によるパフォーマンス向上は、それと わかる程度から劇的なものまで様々である。測定されたRTT の分散を計算に組み入れるJacobsonのアルゴリズムは、低速の リンクで特に重要となる。低速リンクでは、パケットサイズ の自然な分散が、RTTの大きな分散を生じさせるからである。 あるベンダーは、分散を考慮するJacobsonのアルゴリズムを TCPに実装した結果、9.6kbps回線のリンク使用率が10%から 90%になることを発見した。 新しい接続に対する評価パラメーターを初期設定するにあたり、 以下の値が使用されるべきである(SHOULD)。 (a) RTT = 0 秒 (b) RTO = 3 秒 (平滑化された分散は、このRTOとなるような値 に初期設定される) 推奨されるRTOの上限と下限は、大規模なインターネットでは不適当 であることがわかっている。下限は(高速LANに対応するため)秒単位 で測定されるべき(SHOULD)であり、上限は2*MSL、つまり240秒と すべきである。 【 議論 】 経験によれば、これらの初期値は妥当であり、どのような場合 においても、KarnのアルゴリズムとJacobsonのアルゴリズムは、 TCPの振る舞いにおける初期パラメーター選択の影響を程よく 弱めることが示されている。 4.2.3.2 ACKセグメントをいつ送信するか TCPデータセグメントのストリームを受信中のホストは、データ セグメントを受信するごとに一つのACK(確認応答)セグメントを返す 形式よりもACKセグメントを少なく送信することで、インターネット とホストの両方の効率を高めることができる。これは"遅延ACK"と して知られている[TCP:5]。 TCPは遅延ACKを実装すべきである(SHOULD)。しかし、ACKは極端に 遅らされるべきではない。具体的に、遅延は0.5秒未満でなければ ならず(MUST)、フルサイズ(訳注: 実効送信MSSバイト)のセグメント のストリームの場合、少なくとも2個ごとにACKセグメントが返される べきである(SHOULD)。 【 議論 】 遅延ACKは、アプリケーションに対してウインドウを更新する 機会と、恐らくは即時の応答を送信する機会を与える。 Internet Engineering Task Force [Page 96] RFC1122 TRANSPORT LAYER -- TCP October 1989 特に、キャラクターモードのリモートログインの場合、遅延ACK は、サーバーによって送信されるセグメント数を3の倍数で削減 できる(ACK、ウインドウ更新、エコー文字がすべて1セグメントに 統合されるため)。 更に、一部の大規模マルチユーザーホストの場合、遅延ACKは 処理されるパケット総数を減らすので、結果としてプロトコル 処理のオーバーヘッドを大幅に削減することができる[TCP:5]。 しかし、ACKの極端な遅延は、ラウンドトリップタイムの計測 やパケットを使用する"時間測定"アルゴリズム[TCP:7]を阻害 する可能性がある。 4.2.3.3 ウインドウ更新をいつ送信するか TCPは、受信側にSWS回避アルゴリズムを組み込まなければならない (MUST)[TCP:5]。 【 実装 】 受信側のSWS回避アルゴリズムは、ウインドウ右端を進めても 問題なくなるのはいつかを決定する。これは慣例的に "ウインドウの更新"として知られている。このアルゴリズム を遅延ACKアルゴリズム(セクション4.2.3.2参照)と組み 合わせることで、現在のウインドウを含むACKセグメントが 受信側に実際に送信されるのはいつかが決定される。本文書は RFC 793の表記法を使用する。RFC 793の図4及び図5を 参照せよ。 受信側のSWS解決策は、たとえネットワークから受信された データが小さいセグメントで構成されていたとしても、 RCV.NXT+RCV.WNDがわずかしか増えないウインドウ右端の 進行を回避することである。 受信バッファー空間の総量をRCV.BUFFとする。また任意の 時点において、この総量RCV.BUFFのうち、データ受信が完了 して確認応答も返したが、ユーザープロセスがまだ消費して いないデータの占める量がRCV.USERオクテットであるとする。 接続が休止状態であればRCV.WND = RCV.BUFFであり、 RCV.USER = 0 である。 データが到着し、確認応答される際にウインドウ右端を固定 したままにするには、受信者がバッファー空間全体よりも 小さい値を提示する必要がある。言い換えると、受信者は RCV.NXTが増加する際に、RCV.NXT+RCV.WNDが変化しないRCV.WND を指定しなければならない。従って、バッファー空間 総量RCV.BUFFは一般に三つの部分に分割される。 Internet Engineering Task Force [Page 97] RFC1122 TRANSPORT LAYER -- TCP October 1989 |<------- RCV.BUFF ---------------->| 1 2 3 ----|---------|------------------|------|---- RCV.NXT ^ (固定) 1 - RCV.USER = 受信されたがまだ消費されていないデータ 2 - RCV.WND = 送信側に広報された空間 3 - Reduction = 利用可能だが広報されていない空間 提案されている受信側用SWS回避アルゴリズムは、 Reduction部に関して以下が満たされるまでRCV.NXT+RCV.WND を固定したままにすることである。 RCV.BUFF - RCV.USER - RCV.WND >= min( Fr * RCV.BUFF, Eff.snd.MSS ) ここで、Frは割合で、その推奨値は1/2である。また、 Eff.snd.MSSは、接続で使用される実効送信MSSである (セクション4.2.2.6参照)。不等式が満たされると、RCV.WND はRCV.BUFF-RCV.USERに設定される。 このアルゴリズムの一般的な効果は、RCV.WNDをEff.snd.MSSずつ 進める(現実の受信バッファーでは、Eff.snd.MSS < RCV.BUFF/2 になるから)ことであることに注意せよ。また、受信側は自身の Eff.snd.MSSを使用しなければならないが、その際にEff.snd.MSS が送信側と同じであるという想定があることにも注意せよ。 4.2.3.4 データをいつ送信するか TCPは、送信側にSWS回避アルゴリズムを組み込まなければならない (MUST)。 TCPは、短いセグメントを統合するためにNagleアルゴリズム[TCP:9] を実装すべきである(SHOULD)。ただし、アプリケーションが個々の 接続でNagleアルゴリズムを無効にする方法がなければならない (MUST)。すべての場合において、送信中のデータは、スロースタート アルゴリズム(セクション4.2.2.15)に課される制約も受ける。 【 議論 】 Nagleアルゴリズムは、一般に以下の通りである。 確認応答されていないデータが存在する場合(つまり、 SND.NXT > SND.UNAの場合)、送信側TCPは次のように 振る舞う。 Internet Engineering Task Force [Page 98] RFC1122 TRANSPORT LAYER -- TCP October 1989 送信側TCPは、送信済みのデータが確認応答されるまで、 またはTCPがフルサイズ(Eff.snd.MSSバイト。セクション 4.2.2.6参照)のセグメントを送信できるようになるまで、 すべてのユーザーデータをバッファーに保存する。 一部のアプリケーション(例えば、リアルタイムの表示 ウインドウ更新)は、Nagleアルゴリズムを無効にする必要が あるため、小さいデータセグメントのストリームが最大 レートで送出される可能性がある。 【 実装 】 送信側は受信側のバッファー空間総量RCV.BUFFを(直接には) 知らないため、送信側のSWS回避アルゴリズムは、受信側 よりも困難である。うまく動作することが分かっている アプローチは、送信側がMax(SND.WND)、つまり接続上で これまでに見られた送信ウインドウの最大値を計算し、 その値をRCV.BUFFの推定値として使用することである。 残念なことに、これは推定値でしかない。受信側はいつでも RCV.BUFFのサイズを減らすことができる。結果として生じる デッドロックを回避するため、SWS回避アルゴリズムに優先 して強制的にデータを転送させるタイムアウトの仕組みを 持つ必要がある。実際のところ、このタイムアウトは滅多に 起きないはずである。 "使用可能ウインドウ"[TCP:5]は以下の通りである。 U = SND.UNA + SND.WND - SND.NXT 言い換えると、提示される送信ウインドウから送信されたが 確認応答されていないデータ量を差し引いたものになる。 送信側TCPのキューに入れられてまだ送信されていない データ量をDとすると、以下の一連のルールが推奨される。 以下のどれかに合致する場合にデータを送信する。 (1) 最大サイズのセグメントが送信可能な場合、すなわち、 以下が成り立つ場合 min(D,U) >= Eff.snd.MSS (2) データがプッシュされており、キュー内の全データを 今すぐに送信可能な場合、すなわち、以下が成り立つ 場合 [SND.NXT = SND.UNA かつ] PUSHED かつ D <= U (角カッコの条件はNagleアルゴリズムに課されたもの である) Internet Engineering Task Force [Page 99] RFC1122 TRANSPORT LAYER -- TCP October 1989 (3) 少なくとも、最大ウインドウに対する割合Fsの量が送信 できる場合、すなわち、以下が成り立つ場合 [SND.NXT = SND.UNA かつ] min(D,U) >= Fs * Max(SND.WND); (4) データがプッシュされており、優先タイムアウト (override timeout)が発生した場合 ここで、Fsは割合で、その推奨値は1/2である。優先タイム アウトは、0.1～1秒の範囲内とすべきである。このタイマー と、ゼロウインドウ調査(セクション4.2.2.17)で使用される タイマーを組み合わせると便利だろう。 最後に、今ここで規定されたSWS回避アルゴリズムは、[TCP:5] に含まれる送信者側アルゴリズムの代わりに使用されることに なるものであることに注意せよ。 4.2.3.5 TCP接続の障害 TCPによる同じセグメントの過度の再送は、リモートホストまたは インターネットパスの何らかの障害を示唆するものである。この 障害は、短時間かもしれないし長時間かもしれない。データ セグメントの過度の再送に対処するため、以下の手順が使用され なければならない(MUST)[IP:11]。 (a) 本手順には、同じセグメントに対して発生した再送の量を 測定する二つのしきい値R1とR2が存在する。R1とR2は、再送 時間か再送回数を測定する。 (b) 同じセグメントの送信回数がしきい値R1以上になると、停止 ゲートウェイ診断を起動させるために、否定的な助言を IPレイヤーに渡す(セクション3.3.1.4参照)。 (c) 同じセグメントの送信回数がR1より大きいしきい値R2に 達したら接続をクローズする。 (d) アプリケーションは、特定の接続に対してR2の値を設定でき なければならない(MUST)。例えば、対話型アプリケーション はR2を"無限大"に設定し、いつ接続を切断するかの制御を ユーザーに与えるかもしれない。 Internet Engineering Task Force [Page 100] RFC1122 TRANSPORT LAYER -- TCP October 1989 (e) R1には到達したがR2には未到達の場合、TCPはアプリケーション に配送の問題を通知すべきである(SHOULD)(ただしそのような 情報がアプリケーションによって無効にされていない場合に 限られる。セクション4.2.4.1参照)。これにより、例えば リモートログイン(User Telnet)アプリケーションプログラム がユーザーに通知できるようになる。 R1の値は、現在のRTOで少なくとも3回の再送に相当するものに すべきである(SHOULD)。R2の値は、少なくとも100秒に相当する ものにすべきである(SHOULD)。 TCP接続オープンの試みは、SYNセグメントの過度の再送か、RST セグメントやICMPポート到達不能の受信などにより失敗すること がある。SYNの再送は、アプリケーションレイヤーへの通知を 含めて、データ再送のために記述された一般的な手順に従って 処理されなければならない(MUST)。 ただし、R1の値とR2の値はSYNセグメントとデータセグメントで 異なっていてもよい。特に、SYNセグメントのR2は、少なくとも 3分間はセグメント再送を行える程度に十分大きい値に設定され なければならない(MUST)。もちろん、アプリケーションは直ちに 接続をクローズする(オープンの試みをあきらめる)こともできる。 【 議論 】 一部のインターネットパスは、接続構築時間がかなり大きい。 そのようなパスの数は、将来増加する可能性がある。 4.2.3.6 TCP接続のキープアライブ "キープアライブ"は広く受け入れられているものではないが、 実装者は、TCP実装にこの機能を組み込んでもよい(MAY)。 キープアライブが組み込まれている場合、アプリケーションは、 TCP接続ごとに機能を有効または無効にできなければならず(MUST)、 またデフォルトは無効でなければならない(MUST)。 キープアライブパケットは、一定期間内に接続に関するデータ パケットも確認応答パケットも受信されなかった場合にのみ送信 されなければならない(MUST)。この期間は設定可能でなければ ならず(MUST)、またデフォルトは2時間以上でなければならない (MUST)。 データを含まないACKセグメントは、TCPによる確実な転送が なされないことを思い出すことは極めて重要である。この理由に より、キープアライブの仕組みが実装されている場合、いかなる 死活確認(probe)の失敗であっても、それを接続障害と解釈しては ならない(MUST NOT)。 Internet Engineering Task Force [Page 101] RFC1122 TRANSPORT LAYER -- TCP October 1989 実装は、データを持たないキープアライブセグメントを送信すべき である(SHOULD)。しかし、誤ったTCP実装との互換性のために、 1オクテットの不要データ(one garbage octet)を含めてキープ アライブセグメントを送信するように設定可能であってもよい(MAY)。 【 議論 】 "キープアライブ"の仕組みは、それを行わないと接続が アイドル状態になってしまう場合に、たとえ送信されるデータ が無くても接続の対向側に対して死活確認を行うものである。 TCP仕様はキープアライブの仕組みを含まない。その理由は 以下の通りである。(1)一時的なインターネット障害の間に、 完璧に良好だった接続を壊してしまう可能性がある。(2)不要 な帯域を消費する可能性がある("誰も接続を使用していない のなら、その接続がまだ良好かはどうでもよいのでは？")。 (3)パケット従量課金するインターネットパスではコストが かさむかもしれない。 しかし、一部のTCP実装はキープアライブの仕組みを組み 込んできた。アイドル状態の接続がまだ有効であることを 確認するため、これらの実装は、対向側TCPから応答を引き出す ように設計された死活確認セグメントを送信する。そのような セグメントは、一般にSEG.SEQ=SND.NXT-1を含み、1オクテット の不要データを含む場合もあれば含まない場合もある。 平穏な接続ではSND.NXT=RCV.NXTになるので、このSEG.SEQ はウインドウの範囲外であることに注意せよ。従って、 死活確認は受信者に確認応答セグメントを返させ、それにより 接続がまだ生きていることを確認する。対向側がネットワーク からの隔絶またはクラッシュにより接続を打ち切っていた場合、 確認応答の代わりにRSTを応答するだろう。 残念なことに、一部の作法を守らないTCP実装は、セグメントが データを含まない限りSEG.SEQ=SND.NXT-1のセグメントの応答に 失敗する。代替手段として、実装は、対向側が不要データ オクテットを含まないキープアライブパケットに正しく応答して きたかを判定して対処することもできるかもしれない。 TCPキープアライブの仕組みは、ネットワーク障害中に クライアントがクラッシュまたはアボートした場合、キープ アライブを行わないと無期限にハングアップし、リソースを 不必要に消費してしまうようなサーバーアプリケーションに おいてのみ起動されるべきである。 Internet Engineering Task Force [Page 102] RFC1122 TRANSPORT LAYER -- TCP October 1989 4.2.3.7 TCPとマルチホーム接続 マルチホームホスト上のアプリケーションが能動的にTCP接続を オープンする際にローカルIPアドレスを指定しなかった場合、 TCPは、(最初の)SYNを送信する前に、IPレイヤーにローカルIPの 選択をするよう依頼しなければならない(MUST)。セクション3.4 の関数GET_SRCADDR()を参照せよ。 それ以外の場合はすべて、接続上で前のセグメントの送信、受信の どちらかがなされている。TCPは、前のセグメントで使用された ものと同じローカルIPアドレスを使用しなければならない(MUST)。 4.2.3.8 IPオプション 受信されたオプションがIPレイヤーからTCPレイヤーに渡される 際に、TCPは理解できないオプションを無視しなければならない (MUST)。 TCPは、タイムスタンプオプションとルート記録オプションを サポートしてもよい(MAY)。 アプリケーションは、TCP接続を能動的にオープンする際に、 ソースルートを指定できなければならず(MUST)、またその指定は 受信されたデータグラムで指定されていたソースルートに優先 されなければならない(MUST)。 TCP接続が受動的にオープンされ、完了したIPソースルートオプション を持つ(つまり復路ルートを含む)パケットが到着した場合、TCPは 復路ルートを保存し、それをその接続上で送信される全セグメント に使用しなければならない(MUST)。後になって異なるソースルート が指定されたセグメントが到着した場合、後の定義で前の定義を 上書きすべきである(SHOULD)。 4.2.3.9 ICMPメッセージ TCPは、IPレイヤーから渡されたICMPエラーメッセージに従って 動作し、それをエラーを生成した接続に適用しなければならない (MUST)。多重分離に必要な情報は、ICMPメッセージのデータ部 に含まれるIPヘッダー等の中で見つけることができる。 ・ 送信元抑制 TCPは、接続上の転送を遅くすることによって送信元抑制に 対応しなければならない(MUST)。推奨される(RECOMMENDED) 手順は、再送タイムアウトが発生したかのように、送信元 抑制をきっかけとして"スロースタート"を起動すること である。 ・ 宛先到達不能(コード0、1、5) Internet Engineering Task Force [Page 103] RFC1122 TRANSPORT LAYER -- TCP October 1989 これらの宛先到達不能メッセージはソフトエラー状態を示して いるので、TCPは接続をアボートしてはならず(MUST NOT)、 アプリケーションがその情報を利用できるようにすべきである (SHOULD)。 【 議論 】 TCPは、ERROR_REPORTルーチンへのアップコールにより、 アプリケーションレイヤーにソフトエラー状態が生じた と直接報告できるかもしれない。あるいは、単に メッセージを記録しておき、TCP接続がタイムアウト した場合にだけそれをアプリケーションレイヤーに報告 するといったこともできるかもしれない。 ・ 宛先到達不能(コード2～4) これらはハードエラー状態なので、TCPは接続をアボート すべきである(SHOULD)。 ・ 時間超過(コード0、1) これは、宛先到達不能(コード0、1、5)と同じように対処 されるべきである(上記参照)。 ・ パラメーター不正 これは、宛先到達不能(コード0、1、5)と同じように対処 されるべきである(上記参照)。 4.2.3.10 リモートアドレスの妥当性検証 TCP実装は、無効なリモートIPアドレス(例えばブロードキャスト アドレスやマルチキャストアドレス)へのローカルなOPENコールを エラーとして拒否しなければならない(MUST)。 無効な送信元アドレスを持つSYNが到着した場合、TCPかIPレイヤー のどちらかで無視されなければならない(セクション3.2.1.3参照)。 TCP実装は、ブロードキャストアドレスまたはマルチキャスト アドレスに宛てられたSYNセグメントが到着した場合、黙って破棄 しなければならない(MUST)。 4.2.3.11 TCPのトラフィックパターン 【 実装 】 TCPプロトコル仕様[TCP:1]は、接続上でメッセージフローを 制御するアルゴリズム、具体的に、パケット化、ウインドウ の管理、確認応答の送信などの設計について、多大な自由を 実装者に与えている。 Internet Engineering Task Force [Page 104] RFC1122 TRANSPORT LAYER -- TCP October 1989 これらの設計上の意思決定は難しい。TCPは幅広いトラフィック パターンに適応しなければならないからである。経験によれば、 TCP実装者は、以下に示す二つの極端なトラフィックパターンに 対して設計を検証する必要があることがわかっている。 ・ 単一文字セグメント 送信者がNagleアルゴリズムを使用していたとしても、 TCP接続が低遅延のLANを介してリモートログイン トラフィックを配送する場合、受信者は、一般に単一 文字セグメントのストリームを取得する。リモート ターミナルのエコーモードが有効になっている場合、 受信者のシステムは、一般に各文字が受信されるごとに その文字をエコーする。 ・ バルク転送 TCPがバルク転送に使用される場合、データストリーム は、(ほぼ)すべてが実効MSSの大きさのセグメントで構成 されるべきである。TCPはバイト(オクテット)単位の シーケンス番号空間を使用しているが、バルク転送 モードでは、TCPがあたかもセグメント数を数えるだけ のシーケンス番号空間を使用しているかのように処理 されるべきである。 更に、経験によれば単一のTCPで効果的かつ効率的にこれら 二つの極端な事例に対処できることが示されている。 新しいTCP実装を検証するための最も重要なツールは、パケット トレースプログラムである。他のTCP実装を通信相手とする 多様なトラフィックパターンをトレースし、その結果を慎重 に検討することの重要性は、膨大な量の経験に裏付けられて いる。 4.2.3.12 効率 【 実装 】 豊富な経験から、効率の高いTCP実装を指向した以下の ような示唆が得られている。 (a) データを極力コピーしない バルクデータ転送では、CPUを集中的に使用する主要な タスクは、データをある場所から別の場所にコピーし、 データのチェックサム計算をすることである。従って、 TCPデータのコピー回数を最小化することが重要である。 Internet Engineering Task Force [Page 105] RFC1122 TRANSPORT LAYER -- TCP October 1989 スピードの上限を定めるものは、メモリバスを介した データのフェッチであるから、コピーとチェックサム 計算を組み合わせ、一回のメモリフェッチでこれらを 同時に実行するようにすると有益だろう。 (b) チェックサムルーチンを独自に作る 優れたTCPチェックサムルーチンは、通常の場合、定義を 単純かつ直接的に実装したものよりも2～5倍高速である。 チェックサムを"超高速に"するには、細心の注意と巧みな コーディングがしばしば必要であり、またそのように することが望ましい。[TCP:10]を参照せよ。 (c) 一般的な事例で使用されるコードに注意を払う TCPプロトコルの処理は複雑になることもあるが、大半の セグメントでは、単純な判定が幾つかあるだけである。 セグメント単位の処理は、最も一般的な事例における 判定数を最小化するように基幹部分をコーディングする ことで、劇的に高速化される。 4.2.4 TCP/アプリケーションレイヤー間のインターフェース 4.2.4.1 非同期の通知 TCPのソフトエラー状態が発生したことをアプリケーションに通知 する仕組みがなければならない(MUST)。一般に、この仕組みは、 アプリケーションによって提供され、トランスポートレイヤー から非同期にアップコールされる以下のERROR_REPORTルーチン [INTRO:7]の形態をとると想定する。 ERROR_REPORT(local connection name, reason, subreason) reason、subreasonといったパラメーターの詳細なエンコーディング はここでは規定されない。ただし、アプリケーションに非同期に 報告されるエラー状態は、以下を含まなければならない(MUST)。 ・ ICMPエラーメッセージの到着(セクション4.2.3.9参照) ・ 過度の再送(セクション4.2.3.5参照) ・ 緊急ポインターがデータストリームの先にある(セクション 4.2.2.4参照) しかし、そのようなERROR_REPORTコールの受信を望まない アプリケーションプログラムは、実効的にこれらのコールを 無効にできるようにすべきである(SHOULD)。 Internet Engineering Task Force [Page 106] RFC1122 TRANSPORT LAYER -- TCP October 1989 【 論点 】 これらのエラー報告は、一般に多くのアプリケーションが 悪影響無しに無視できるソフトエラーを反映するものである。 これらのエラー報告コールは、デフォルトでは"無効"にすべき だと提案されているが、それは必須ではない。 4.2.4.2 タイプオブサービス アプリケーションレイヤーは、接続上で送信されるセグメントの タイプオブサービス(TOS)を指定できなければならない(MUST)。 必須ではないが、接続の存続期間中にアプリケーションがTOSを 変更できるようにすべきである(SHOULD)。TCPは、接続上で セグメントを送信する際に、現在のTOS値を変更せずにIPレイヤー に渡すべきである(SHOULD)。 TOSは、接続の各方向で独立に指定されるので、受信側 アプリケーションは、ACKセグメントで使用されるTOSを指定 することになる。 TCPは、直前に受信したTOSをアプリケーションに渡してもよい (MAY)。 【 議論 】 幾つかのアプリケーション(例えばSMTP)は、接続の存続 期間中に通信の特性を変化させるので、TOSの指定変更を 望んでいる。 また、RFC 793で規定されるOPENコールは、コール元がソース ルート、ルート記録、タイムスタンプといったIPオプション を指定できるパラメーター("options")を含むことに注意せよ。 4.2.4.3 FLUSHコール 一部のTCP実装は、FLUSHコールを組み込んできた。これは、 ユーザーがSENDコールを発行済みだが、依然として現在の送信 ウインドウの右側にあるあらゆるデータのTCP送信キューを空に するものである。言い換えると、シーケンス番号の同期を失う ことなく、キューに入れられた送信データを可能な限り廃棄する ということである。これは、Telnetの"Abort Output(AO)"機能 の実装に便利である。 Internet Engineering Task Force [Page 107] RFC1122 TRANSPORT LAYER -- TCP October 1989 4.2.4.4 マルチホーム接続 RFC 793のセクション2.7及び3.8で概説されているユーザー インターフェースは、マルチホーム接続のために拡張される必要 がある。OPENコールは、以下に示す任意のパラメーターを 持たなければならない(MUST)。 OPEN( ... [local IP address,] ... ) これにより、ローカルIPアドレスの指定が可能となる。 【 議論 】 一部のTCPベースのアプリケーションは、特定の接続を オープンするために使用されるローカルIPアドレスを指定 する必要がある。FTPはその一例である。 【 実装 】 "ローカルIPアドレス"パラメーターを指定された受動的なOPEN コールは、そのアドレスへの接続リクエストの到着を待つ。 パラメーターが指定されない場合、受動的なOPENは、あらゆる ローカルIPアドレスへの接続リクエスト到着を待ち、"その接続 のローカルIPアドレス"として、リクエストされた特定の アドレスを対応させる。 能動的なOPENコールの場合、指定された"ローカルIPアドレス" パラメーターは、接続をオープンするために使用される。 パラメーターが指定されない場合、ネットワーキングソフト ウェアが接続で使用される適切なローカルIPアドレスを 選択する(セクション3.3.4.2参照)。 4.2.5 TCPの要件の概要 | | | | |S| | | | | | |H| | | | | | |O|M| | | |S| |U|U| | | |H| |L|S| | |M|O| |D|T|脚 | |U|U|M| | | | |S|L|A|N|N| | |T|D|Y|O|O|注 機 能 | ｾｸｼｮﾝ | | | |T|T| -------------------------------------------------|--------|-|-|-|-|-|-- | | | | | | | PUSHフラグ | | | | | | | プッシュされないデータを集約またはキュー保存 |4.2.2.2 | | |x| | | 送信者がPUSHフラグを畳み込む |4.2.2.2 | |x| | | | SENDコールでPUSHを指定可能 |4.2.2.2 | | |x| | | Internet Engineering Task Force [Page 108] RFC1122 TRANSPORT LAYER -- TCP October 1989 指定不可時: 送信者が無期限にバッファー保存 |4.2.2.2 | | | | |x| 指定不可時: 最終セグメントにPSH設定 |4.2.2.2 |x| | | | | 受信ALPにPSHを通知 |4.2.2.2 | | |x| | |1 可能な場合は常に最大サイズのセグメントを送信 |4.2.2.2 | |x| | | | | | | | | | | ウインドウ | | | | | | | 符号無しの数として扱う |4.2.2.3 |x| | | | | 32ビットの数字として処理する |4.2.2.3 | |x| | | | ウインドウを右端から縮小させる |4.2.2.16| | | |x| | ウインドウの縮小に対して堅牢 |4.2.2.16|x| | | | | 受信ウインドウを無期限にクローズ |4.2.2.17| | |x| | | 送信者がゼロウインドウを調査 |4.2.2.17|x| | | | | RTO後に最初の調査を行う |4.2.2.17| |x| | | | 指数的バックオフ |4.2.2.17| |x| | | | ウインドウが無期限にゼロのまま留まることを許容 |4.2.2.17|x| | | | | ゼロウインドウを理由に送信側がタイムアウト |4.2.2.17| | | | |x| | | | | | | | 緊急データ | | | | | | | ポインターは最終オクテットを指す |4.2.2.4 |x| | | | | 任意の長さの緊急データオクテット列サポート |4.2.2.4 |x| | | | | 緊急データを非同期にALPに通知 |4.2.2.4 |x| | | | |1 ALPがｷｭｰに入れられた緊急ﾃﾞｰﾀの有無/量を学習可 |4.2.2.4 |x| | | | |1 | | | | | | | TCPオプション | | | | | | | いかなるセグメント内のTCPオプションも受信 |4.2.2.5 |x| | | | | 未サポートのオプションを無視 |4.2.2.5 |x| | | | | 不正なオプション長への対処 |4.2.2.5 |x| | | | | 送信、受信の両方でMSSオプションを実装 |4.2.2.6 |x| | | | | MSSが536でないならMSSオプションを送信 |4.2.2.6 | |x| | | | MSSオプションを常に送信 |4.2.2.6 | | |x| | | 送信MSSのデフォルトは536 |4.2.2.6 |x| | | | | 実効送信MSSサイズの計算 |4.2.2.6 |x| | | | | | | | | | | | TCPチェックサム | | | | | | | 送信者がチェックサムを計算 |4.2.2.7 |x| | | | | 受信者がチェックサムを検査 |4.2.2.7 |x| | | | | | | | | | | | クロックに基づくISN選定の使用 |4.2.2.9 |x| | | | | | | | | | | | 接続のオープン | | | | | | | 同時オープンの試みをサポート |4.2.2.10|x| | | | | SYN-RCVDは直前の状態を記憶 |4.2.2.11|x| | | | | 受動的なOPENコールが他に干渉する |4.2.2.18| | | | |x| ｱﾌﾟﾘｹｰｼｮﾝが同じﾎﾟｰﾄ上で同時に待機する機能 |4.2.2.18|x| | | | | 必要ならSYNで使用する送信元アドレスをIPに依頼 |4.2.3.7 |x| | | | | それ以外の場合、接続で使用中のﾛｰｶﾙｱﾄﾞﾚｽ使用 |4.2.3.7 |x| | | | | ﾌﾞﾛｰﾄﾞｷｬｽﾄ/ﾏﾙﾁｷｬｽﾄIPｱﾄﾞﾚｽへのOPEN |4.2.3.10| | | | |x| ﾌﾞﾛｰﾄﾞｷｬｽﾄ/ﾏﾙﾁｷｬｽﾄｱﾄﾞﾚｽ宛ｾｸﾞﾒﾝﾄを黙って破棄 |4.2.3.10|x| | | | | (訳註: 本段落はErrata ID: 618を反映している)。 Internet Engineering Task Force [Page 109] RFC1122 TRANSPORT LAYER -- TCP October 1989 | | | | | | | 接続のクローズ | | | | | | | RSTがデータを保持可能 |4.2.2.12| |x| | | | アプリケーションに接続アボートを通知 |4.2.2.13|x| | | | | 半二重な接続のクローズ |4.2.2.13| | |x| | | データ消失を提示するためRST送信 |4.2.2.13| |x| | | | TIME-WAIT状態で2xMSL秒待機 |4.2.2.13|x| | | | | TIME-WAIT状態からのSYNの受理 |4.2.2.13| | |x| | | | | | | | | | 再送 | | | | | | | Jacobsonのスロースタートアルゴリズム |4.2.2.15|x| | | | | Jacobsonのふくそう回避アルゴリズム |4.2.2.15|x| | | | | 同じIP識別番号を使用して再送 |4.2.2.15| | |x| | | Karnのアルゴリズム |4.2.3.1 |x| | | | | JacobsonのRTO推定アルゴリズム |4.2.3.1 |x| | | | | 指数的バックオフ |4.2.3.1 |x| | | | | SYNのRTOをデータと同じ方法で計算 |4.2.3.1 | |x| | | | 推奨される初期値及び上限・下限値の使用 |4.2.3.1 | |x| | | | | | | | | | | ACKの生成: | | | | | | | 順番どおりでないセグメントをキューに入れる |4.2.2.20| |x| | | | ACK送信前にキュー内のセグメントをすべて処理 |4.2.2.20|x| | | | | 順番どおりでないセグメントに対するACK送信 |4.2.2.21| | |x| | | 遅延ACKの実装 |4.2.3.2 | |x| | | | 遅延は0.5秒未満 |4.2.3.2 |x| | | | | フルサイズセグメント2個ごとにACK送信 |4.2.3.2 |x| | | | | 受信側のSWS回避アルゴリズム実装 |4.2.3.3 |x| | | | | | | | | | | | データ送信 | | | | | | | TTL値を設定可能 |4.2.2.19|x| | | | | 送信側のSWS回避アルゴリズム実装 |4.2.3.4 |x| | | | | Nagleアルゴリズム実装 |4.2.3.4 | |x| | | | ｱﾌﾟﾘｹｰｼｮﾝがNagleｱﾙｺﾞﾘｽﾞﾑを無効にできる |4.2.3.4 |x| | | | | | | | | | | | 接続の障害: | | | | | | | 再送回数がR1に達したらIPに否定的助言を与える |4.2.3.5 |x| | | | | 再送回数がR2に達したら接続をクローズ |4.2.3.5 |x| | | | | ALPがR2を設定可能 |4.2.3.5 |x| | | | |1 R1 <= 再送回数 < R2の間にALPに通知 |4.2.3.5 | |x| | | |1 R1、R2に対して推奨値を適用 |4.2.3.5 | |x| | | | SYNに対しても同じ仕組みを使用 |4.2.3.5 |x| | | | | SYNの場合、R2は少なくとも3分間 |4.2.3.5 |x| | | | | | | | | | | | キープアライブパケットの送信: |4.2.3.6 | | |x| | | - アプリケーションが利用の有無をリクエスト可 |4.2.3.6 |x| | | | | - デフォルトは"無効" |4.2.3.6 |x| | | | | - 一定期間アイドルだった場合にのみ送信 |4.2.3.6 |x| | | | | - 期間を設定可能 |4.2.3.6 |x| | | | | Internet Engineering Task Force [Page 110] RFC1122 TRANSPORT LAYER -- TCP October 1989 - デフォルトは少なくとも2時間 |4.2.3.6 |x| | | | | - ACK消失に耐性を持つ |4.2.3.6 |x| | | | | | | | | | | | IPオプション | | | | | | | TCPが理解できないオプションを無視 |4.2.3.8 |x| | | | | タイムスタンプオプションをサポート |4.2.3.8 | | |x| | | ルート記録オプションをサポート |4.2.3.8 | | |x| | | ソースルートオプション: | | | | | | | ALPが指定可能 |4.2.3.8 |x| | | | |1 データグラム内のソースルートに優先 |4.2.3.8 |x| | | | | ソースルートから復路ルートを構築 |4.2.3.8 |x| | | | | ソースルートを後で上書き |4.2.3.8 | |x| | | | | | | | | | | IPレイヤーからのICMPメッセージ受信 |4.2.3.9 |x| | | | | 宛先到達不能(コード0,1,5) => ALPに通知 |4.2.3.9 | |x| | | | 宛先到達不能(コード0,1,5) => 接続アボート |4.2.3.9 | | | | |x| 宛先到達不能(コード2～4) => 接続アボート |4.2.3.9 | |x| | | | 送信元抑制 => スロースタート |4.2.3.9 | |x| | | | 時間超過 => ALPに通知、アボートせず |4.2.3.9 | |x| | | | パラメーター不正 => ALPに通知、アボートせず |4.2.3.9 | |x| | | | | | | | | | | アドレスの妥当性検証 | | | | | | | 無効なIPアドレスへのOPENコールを拒否 |4.2.3.10|x| | | | | 無効なIPアドレスからのSYNを拒否 |4.2.3.10|x| | | | | ﾌﾞﾛｰﾄﾞｷｬｽﾄ/ﾏﾙﾁｷｬｽﾄｱﾄﾞﾚｽへのSYNを黙って破棄 |4.2.3.10|x| | | | | | | | | | | | TCP/ALP間のインターフェースサービス | | | | | | | エラー通知の仕組み |4.2.4.1 |x| | | | | ALPはエラー通知ルーチンを無効にできる |4.2.4.1 | |x| | | | ALPは送信時にTOSを指定可能 |4.2.4.2 |x| | | | | TOS値を変更せずにIPに渡す |4.2.4.2 | |x| | | | 接続の存続期間中にALPがTOSを変更可能 |4.2.4.2 | |x| | | | 受信されたTOSをALPに渡す |4.2.4.2 | | |x| | | FLUSHコール |4.2.4.3 | | |x| | | OPENｺｰﾙにおいてﾛｰｶﾙIPｱﾄﾞﾚｽﾊﾟﾗﾒｰﾀｰを任意で指定 |4.2.4.4 |x| | | | | -------------------------------------------------|--------|-|-|-|-|-|-- -------------------------------------------------|--------|-|-|-|-|-|-- 脚注: (1) "ALP"は、アプリケーションレイヤープログラムを意味する。 Internet Engineering Task Force [Page 111] RFC1122 TRANSPORT LAYER -- TCP October 1989 5. REFERENCES INTRODUCTORY REFERENCES [INTRO:1] "Requirements for Internet Hosts -- Application and Support," IETF Host Requirements Working Group, R. Braden, Ed., RFC-1123, October 1989. [INTRO:2] "Requirements for Internet Gateways," R. Braden and J. Postel, RFC-1009, June 1987. [INTRO:3] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI International, December 1985. [INTRO:4] "Official Internet Protocols," J. Reynolds and J. Postel, RFC-1011, May 1987. This document is republished periodically with new RFC numbers; the latest version must be used. [INTRO:5] "Protocol Document Order Information," O. Jacobsen and J. Postel, RFC-980, March 1986. [INTRO:6] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May 1987. This document is republished periodically with new RFC numbers; the latest version must be used. [INTRO:7] "Modularity and Efficiency in Protocol Implementations," D. Clark, RFC-817, July 1982. [INTRO:8] "The Structuring of Systems Using Upcalls," D. Clark, 10th ACM SOSP, Orcas Island, Washington, December 1985. Secondary References: [INTRO:9] "A Protocol for Packet Network Intercommunication," V. Cerf and R. Kahn, IEEE Transactions on Communication, May 1974. [INTRO:10] "The ARPA Internet Protocol," J. Postel, C. Sunshine, and D. Cohen, Computer Networks, Vol. 5, No. 4, July 1981. [INTRO:11] "The DARPA Internet Protocol Suite," B. Leiner, J. Postel, R. Cole and D. Mills, Proceedings INFOCOM 85, IEEE, Washington DC, Internet Engineering Task Force [Page 112] RFC1122 TRANSPORT LAYER -- TCP October 1989 March 1985. Also in: IEEE Communications Magazine, March 1985. Also available as ISI-RS-85-153. [INTRO:12] "Final Text of DIS8473, Protocol for Providing the Connectionless Mode Network Service," ANSI, published as RFC-994, March 1986. [INTRO:13] "End System to Intermediate System Routing Exchange Protocol," ANSI X3S3.3, published as RFC-995, April 1986. LINK LAYER REFERENCES [LINK:1] "Trailer Encapsulations," S. Leffler and M. Karels, RFC-893, April 1984. [LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826, November 1982. [LINK:3] "A Standard for the Transmission of IP Datagrams over Ethernet Networks," C. Hornig, RFC-894, April 1984. [LINK:4] "A Standard for the Transmission of IP Datagrams over IEEE 802 "Networks," J. Postel and J. Reynolds, RFC-1042, February 1988. This RFC contains a great deal of information of importance to Internet implementers planning to use IEEE 802 networks. IP LAYER REFERENCES [IP:1] "Internet Protocol (IP)," J. Postel, RFC-791, September 1981. [IP:2] "Internet Control Message Protocol (ICMP)," J. Postel, RFC-792, September 1981. [IP:3] "Internet Standard Subnetting Procedure," J. Mogul and J. Postel, RFC-950, August 1985. [IP:4] "Host Extensions for IP Multicasting," S. Deering, RFC-1112, August 1989. [IP:5] "Military Standard Internet Protocol," MIL-STD-1777, Department of Defense, August 1983. This specification, as amended by RFC-963, is intended to describe Internet Engineering Task Force [Page 113] RFC1122 TRANSPORT LAYER -- TCP October 1989 the Internet Protocol but has some serious omissions (e.g., the mandatory subnet extension [IP:3] and the optional multicasting extension [IP:4]). It is also out of date. If there is a conflict, RFC-791, RFC-792, and RFC-950 must be taken as authoritative, while the present document is authoritative over all. [IP:6] "Some Problems with the Specification of the Military Standard Internet Protocol," D. Sidhu, RFC-963, November 1985. [IP:7] "The TCP Maximum Segment Size and Related Topics," J. Postel, RFC-879, November 1983. Discusses and clarifies the relationship between the TCP Maximum Segment Size option and the IP datagram size. [IP:8] "Internet Protocol Security Options," B. Schofield, RFC-1108, October 1989. [IP:9] "Fragmentation Considered Harmful," C. Kent and J. Mogul, ACM SIGCOMM-87, August 1987. Published as ACM Comp Comm Review, Vol. 17, no. 5. This useful paper discusses the problems created by Internet fragmentation and presents alternative solutions. [IP:10] "IP Datagram Reassembly Algorithms," D. Clark, RFC-815, July 1982. This and the following paper should be read by every implementor. [IP:11] "Fault Isolation and Recovery," D. Clark, RFC-816, July 1982. SECONDARY IP REFERENCES: [IP:12] "Broadcasting Internet Datagrams in the Presence of Subnets," J. Mogul, RFC-922, October 1984. [IP:13] "Name, Addresses, Ports, and Routes," D. Clark, RFC-814, July 1982. [IP:14] "Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQUID)," W. Prue and J. Postel, RFC-1016, July 1987. This RFC first described directed broadcast addresses. However, the bulk of the RFC is concerned with gateways, not hosts. Internet Engineering Task Force [Page 114] RFC1122 TRANSPORT LAYER -- TCP October 1989 UDP REFERENCES: [UDP:1] "User Datagram Protocol," J. Postel, RFC-768, August 1980. TCP REFERENCES: [TCP:1] "Transmission Control Protocol," J. Postel, RFC-793, September 1981. [TCP:2] "Transmission Control Protocol," MIL-STD-1778, US Department of Defense, August 1984. This specification as amended by RFC-964 is intended to describe the same protocol as RFC-793 [TCP:1]. If there is a conflict, RFC-793 takes precedence, and the present document is authoritative over both. [TCP:3] "Some Problems with the Specification of the Military Standard Transmission Control Protocol," D. Sidhu and T. Blumer, RFC-964, November 1985. [TCP:4] "The TCP Maximum Segment Size and Related Topics," J. Postel, RFC-879, November 1983. [TCP:5] "Window and Acknowledgment Strategy in TCP," D. Clark, RFC-813, July 1982. [TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM SIGCOMM-87, August 1987. [TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88, August 1988. SECONDARY TCP REFERENCES: [TCP:8] "Modularity and Efficiency in Protocol Implementation," D. Clark, RFC-817, July 1982. Internet Engineering Task Force [Page 115] RFC1122 TRANSPORT LAYER -- TCP October 1989 [TCP:9] "Congestion Control in IP/TCP," J. Nagle, RFC-896, January 1984. [TCP:10] "Computing the Internet Checksum," R. Braden, D. Borman, and C. Partridge, RFC-1071, September 1988. [TCP:11] "TCP Extensions for Long-Delay Paths," V. Jacobson & R. Braden, RFC-1072, October 1988. セキュリティに関する考慮点 ホストソフトウェアの通信レイヤーには、多くのセキュリティ上の課題が 存在するが、本格的な議論は本RFCの対象範囲を越える。 インターネットアーキテクチャーは、一般にIP送信元アドレスを偽造した なりすましに対してわずかな保護しか提供しないので、データグラムの送信元 アドレスの検証に基づくあらゆるセキュリティの仕組みは、疑いを持ちつつ 取り扱われるべきである。しかし、制限された環境においては、ある程度の 送信元アドレス検査が可能な場合もある。例えば、保護されたLANがあり、 そのLANから残りのインターネット全域につながるゲートウェイが、送信元 アドレスをLANのアドレスに偽装したあらゆる到着データグラムを破棄する ような状況が考えられる。この場合、LAN上のホストは、送信元アドレスを 使用して送信元がローカルなのかリモートなのかを検査できるかもしれない。 この問題はソースルーティングによって複雑になるので、ソースルート指定 されたデータグラムをホストが転送する(セクション3.3.5参照)のは セキュリティ上の理由から禁止すべきだとの提案もされてきている。 セキュリティ関連の課題は、IPセキュリティオプション(セクション3.2.1.8)、 ICMPパラメーター不正メッセージ(セクション3.2.2.5)、UDPデータグラムのIP オプション処理(セクション4.1.3.2)、TCPの予約済みポート(セクション4.2.2.1) でそれぞれ述べられている。 Author's Address Robert Braden USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695 Phone: (213) 822 1511 EMail: Braden@ISI.EDU Internet Engineering Task Force [Page 116]