メインコンテンツまでスキップ

1. はじめに (Introduction)

本文書は、インターネットプロトコルスイート (Internet protocol suite) のホストシステム実装の要件を定義および議論する一対の文書の1つです。本RFCは、通信プロトコル層 (communication protocol layers)、すなわちリンク層 (link layer)、IP層 (IP layer)、およびトランスポート層 (transport layer) をカバーしています。その姉妹RFC「Requirements for Internet Hosts -- Application and Support」[INTRO:1] は、アプリケーション層プロトコルをカバーしています。本文書は、「Requirements for Internet Gateways」[INTRO:2] と併せて読む必要があります。

これらの文書は、ベンダー、実装者、およびインターネット通信ソフトウェアのユーザーにガイダンスを提供することを目的としています。これらは、インターネット研究およびベンダーコミュニティのメンバーによって貢献された、大量の技術経験と知恵の合意を表しています。

本RFCは、インターネットに接続されたホストが使用しなければならない (MUST) 標準プロトコルを列挙し、これらのプロトコルの現在の仕様を記述するRFCおよびその他の文書を参照により組み込んでいます。これは、参照される文書のエラーを訂正し、実装者のための追加の議論とガイダンスを追加します。

各プロトコルについて、本文書には明示的な要件、推奨事項、およびオプションのセットも含まれています。読者は、本文書の要件のリストがそれ自体では不完全であることを理解する必要があります。インターネットホストの完全な要件セットは、主に標準プロトコル仕様文書で定義されており、本RFCに含まれる訂正、修正、および補足を伴います。

RFC を注意深く読み、インターネット技術コミュニティとの何らかの交流を行い、優れた通信ソフトウェアエンジニアリング実践に従って作成されたプロトコルの誠実な実装は、本文書の要件とは些細な点でのみ異なるはずです。したがって、多くの場合、本RFCの「要件」は標準プロトコル文書で既に述べられているか暗示されているため、ここに含めることは、ある意味で冗長です。しかし、過去のいくつかの実装が誤った選択を行い、相互運用性、パフォーマンス、および/またはロバストネスの問題を引き起こしたため、これらが含まれました。

本文書には、多くの要件と推奨事項の議論と説明が含まれています。要件の単純なリストは危険です。なぜなら:

  • 一部の必須機能は他のものより重要であり、一部の機能は任意である (optional) からです。
  • 制限されたコンテキスト向けに設計された特定のベンダー製品が異なる仕様を使用することを選択する正当な理由がある場合があるためです。

ただし、本文書の仕様は、インターネットシステムの多様性と複雑性にわたる任意のホスト相互運用という一般的な目標を達成するために従わなければなりません (MUST)。現在のほとんどの実装は、些細なものから主要なものまで、さまざまな方法でこれらの要件を満たしていませんが、この仕様は私たちが向かう必要がある理想です。

これらの要件は、インターネットアーキテクチャの現在のレベルに基づいています。本文書は、仕様がまだ進化している分野で追加の明確化を提供するため、または追加情報を含めるために、必要に応じて更新されます。

この導入セクションは、ホストに関連するインターネットアーキテクチャの簡単な概要から始まり、次にホストソフトウェアベンダーへの一般的なアドバイスを提供します。最後に、本文書の残りの部分を読むためのガイダンスといくつかの用語があります。

1.1 インターネットアーキテクチャ (The Internet Architecture)​

インターネットアーキテクチャおよびサポートプロトコルスイートに関する一般的な背景と議論は、DDN Protocol Handbook [INTRO:3] にあります。背景については、例えば [INTRO:9]、[INTRO:10]、および [INTRO:11] を参照してください。参考文献 [INTRO:5] は、インターネットプロトコル文書を取得する手順を説明し、[INTRO:6] には、インターネットプロトコル内で割り当てられた番号のリストが含まれています。

1.1.1 インターネットホスト (Internet Hosts)​

ホストコンピュータ、または単に「ホスト (host)」は、通信サービスの最終的な消費者です。ホストは一般に、ユーザーに代わってアプリケーションプログラムを実行し、この機能をサポートするためにネットワークおよび/またはインターネット通信サービスを使用します。インターネットホストは、OSIプロトコルスイート [INTRO:13] で使用される「エンドシステム (End-System)」の概念に対応します。

1.1.2 アーキテクチャの前提 (Architectural Assumptions)​

インターネットアーキテクチャは、通信システムに関する特定の一連の前提に基づいており、実装はこれらの前提を反映する必要があります。主要なアーキテクチャの前提は次のとおりです:

  • インターネットは大規模な分散システムである: 中央制御はなく、代わりに自律管理ドメイン、または「自律システム (Autonomous Systems, AS)」があります。
  • 異質性 (Heterogeneity): インターネットは、異なるデータリンク技術や異なるルーター実装を含む、多くの異なる通信システムから構築されています。
  • ロバストネス (Robustness): システムは、コンポーネントの障害に直面しても機能し続けなければなりません (MUST)。

1.1.3 インターネットプロトコルスイート (Internet Protocol Suite)​

インターネットシステムを使用して通信するには、ホストはインターネットプロトコルスイートを構成する階層化されたプロトコルのセットを実装しなければなりません (MUST)。ホストは通常、各層から少なくとも1つのプロトコルを実装する必要があります。

インターネットアーキテクチャで使用されるプロトコル層は次のとおりです:

  • アプリケーション層 (Application Layer)
  • トランスポート層 (Transport Layer)
  • インターネット層 (Internet Layer)
  • リンク層 (Link Layer)

1.1.4 組み込みゲートウェイコード (Embedded Gateway Code)​

一部のインターネットホストは、スタブネットワーク (stub networks) として指定されたネットワークに接続されます。スタブネットワークは、直接接続されたホストのトラフィックのみを伝送するネットワークとして定義されます。スタブネットワークの一般的な例は、部門LANです。

1.2 一般的な考慮事項 (General Considerations)​

1.2.1 継続的なインターネットの進化 (Continuing Internet Evolution)​

インターネットシステムは、20年以上前のARPANETでの始まり以来、継続的に成長および進化してきました。したがって、実装要件と仕様は、継続的な変化に対応するために柔軟でなければなりません (MUST)。

1.2.2 ロバストネスの原則 (Robustness Principle)​

プロトコルのすべての層で、莫大なロバストネスと相互運用性の利益につながる一般的な規則があります:

「受け入れるものには寛容に、送信するものには保守的に」

ソフトウェアは、どんなに起こりそうもないエラーでも、考えられるすべてのエラーに対処するように書かれるべきです (SHOULD)。遅かれ早かれ、特定のエラーと属性の組み合わせを持つパケットが到着し、ソフトウェアが準備されていない限り、混乱が生じる可能性があります。一般的に、ネットワークが最悪の影響を与えるように設計されたパケットを送信する悪意のあるエンティティで満たされていると仮定するのが最善です。この仮定は、適切な保護設計につながります。

1.2.3 エラーログ (Error Logging)​

インターネットプロトコルスイートには、エラーをソースホストに報告するためのいくつかのメカニズムが含まれています。ただし、すべてのエラーがプロトコルメカニズムを通じて報告されるわけではありません。一部は、ホストシステムでローカルにログに記録されるだけです。エラーログ機能の洗練度とその使用方法の詳細は、システムによって異なる場合があります。

1.2.4 構成 (Configuration)​

ホストシステムの構成は、一般にインターネットプロトコル文書では指定されていません。ただし、任意のインターネットホストで設定可能でなければならない (MUST) 特定の構成パラメーターがあります。

1.3 本文書の読み方 (Reading this Document)​

1.3.1 構成 (Organization)​

本文書は、次の主要な領域をカバーしています:

  • リンク層 (Link Layer) (セクション2)
  • インターネット層プロトコル (Internet Layer protocols) (セクション3)
  • トランスポート層プロトコル (Transport Layer protocols) (セクション4)

1.3.2 要件 (Requirements)​

本文書では、各特定の要件の重要性を定義するために使用される単語は大文字で表記されます。これらの単語は次のとおりです:

  • MUST: この単語または形容詞「REQUIRED」は、その項目が仕様の絶対要件であることを意味します。
  • SHOULD: この単語または形容詞「RECOMMENDED」は、特定の状況でこの項目を無視する正当な理由が存在する場合がありますが、完全な影響を理解し、別のコースを選択する前に慎重に検討する必要があることを意味します。
  • MAY: この単語または形容詞「OPTIONAL」は、この項目が本当に任意であることを意味します。

1.3.3 用語 (Terminology)​

本文書では、次の技術用語を使用します:

  • セグメント (Segment): セグメントは、TCPプロトコルにおけるエンドツーエンド伝送の単位です。
  • メッセージ (Message): 下位層プロトコルのこの説明では、メッセージはトランスポート層プロトコルにおける伝送の単位です。
  • データグラム (Datagram): データグラムは、IPパケットです。
  • パケット (Packet): パケットは、任意の形式のデータブロックです。
  • フレーム (Frame): フレームは、リンク層パケットです。
  • 接続ネットワーク (Connected Network): 接続ネットワークは、ホストが物理的、仮想的、または論理的にインターフェースされる任意のネットワークです。
  • マルチホーム (Multihomed): ホストが複数のIPアドレスを持つ場合、マルチホームであると言われます。

1.4 謝辞 (Acknowledgments)​

本文書には、インターネットコミュニティの多くのメンバーからの貢献とコメントが組み込まれています。

に最終更新