1. はじめに (INTRODUCTION)
本ドキュメントは、もう一つの文書と共に、インターネットプロトコル群のホストシステム実装の要件を定義し、論じる。本 RFC は通信プロトコル層、すなわちリンク層、IP 層、およびトランスポート層を扱う。姉妹編 RFC「インターネットホスト要件 -- アプリケーションとサポート」[INTRO:1] はアプリケーション層プロトコルを扱う。本ドキュメントは「インターネットゲートウェイ要件」[INTRO:2] と併せて読まれるべきである。
これらのドキュメントは、インターネット通信ソフトウェアのベンダー、実装者、およびユーザーにガイダンスを提供することを目的としている。それらは、インターネットの研究およびベンダーコミュニティのメンバーによって寄与された広範な技術的経験と知恵の合意を表している。
本 RFC は、インターネットに接続されたホストが使用しなければならない標準プロトコルを列挙し、それらのプロトコルの現在の仕様を記述する RFC およびその他の文書を参照により採用する。それはまた、参照された文書の誤りを是正し、実装者への追加の議論とガイダンスを補足する。
各プロトコルについて、本ドキュメントは明確な要件、推奨、およびオプションの集合も含んでいる。読者は、本ドキュメントの要件リストそのものは不完全であることを理解しなければならない。インターネットホストの完全な要件集合は、主として標準プロトコル仕様文書に定義されており、本 RFC における是正、改訂、および補足を含んでいる。
RFC を慎重に読み、インターネット技術コミュニティとある程度交流した上で、誠実にプロトコルを実装し、優れた通信ソフトウェア工学の実践に従うならば、得られる実装は本ドキュメントの要件とわずかな相違のみになるはずである。したがって、多くの場合、本 RFC の「要件」は標準プロトコル文書ですでに述べられているか、含意されているため、それを含めることはある意味で冗長である。しかし、それらを含めたのは、過去一部の実装が誤った選択を行い、相互運用性、パフォーマンス、および／または堅牢性の問題を引き起こしたためである。
本ドキュメントには、多くの要件と推奨に対する議論と説明が含まれている。単なる要件のリストは危険である。なぜなら：
- 一部の必須特性は他よりも重要であり、また一部の特性はオプションである。
- 特定のベンダー製品が、制約された環境向けに設計されているという正当な理由により、異なる仕様を選択する可能性がある。
しかし、インターネットシステムの多様性と複雑性において任意のホストが相互運用可能であるという全体的目標を満たすためには、本ドキュメントの規範に従わなければならない。現在、ほとんどの実装は様々な形（軽微なものから重大なものまで）でこれらの要件を満たせていないが、本仕様は我々が近づくべき理想である。
これらの要件は、現在のインターネットアーキテクチャの水準に基づいている。本ファイルは、規範がまだ進化している分野において追加の明確化を提供するか、追加情報を組み込むために、必要に応じて更新される。
この導入部分は、まずホストに関連するインターネットアーキテクチャの簡単な概要を示し、次にホストソフトウェアベンダーへのいくつかの一般的な助言を与える。最後に、ドキュメントの残りの部分といくつかの用語を読むためのガイダンスを提供する。
1.1 インターネットアーキテクチャ (The Internet Architecture)
インターネットアーキテクチャとそれを支えるプロトコル群の一般的な背景と議論は、DDN プロトコルハンドブック [INTRO:3] にある。背景資料として [INTRO:9]、[INTRO:10]、[INTRO:11] などを参照。参考文献 [INTRO:5] はインターネットプロトコル文書の入手手順を説明し、[INTRO:6] はインターネットプロトコル内で割り当てられた番号のリストを含む。
1.1.1 インターネットホスト (Internet Hosts)
ホストコンピュータ、または単に「ホスト (host)」は、通信サービスの最終的な消費者である。ホストは通常ユーザーの代わりにアプリケーションを実行し、ネットワークおよび／またはインターネット通信サービスを利用してその機能を支援する。インターネットホストは、OSI プロトコル群 [INTRO:13] で使用される「エンドシステム (End-System)」の概念に対応する。
インターネット通信システムは、インターネットプロトコルを使用してホストコンピュータ間の通信を支援する、相互接続されたパケットネットワークから構成される。これらのネットワークは、「ゲートウェイ (gateways)」または「IP ルーター (IP routers)」（インターネットコミュニティの呼称）、「中間システム (Intermediate Systems)」（OSI 世界の呼称）[INTRO:13] と呼ばれるパケット交換コンピュータを使用して相互接続される。RFC「インターネットゲートウェイ要件」[INTRO:2] にはインターネットゲートウェイの公式仕様が含まれている。その RFC と本ファイルおよびその姉妹編 [INTRO:1] は、現在のインターネットアーキテクチャ実装の規則を定義する。
インターネットホストは、規模、速度、機能において大きく異なる。規模はマイクロプロセッサからワークステーション、メインフレーム、スーパーコンピュータまで及ぶ。機能的には、単一用途ホスト（ターミナルサーバーなど）から、リモートログイン、ファイル転送、電子メールなどのオンラインネットワークサービスを多数サポートするフルサービスホストまで様々である。
ホストが同じネットワークまたは異なるネットワークへの複数のインタフェースを持つ場合、それは通常マルチホーム (multihomed) と呼ばれる。第 3.3.4 節のマルチホーミングを参照。
1.1.2 アーキテクチャ上の仮定 (Architectural Assumptions)
現在のインターネットアーキテクチャは、通信システムに関する一連の仮定に基づいている。ホストに最も関連する仮定は以下の通りである。
(a) インターネットはネットワークのネットワークである。
各ホストは特定のネットワークに直接接続されている。インターネットへのその接続は概念的なものにすぎない。同じネットワーク上の 2 台のホストが互いに通信する場合、使用するプロトコル集合は、それらが遠隔のネットワーク上のホストと通信する場合と同じである。
(b) ゲートウェイは接続状態情報を保持しない。
通信システムの堅牢性を高めるため、ゲートウェイはステートレスになるように設計されており、他のデータグラムに依存せず、各 IP データグラムを独立して転送する。したがって、冗長パスは、中間ゲートウェイおよびネットワークの障害時に堅牢なサービスを提供するために使用できる。
エンドツーエンドのフロー制御および信頼性に必要な状態情報はすべて、トランスポート層またはアプリケーション内のホストに実装される。したがって、すべての接続制御情報は通信の端点と共にあり、エンドポイントが障害を起こした場合にのみ失われる。
(c) ルーティングの複雑さはゲートウェイに置くべきである。
ルーティングは複雑で困難な問題であり、ホストではなくゲートウェイによって実行されるべきである。重要な目標は、ホストソフトウェアを、インターネットのルーティングアーキテクチャの不可避的な進化による変化から隔離することである。
(d) システムはネットワークの広範な違いに耐えなければならない。
インターネット設計の基本的な目標の一つは、帯域幅、遅延、パケット損失、順序乱れ、および最大パケットサイズにおける広範なネットワーク特性に耐えることである。もう一つの目標は、個々のネットワーク、ゲートウェイ、およびホストの障害に対する堅牢性であり、利用可能な帯域幅を利用することである。最終的な目標は完全な「開放型システム間相互接続」である。インターネットホストは、多様なインターネットパス上の任意の他のインターネットホストと、堅牢かつ効果的に相互運用できなければならない。
ホストの実装者が、より限定的な目標のために設計することがある。例えば、LAN 環境は通常、全体のインターネットよりもはるかに穏やかである。LAN は低いパケット損失、低い遅延、および順序乱れがない。一部のベンダーは、単純な LAN 環境専用のホスト実装を提供するが、一般的な相互運用性はひどい。ベンダーは、制約された LAN 市場で経済的であることで、このような製品を正当化する。しかし、孤立した LAN が長く孤立したままになることはめったにない。それらはすぐに互いに、組織全体のインターネットに、そして最終的にグローバルなインターネットシステムに接続される。最終的に、不完全または不適格なインターネットホストソフトウェアは、顧客にとってもベンダーにとっても不利である。
本ドキュメントで詳細に規定されている要件は、任意のインターネットパス上で完全な相互運用性を実現できる全機能インターネットホストのために設計されている。
1.1.3 インターネットプロトコル群 (Internet Protocol Suite)
インターネットシステムを使用して通信するには、ホストはインターネットプロトコル群を構成する階層型プロトコル集合を実装しなければならない。ホストは通常、各層から少なくとも 1 つのプロトコルを実装しなければならない。
インターネットアーキテクチャで使用されるプロトコル層は以下の通り [INTRO:4]：
アプリケーション層 (Application Layer)
アプリケーション層はインターネットプロトコル群の最上位層である。インターネットプロトコル群はアプリケーション層をそれ以上細分化していないが、一部のインターネットアプリケーション層プロトコルには確かにいくつかの内部サブレイヤーが存在する。インターネットプロトコル群のアプリケーション層は、本質的に OSI 参照モデルの最上位 2 層、つまりプレゼンテーション層とアプリケーション層の機能を組み合わせたものである。
我々は 2 つのクラスのアプリケーション層プロトコルを区別する。ユーザーに直接サービスを提供するユーザープロトコルと、一般的なシステム機能を提供するサポートプロトコルである。ユーザーおよびサポートプロトコルの要件は姉妹編 RFC [INTRO:1] にある。
最も一般的なインターネットユーザープロトコルは以下の通り：
- Telnet（リモートログイン）
- FTP（ファイル転送）
- SMTP（電子メール配送）
他にも多くの標準化されたユーザープロトコル [INTRO:4] や、多くの私用ユーザープロトコルが存在する。
ホスト名マッピング、ブートストラップ、管理のためのサポートプロトコルには、SNMP、BOOTP、RARP、およびドメインネームシステム (DNS) プロトコルが含まれる。
トランスポート層 (Transport Layer)
トランスポート層は、アプリケーションにエンドツーエンド通信サービスを提供する。現在、2 つの主要なトランスポート層プロトコルがある：
- 伝送制御プロトコル (TCP)
- ユーザデータグラムプロトコル (UDP)
TCP は、エンドツーエンドの信頼性、再順序付け、およびフロー制御を提供する、信頼性のある接続指向の転送サービスである。UDP は、コネクションレス（「データグラム」）転送サービスである。
研究コミュニティは他の転送プロトコルを開発しており、将来、公式なインターネット転送プロトコル集合が拡張される可能性がある。
トランスポート層プロトコルは第 4 章で論じる。
インターネット層 (Internet Layer)
すべてのインターネット転送プロトコルは、インターネットプロトコル (IP) を使用してデータを送信元ホストから宛先ホストに転送する。IP は、到達保証を提供しないコネクションレスまたはデータグラムのインターネットワークサービスである。したがって、IP データグラムは、破損した、重複した、順序が入れ替わった形で宛先ホストに到着するか、あるいはそもそも到着しないことがある。信頼性が要求される場合、IP より上の層が信頼できる配送サービスを提供する責任を持つ。IP プロトコルは、アドレッシング、サービスタイプの指定、フラグメンテーションと再構成、およびセキュリティ情報の規定を含んでいる。
IP プロトコルのデータグラムまたはコネクションレス特性は、インターネットアーキテクチャの基本的かつ特徴的な特徴である。インターネット IP は、OSI コネクションレス網プロトコル [INTRO:12] のモデルである。
ICMP は制御プロトコルであり、IP の構成要素と見なされるが、アーキテクチャ上は IP の上に位置し、つまり TCP や UDP などの転送プロトコルと同様に、そのデータを端から端へ運ぶために IP を使用する。ICMP は、エラー報告、輻輳報告、および第一ホップゲートウェイのリダイレクトを提供する。
IGMP は、IP マルチキャストのための動的ホストグループを確立するために使用されるインターネット層プロトコルである。
インターネット層プロトコル IP、ICMP、および IGMP は第 3 章で論じる。
リンク層 (Link Layer)
直接接続されたネットワーク上で通信するために、ホストはそのネットワークへの接続に使用される通信プロトコルを実装しなければならない。これをリンク層またはメディアアクセス層プロトコルと呼ぶ。
多くの異なるリンク層プロトコルが存在し、それらは多くの異なるタイプのネットワークに対応している。第 2 章を参照。
1.1.4 組み込みゲートウェイコード (Embedded Gateway Code)
一部のインターネットホストソフトウェアには、これらのホストがゲートウェイと同様にパケットを転送できるようにする、組み込みゲートウェイ機能が含まれている。同時にホストのアプリケーション層機能も実行する。
このような二重目的システムは、ゲートウェイ機能に関してはゲートウェイ要件 RFC [INTRO:2] に従わなければならず、ホスト機能に関しては本ファイルに従わなければならない。重複するすべてのケースにおいて、2 つの仕様は一致するはずである。
インターネットコミュニティには、組み込みゲートウェイ機能に対する相反する意見がある。主な議論は以下の通り：
賛成 (Pro)： 非公式な LAN 環境や孤立したインターネットにおいて、既存のホストシステムをゲートウェイとして使用することは、便利で経済的である可能性がある。
組み込みゲートウェイ機能を支持するアーキテクチャ上の議論もある。マルチホーミングは、最初に予想されたよりもはるかに一般的であり、マルチホーミングはホストにゲートウェイと同様のルーティング決定を行わせる。マルチホームホストに組み込みゲートウェイが含まれていれば、完全なルーティング知識を持つため、より優れたルーティング決定を行うことができる。
反対 (Con)： ゲートウェイアルゴリズムとプロトコルはまだ変化しており、インターネットシステムが大きくなるにつれて変化し続ける。ホスト IP 層に汎用ゲートウェイ機能を含めようとすることは、これらの（より頻繁な）変化をホストシステム保守者が追跡することを強いる。さらに、より大きなゲートウェイ実装のプールは、変更の調整をより困難にする。最後に、ゲートウェイ IP 層の複雑さはホストよりわずかに高く、実装と運用タスクをより複雑にする。
さらに、一部のホストの運用スタイルは、安定した堅牢なゲートウェイサービスを提供するのに適していない。
どちらの見方にも相当の道理がある。導き出せる結論の一つは、特定のホストがゲートウェイとして機能するかどうかをホスト管理者が意識的に制御できなければならないということである。詳細な要件は第 3.1 節を参照。
1.2 一般的考慮事項 (General Considerations)
インターネットホストソフトウェアベンダーは 2 つの重要な教訓を学んでおり、新しいベンダーは真剣に考慮すべきである。
1.2.1 継続するインターネットの進化 (Continuing Internet Evolution)
インターネットの巨大な成長は、大規模なデータグラムベースのパケット通信システムの管理と拡張における問題を露呈した。これらの問題は解決されつつあり、したがって本ドキュメントで記述された規範は継続的に進化する。これらの変更は慎重に計画され、制御される。なぜなら、ベンダーおよびネットワーク運用組織がこの計画に幅広く関与しているからである。
開発、進化、および改訂は、今日のコンピュータネットワークプロトコルの特徴であり、これは数年間続く。インターネットプロトコル群（または他のいかなるプロトコル群も！）のためにコンピュータ通信ソフトウェアを開発し、その後変化する仕様に合わせてそのソフトウェアを保守および更新しなかったベンダーは、不満を持つ顧客の列を残すことになるだろう。インターネットは、ユーザー同士が継続的に連絡を取り合う大規模な通信ネットワークである。経験によれば、ベンダーのソフトウェアの欠陥に関する知識は、インターネット技術コミュニティ内で急速に広がる。
1.2.2 堅牢性の原則 (Robustness Principle)
各プロトコル層には、その適用が堅牢性と相互運用性に多大な利益をもたらす一般的な規則がある [IP:1]：
「受け入れることにおいて寛容に、送信することにおいて保守的に (Be liberal in what you accept, and conservative in what you send)」
ソフトウェアは、どんなにありそうもないものであっても、考えられるあらゆるエラーを処理するように書かれるべきである。遅かれ早かれ、その特定のエラーと属性の組み合わせを持つパケットが到着するだろう。ソフトウェアがそれに備えていなければ、混乱が続く可能性がある。一般に、ネットワーク内に悪意のあるエンティティが満ちており、最悪の影響をもたらすようなパケットを送信することを想定するのがよい。この仮定は、適切な保護的設計へと導く。とはいえ、インターネットにおける最も深刻な問題は、低確率のイベントによって引き起こされる、想定されていなかったメカニズムによって引き起こされる。単なる人間の悪意では、これほど回りくどい経路をとることはない！
インターネットホストソフトウェアのすべてのレベルは、変化に対する適応性を備えて設計されなければならない。簡単な例として、プロトコル仕様に特定のヘッダーフィールドの列挙値（タイプフィールド、ポート番号、エラーコードなど）が含まれているとする。その列挙は不完全であると想定しなければならない。したがって、プロトコル仕様が 4 つの可能なエラーコードを定義している場合、5 番目のコードが現れてもソフトウェアがクラッシュしてはならない。未定義のコードは記録されてもよい（後述）が、障害を引き起こしてはならない。
この原則の第二部分もほぼ同様に重要である。他のホスト上のソフトウェアには欠陥があり、正当だが珍しいプロトコル特性を利用することが賢明ではない場合がある。「明白で単純なもの」から逸脱することは危険であり、他の場所に悪影響を及ぼす可能性がある。その推論は「不正な動作をするホストに警戒せよ」である。ホストソフトウェアは、他の不正なホストの前で生き残るように準備するだけでなく、そのようなホストが共有通信設備に与える破壊の程度を制限するために協力すべきである。
1.2.3 エラーログ (Error Logging)
インターネットには、多くのホストとゲートウェイシステムが含まれており、それぞれが多くのプロトコルとプロトコル層を実装している。その一部には、インターネットプロトコルソフトウェアにエラーと欠陥特性が含まれている。機能の複雑さ、多様性、および分散性のため、インターネットの問題の診断はしばしば非常に困難である。
ホスト実装に、エラーまたは「奇妙な」プロトコルイベントを記録するための十分に設計された機能が含まれていれば、問題の診断に役立つだろう。エラーを記録する際には、可能な限り多くの診断情報を含めることが重要である。特に、エラーを引き起こしたパケットのヘッダーを記録することはしばしば有用である。しかし、エラーログが過剰なリソースを消費したり、ホストの動作を妨害したりしないように注意しなければならない。
異常だが無害なプロトコルイベントは、エラーログファイルをあふれさせることがある。これは「循環 (circular)」ログを使用するか、既知の障害時にのみログを有効にすることで回避できる。連続する重複メッセージをフィルタリングしてカウントすることも有用である。うまく機能するように見える戦略の 1 つは、(1) 常に異常事象をカウントし、管理プロトコル（[INTRO:1] 参照）を通じてこれらのカウントにアクセスできるようにすること、および (2) 大量のイベントの記録を選択的に有効にできるようにすることである。例えば、「すべてを記録する」または「ホスト X のすべてを記録する」ことができると有用である可能性がある。
異常なプロトコルイベントに対して、通常どの程度のエラーログを有効にするかについて、管理者によって異なる戦略があることに注意されたい。ある者は「私に害が及ばない限り、知りたくない」と言い、他の者はプロトコルの異常を検出し排除することに対して、より警戒的で積極的な態度をとる。
1.2.4 設定 (Configuration)
インターネットプロトコル群のホスト実装が完全に自己設定可能であれば理想的である。これにより、プロトコル群全体を ROM に実装したりシリコンに焼き付けたりし、ディスクレスワークステーションを単純化し、慌ただしい LAN 管理者およびシステムベンダーにとって大きな福音となる。我々はその理想にまだ達していない。実際、かなり遠い。
本ドキュメントの多くの箇所で、あるパラメータが設定可能なオプションでなければならないという要件を見つけるだろう。この種の要件の背後には、いくつかの異なる理由がある。少数のケースでは、最適値について現在不確実または意見の相違があり、将来推奨値を更新する必要があるかもしれない。他のケースでは、その値は外部要因（ホストの規模およびその通信負荷の分布、または近隣ネットワークの速度とトポロジーなど）に実際に依存しており、自己チューニングアルゴリズムは利用できず、また不十分である可能性がある。一部のケースでは、管理要件のために設定可能性が必要である。
最後に、ソースコードを配布しない古い、または誤ったプロトコル実装と通信するために、特定の設定オプションが必要である。正しいシステムがこれらの障害のあるシステムと共存できるようにするには、管理者は「誤った設定」を正しいシステムに対して行わなければならないことが多い。障害のあるシステムが退役するにつれて、この問題は徐々に自己修正されるが、ベンダーはそれを無視することはできない。
パラメータが設定可能でなければならないと言うとき、我々は、起動するたびに設定ファイルからその値を明示的に読み取ることを要求しているのではない。実装者には、各パラメータのデフォルト値を設定することを推奨する。したがって、設定ファイルは、特定のインストールで不適切なデフォルト値を上書きするためだけに使用される。したがって、設定可能性の要件は、バイナリまたは ROM ベースの製品であっても、必要に応じてデフォルト値を上書きできるという保証である。
本ドキュメントのいくつかのケースでは、このようなデフォルト値が特定の値をとることを要求している。設定項目が既存の障害システムとの互換性を制御する場合、デフォルト値の選択は敏感な問題である。インターネットが完全な相互運用性へと収束するためには、製品に組み込まれたデフォルト値は、障害のある実装に迎合するための「誤った設定」ではなく、公式プロトコルでなければならない。市場の考慮から一部のベンダーが誤った設定のデフォルト値を選択しているが、我々はベンダーに標準に準拠したデフォルト値を選択するよう促す。
最後に、ベンダーはすべての設定パラメータ、その制限、および影響について十分な文書を提供する必要があることに注意する。
1.3 本文書の読み方 (Reading this Document)
1.3.1 組織方式 (Organization)
プロトコル階層は、ネットワークソフトウェアを実装するための組織原則として、また本ドキュメントを組織するために通常使用される。規則を記述する際、我々は実装がプロトコルの階層を厳密にマッピングしていると仮定する。したがって、以下の 3 つの主要な章は、それぞれリンク層、インターネット層、およびトランスポート層の要件を規定する。姉妹編 RFC [INTRO:1] はアプリケーション層ソフトウェアを扱う。この階層的な組織化は、単純さと明確さのために選択された。
しかし、厳密な階層化は、プロトコル群と推奨される実装方法の両方に対して不完全なモデルである。異なる層のプロトコルは複雑かつ時として微妙な方法で相互作用し、特定の機能はしばしば複数の層に関与する。実装には多くの設計選択があり、その多くは創造的に「厳密な階層化を破る」ことに関与している。我々は各実装者に参考文献 [INTRO:7] および [INTRO:8] を読むことを促す。
本ドキュメントは、層間の概念的サービスインタフェースを記述するために、TCP 仕様 [TCP:1] で使用されているものと同様の関数型（「プロシージャルコール」）表記を使用する。ホスト実装は、これらの呼び出しが暗示する論理的な情報フローをサポートしなければならないが、呼び出し自体を文字通り実装する必要はない。例えば、多くの実装では、トランスポート層と IP 層の間の結合を反映するために、共通のデータ構造を共有している。したがって、これらのデータ構造が、多くの必要な情報を伝達する媒体となる。
一般に、本ドキュメントの各主要章は以下の小節で構成される：
- はじめに (Introduction)
- プロトコルウォークスルー (Protocol Walk-Through) —— プロトコル仕様文書を節ごとに検討し、誤りを是正し、曖昧または定義が不十分な要件を記述し、さらに明確化または説明を提供する。
- 個別課題 (Specific Issues) —— ウォークスルーに含まれていないプロトコルの設計および実装の問題を論じる。
- インタフェース (Interfaces) —— 次の上位層へのサービスインタフェースについて論じる。
- サマリ (Summary) —— 本節の要件のサマリを含む。
本ドキュメントの多くの個別トピックの下には、「DISCUSSION」または「IMPLEMENTATION」と注記された材料がある。これらの材料の目的は、前述の要件テキストを明確化および説明することである。また、可能な将来の方向性や開発に関するいくつかの提案も含まれている。実装材料には、実装者が検討したいと思う可能性のある推奨手法が含まれている。
サマリ小節は、本文へのガイドおよび索引として機能することを意図しているが、必然的に簡略化され不完全である。サマリは、完全な RFC から切り離して単独で使用または参照されるべきではない。
1.3.2 要件 (Requirements)
本ドキュメントでは、各特定の要件の重要性を定義するために使用される用語は大文字で表記される。これらの用語は以下の通り：
「MUST」(必須)
この語、または形容詞「REQUIRED」は、その項目が規範的な絶対要件であることを示す。
「SHOULD」(推奨)
この語、または形容詞「RECOMMENDED」は、特定の状況下ではその項目を無視する正当な理由が存在する可能性があるが、異なる方法を選択する前に、その全 implications を理解し、慎重に比較検討しなければならないことを示す。
「MAY」(可能)
この語、または形容詞「OPTIONAL」は、その項目が実際にオプションであることを示す。例えば、あるベンダーは特定の市場ニーズまたは製品の強化のためにその項目を含めることを選択するかもしれない。別のベンダーは同じ項目を省略してもよい。
実装が、それが実装するプロトコルの 1 つ以上の MUST 要件を満たさない場合、その実装は仕様に準拠していない。実装がそのプロトコルのすべての MUST 要件およびすべての SHOULD 要件を満たす場合、「無条件準拠 (unconditionally compliant)」と呼ばれる。すべての MUST 要件を満たすがすべての SHOULD 要件を満たさない実装は、「条件付き準拠 (conditionally compliant)」と呼ばれる。
1.3.3 用語 (Terminology)
本ドキュメントは以下の技術用語を使用する：
セグメント (Segment)
セグメントは、TCP プロトコルにおけるエンドツーエンド転送の単位である。セグメントは、TCP ヘッダーの後にアプリケーションデータが続くもので構成される。セグメントは、IP データグラム内にカプセル化されて転送される。
メッセージ (Message)
低レイヤープロトコルの説明では、メッセージはトランスポート層プロトコルにおける転送単位である。特に、TCP セグメントはメッセージである。メッセージは、トランスポートプロトコルヘッダーの後にアプリケーションプロトコルデータが続くもので構成される。インターネットをエンドツーエンドで転送するには、メッセージはデータグラム内にカプセル化されなければならない。
IP データグラム (IP Datagram)
IP データグラムは、IP プロトコルにおけるエンドツーエンド転送の単位である。IP データグラムは、IP ヘッダーの後にトランスポート層データ、つまり IP ヘッダーの後にメッセージが続くもので構成される。
インターネット層（第 3 節）の説明では、修飾のない用語「データグラム (datagram)」は IP データグラムを指すものと理解される。
パケット (Packet)
パケットは、インターネット層とリンク層の間のインタフェースをまたがって渡されるデータ単位である。それは IP ヘッダーとデータを含む。パケットは、完全な IP データグラム、または IP データグラムのフラグメントのいずれかである。
フレーム (Frame)
フレームは、リンク層プロトコルにおける転送単位であり、リンク層ヘッダーの後にパケットが続くもので構成される。
接続されたネットワーク (Connected Network)
ホストがインタフェースを持つネットワークは、そのホストに対して「ローカルネットワーク (local network)」または「サブネットワーク (subnetwork)」と呼ばれることが多い。しかし、これらの用語は混乱を招く可能性があるため、本ドキュメントでは「接続されたネットワーク (connected network)」という用語を使用する。
マルチホーム (Multihomed)
ホストが複数の IP アドレスを持つ場合、それはマルチホームと呼ばれる。マルチホーミングについての議論は第 3.3.4 節を参照。
物理ネットワークインタフェース (Physical network interface)
これは接続されたネットワークへの物理インタフェースであり、一意の（一意である可能性がある）リンク層アドレスを持つ。1 台のホスト上の複数の物理ネットワークインタフェースが同じリンク層アドレスを共有してもよいが、そのアドレスは同じ物理ネットワーク上の異なるホストに対して一意でなければならない。
論理 [ネットワーク] インタフェース (Logical [network] interface)
我々は、一意の IP アドレスによって区別される、接続されたネットワークへの論理パスとして、論理 [ネットワーク] インタフェースを定義する。第 3.3.4 節を参照。
特定の宛先アドレス (Specific-destination address)
これは、ブロードキャストまたはマルチキャストであっても、データグラムの有効な宛先アドレスである。第 3.2.1.3 節を参照。
パス (Path)
ある時点で、特定の送信元ホストから特定の宛先ホストへのすべての IP データグラムは、通常、同じゲートウェイ系列を通過する。この系列を「パス (Path)」という用語で指す。パスは一方向であることに注意。特定の一対のホスト間で、2 つの方向に異なるパスを持つことは珍しくない。
MTU
最大転送単位 (Maximum Transfer Unit)。つまり、転送できる最大パケットサイズである。
用語フレーム、パケット、データグラム、メッセージ、およびセグメントは、以下の概略図によって説明される：
A. 接続されたネットワーク上での転送：
_______________________________________________
| LL hdr | IP hdr | (data) |
|________|________|_____________________________|
<---------- Frame ----------------------------->
<----------Packet -------------------->
B. IP フラグメンテーションの前、または IP 再構成の後：
______________________________________
| IP hdr | transport| Application Data |
|________|____hdr___|__________________|
<-------- Datagram ------------------>
<-------- Message ----------->
または、TCP の場合：
______________________________________
| IP hdr | TCP hdr | Application Data |
|________|__________|__________________|
<-------- Datagram ------------------>
<-------- Segment ----------->
1.4 謝辞 (Acknowledgments)
本ドキュメントは、インターネットプロトコルの専門家（大学および研究研究所、ベンダー、政府機関の代表を含む）からの貢献とコメントを多数取り入れている。それは主として、インターネット技術タスクフォース (IETF) のホスト要件ワーキンググループ (Host Requirements Working Group) によって編纂された。
編集者は特に、過去 18 ヶ月間にわたって多くの長い会議に参加し、この文書を実現するために 300 万バイトの電子メールを生成した以下の人々の献身的な貢献に感謝したい。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)、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)。
我々は、リストに含まれるべきだったかもしれないすべての貢献者、および不注意で省略された可能性のあるすべての貢献者に謝意を表する。