|
Network Working Group Request for Comments: 1122 |
Internet Engineering Task Force R. Braden, Editor October 1989 |
この RFC は、インターネット社会のための公式の規定である。これは、ホストに関連する基本的なプロトコル標準のドキュメントを参照、改正、修正、補足することによって編入している。このドキュメントの配布は制限されない。
これは、インターネットホストソフトウェアを定義し議論する一組の RFC である。この RFC は、通信プロトコル層: リンク層、IP 層、トランスポート層をカバーしている。もう片方の RFC-1123 は、アプリケーションとサポートプロトコルをカバーしている。
Table of Contents
1. 導入
1.1 インターネット体系
1.1.1 インターネットホスト
1.1.2 体系上の仮定
1.1.3 インターネットプロトコルスイート
1.1.4 組み込みゲートウェイコード
1.2 一般的な考慮
1.2.1 発展し続けるインターネット
1.2.2 頑強さの指針
1.2.3 エラーのログ採取
1.2.4 設定
1.3 このドキュメントを読む
1.3.1 構成
1.3.2 要件
1.3.3 用語
1.4 謝辞
2. リンク層
2.1 導入
2.2 プロトコルウォークスルー
2.3 特定の問題
2.3.1 トレーラープロトコル折衝
2.3.2 アドレス解決プロトコル -- ARP
2.3.2.1 ARP キャッシュの有効性
2.3.2.2 ARP パケットキュー
2.3.3 イーサネットと IEEE 802.2 のカプセル化
2.4 リンク/インターネット層インタフェース
2.5 リンク層要件要約
3. インターネット層プロトコル
3.1 導入
3.2 プロトコルウォークスルー
3.2.1 インターネットプロトコル -- IP
3.2.1.1 バージョン番号
3.2.1.2 チェックサム
3.2.1.3 アドレス付け
3.2.1.4 分割と組立
3.2.1.5 識別子
3.2.1.6 サービスタイプ
3.2.1.7 生存時間
3.2.1.8 オプション
3.2.2 インターネット制御メッセージプロトコル -- ICMP
3.2.2.1 宛先未到達
3.2.2.2 リダイレクト
3.2.2.3 送信元損失
3.2.2.4 時間超過
3.2.2.5 パラメタ問題
3.2.2.6 エコー要求/応答
3.2.2.7 情報要求/応答
3.2.2.8 タイムスタンプとタイムスタンプ応答
3.2.2.9 アドレスマスク要求/応答
3.2.3 インターネットグループ管理プロトコル IGMP
3.3 特定の問題
3.3.1 出力データグラムのルーティング
3.3.1.1 ローカル/リモート決定
3.3.1.2 ゲートウェイの選択
3.3.1.3 経路キャッシュ
3.3.1.4 ゲートウェイ障害検出
3.3.1.5 新たなゲートウェイ検出
3.3.1.6 初期化
3.3.2 組立
3.3.3 分割
3.3.4 ローカルなマルチホーム化
3.3.4.1 導入
3.3.4.2 マルチホーム化の要件
3.3.4.3 送信元アドレスの選択
3.3.5 送信元経路の転送
3.3.6 ブロードキャスト
3.3.7 IP マルチキャスト
3.3.8 エラー通知
3.4 インターネット/トランスポート層インタフェース
3.5 インターネット層要件要約
4. トランスポートプロトコル
4.1 ユーザデータグラムプロトコル - UDP
4.1.1 導入
4.1.2 プロトコルウォークスルー
4.1.3 特定の問題
4.1.3.1 ポート
4.1.3.2 IP オプション
4.1.3.3 ICMP メッセージ
4.1.3.4 UDP チェックサム
4.1.3.5 UDP マルチホーム
4.1.3.6 不正なアドレス
4.1.4 UDP アプリケーション層インタフェース
4.1.5 UDP 要件要約
4.2 転送制御プロトコル -- TCP
4.2.1 導入
4.2.2 プロトコルウォークスルー
4.2.2.1 よく知られたポート
4.2.2.2 プッシュの使用
4.2.2.3 ウィンドウサイズ
4.2.2.4 緊急ポインタ
4.2.2.5 TCP オプション
4.2.2.6 最大セグメント長オプション
4.2.2.7 TCP チェックサム
4.2.2.8 TCP コネクション状態遷移図
4.2.2.9 初期シーケンス番号選択
4.2.2.10 同時オープンの試み
4.2.2.11 古い重複 SYN からの回復
4.2.2.12 RST セグメント
4.2.2.13 コネクションのクローズ
4.2.2.14 データ通信
4.2.2.15 再送タイムアウト
4.2.2.16 ウィンドウ管理
4.2.2.17 ゼロウィンドウのプローブ
4.2.2.18 受動的 OPEN 呼び出し
4.2.2.19 生存時間
4.2.2.20 イベント処理
4.2.2.21 キューイングされたセグメントに対する肯定応答
4.2.3 特定の問題
4.2.3.1 再送タイムアウトの計算
4.2.3.2 いつ ACK セグメントを送信するか
4.2.3.3 いつウィンドウを更新するか
4.2.3.4 いつデータを送信するか
4.2.3.5 TCP コネクション障害
4.2.3.6 TCP Keep-Alives
4.2.3.7 TCP マルチホーム
4.2.3.8 IP オプション
4.2.3.9 ICMP メッセージ
4.2.3.10 リモートアドレス検査
4.2.3.11 TCP トラフィックパターン
4.2.3.12 効率性
4.2.4 TCP/アプリケーション層インタフェース
4.2.4.1 非同期通知
4.2.4.2 サービスタイプ
4.2.4.3 フラッシュ呼び出し
4.2.4.4 マルチホーム化
4.2.5 TCP 要件要約
5. 参照
セキュリティの考慮
作者のアドレス
このドキュメントは、インターネットプロトコルスイートのホストシステム実装要件を定義し議論するペアドキュメントのうちの一つである。この RFC は、通信プロトコル層: リンク層、IP 層、トランスポート層をカバーしている。もう片方の RFC "インターネットホスト要件 -- アプリケーションとサポート" [INTRO:1] は、アプリケーション層プロトコルをカバーしている。また、このドキュメントは "インターネットゲートウェイ要件" [INTRO:2] と共に読むべきである。
これらのドキュメントは、インターネット通信ソフトウェアのベンダー、実装者、ユーザ向けにガイダンスを提供することを意図している。それらは、インターネット研究団体やベンダのコミュニティによって寄与された、大多数の技術上の経験や知識のコンセンサスを表している。
この RFC は、インターネットに接続されたホストが使用しなければならない標準プロトコルを列挙しており、これらのプロトコルの現在の規定を記述している RFC や他のドキュメントを参照することによって編入している。それは、参照しているドキュメント中の誤りを修正し、実装者のために付加的な議論やガイダンスを追加している。
各々のプロトコルに対し、このドキュメントは要件や推奨やオプション等の明示的なセットも含んでいる。このドキュメント中の要件のリストはそれ自身では不完全であることを、読者は理解しなければならない。インターネットホストのための完全な要件は、基本的に標準プロトコルの規定ドキュメントで定義され、この RFC に記述された修正、改正、補足を含む。
注意深く RFC を読み、インターネット技術社会と協調し、適切な通信ソフトウェア技術の実践に従った上で作成されたプロトコルの誠実な実装は、このドキュメントの要件との相違はマイナーなものに限られるはずである。従って、多くの場合この RFC の "要件" は、既に標準プロトコルドキュメントで述べられているか、含まれている。よってここに含めることは、ある意味冗長である。しかし、幾つかの過去の実装は誤った選択をし、相互接続性やパフォーマンス、頑強性に問題を引き起こしたことがあるので、それらを含めている。
このドキュメントは、数多くの要件や推奨についての議論や説明を含んでいる。要件を簡単に一覧化することは危険である。なぜなら、
しかし、このドキュメントの規定は、多種多様で複雑なインターネットシステム全体で、任意のホストの相互運用の一般的な目標に適合するために従わなければならない。現在の大半の実装は、あるものはメジャーな、またあるものはマイナーな様々な点でこれらの要件に適合していないが、この規定は我々が移行する必要のある考え方である。
これらの要件は、インターネット体系の現在のレベルに基づいている。このドキュメントは、追加の説明を提供したり、規定が依然として発展している分野における追加の情報を含めるために、必要に応じて更新されるだろう。
この導入部のセクションは、ホストに関するインターネット体系の簡潔な概要から始め、次にホストソフトウェアベンダに幾つかの一般的なアドバイスを提示している。そして最後に、ドキュメントの残りと幾つかの用語を読むにあたってのガイダンスを示している。
インターネット体系とサポートするプロトコルスイートに関する一般的な背景と議論は DDN プロトコルハンドブック [INTRO:3] で見ることができる。背景については、例えば [INTRO:9]、[INTRO:10]、[INTRO:11] を参照されたい。参照 [INTRO:5] は、インターネットプロトコルドキュメントを手に入れる手続きについて説明している。一方 [INTRO:6] は、インターネットプロトコルの中で割り当てられた番号の一覧を含んでいる。
ホストコンピュータ、あるいは単に "ホスト" は、通信サービスの最終的な消費者である。ホストは通常、この機能をサポートするネットワークやインターネット通信サービスを使用して、ユーザのためにアプリケーションプログラムを実行する。インターネットホストは、OSI プロトコルスイート [INTRO:13] で使用される "終端システム" の概念に相当する。
インターネット通信システムは、インターネットプロトコルを使用するホストコンピュータ間の通信をサポートした、相互接続されたパケットネットワークで構成される。そのネットワークは、インターネット社会では "ゲートウェイ" あるいは "IP ルータ" と呼ばれ、OSI の世界 [INTRO:13] では "中間システム" と呼ばれる、パケット交換コンピュータを使用して相互接続される。RFC "インターネットゲートウェイの要件" [INTRO:2] は、インターネットゲートウェイのための公式の規定を含んでいる。現ドキュメントともう片方のドキュメント [INTRO:1] と共にその RFC は、インターネット体系の現在の実現化のための規則を定義している。
インターネットホストは広範囲なサイズ、速度、機能に及ぶ。それらは、小さなマイクロプロセッサからワークステーション、そして汎用機やスーバコンピュータといった範囲にわたる。機能に関しては、単一目的のホスト (例えば端末サービス) から、一般的なリモートログインやファイル転送、電子メールを含む、多種多様なオンラインネットワークサービスをサポートする完全なサービスの範囲に及ぶ。
ホストは、同じか異なるネットワークに一つ以上のインタフェースを持っていたら、マルチホームと通常呼ばれる。"用語" については、セクション 1.3.3 を参照されたい。
現在のインターネット体系は、通信システムに関して一連の仮定に基づいている。大半はホストに関係するその仮定は、以下のものである。
(a) インターネットはネットワークのネットワークである。
各々のホストは、幾つかの特定のネットワークに直接接続されている。インターネットへの接続は、単に概念的なものである。同じネットワーク上の二つのホストは、離れたネットワーク上のホストと通信するために、同じセットのプロトコルを使用して互いに通信する。
(b) ゲートウェイはコネクション状態の情報を保持しない
通信システムの頑強性を改善するために、ゲートウェイは状態を持たず、各 IP
データグラムを他のデータグラムに依存せずに転送するよう設計されている。その結果、介在するゲートウェイやネットワークが障害になっても、頑強なサービスを提供するために冗長なパスを利用することができる。
エンドツーエンドのフロー制御や信頼性向上のために必要な全ての状態情報は、ホストのトランスポート層かアプリケーションプログラムで実装される。従って、全てのコネクション制御情報は通信の終端の同じ場所に配置されるので、終端が障害になった場合にのみそれが失われる。
(c) ルーティングの複雑さはゲートウェイにあるべきである。
ルーティングは複雑で難しい問題であり、ホストではなくゲートウェイによって実行されるべきである。重要な目的は、インターネットルーティング体系の避けられない発展による、ホストソフトウェアの変更を防ぐことである。
(d) システムは広範囲にわたるネットワークの多様性に対応しなければならない。
インターネット設計の基本的な目的は、広範囲にわたるネットワーク特性、例えば帯域や遅延、パケット損失、パケットの再順序付け、最大パケット長などに対応することである。別の目的は、個々のネットワーク、ゲートウェイ、ホストの障害に対する頑強性であり、まだ利用できる帯域を使用する。最終的に、目標は完全な
"オープンシステム相互接続" である。インターネットホストは、様々なインターネットパスに渡って、他のいかなるホストとも頑強で効率的に相互動作できなければならない。
ホストの実装者は時々、あまり野心的でない目標で設計していた。例えば、通常 LAN 環境は全体的にインターネットよりも良好である。LAN ではパケットの損失や遅延が少なく、パケットの再順序付けもほとんどない。幾つかのベンダは単純な LAN 環境に適したホスト実装を配備したが、一般的な相互動作での動作は具合が悪かった。ベンダはそのような製品を、限定された LAN マーケットでは経済的であるとして正当化している。しかし、隔離されている LAN が長い間隔離されたままに留まることはめったにない。それらは間もなくお互いに、そして組織単位で、最終的にはグローバルなインターネットシステムにゲートウェイされるだろう。結局、不完全な、あるいは標準に外れたインターネットホストソフトウェアは、消費者にもベンダにも役に立たないのである。
このドキュメントで詳述された要件は、任意のインターネットパス上で完全な相互動作を行える、完全な機能を持つインターネットホストのために設計されている。
インターネットシステムを使用して通信するために、ホストはインターネットプロトコルスイートを構成する、層に分けられたプロトコルのセットを実装しなければならない。ホストは、各々の層から少なくとも一つのプロトコルスイートを一般に実装しなければならない。
インターネット体系で使用されるプロトコル層は、以下の通り [INTRO:4]。
・アプリケーション層
アプリケーション層は、インターネットプロトコルスイートの最上位である。インターネットアプリケーション層のプロトコルの幾つかは、実際は内部的にサブレイヤを含んでいるが、インターネットスイートは、アプリケーション層をさらに細分化しない。インターネットスイートのアプリケーション層は、OSI
参照モデルの最上位の二つの層、プレゼンテーション層とアプリケーション層を本質的に結合する。
我々は、アプリケーション層プロトコルの二つのカテゴリを区別する。それは、ユーザに直接サービスを提供するユーザプロトコルと、共通的なシステム機能を提供するサポートプロトコルである。ユーザプロトコルとサポートプロトコルのための要件は、ペアの RFC [INTRO:1] に示されている。
最も一般的なインターネットユーザプロトコルは以下のもの。
数多くの他の標準化されたユーザプロトコル [INTRO:4] や、多くのプライベートなユーザプロトコルが存在する。
サポートプロトコルは、SNMP, BOOTP, RARP, ドメイン名システム (DNS) プロトコルを含み、ホスト名のマッピングや管理で使用される。
・トランスポート層
トランスポート層は、アプリケーションのためにエンドツーエンドの通信サービスを提供する。現在、二つの基本的なトランスポート層プロトコルが存在する。
TCP は信頼できるコネクション型トランスポートサービスであり、エンドツーエンドの信頼性や再順序付け、フロー制御を提供する。UDP はコネクションレス ("データグラム") トランスポートサービスである。
研究団体によって他のトランスポートプロトコルが開発されており、公式のインターネットトランスポートプロトコルのセットは、将来拡張されるかもしれない。
トランスポート層プロトコルは、チャプタ 4 で論じられている。
・インターネット層
全てのインターネットトランスポート層プロトコルは、データを送信元から宛先ホストに運ぶために、インターネットプロトコル
(IP) を使用する。IP はコネクションレス、あるいはデータグラム相互ネットワークサービスであり、エンドツーエンドの配送保証は提供しない。従って、IP
データグラムは宛先ホストに損傷を受けたり重複したり順序が変わったりして到着するかもしれないし、あるいは全く到着しないかもしれない。IP
上の層は、必要な場合は信頼できる配送サービスを提供する責任がある。IP
プロトコルは、アドレス付けやサービスタイプの指定、分割や組立、セキュリティ情報のための設備を含む。
データグラムや IP プロトコルのコネクションレス特性は基本的であり、インターネット体系の特徴的な一面である。インターネット IP は、OSI コネクションレスネットワークプロトコル [INTRO:12] のモデルであった。
ICMP は制御プロトコルであり、体系的には IP 上の層、すなわち ICMP は、TCP や UDP のようなトランスポートプロトコルと同様に、データをエンドツーエンドに運ぶために IP を使用するが、IP の重要な一部分であると見なされる。ICMP はエラー通知や輻輳通知、第一ホップのゲートウェイリダイレクションを提供する。
IGMP は、IP マルチキャストで動的なホストグループを確立するために使用されるインターネット層プロトコルである。
インターネット層プロトコルの IP, ICMP, IGMP については、チャプタ 3 で論じられる。
・リンク層
直接接続されたネットワーク上で通信するために、ホストは、そのネットワークにインタフェース接続するために使用される通信プロトコルを実装しなければならない。我々は、これをリンク層、あるいはメディアアクセス層プロトコルと呼ぶ。
多くの異なるネットワークのタイプに応じて、広範囲に渡るリンク層プロトコルが存在する。チャプタ 2 を参照されたい。
幾つかのインターネットホストソフトウェアは、ゲートウェイ機能を埋め込んでいる。これらのホストは、ホストのアプリケーション層の機能を実行しながらも、ゲートウェイのようにパケットを転送できる
このような二重の目的を持つシステムは、ゲートウェイ機能に関してはゲートウェイ要件 RFC [INTRO:2] に従わなければならず、ホスト機能に関してはこのドキュメントに従わなければならない。重複するケースについては全て、この二つの規定は合致しているはずである。
組み込みゲートウェイ機能については、インターネット社会において様々な意見がある。主要な議論は以下の通り。
これらの観点の両方ともかなりのメリットがある。一つの結論を抜き出せるだろう: ホスト管理者は、所定のホストがゲートウェイとして動作するか否かを意識的に制御しなければならない。詳細な要件については、セクション 3.1 を参照されたい。
インターネットホストソフトウェアのベンダが学び、新たなベンダが真剣に考慮すべき二つの重要な教訓がある。
インターネットの膨大な成長は、大きなデータグラムベースのパケット通信システムにおける、管理と規模の問題を暴露した。これらの問題は取り組まれており、結果的にこのドキュメントで示される規定も発展し続けるだろう。こうした計画には、ベンダやネットワークの運用に責任がある組織が広範囲に渡って関係しているので、これらの変更は慎重に計画、管理される。
成長、発展、改訂は今日のコンピュータネットワークプロトコルの特徴であり、この状態は数年は続くであろう。インターネットプロトコルスイート (あるいは他の如何なるプロトコルスイートでも !) のコンピュータ通信ソフトウェアを開発して、その後の規約の変更に対してそのソフトウェアの保守や更新を行なわないベンダは、不幸な消費者の跡を残すだろう。インターネットは大規模な通信ネットワークであり、ユーザは絶えずそれを通じて接触する。経験からすると、ベンダソフトウェアの欠陥に関する知識は、インターネット技術社会を通じて急速に伝達されるようである。
プロトコルの全ての層において、アプリケーションが頑強さと相互接続性に関して、莫大な利益をもたらすことができる一般原則がある [IP:1]。それは、
"受信するものには寛大であれ、送信するものには慎重であれ"
ソフトウェアは、考えられる異常を、たとえそれがあり得そうに無いものであっても処理できるよう書かれるべきである。遅かれ早かれ、パケットはある特定のエラーや属性が組み合わさって入ってくる。もしソフトウェアがそれに備えていなければ、混乱が起こり得る。一般に、ネットワークは最悪の影響を及ぼすことを意図したパケットを送信する、悪意を持ったエンティティが数多く存在するものと想定することが最善である。大半のインターネットの重大な問題は、低い確率で発生するイベントによって引き起こされる、予見できないメカニズムが原因ではあるが、この想定は適切な防御設計につながるだろう。人的悪意だけでは、さほど踏み誤った進路を辿ることはほとんど無い!
修正に対する適応性は、インターネットホストのソフトウェアの全てのレベルにおいて設計しなければならない。簡単な例だが、特定のヘッダフィールド値の列挙、たとえばタイプフィールドやポート番号、エラーコードを含むプロトコル規約を考慮した場合、この列挙値は完全ではないと想定しなければならない。従って、もしプロトコル規約が 4 つのあり得るエラーコードを定義したら、ソフトウェアは 5 つめのコードが現れたときに壊れてはならない。未定義のコードはログに採取してもよいが (後述)、障害の原因になってはならない。
指針の二番目の部分は、次の点において重要である。他のホスト上のソフトウェアは、正しいが不明確なプロトコル機能の開発を浅はかにする欠陥を含むかもしれない。面倒な影響を結果的にどこかに及ぼすのは良くないので、明確さや単純さから離れることは馬鹿げている。この結論は、"誤った動作をするホストに用心せよ" である。ホストソフトウェアは、単に他の誤った動作をするホストがあっても生き残るだけではなく、そうしたホストが原因で起こり得る、共有された通信設備への混乱の量を限定するために協調することを考慮すべきである。
インターネットは非常に多岐に渡るホストやゲートウェイシステムを伴い、その各々は多くのプロトコルやプロトコル層を実装しており、これらの幾つかはインターネットプロトコルソフトウェアの中にバグや機能誤りを含んでいる。複雑さや多様性や機能の分散の結果として、インターネット問題の診断はしばしば非常に困難である。
もしホスト実装が、異常や "奇妙な" プロトコルイベントをログに採取するために、注意深く設計された機能を含んでいれば、問題の診断に役立つだろう。エラーログを採取する際に、可能な限り多くの診断を含めることは重要である。特に、エラーの原因となったパケットのヘッダを記録することはしばしば効果的である。しかし、エラーのログ採取が極端に大量の資源を消費したり、さもなくばホスト処理の邪魔にならないことを保証するよう、注意しなければならない。
異常だが害は無いプロトコルイベントが、エラーのログファイルを溢れさせる傾向がある。これは "循環" ログを使用するか、あるいは既知の障害を診断する場合にのみログの採取を有効にすることによって回避できる。連続して重複したメッセージをフィルタにかけて、その回数を数えるのは効果的かもしれない。うまくいきそうな戦略は、(1) 常に異常事象をカウントし、その数には管理プロトコル ([INTRO:1] 参照) を通じてアクセスさせること。(2) 多様なイベントのログ採取を選択可能にすること。例えば、"全てをログに採る"、あるいは "ホスト X の全てをログに採る" ことができると便利かもしれない。
異なる管理者は、通常時にホストで有効にしたいエラーログの採取量に関して、異なる指針を持つかもしれない。ある者は "もし自分の害にならなければ、それについて知りたくない" と言うかもしれないし、またある者は、より注意深く積極的にプロトコル異常を検出し除去したいと思うかもしれない。
もしインターネットプロトコルスイートのホスト実装が完全に自己設定できれば、理想的である。これによって、スイート全体を ROM に実装したり、シリコンに組み込むことが可能になる。それによってディスクレスワークステーションが単純になり、システムベンダのみならず、苦しんでいる LAN 管理者にも莫大な恩恵をもたらすだろう。我々はまだこの理想には到達していないし、実際近づいてもいない。
このドキュメントの多くの個所に、このパラメタは設定可能なオプションであることという要件が見つかるだろう。そうした要件の背景には、幾つかの異なる理由がある。幾つかのケースでは、最適値について現在確定していないか同意されておらず、将来、推奨値を更新する必要があるかもしれない。別のケースでは、値が実際に外部要因に依存する。例えば、ホストのサイズや通信負荷の分散、隣接するネットワークの速度やトポロジなどである。そして自己調整アルゴリズムが使用できなかったり、不十分であるかもしれない。またあるケースでは、管理要件のために設定可能であることが必要とされる。
最後に、ある設定オプションは、廃止された、あるいはプロトコルの不正な実装体と通信するために必要である。それらはソース無しで配布され、不幸にもインターネットの多くの部分に残っている。正しいシステムをこれらの欠陥システムと共存させるために、管理者はしばしば、正しいシステムに "誤設定" を施す必要がある。この問題は、欠陥システムが退くにつれて次第に改善されていくだろう。しかし、ベンダはそれを無視することができない。
パラメタが設定可能でなければならないと言う場合、その値が毎回ブート時に設定ファイルから明示的に読み込まれる必要があることは意図していない。実装者は各パラメタにデフォルトを設定することが推奨される。よって設定ファイルは、ある特定のインストールにおいて適切でないデフォルトを、上書きする場合にのみ必要である。従って、設定を可能にするという要件は、バイナリのみや ROM ベースの製品でさえも、必要時にデフォルトを上書きすることができることの保証である。
このドキュメントは、幾つかのケースでそうしたデフォルトとして、特定の値を要求している。デフォルトの選択は、設定項目が既存の欠陥システムへの適応を制御する場合は、微妙な問題である。もしインターネットが完全な相互接続性に正常に収束するならば、実装体に組み込まれるデフォルト値は、欠陥システムに便宜を図るための "誤設定" ではなく、公式のプロトコルを実装しなければならない。市場を考慮すると、あるベンダは誤設定のデフォルトを選択するかもしれないが、我々は、この標準に適合したデフォルトをベンダが選択することを強く推奨する。
最後に、ベンダは全ての設定パラメタや、それらの制限や効果に関して、必要十分なドキュメントを提供する必要があることを書き留めておく。
プロトコルの層分けは、ネットワークソフトウェアを実装する際に構成の指針として通常使用されるが、このドキュメントの構成でも使用している。規則を規定する際、実装体はプロトコルの層を厳密に反映しているものと仮定する。従って、以下の三つの主要なセクションは、リンク層、インターネット層、トランスポート層の要件をそれぞれ規定する。ペアの RFC [INTRO:1] は、アプリケーションレベルのソフトウェアをカバーする。この層による構成は、平易さと明確さのために選択された。
しかし厳密な層分けは、プロトコルスイートと推奨される実装アプローチの両方にとって不完全なモデルである。異なる層のプロトコルは、複雑に、時には微妙に影響し合う。そしてある特定の機能は、複数の層にしばしば関係する。実装には多くの設計の選択肢があり、それらの多くは、厳密な層分けの創造的な "破壊" を伴う。参照 [INTRO:7] と [INTRO:8] を読むことを、全ての実装者に強く推奨する。
このドキュメントは、層と層の間の概念的なサービスインタフェースを、TCP 規定 [TCP:1] で使用されているような、関数的な ("手続き呼出し") 表記法で記述する。ホスト実装は、これらの呼出しが意味する論理的な情報の流れをサポートしなければならないが、その呼出し自身を文字通りに実装する必要は無い。例えば、多くの実装体は、共通のデータ構造にアクセスを共有させることにより、トランスポート層と IP 層の結合を反映している。これらのデータ構造は、明示的な手続き呼出しというよりはむしろ、必要な情報の大半を渡すための代用品である。
一般に、このドキュメントの各々の主要なセクションは、以下のサブセクションで構成される。
このドキュメント中の多くの個々のトピックの配下に、"DISCUSSION" か "IMPLEMENTATION" というラベルが付いた挿入句的な説明がある。この説明は、この前の要件テキストを明確化したり、説明を加えることを意図している。また、起こり得る将来の方向性や開発に対する幾つかの提案も含んでいる。実装説明は、実装者が考慮する必要のある提案されたアプローチを含む。
要約セクションは、テキストへのガイドとインデクスになることを意図しているが、かなり短く不完全である。要約は、完全な RFC とは切り離して使用したり参照すべきではない。
このドキュメントでは、各々の特定の要件の重要性を定義するために使用される単語は、大文字で記述される。これらの単語とは、
もし実装するプロトコルの一つ以上の MUST 要件を満たさなければ、その実装体は準拠していない。プロトコルの全ての MUST 要件と SHOULD 要件を満たしている実装体は、"無条件に準拠" と呼ばれる。プロトコルの MUST 要件は全て満たしているが、SHOULD 要件は全て満たしているわけではない実装体は、"条件付きで準拠" と呼ばれる。
このドキュメントは、以下の技術用語を使用する。
インターネット層の説明 (セクション 3) では、"データグラム" という用語に修飾子が無ければ、IP データグラムを指すものと解釈すべきである。
フレーム、パケット、データグラム、メッセージ、セグメントといった用語は、以下の概略図によって示されている。
A. 接続されたネットワーク上の転送:
_______________________________________________
| LL hdr | IP hdr | (data) |
|________|________|_____________________________|
<---------- Frame ----------------------------->
<----------Packet -------------------->
B. IP 分割前か、IP 組立後:
______________________________________
| IP hdr | transport| Application Data |
|________|____hdr___|__________________|
<-------- Datagram ------------------>
<-------- Message ----------->
3. あるいは TCP:
______________________________________
| IP hdr | TCP hdr | Application Data |
|________|__________|__________________|
<-------- Datagram ------------------>
<-------- Segment ----------->
このドキュメントは、大学や研究機関の代表者、ベンダ、政府機関の代理人を含む、インターネットプロトコルの専門家の大きなグループからの寄与とコメントを反映している。基本的には、インターネット技術作業団体 (IETF) のホスト要件作業グループによって整理された。
編集者は、特に次の人々の多大な貢献に感謝したい。彼らは、多くの長い会議に参加し、このドキュメントの検討で、過去 18 ヶ月に及ぶ 3 百万バイトもの電子メールを作成した。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), James Van Bokkelen (FTP Software)。
加えて、次の人々は成果に主要な寄与を施した。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)。また次の人々は、特定の分野に重要な寄与をもたらした。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), Rayan Zachariassen (Toronto)。
この一覧からたまたま漏れているかもしれない寄与者を含め、皆に感謝したい。
全てのインターネットシステムのホストとゲートウェイの両方は、リンク層プロトコルで同じ要件を持つ。これらの要件は "インターネットゲートウェイの要件" [INTRO:2] チャプタ 3 で示されており、このセクションの資料を増やしている。
無し
リンク層カプセル化のトレーラープロトコル [LINK:1] は使用してもよい (MAY) が、両方のシステム (ホストかゲートウェイ) が、リンク層通信実装にトレーラーを含んでいることが確かめられた場合に限る。もしシステムが、宛先毎に動的にトレーラープロトコルの使用を折衝しないならば、デフォルト設定はそのプロトコルを使用不可にしなければならない (MUST)。
DISCUSSION:
トレーラープロトコルはリンク層のカプセル化技術であり、物理ネットワークに送信されたパケットのデータ内容を再編集する。あるケースでは、トレーラーはオペレーティングシステム内のデータのコピー量を減らすことによって、上位層プロトコルのスループットを改善する。上位層プロトコルはトレーラーの使用を知らないが、もし使用されているならば、送信側と受信側の両方のホストはそのプロトコルを理解しなければならない
(MUST)。
トレーラーの不適切な使用は、大きな混乱を招く兆候を生み出す可能性がある。特定のサイズ属性を持つパケットだけがトレーラーを使用してカプセル化され、通常交換されているパケットの小さい断片だけがこれらの属性を持つ。従って、もしトレーラーを使用しているシステムが使用していないシステムとパケットを交換したら、他のパケットは正常に配送されるが、幾つかのパケットはブラックホールの中に消える。
IMPLEMENTATION:
イーサネット上では、トレーラー付きでカプセル化されたパケットは別のイーサネットタイプを使用し
[LINK:1]、トレーラーの折衝は、宛先システムのリンク層アドレスを検出するために ARP
が使用される時に行なわれる。特に、ARP 交換は通常の IP プロトコルタイプを使用する通常の方法で完了する。しかしトレーラーを喋りたいホストは、追加の
"トレーラー ARP 応答" パケット、すなわちトレーラーカプセル化プロトコルタイプを指定し、それ以外は通常の
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 応答に対してトレーラー ARP 応答を送信しないことによって回避される。これは、IP ARP 応答を受信したときにホストのハードウェアアドレスがまだ未知ならば真である。トレーラー ARP 応答は、IP ARP 要求に応答する IP ARP 応答と一緒に常に送信してもよい。
アドレス解決プロトコル (ARP) [LINK:2] は、古いキャッシュエントリをフラッシュするメカニズムを提供しなければならない (MUST)。もしこのメカニズムがタイムアウトによるものならば、そのタイムアウト値の設定を可能にすべきである (SHOULD)。
ARP フラッド (高い割合で同じ IP アドレスに ARP 要求を繰り返し送信すること) を防ぐメカニズムを含めなければならない (MUST)。推奨メカニズムは、宛先毎に 1 秒間につき 1 つの割合である。
DISCUSSION:
ARP 規約 [LINK:2]
は、ホストがイーサネットアドレスを変更する時に、キャッシュエントリを無効にするために、タイムアウトメカニズムを提案しているが、要求はしない。プロクシ
ARP ([INTRO:2] のセクション 2.4 参照)
の普及により、ホスト中のキャッシュエントリが無効になる見込みがかなり増えている。よって、幾つかの
ARP キャッシュ無効化メカニズムが、現在ホストで必要である。プロクシ ARP が存在しない場合でも、長時間のキャッシュタイムアウトは、キャッシングされた不正な
ARP データを自動的に修正するのに有効である。
IMPLEMENTATION:
古いキャッシュエントリをフラッシュするために、4 つのメカニズムが時には組み合わされて使用される。
(1) と (2) のアプローチは、分オーダ以下の ARP キャッシュタイムアウトを伴うものである。プロクシ ARP が無い場合は、このタイムアウトが短いと、大規模なイーサネット上で顕著なトラフィックのオーバーヘッドを生み出す。従って ARP キャッシュタイムアウトを延ばすよう、ホストを設定する必要があるかもしれない。
リンク層は同じ未解決の IP アドレス宛ての各一セットのパケットの、少なくとも 1 つの (最新の) パケットを (破棄するのではなく) 保持して、アドレスが解決された時に保持したパケットを送信すべきである (SHOULD)。
DISCUSSION:
この推奨に従わないと、全ての交換の一番最初のパケットが失われることになる。上位層プロトコルは、一般に再送によってパケット損失に対処することができるが、パケット損失はパフォーマンスにかなり影響する。例えば、TCP
オープン要求が損失すると、初期ラウンドトリップ時間の見積りが膨らんでしまう。ドメイン名システム等の
UDP ベースのアプリケーションでは、影響がより重大である。
イーサネットでの IP カプセル化は RFC894 [LINK:3] で規定され、RFC1042 [LINK:4] は IEEE 802 ネットワークにおける IP カプセル化を規定する。RFC1042 は、[INTRO:2] のセクション 3.4 の議論を詳述し、置き換えている。
10Mbps のイーサネットケーブルに接続される全てのインターネットホストは、
RFC894 と RFC1042 の両方のカプセル化を送信するよう実装したホストは、どちらを送信するかを選択する設定スイッチを提供しなければならず (MUST)、このスイッチはデフォルトで RFC894 でなければならない (MUST)。
注記: RFC1042 の IP カプセル化標準は IEEE が IP のために予約したプロトコル id 値 (K1=6) を使用せず、代わりにイーサタイプフィールドを保持するために使用できる拡張 ("SNAP") を含む値 (K1=170) を使用する。インターネットシステムは、K1=6 を使用した 802 パケットを送信してはならない (MUST)。
インターネットアドレスからイーサネットや IEEE 802 ネットワーク上のリンク層アドレスへのアドレス変換は、アドレス解決プロトコル (ARP) で処理しなければならない (MUST)。
イーサネットの MTU は 1500 であり、802.3 では 1492 である。
DISCUSSION:
IEEE 802.3 規約は、10Mbps イーサネットケーブル上の処理を提供している。その場合、イーサネットと IEEE 802.3
フレームは物理的に混在する。受信側は、イーサネットと 802.3 フレームを 802.3 長さフィールドの値によって区別できる。この
2 オクテットは、ヘッダ中でイーサネットフレームのイーサタイプフィールドと場所が一致する。特に、802.3 長さフィールドは
1500 以下でなければならないが、イーサタイプの値の正しい値は全て 1500 よりも大きい。
別の互換性問題は、リンク層プロトコルで起こる。一方のフレームで送信されるブロードキャストは、もう一方のフレームしか受信できないホストには見えない
このセクションの規定は、同じケーブル上で 894 ケーブルと 1042 ケーブルシステム間の直接の相互処理を、できる限り可能にして提供するために設計された。894 のみのシステムが主である現在の状況をサポートすることを意図し、将来 1042 ケーブルシステムが一般的になった場合に、容易な移行を提供する。
894 のみのシステムは、1042 のみのシステムとは直接に相互処理することはできない。もし二つのシステムタイプが、二つの異なる論理ネットワークとして同じケーブル上で設定されたら、IP ゲートウェイを通じなければ通信できないことに注意されたい。 さらに、リンク層ブロードキャストの問題があるために、両形式をサポートするホストが、自動的にどちらの形式が送信されたかを検知することは実用的ではないし、あるいは可能ですらない。
IP 層とリンク層間のパケット受信インタフェースは、入力パケットがリンク層ブロードキャストアドレス宛てか否かを示すためのフラグを含まなければならない (MUST)。
DISCUSSION:
IP 層は、通常リンク層アドレスを知らないが (全ての異なるネットワーク媒体は、通常異なるアドレス形式を持つので)、ブロードキャストケーブル媒体上のブロードキャストアドレスは、重要で特別なケースである。セクション 3.2.2
を参照されたい。特にブロードキャストストームに関しては DISCUSSION を参照されたい。
IP 層とリンク層間のパケット送信インタフェースは、5 ビットの TOS フィールド (セクション 3.2.1.6 参照) を含まなければならない (MUST)。
リンク層は、その宛先の ARP キャッシュエントリが存在しないという理由だけで、IP に宛先未到達エラーを通知してはならない (MUST NOT)
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION| | | |T|T|e
--------------------------------------------------|-------|-|-|-|-|-|--
| | | | | | |
トレーラーカプセル化 |2.3.1 | | |x| | |
折衝せずにデフォルトでトレーラーを送信する |2.3.1 | | | | |x|
ARP |2.3.2 | | | | | |
古い ARP キャッシュエントリをフラッシュする |2.3.2.1|x| | | | |
ARP フラッドを防ぐ |2.3.2.1|x| | | | |
キャッシュのタイムアイトを設定可能にする |2.3.2.1| |x| | | |
少なくとも一つの(最新の)未解決パケットを保持する|2.3.2.2| |x| | | |
イーサネットと IEEE 802 のカプセル化 |2.3.3 | | | | | |
ホストが可能なこと |2.3.3 | | | | | |
RFC894 のカプセル化の送受信 |2.3.3 |x| | | | |
RFC1042 のカプセル化の受信 |2.3.3 | |x| | | |
RFC1042 のカプセル化の送信 |2.3.3 | | |x| | |
選択スイッチの設定のデフォルトは RFC894 |2.3.3 |x| | | | |
K1=6 のカプセル化を送信する |2.3.3 | | | | |x|
イーサネットと IEEE802 ネットで ARP を使用する |2.3.3 |x| | | | |
リンク層が IP 層にブロードキャストを通知する |2.4 |x| | | | |
IP 層がリンク層に TOS を渡す |2.4 |x| | | | |
ARP キャッシュエントリ無しを宛先未到達として扱う |2.4 | | | | |x|
頑強さの指針 "受信するものには寛大であれ、送信するものには慎重であれ" は、インターネット層では特に重要である。一つの誤った動作をするホストによって、他の多くのホストのインターネットサービスが拒否される可能性がある。
インターネット層で使用されるプロトコル標準は、
IP マルチキャストのターゲットは、インターネットホストの任意のホストであってもよい。IP マルチキャストは、幾つかのネットワークのリンク層マルチキャスト機能の自然な拡張として設計されており、そうしたリンク層マルチキャスト機能へのローカルアクセスの標準的な手段を提供する。
他の重要な参照は、このドキュメントのセクション 5 に一覧化されている。
ホストソフトウェアのインターネット層は、IP と ICMP の両方を実装しなければならない (MUST)。 IGMP のサポートについての要件は、セクション 3.3.7 を参照されたい。
ホスト IP 層は二つの基本的な機能を持っている。(1) 出力 IP データグラムのための "次ホップ" ゲートウェイかホストを選択する。(2) 入力 IP データグラムを組み立てる。IP 層は (3) 出力データグラムの意図的な分割を実装してもよい。最後に、IP 層は (4) 診断とエラー機能を提供しなければならない。インターネットの制御や管理設備が更に発展するにつれて、IP 層の機能が将来増加されることが期待される。
通常のデータグラムに対して、その処理は率直である。入力データグラムに対して、IP 層は以下を行なう。
出力データグラムに対して、IP 層は以下を行なう。
もしホストが複数の IP アドレスを持っていたら、それはマルチホームと呼ばれる。マルチホームはかなりの混乱と複雑さをプロトコルスイートにもたらし、インターネット体系だけでは全ての問題に対処しきれない分野である。マルチホームには、以下の二つの異なる問題の領域がある。
ペア RFC [INTRO:1] で論じられているように、現在リモートマルチホームは、アプリケーション層で処理しなければならない (MUST)。ホストはローカルマルチホームをサポートしてもよく (MAY)、それはこのドキュメント、特にセクション 3.3.4 で論じられている。
別のホストによって生成されたデータグラムを転送するホストは全てゲートウェイとして動作し、ゲートウェイ要件 RFC [INTRO:2] に示されている規定にも適合しなければならない。組み込みゲートウェイコードを含むインターネットホストは、ゲートウェイ機能を不可にする設定スイッチを持たなければならず (MUST)、このスイッチはデフォルトでは非ゲートウェイモードでなければならない (MUST)。非ゲートウェイモードの場合、一つのインタフェースを通じて到着したデータグラムは、そのホストがシングルホームかマルチホームかに関わらず、別のホストやゲートウェイ (もしそれが送信元経路でなければ) に転送しない。もしホストが一つ以上のインタフェースを持っていなければ、マシンのオペレータがサービスを提供したくないかもしれないし、それを行なう権限が無いかもしれないので、ホストソフトウェアは自動的にゲートウェイモードに移行してはならない (MUST NOT)。
以下で、あるケースで規定される動作は、受信したパケットを "黙って破棄する" ことである。これは、データグラムを破棄する以外の処理は行なわず、結果的にホストは何の ICMP エラーメッセージも送信しないことを意味する。しかし、問題の診断のために、黙って破棄したデータグラムの内容を含め、ホストはエラーのログを採取する機能を提供すべきであり (SHOULD) (セクション 1.2.3 参照)、イベントを統計数に記録すべきである (SHOULD)。
DISCUSSION:
異常なデータグラムを黙って破棄することは、一般に "ブロードキャストストーム"
を避けることを意図している。
バージョン番号が 4 ではないデータグラムは、黙って破棄しなければならない (MUST)。
ホストは、全ての受信データグラムに対して IP ヘッダチェックサムをチェックし、不正なチェックサムを持つデータグラムは全て黙って破棄しなければならない (MUST)。
現在、クラス A からクラス E までの、5 つの IP アドレスのクラスが存在する。クラス D アドレスは IP マルチキャスト [IP:4] のために使用され、クラス E アドレスは実験的な使用のために予約される。
マルチキャスト (クラス D) アドレスは、ホストのグループを表す 28 ビットの論理アドレスであり、永続的か一時的かのいずれかである。永続的なマルチキャストアドレスはインターネット番号割り当て機関 [INTRO:6] によって割り当てられ、一時的なアドレスは動的に一時的なグループに割り当ててよい。グループのメンバーシップは IGMP [IP:4] を使用して動的に決定される。
クラス A, B, C の IP アドレスについて、以下の 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)。
(f) { <ネットワーク番号>, -1, -1 }
特定サブネット化されたネットワークの全てのサブネットへの直接ブロードキャスト。送信元アドレスとして使用してはならない (MUST NOT)。
(g) { 127, <any> }
内部のホストループバックアドレス。この形式のアドレスは、ホストの外側に表れてはならない (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)。入力データグラムは、データグラムの宛先アドレスフィールドが以下のものであれば、そのホスト宛てである。
大半の目的では、ブロードキャストかマルチキャストアドレス宛てのデータグラムは、あたかもホストの IP アドレスの一つに宛てられていたかのように処理される。"特定宛先のアドレス" という用語は、ホストのローカル IP アドレスと同等なものとして使用される。もしヘッダがブロードキャストかマルチキャストアドレスを含まなければ、特定宛先のアドレスは IP ヘッダ中の宛先アドレスであると定義される。含む場合は、特定宛先はデータグラムが到着した物理インタフェースに割り当てられた IP アドレスである。
ホストは、このセクションにて不正な IP 送信元アドレスを含む入力データグラムを黙って破棄しなければならない (MUST)。このチェックは、IP 層かトランスポート層の各プロトコルによって行なわれる。
DISCUSSION:
ユニキャストデータグラムのリンク層ブロードキャストによって、あるいは混乱や設定誤りのあるゲートウェイかホストによって、アドレスに誤りのあるデータグラムが生じるかもしれない。
インターネットホストにおける IP アドレスの体系上の目標は、特徴の無い 32 ビット数字になることを可能にすることであり、それは IP アドレス形式の知識を必要とするアルゴリズムを避ける。さもなければ、IP アドレスの形式や解釈に関して将来変更があると、ホストソフトウェアの変更が必要になるだろう。しかし、ブロードキャストとマルチキャストアドレスのチェックは、この目標に反している。他の幾つかの相反は、このドキュメントの別の場所で説明されている。
実装者は、全サブネット直接ブロードキャストアドレス (f) に依存しているアプリケーションは、あるネットワーク上では使用できないかもしれないことを知るべきである。全サブネットブロードキャストは、ベンダゲートウェイには現在広く実装されていない。実装されている場合でさえも、ある特定のネットワーク管理がゲートウェイ設定でそれを使用不可にするかもしれない。
インターネットモデルは、全てのホストが組立をサポートすることを要求する。分割と組立の要件については、セクション 3.3.2 とセクション 3.3.3 を参照されたい。
前のデータグラムと同じ複製を送信する時、ホストは任意でその複製と同じ識別子フィールドを保持してもよい (MAY)。
DISCUSSION:
あるインターネットプロトコルの専門家は、ホストが前のデータグラムと同じ複製を送信する時、新しい複製は元と同じ識別子値を含むべきであると主張した。これには二つの利点が提案されている。(1)
もしデータグラムが分割され、そのフラグメントの幾つかが消失したら、受信側は完全なデータグラムを元のフラグメントと複製から再構成できるかもしれない。(2)
輻輳したゲートウェイは、キューからの重複したデータグラムを破棄するために、IP 識別子フィールド
(とフラグメントオフセット) を使用するかもしれない。
しかし、インターネットにおけるデータグラム損失のよく見られるパターンは、再送されたフラグメントが組立の穴を埋める可能性に肯定的ではない。他のメカニズム (再送時の TCP 再パケット化) は、同じデータグラムの再送を避ける傾向にある [IP:9]。従って、同じ識別子フィールドの再送は有効であるとは思われない。また、UDP のようなコネクションレス型トランスポートプロトコルの場合、同じデータグラムの同じ識別子値を保持するために、アプリケーションプログラムとの協調が必要になるだろう。
IP ヘッダ中の "サービスタイプ" のバイトは、二つのセクションに分けられる。それは、優先度フィールド (上位 3 ビット) と慣習的に "サービスタイプ" か "TOS" と呼ばれるフィールド (下位 5 ビット) である。このドキュメントでは、"TOS" か "サービスタイプ" と呼ぶものは全て、下位 5 ビットのみを指す。
優先度フィールドは、インターネットプロトコルの国防総省アプリケーションでの使用を意図している。このフィールドに 0 でない値を使用することは、このドキュメントと IP 標準規約の適用外である。ベンダは、国防通信機関 (DCA: Defense Communication Agency) に、IP 優先度フィールドと他のプロトコル層への関連性のガイダンスに関して相談すべきである。しかし、ベンダは優先度を使用する場合、プロトコル層の間で TOS フィールドを渡すのと全く同じ方法でその値を渡す必要が恐らくあることに注意すべきである。
IP 層は、トランスポート層が全ての送信データグラムの TOS フィールドを設定する手段を提供しなければならない (MUST)。デフォルトは全て 0 である。IP 層は、受信した TOS 値をトランスポート層まで渡すべきである (SHOULD)。
RFC-795 に含まれている TOS の特定のリンク層へのマッピングは、実装すべきではない (SHOULD)。
DISCUSSION:
TOS フィールドは過去ほとんど使用されておらず、近い将来、その役割が増すことが期待される。TOS
フィールドは、ゲートウェイ処理の二つの面を制御するために使用することが期待される。それは、ルーティングとキューイングのアルゴリズムである。TOS
値を指定するアプリケーションプログラムの要件については、[INTRO:1] のセクション 2 を参照されたい。
TOS フィールドはリンク層のサービス選択子にマッピングしてもよい。これは例えば、TCP トラフィックの異なるクラスでのシリアル回線の効率的な共有を提供することに適用される。しかし、1981 年現在のインターネットに含まれているネットワークで、RFC-795 で提案されたマッピングは現在廃止されている。
ホストは 0 の生存時間 (TTL) の値を持つデータグラムを送信してはならない (MUST NOT)。
ホストは、2 より小さい TTL を受信したという理由だけでデータグラムを破棄してはならない (MUST NOT)。
IP 層はトランスポート層のために、送信する全てのデータグラムの TTL フィールドを設定する手段を提供しなければならない (MUST)。固定の TTL 値を使用する場合、設定可能でなければならない (MUST)。現在提案されている値は、"番号割り当て" の RFC で公開されている。
DISCUSSION:
TTL フィールドは二つの機能を持つ。それは、TCP セグメントの生存時間を制限する (RFC793
[TCP:1], p.28 参照) ことと、インターネットルーティングループを終了させることである。TTL
は秒単位の時間であるが、各ゲートウェイは少なくとも TTL を 1 減らす必要があるので、ホップ数の属性も若干持っている。
意図は、TTL 満了によって宛先ホストではなくゲートウェイがデータグラムを破棄することである。しかし、データグラムを転送するためにゲートウェイとして動作するホストは、TTL に関するゲートウェイの規則に従わなければならない。
幾つかのインターネットリソースの "拡張範囲" 検索を実装するために、上位層プロトコルが TTL を設定することを望むかもしれない。これは診断ツールによって使用され、例えば IP マルチキャストを使用している指定されたクラスの、"最も近い" サーバを捜し当てるのに有効であると期待される。ある特定のトランスポートプロトコルもまた、最大データグラム生存時間を割り当てた自分自身の TTL を指定することを望むかもしれない。
固定の値は、少なくともインターネットの "直径"、すなわちあり得る最長のパス、の大きさでなければならない。インターネットの継続的な発展を可能にするため、妥当な値は直径の約 2 倍である
送信する IP データグラム (セクション 3.4 参照) に含める IP オプションを、トランスポート層で指定できる手段が存在しなければならない (MUST)。
データグラム中で受信した全ての IP オプション (NOP や END-OF-LIST は除く) は、トランスポート層 (あるいは、データグラムが ICMP メッセージである場合は ICMP プロセス) に渡さなければならない (MUST)。IP とトランスポート層はそれぞれ、理解できる IP オプションは解釈し、理解できないものは黙って無視しなければならない (MUST)。
このドキュメントの以降のセクションで、ICMP, TCP, UDP でそれぞれ必要な特定の IP オプションのサポートについて論じている。
DISCUSSION:
受信した全ての IP オプションをトランスポート層に渡すことは意図的な "厳密な階層化違反"
であり、それは将来的に新しいトランスポート関連の IP
オプションを導入し易くするために設計されている。各層は自分自身の処理に関連するオプションを全て抽出し、残りは無視しなければならない。このために、NOP
と END-OF-LIST を除く全ての IP オプションは、自分の長さの指定を含んでいる。
このドキュメントは、同じ IP ヘッダ名中の複数のオプションを、受信側が処理しなければならない順序は定義していない。複数のオプションを送信するホストは、送信元経路オプションと結合された場合、あるオプションの意味が曖昧になることを招くことを知らなければならない。
IMPLEMENTATION:
IP 層は、あり得る範囲外のオプション長が指定されたがためにクラッシュしてはならない。例えば、異常なオプション長が IP
実装を無限ループに陥れることが確認されたことがある。
以下は、特定の IP オプションの要件である。
(a) セキュリティオプション
ある環境は、全てのデータグラムにセキュリティオプションを必要とする。そうした要件は、このドキュメントや IP 標準規約の適用外である。しかし、RFC791
と RFC1038 で規定されているセキュリティオプションは廃止されたことに注意されたい。DoD アプリケーションでは、ベンダは指針として
[IP:8] を調べるべきである。
(b) ストリーム識別子オプション
このオプションは廃止されている。これは送信すべきでなく
(SHOULD NOT)、もし受信したら黙って破棄しなければならない (MUST)。
(c) 送信元経路オプション
ホストは送信元経路の起動をサポートしなければならず (MUST)、送信元経路の最終宛先として動作できなければならない (MUST)。
もしホストが完了した送信元経路を含んでいるデータグラムを受信したら (すなわち、ポインタが最終フィールドを超えた位置を指している)、そのデータグラムは最終宛先に到達しており、そのオプションを受信した通りに (記録された経路)、トランスポート層 (あるいは ICMP メッセージ処理) まで渡さなければならない (MUST)。この記録された経路は反転され、応答データグラムの返却送信元経路を作成するために使用される (セクション 4 の IP オプションの議論参照)。返却送信元経路を作成する場合、たとえ記録された経路が送信元ホストを含んでいても、正しく生成しなければならない (MUST) (以下の議論のケース (B) 参照)。
一つ以上の送信元経路オプションを含んでいる IP ヘッダを送信してはならず (MUST)、複数の送信元経路オプションを振り分ける際の効果は、実装依存である。
セクション 3.3.5 は、送信元経路の中間ホップとして動作する、すなわち送信元経路付きのデータグラムを転送するホストの規則を示している。
DISCUSSION:
もし送信元経路付きのデータグラムが分割されたら、各フラグメントは送信元経路の複製を含む。IP オプション
(送信元経路を含む) の処理のために、元のデータグラムは最終宛先に到達するまで組み立てられないだろう。
送信元経路付きのデータグラムがホスト S からホスト D に、ゲートウェイ G1, G2, ... Gn を経由して振り分けられると仮定する。S によって送出されるデータグラム中の送信元経路オプションが、以下の (A) であるべきか (B) であるべきかについて規約に曖昧さがあった。
(A): {>>G2, G3, ... Gn, D} <---- 正しい
(B): {S, >>G2, G3, ... Gn, D} <---- 誤り
(>> はポインタを示している)。もし (A) が送信されたら、D で受信されるデータグラムには {G1, G2, ... Gn >>} というオプションが含まれ、IP 送信元と宛先アドレスは S と D になる。もし (B) が送信されたら、D で受信されるデータグラムには、同じ IP 送信元と宛先アドレスには S と D が再び含まれるが、オプションは {S, G1, ...Gn >>} になる。すなわち、発呼元ホストが経路の第一ホップになるのである。
(d) 経路記録オプション
経路記録オプションを発呼や処理する実装はオプションである (OPTIONAL)。
(e) タイムスタンプオプション
タイムスタンプオプションを発呼や処理する実装はオプションである (OPTIONAL)。もし実装するならば、以下の規則が適用される。
ICMP メッセージは二つのクラスに分類される。
* ICMP エラーメッセージ 宛先未到達 (セクション 3.2.2.1 参照) リダイレクト (セクション 3.2.2.2 参照) 送信元損失 (セクション 3.2.2.3 参照) 時間超過 (セクション 3.2.2.4 参照) パラメタ問題 (セクション 3.2.2.5 参照) * ICMP キュエリメッセージ エコー (セクション 3.2.2.6 参照) 情報 (セクション 3.2.2.7 参照) タイムスタンプ (セクション 3.2.2.8 参照) アドレスマスク (セクション 3.2.2.9 参照)
もし未知のタイプの ICMP メッセージを受信したら、黙って破棄しなければならない (MUST)。
全ての ICMP エラーメッセージは、エラーの引き金となったデータグラムのインターネットヘッダと少なくとも最初の 8 データオクテット、8 オクテット以上でもよい (MAY)、を含む。このヘッダとデータは、受信したデータグラムから変更無しでなければならない (MUST)。
インターネット層が ICMP エラーメッセージをトランスポート層に渡す必要がある場合、元のヘッダから IP プロトコル番号を抽出して、そのエラーを扱う適切なトランスポートプロトコルエンティティを選択するために使用しなければならない (MUST)。
ICMP エラーメッセージは、通常の TOS ビット (すなわち 0) で送信すべきである (SHOULD)。
ICMP エラーメッセージは、以下を受信した結果で送信してはならない (MUST NOT)。
注記: これらの制限は、このドキュメントの他の個所で示されている ICMP エラーメッセージ送信に関するいかなる要件よりも優先される。
DISCUSSION:
これらの要件は、ホストがブロードキャストデータグラムの応答で ICMP エラーメッセージを返却した結果発生する
"ブロードキャストの嵐" を防ぐだろう。例えば、存在しないポートへのブロードキャスト UDP
セグメントは、その宛先ポートのクライアントが無い全てのマシンにより、ICMP
宛先未到達データグラムの洪水が引き起こされるかもしれない。大規模なイーサネット上では、その結果発生する衝突により、一秒間以上ネットワークが無効になる可能性がある。
接続されたネットワーク上のブロードキャストでは、全てのデータグラムは、その IP 宛先として正しい IP ブロードキャストアドレスを持つべきである (セクション 3.3.6 参照)。しかし、幾つかのホストはこの規則に違反している。従って、ブロードキャストデータグラムを確実に検出するために、ホストは IP 層のブロードキャストアドレスだけでなく、リンク層のブロードキャストもチェックする必要がある。
IMPLEMENTATION:
これは、リンク層がリンク層ブロードキャストを受信した時に IP
層に通知することを必要とする。セクション 2.4 を参照されたい。
以下の追加コードがここで定義される。
6 = 未知の宛先ネットワーク
7 = 未知の宛先ホスト
8 = 孤立した送信元ホスト
9 = 宛先ネットワークとの通信は管理上禁止
10 = 宛先ホストとの通信は管理上禁止
11 = サービスタイプでネットワーク未到達
12 = サービスタイプでホスト未到達
ホストは、以下のコードを持つ宛先未到達メッセージを生成すべきである (SHOULD)。
2 (プロトコル未到達) 指定されたトランスポートプロトコルがサポートされていない時。
3 (ポート未到達) 指定されたトランスポートプロトコル (例えば UDP) がデータグラムを多重化できないが、送信側に通知するためのプロトコルメカニズムを持たない。
受信した宛先未到達メッセージはトランスポート層に通知しなければならない (MUST)。トランスポート層はその情報を適切に使用すべきである (SHOULD)。例えば、以下のセクション 4.1.3.3, 4.2.3.9, 4.2.4 を参照されたい。ポートが未到達であることを送信側に通知するためのメカニズムを持つトランスポートプロトコル (例えば RST セグメントを送信する TCP) でも、同じ目的のために ICMP ポート未到達を受諾しなければならない (MUST)。
コード 0 (ネット)、1 (ホスト)、5 (不当な送信元経路) を持つ宛先未到達メッセージは、ルーティングで一時的に発生するかもしれない。従って、指定された宛先が未到達 [IP:11] であることは、証拠ではなくヒントとしてのみ解釈しなければならない (MUST)。例えば、ゲートウェイの故障の証拠として使用してはならない (MUST NOT) (セクション 3.3.1 参照)。
ホストは ICMP リダイレクトメッセージを送信すべきではない (SHOULD NOT)。リダイレクトはゲートウェイが送信するものである。
リダイレクトメッセージを受信したホストは、ルーティング情報をそれに従って更新しなければならない (MUST)。全てのホストは、ホストとネットワークの両方のリダイレクトを受諾し、以下のセクション 3.3.1.2 で規定されているように処理する準備をしなければならない (MUST)。
もし指定された新しいゲートウェイアドレスが、リダイレクトが到着したのと同じ接続された (サブ) ネット上に無い ([INTRO:2] Appendix A) か、もしリダイレクトの送信元が 指定された宛先に対して現在の第一ホップゲートウェイでない (セクション 3.3.1 参照) ならば、そのリダイレクトメッセージを黙って破棄すべきである (SHOULD)。
ホストは、組立バッファや他の資源の不足によって、入力データグラムを強制的に破棄する点に近づくか到達したら、送信元損失メッセージを送信してもよい (MAY)。送信元損失をいつ送信するかについての提案は、[INTRO:2] のセクション 2.2.3 を参照されたい。
もし送信元損失メッセージを受信したら、IP 層はそれをトランスポート層 (あるいは ICMP 処理) に通知しなければならない (MUST)。一般に、トランスポートやアプリケーション層は、どのプロトコルにおいても送信元損失に対して応答し、一連のデータグラムを同じ宛先に送信でき、これを可能にするのに十分な状態情報を効率的に維持できるメカニズムを実装すべきである (SHOULD)。TCP と UDP による送信元損失の取り扱いについては、セクション 4 を参照されたい。
DISCUSSION:
送信元損失は、ターゲットホストやデータグラムのパス中のゲートウェイが生成するかもしれない。送信元損失を受信したホストは一定時間送信を抑え、徐々に送信レートを再び増やすべきである。送信元損失に応答するメカニズムはトランスポート層
(TCP のようなコネクション型プロトコルの場合) や、アプリケーション層 (UDP の上位に位置するプロトコルの場合) にあってもよい。
データグラムの送信レートを制御することによって、IP 層が送信元損失に直接応答するメカニズムが提案されている [IP:14] が、この提案は現在実験的なものであり、推奨はされていない。
受信した時間超過メッセージはトランスポート層に渡さなければならない (MUST)。
DISCUSSION:
ゲートウェイは TTL フィールドの満了によってデータグラムを破棄した時、時間超過コード 0 (一時的)
のメッセージを送信するだろう。これは、ゲートウェイのルーティングループか小さ過ぎる初期 TTL 値のいずれかを示す。
ホストは、タイムアウトになって不完全なデータグラムを破棄した宛先ホストから、時間超過コード 1 (組立タイムアウト) のメッセージを受信するかもしれない。以降のセクション 3.3.2 を参照されたい。将来、このメッセージの受信は、分割せずにパス上に送信できる最大データグラムサイズを検出するための、"MTU 検出" 手続きの一部になるかもしれない。
ホストはパラメタ問題メッセージを生成すべきである (SHOULD)。受信したパラメタ問題メッセージはトランスポート層に渡さなければならず (MUST)、ユーザに通知してもよい (MAY)。
DISCUSSION:
ICMP パラメタ問題メッセージは、特に別の ICMP
パラメタ問題メッセージによってカバーされない問題に対して、送信元ホストに送信される。パラメタ問題メッセージの受信は、ローカルかリモートの実装エラーを通常示す。
パラメタ問題メッセージの新たな変形は、以下に定義される。
Code 1 = 必要なオプションが省略されている。
DISCUSSION:
この変形はセキュリティオプションの省略で、軍事コミュニティで使用されている。
全てのホストはエコー要求を受信し、それに対応するエコー応答を送信する ICMP エコーサーバ関数を実装しなければならない (MUST)。ホストは診断目的で、エコー要求を送信し、エコー応答を受信するアプリケーション層インタフェースも実装すべきである (SHOULD)。
IP ブロードキャストか IP マルチキャストアドレス宛ての ICMP エコー要求は、黙って破棄してもよい (MAY)。
DISCUSSION:
この中庸の準備は、ブロードキャストアドレスへの ICMP
エコーは価値ある診断能力を提供すると考える人と、この機能の誤使用によってパケットストームが発生し易いと考える人との間の激しい議論の結果である。
ICMP エコー応答の IP 送信元アドレスは、対応する ICMP エコー要求メッセージの特定の宛先アドレスと同じでなければならない (セクション 3.2.1.3 で定義)。
ICMP エコー要求で受信したデータは、結果として発生するエコー応答に完全に含まれなければならない (MUST)。しかし、もしエコー応答の送信が実装されていない意図的な分割を必要とするならば、データグラムは最大転送サイズ (セクション 3.3.3 参照) に切り詰めて送信しなければならない (MUST)。
もし対応するエコー要求が IP 層で生成されたものでないならば、エコー応答は ICMP ユーザインタフェースに渡さなければならない (MUST)。
もし ICMP エコー要求で経路記録とタイムスタンプオプションを受信したら、このオプション (これらのオプション) は現在のホストを含めるように更新し、"切り詰め" ずにエコー応答メッセージの IP ヘッダに含めるべきである (SHOULD)。従って、経路記録はラウンドトリップ全体になるだろう。
もし ICMP エコー要求で送信元経路オプションを受信したら、その返却経路は反転して、エコー応答メッセージで送信元経路オプションとして使用しなければならない (MUST)。
ホストは、これらのメッセージを実装すべきではない (SHOULD NOT)。
DISCUSSION:
情報要求/応答のペアは、起動時に IP
ネットワーク番号の検出を可能にするために、ディスクレスワークステーションのような自己設定システムをサポートすることを意図していた。しかし、RARP と BOOTP
プロトコルは、ホストが自分の IP アドレスを検出するためのより良いメカニズムを提供している。
ホストは、タイムスタンプとタイムスタンプ応答を実装してもよい (MAY)。もし実装するならば、以下の規則に従わなければならない (MUST)。
以下のタイムスタンプのケースは、対応する ICMP エコーの規則に従って処理されるものである。
タイムスタンプ値の好ましい形式 ("標準的な値") は、世界時 0 時からのミリ秒単位でである。しかし、この値をミリ秒の精度で提供することは困難かもしれない。例えば、多くのシステムは、1 秒間に 50,60 回の回線周波数でのみ更新するクロックを使用している。従って、ある程度は、以下の "標準値" が許されている。
ホストは、その IP アドレスに対応するアドレスマスクを決めるために、以下の方法のうちの一番目のものをサポートしなければならず (MUST)、三つ全て実装してもよい (MAY)。
特定のホストで使用される方法の選択は、設定可能でなければならない (MUST)。
方法 (3) でアドレスマスクメッセージの使用が可能である場合、
逆に、もしアドレスマスクメッセージが不使用ならば、ICMP アドレスマスク要求を送信せず、ローカル IP アドレスで受信した如何なるアドレスマスク応答も (黙って) 無視しなければならない (MUST)。
ホストはインストールしているアドレスマスクについて、道理に合ったチェックを行うべきである (SHOULD)。以下の IMPLEMENTATION セクションを参照されたい。
システムは、自分がアドレスマスクについて権威のあるエージェントでなければ、アドレスマスク応答を送信してはならない (MUST NOT)。権威のあるエージェントはホストであってもよいし、ゲートウェイであってもよい。ただしそれは、アドレスマスクエージェントとして明示的に設定されていなければならない (MUST)。アドレスマスク応答を経てアドレスマスクを受信しても受信側に権威を与えることはなく、アドレスマスク応答を発行する根拠として使用してはならない (MUST NOT)。
静的に設定されたアドレスマスクでは、ホストがマスクについて権威のあるエージェントとして動作するか否か、すなわちアドレスマスク要求メッセージに、このマスクを使用して応えるか否かを決める、追加の設定フラグが存在すべきである (SHOULD)。
もしエージェントとして設定されたら、ホストは起動時に適切なインタフェース上にアドレスマスク応答をブロードキャストしなければならない (MUST)。
アドレスマスク要求/応答メッセージの使用に関する詳細情報については、[INTRO:1] の "システム起動" を参照されたい。
DISCUSSION:
不用意に不正なアドレスマスクを持つアドレスマスク応答を送信するホストは、大抵重大な有害物である。これを防ぐために、アドレスマスク応答は、明確な管理処置によって選択された権威のあるエージェントのみが送信すべきである。
権威のあるエージェントがアドレスマスク要求メッセージを受信した時、送信元 IP アドレスにユニキャストのアドレスマスク応答を送信するだろう。もし、このアドレスのネットワーク部が 0 ならば (3.2.1.3 の (a) と (b) 参照)、応答はブロードキャストされるだろう。
そのアドレスマスク要求メッセージに応答がない場合、ホストはエージェントがいないと仮定し、サブネット化されていないマスクを使用する。しかし、エージェントが一時的に到達不能なのかもしれない。エージェントは、起動中に全ホストのマスクを更新するために、起動時に必ず望まれないアドレスマスク応答をブロードキャストする。
IMPLEMENTATION:
アドレスマスクに対する道理に合ったチェックは次の通り: マスクのビットが全て 1 でなく、最上位の 8 ビットが 0 か、さもなくば 1 である。
IGMP [IP:4] は、特定のマルチキャストグループでホストのメンバーシップを確立するために、単一のネットワーク上でホストとゲートウェイとの間で使用されるプロトコルである。ゲートウェイはマルチキャストルーティングプロトコルと共に、インターネットに渡る IP マルチキャストをサポートするためにこの情報を使用する。
この時点では、IGMP の実装はオプションであり、詳細な情報についてはセクション 3.3.7 を参照されたい。IGMP が無くても、ホストは接続されたネットワークのローカルなマルチキャストに参加することができる。