RFC1122 日本語訳

1122 Requirements for Internet Hosts - Communication Layers. R.Braden, Ed.. October 1989. (Format: TXT=295992 bytes) (Updates RFC0793) (Updated by RFC1349, RFC4379) (Also STD0003) (Status: STANDARD)

RFC一覧
英語原文

Network Working Group                    Internet Engineering Task Force
Request for Comments: 1122                             R. Braden, Editor
                                                            October 1989

        Requirements for Internet Hosts -- Communication Layers

Status of This Memo

   この RFC は、インターネット社会のための公式の規定である。これは、ホ
   ストに関連する基本的なプロトコル標準のドキュメントを参照、改正、修 
   正、補足することによって編入している。このドキュメントの配布は制限 
   されない。

Summary

   これは、インターネットホストソフトウェアを定義し議論する一組の 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 アドレスマスク要求/応答: RFC-950
       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. 参照
セキュリティの考慮
作者のアドレス

1. 導入

   このドキュメントは、インターネットプロトコルスイートのホストシステ 
   ム実装要件を定義し議論するペアドキュメントのうちの一つである。この 
   RFC は、通信プロトコル層: リンク層、IP 層、トランスポート層をカバー
   している。もう片方の RFC "インターネットホスト要件 -- アプリケーショ
   ンとサポート" [INTRO:1] は、アプリケーション層プロトコルをカバーし 
   ている。また、このドキュメントは "インターネットゲートウェイ要件"
   [INTRO:2] と共に読むべきである。

   これらのドキュメントは、インターネット通信ソフトウェアのベンダ、実 
   装者、ユーザのために、ガイダンスを提供することを意図している。それ 
   らは、インターネット研究団体やベンダのメンバによって寄与された、大 
   多数の技術上の経験や知識のコンセンサスを表している。

   この RFC は、インターネットに接続されたホストが使用しなければならな
   い標準プロトコルを列挙しており、これらのプロトコルの現在の規定を記 
   述している RFC や他のドキュメントを参照することによって編入している。
   それは、参照しているドキュメント中の誤りを修正し、実装者のために付 
   加的な議論やガイダンスを追加している。

   各々のプロトコルに対し、このドキュメントは要件や推奨やオプション等 
   の明示的なセットも含んでいる。このドキュメント中の要件のリストはそ 
   れ自身では不完全であることを、読者は理解しなければならない。インタ 
   ーネットホストのための完全な要件は、基本的に標準プロトコルの規定ド 
   キュメントで定義され、この RFC に記述された修正、改正、補足を含む。

   注意深く RFC を読み、インターネット技術社会と協調し、適切な通信ソフ
   トウェア技術の実践に従った上で作成されたプロトコルの誠実な実装は、 
   このドキュメントの要件との相違はマイナーなものに限られるはずである。
   従って、多くの場合この RFC の "要件" は、既に標準プロトコルドキュメ
   ントで述べられているか、含まれている。よってここに含めることは、あ 
   る意味冗長である。しかし、幾つかの過去の実装は誤った選択をし、相互 
   接続性やパフォーマンス、頑強性に問題を引き起こしたことがあるので、 
   それらを含めている。

   このドキュメントは、数多くの要件や推奨についての議論や説明を含んで 
   いる。要件を簡単に一覧化することは危険である。なぜなら、

   o    ある必要な機能は他の機能よりも重要であり、ある機能はオプション
        である。

   o    制限されたコンテキストで設計された特定のベンダ製品が、異なる規
        定の使用を選択したことは、正当な理由があるかもしれない。

   しかし、このドキュメントの規定は、多種多様で複雑なインターネットシ 
   ステム全体で、任意のホストの相互運用の一般的な目標に適合するために 
   従わなければならない。現在の大半の実装は、あるものはメジャーな、ま 
   たあるものはマイナーな様々な点でこれらの要件に適合していないが、こ 
   の規定は我々が移行する必要のある考え方である。

   これらの要件は、インターネット体系の現在のレベルに基づいている。こ 
   のドキュメントは、追加の説明を提供したり、規定が依然として発展して 
   いる分野における追加の情報を含めるために、必要に応じて更新されるだ 
   ろう。

   この導入部のセクションは、ホストに関するインターネット体系の簡潔な 
   概要から始め、次にホストソフトウェアベンダに幾つかの一般的なアドバ 
   イスを提示している。そして最後に、ドキュメントの残りと幾つかの用語 
   を読むにあたってのガイダンスを示している。

   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] では "中間システム" と呼ばれる、パケッ 
         ト交換コンピュータを使用して相互接続される。RFC "インターネッ
         トゲートウェイの要件" [INTRO:2] は、インターネットゲートウェ 
         イのための公式の規定を含んでいる。現ドキュメントともう片方の 
         ドキュメント [INTRO:1] と共にその RFC は、インターネット体系 
         の現在の実現化のための規則を定義している。

         インターネットホストは広範囲なサイズ、速度、機能に及ぶ。それ 
         らは、小さなマイクロプロセッサからワークステーション、そして 
         汎用機やスーバコンピュータといった範囲にわたる。機能に関して 
         は、単一目的のホスト (例えば端末サービス) から、一般的なリモ 
         ートログインやファイル転送、電子メールを含む、多種多様なオン 
         ラインネットワークサービスをサポートする完全なサービスの範囲 
         に及ぶ。

         ホストは、同じか異なるネットワークに一つ以上のインタフェース 
         を持っていたら、マルチホームと通常呼ばれる。"用語" については、
         セクション 1.3.3 を参照されたい。

      1.1.2 体系上の仮定

         現在のインターネット体系は、通信システムに関して一連の仮定に 
         基づいている。大半はホストに関係するその仮定は、以下のもので 
         ある。

         (a) インターネットはネットワークのネットワークである。

              各々のホストは、幾つかの特定のネットワークに直接接続され
              ている。インターネットへの接続は、単に概念的なものである。
              同じネットワーク上の二つのホストは、離れたネットワーク上
              のホストと通信するために、同じセットのプロトコルを使用し
              て互いに通信する。

         (b) ゲートウェイはコネクション状態の情報を保持しない

              通信システムの頑強性を改善するために、ゲートウェイは状態
              を持たず、各 IP データグラムを他のデータグラムに依存せず
              に転送するよう設計されている。その結果、介在するゲートウェ
              イやネットワークが障害になっても、頑強なサービスを提供す
              るために冗長なパスを利用することができる。

              エンドツーエンドのフロー制御や信頼性向上のために必要な全
              ての状態情報は、ホストのトランスポート層かアプリケーショ
              ンプログラムで実装される。従って、全てのコネクション制御
              情報は通信の終端の同じ場所に配置されるので、終端が障害に
              なった場合にのみそれが失われる。

         (c) ルーティングの複雑さはゲートウェイにあるべきである。

              ルーティングは複雑で難しい問題であり、ホストではなくゲー
              トウェイによって実行されるべきである。重要な目的は、イン
              ターネットルーティング体系の避けられない発展による、ホス
              トソフトウェアの変更を防ぐことである。

         (d) システムは広範囲にわたるネットワークの多様性に対応しなけ 
             ればならない。

              インターネット設計の基本的な目的は、広範囲にわたるネット
              ワーク特性、例えば帯域や遅延、パケット損失、パケットの再
              順序付け、最大パケット長などに対応することである。別の目
              的は、個々のネットワーク、ゲートウェイ、ホストの障害に対
              する頑強性であり、まだ利用できる帯域を使用する。最終的に、
              目標は完全な "オープンシステム相互接続" である。インター
              ネットホストは、様々なインターネットパスに渡って、他のい
              かなるホストとも頑強で効率的に相互動作できなければならな
              い。

              ホストの実装者は時々、あまり野心的でない目標で設計してい
              た。例えば、通常 LAN 環境は全体的にインターネットよりも 
              良好である。LAN ではパケットの損失や遅延が少なく、パケッ
              トの再順序付けもほとんどない。幾つかのベンダは単純な LAN
              環境に適したホスト実装を配備したが、一般的な相互動作での
              動作は具合が悪かった。ベンダはそのような製品を、限定され
              た LAN マーケットでは経済的であるとして正当化している。 
              しかし、隔離されている LAN が長い間隔離されたままに留ま 
              ることはめったにない。それらは間もなくお互いに、そして組
              織単位で、最終的にはグローバルなインターネットシステムに
              ゲートウェイされるだろう。結局、不完全な、あるいは標準に
              外れたインターネットホストソフトウェアは、消費者にもベン
              ダにも役に立たないのである。

              このドキュメントで詳述された要件は、任意のインターネット
              パス上で完全な相互動作を行える、完全な機能を持つインター
              ネットホストのために設計されている。

      1.1.3 インターネットプロトコルスイート

         インターネットシステムを使用して通信するために、ホストはイン 
         ターネットプロトコルスイートを構成する、層に分けられたプロト 
         コルのセットを実装しなければならない。ホストは、各々の層から 
         少なくとも一つのプロトコルスイートを一般に実装しなければなら 
         ない。

         インターネット体系で使用されるプロトコル層は、以下の通り
         [INTRO:4]。

         o  アプリケーション層

              アプリケーション層は、インターネットプロトコルスイートの
              最上位である。インターネットアプリケーション層のプロトコ
              ルの幾つかは、実際は内部的にサブレイヤを含んでいるが、イ
              ンターネットスイートは、アプリケーション層をさらに細分化
              しない。インターネットスイートのアプリケーション層は、  
              OSI 参照モデルの最上位の二つの層、プレゼンテーション層と
              アプリケーション層を本質的に結合する。

              我々は、アプリケーション層プロトコルの二つのカテゴリを区
              別する。それは、ユーザに直接サービスを提供するユーザプロ
              トコルと、共通的なシステム機能を提供するサポートプロトコ
              ルである。ユーザプロトコルとサポートプロトコルのための要
              件は、ペアの RFC [INTRO:1] に示されている。

              最も一般的なインターネットユーザプロトコルは以下のもの。

                o  Telnet (リモートログイン)
                o  FTP    (ファイル転送)
                o  SMTP   (電子メール配送)

              数多くの他の標準化されたユーザプロトコル [INTRO:4] や、 
              多くのプライベートなユーザプロトコルが存在する。

              サポートプロトコルは、SNMP, BOOTP, RARP, ドメイン名シス 
              テム (DNS) プロトコルを含み、ホスト名のマッピングや管理 
              で使用される。

         o  トランスポート層

              トランスポート層は、アプリケーションのためにエンドツーエ
              ンドの通信サービスを提供する。現在、二つの基本的なトラン
              スポート層プロトコルが存在する。

                o 転送制御プロトコル (TCP)
                o ユーザデータグラムプロトコル(UDP)

              TCP は信頼できるコネクション型トランスポートサービスであ
              り、エンドツーエンドの信頼性や再順序付け、フロー制御を提
              供する。UDP はコネクションレス ("データグラム") トランス
              ポートサービスである。

              研究団体によって他のトランスポートプロトコルが開発されて
              おり、公式のインターネットトランスポートプロトコルのセッ
              トは、将来拡張されるかもしれない。

              トランスポート層プロトコルは、チャプタ 4 で論じられてい 
              る。

         o  インターネット層

              全てのインターネットトランスポート層プロトコルは、データ
              を送信元から宛先ホストに運ぶために、インターネットプロト
              コル (IP) を使用する。IP はコネクションレス、あるいはデ 
              ータグラム相互ネットワークサービスであり、エンドツーエン
              ドの配送保証は提供しない。従って、IP データグラムは宛先 
              ホストに損傷を受けたり重複したり順序が変わったりして到着
              するかもしれないし、あるいは全く到着しないかもしれない。
              IP 上の層は、必要な場合は信頼できる配送サービスを提供す 
              る責任がある。IP プロトコルは、アドレス付けやサービスタ 
              イプの指定、分割や組立、セキュリティ情報のための設備を含
              む。

              データグラムや IP プロトコルのコネクションレス特性は基本
              的であり、インターネット体系の特徴的な一面である。インタ
              ーネット IP は、OSI コネクションレスネットワークプロトコ
              ル [INTRO:12] のモデルであった。

              ICMP は制御プロトコルであり、体系的には IP 上の層、すな 
              わち ICMP は、TCP や UDP のようなトランスポートプロトコ 
              ルと同様に、データをエンドツーエンドに運ぶために IP を使
              用するが、IP の重要な一部分であると見なされる。ICMP はエ
              ラー通知や輻輳通知、第一ホップのゲートウェイリダイレクショ
              ンを提供する。

              IGMP は、IP マルチキャストで動的なホストグループを確立す
              るために使用されるインターネット層プロトコルである。

              インターネット層プロトコルの IP, ICMP, IGMP については、
              チャプタ 3 で論じられる。

         o  リンク層

              直接接続されたネットワーク上で通信するために、ホストは、
              そのネットワークにインタフェース接続するために使用される
              通信プロトコルを実装しなければならない。我々は、これをリ
              ンク層、あるいはメディアアクセス層プロトコルと呼ぶ。

              多くの異なるネットワークのタイプに応じて、広範囲に渡るリ
              ンク層プロトコルが存在する。チャプタ 2 を参照されたい。

      1.1.4  組み込みゲートウェイコード

         幾つかのインターネットホストソフトウェアは、ゲートウェイ機能 
         を埋め込んでいる。これらのホストは、ホストのアプリケーション 
         層の機能を実行しながらも、ゲートウェイのようにパケットを転送 
         できる

         このような二重の目的を持つシステムは、ゲートウェイ機能に関し 
         てはゲートウェイ要件 RFC [INTRO:2] に従わなければならず、ホス
         ト機能に関してはこのドキュメントに従わなければならない。重複 
         するケースについては全て、この二つの規定は合致しているはずで 
         ある。

         組み込みゲートウェイ機能については、インターネット社会におい 
         て様々な意見がある。主要な議論は以下の通り。

         o    賛成: ローカルネットワーク環境ではネットワークは非公式、
              あるいはインターネットから切り離されている。既存のホスト
              システムをゲートウェイとして使用することは、便利で効率的
              かもしれない。

              組み込みゲートウェイ機能については体系的な議論もある。マ
              ルチホーミングは元々予想されていたよりも、ずっと一般的に
              なっており、マルチホーミングは、あたかもゲートウェイであ
              るかのようにルーティングの決定をホストに強制する。もしマ
              ルチホーム化されたホストが組み込みゲートウェイを含むなら
              ば、完全なルーティングの知識を持つだろう。結果的に最適な
              ルーティングの決定を行なうことができる。

         o    反対: ゲートウェイアルゴリズムとプロトコルは依然として変
              更されており、インターネットシステムはさらに大きくなるの
              で、変更され続けるであろう。ホスト IP 層の中に一般的なゲ
              ートウェイ機能を含めようと試みると、ホストシステム管理者
              はこれらの (しばしばある) 変更を追わなければならなくなる。
              また、ゲートウェイ実装の大きなプールにより、変更を調整す
              ることがより困難になる。最後に、ゲートウェイ IP 層は複雑
              であるため、ホストよりも幾分大きく、実装や操作作業がより
              複雑になる。

              加えて、幾つかのホストの処理スタイルは、安定して堅固なゲ
              ートウェイサービスを提供するのに適切ではない。

         これらの観点の両方ともかなりのメリットがある。一つの結論を抜 
         き出せるだろう: ホスト管理者は、所定のホストがゲートウェイと 
         して動作するか否かを意識的に制御しなければならない。詳細な要 
         件については、セクション 3.1 を参照されたい。

   1.2 一般的な考慮

      インターネットホストソフトウェアのベンダが学び、新たなベンダが真
      剣に考慮すべき二つの重要な教訓がある。

      1.2.1 発展し続けるインターネット

         インターネットの膨大な成長は、大きなデータグラムベースのパケッ
         ト通信システムにおける、管理と規模の問題を暴露した。これらの 
         問題は取り組まれており、結果的にこのドキュメントで示される規 
         定も発展し続けるだろう。こうした計画には、ベンダやネットワー 
         クの運用に責任がある組織が広範囲に渡って関係しているので、こ 
         れらの変更は慎重に計画、管理される。

         成長、発展、改訂は今日のコンピュータネットワークプロトコルの 
         特徴であり、この状態は数年は続くであろう。インターネットプロ 
         トコルスイート (あるいは他の如何なるプロトコルスイートでも !)
         のコンピュータ通信ソフトウェアを開発して、その後の規約の変更 
         に対してそのソフトウェアの保守や更新を行なわないベンダは、不 
         幸な消費者の跡を残すだろう。インターネットは大規模な通信ネッ 
         トワークであり、ユーザは絶えずそれを通じて接触する。経験から 
         すると、ベンダソフトウェアの欠陥に関する知識は、インターネッ 
         ト技術社会を通じて急速に伝達されるようである。

      1.2.2 頑強さの指針

         プロトコルの全ての層において、アプリケーションが頑強さと相互 
         接続性に関して、莫大な利益をもたらすことができる一般原則があ 
         る [IP:1]。それは、

                "受信するものには寛大であれ、
                 送信するものには慎重であれ"

         ソフトウェアは、考えられる異常を、たとえそれがあり得そうに無 
         いものであっても処理できるよう書かれるべきである。遅かれ早か 
         れ、パケットはある特定のエラーや属性が組み合わさって入ってく 
         る。もしソフトウェアがそれに備えていなければ、混乱が起こり得 
         る。一般に、ネットワークは最悪の影響を及ぼすことを意図したパ 
         ケットを送信する、悪意を持ったエンティティが数多く存在するも 
         のと想定することが最善である。大半のインターネットの重大な問 
         題は、低い確率で発生するイベントによって引き起こされる、予見 
         できないメカニズムが原因ではあるが、この想定は適切な防御設計 
         につながるだろう。人的悪意だけでは、さほど踏み誤った進路を辿 
         ることはほとんど無い!

         修正に対する適応性は、インターネットホストのソフトウェアの全 
         てのレベルにおいて設計しなければならない。簡単な例だが、特定 
         のヘッダフィールド値の列挙、たとえばタイプフィールドやポート 
         番号、エラーコードを含むプロトコル規約を考慮した場合、この列 
         挙値は完全ではないと想定しなければならない。従って、もしプロ 
         トコル規約が 4 つのあり得るエラーコードを定義したら、ソフトウェ
         アは 5 つめのコードが現れたときに壊れてはならない。未定義のコ
         ードはログに採取してもよいが (後述)、障害の原因になってはなら
         ない。

         指針の二番目の部分は、次の点において重要である。他のホスト上 
         のソフトウェアは、正しいが不明確なプロトコル機能の開発を浅は 
         かにする欠陥を含むかもしれない。面倒な影響を結果的にどこかに 
         及ぼすのは良くないので、明確さや単純さから離れることは馬鹿げ 
         ている。この結論は、"誤った動作をするホストに用心せよ" である。
         ホストソフトウェアは、単に他の誤った動作をするホストがあって 
         も生き残るだけではなく、そうしたホストが原因で起こり得る、共 
         有された通信設備への混乱の量を限定するために協調することを考 
         慮すべきである。

      1.2.3 エラーのログ採取

         インターネットは非常に多岐に渡るホストやゲートウェイシステム 
         を伴い、その各々は多くのプロトコルやプロトコル層を実装してお 
         り、これらの幾つかはインターネットプロトコルソフトウェアの中 
         にバグや機能誤りを含んでいる。複雑さや多様性や機能の分散の結 
         果として、インターネット問題の診断はしばしば非常に困難である。

         もしホスト実装が、異常や "奇妙な" プロトコルイベントをログに 
         採取するために、注意深く設計された機能を含んでいれば、問題の 
         診断に役立つだろう。エラーログを採取する際に、可能な限り多く 
         の診断を含めることは重要である。特に、エラーの原因となったパ 
         ケットのヘッダを記録することはしばしば効果的である。しかし、 
         エラーのログ採取が極端に大量の資源を消費したり、さもなくばホ 
         スト処理の邪魔にならないことを保証するよう、注意しなければな 
         らない。

         異常だが害は無いプロトコルイベントが、エラーのログファイルを 
         溢れさせる傾向がある。これは "循環" ログを使用するか、あるい 
         は既知の障害を診断する場合にのみログの採取を有効にすることに 
         よって回避できる。連続して重複したメッセージをフィルタにかけ 
         て、その回数を数えるのは効果的かもしれない。うまくいきそうな 
         戦略は、(1) 常に異常事象をカウントし、その数には管理プロトコ 
         ル ([INTRO:1] 参照) を通じてアクセスさせること。(2) 多様なイ 
         ベントのログ採取を選択可能にすること。例えば、"全てをログに採
         る"、あるいは "ホスト X の全てをログに採る" ことができると便 
         利かもしれない。

         異なる管理者は、通常時にホストで有効にしたいエラーログの採取 
         量に関して、異なる指針を持つかもしれない。ある者は "もし自分 
         の害にならなければ、それについて知りたくない" と言うかもしれ 
         ないし、またある者は、より注意深く積極的にプロトコル異常を検 
         出し除去したいと思うかもしれない。

      1.2.4 設定

         もしインターネットプロトコルスイートのホスト実装が完全に自己 
         設定できれば、理想的である。これによって、スイート全体を ROM 
         に実装したり、シリコンに組み込むことが可能になる。それによっ 
         てディスクレスワークステーションが単純になり、システムベンダ 
         のみならず、苦しんでいる LAN 管理者にも莫大な恩恵をもたらすだ
         ろう。我々はまだこの理想には到達していないし、実際近づいても 
         いない。

         このドキュメントの多くの個所に、このパラメタは設定可能なオプ 
         ションであることという要件が見つかるだろう。そうした要件の背 
         景には、幾つかの異なる理由がある。幾つかのケースでは、最適値 
         について現在確定していないか同意されておらず、将来、推奨値を 
         更新する必要があるかもしれない。別のケースでは、値が実際に外 
         部要因に依存する。例えば、ホストのサイズや通信負荷の分散、隣 
         接するネットワークの速度やトポロジなどである。そして自己調整 
         アルゴリズムが使用できなかったり、不十分であるかもしれない。 
         またあるケースでは、管理要件のために設定可能であることが必要 
         とされる。

         最後に、ある設定オプションは、廃止された、あるいはプロトコル 
         の不正な実装体と通信するために必要である。それらはソース無し 
         で配布され、不幸にもインターネットの多くの部分に残っている。 
         正しいシステムをこれらの欠陥システムと共存させるために、管理 
         者はしばしば、正しいシステムに "誤設定" を施す必要がある。こ 
         の問題は、欠陥システムが退くにつれて次第に改善されていくだろ 
         う。しかし、ベンダはそれを無視することができない。

         パラメタが設定可能でなければならないと言う場合、その値が毎回 
         ブート時に設定ファイルから明示的に読み込まれる必要があること 
         は意図していない。実装者は各パラメタにデフォルトを設定するこ 
         とが推奨される。よって設定ファイルは、ある特定のインストール 
         において適切でないデフォルトを、上書きする場合にのみ必要であ 
         る。従って、設定を可能にするという要件は、バイナリのみや ROM 
         ベースの製品でさえも、必要時にデフォルトを上書きすることがで 
         きることの保証である。

         このドキュメントは、幾つかのケースでそうしたデフォルトとして、
         特定の値を要求している。デフォルトの選択は、設定項目が既存の 
         欠陥システムへの適応を制御する場合は、微妙な問題である。もし 
         インターネットが完全な相互接続性に正常に収束するならば、実装 
         体に組み込まれるデフォルト値は、欠陥システムに便宜を図るため 
         の "誤設定" ではなく、公式のプロトコルを実装しなければならな 
         い。市場を考慮すると、あるベンダは誤設定のデフォルトを選択す 
         るかもしれないが、我々は、この標準に適合したデフォルトをベン 
         ダが選択することを強く推奨する。

         最後に、ベンダは全ての設定パラメタや、それらの制限や効果に関 
         して、必要十分なドキュメントを提供する必要があることを書き留 
         めておく。

   1.3 このドキュメントを読む

      1.3.1 構成

         プロトコルの層分けは、ネットワークソフトウェアを実装する際に 
         構成の指針として通常使用されるが、このドキュメントの構成でも 
         使用している。規則を規定する際、実装体はプロトコルの層を厳密 
         に反映しているものと仮定する。従って、以下の三つの主要なセク 
         ションは、リンク層、インターネット層、トランスポート層の要件 
         をそれぞれ規定する。ペアの RFC [INTRO:1] は、アプリケーション
         レベルのソフトウェアをカバーする。この層による構成は、平易さ 
         と明確さのために選択された。

         しかし厳密な層分けは、プロトコルスイートと推奨される実装アプ 
         ローチの両方にとって不完全なモデルである。異なる層のプロトコ 
         ルは、複雑に、時には微妙に影響し合う。そしてある特定の機能は、
         複数の層にしばしば関係する。実装には多くの設計の選択肢があり、
         それらの多くは、厳密な層分けの創造的な "破壊" を伴う。参照
         [INTRO:7] と [INTRO:8] を読むことを、全ての実装者に強く推奨す
         る。

         このドキュメントは、層と層の間の概念的なサービスインタフェー 
         スを、TCP 規定 [TCP:1] で使用されているような、関数的な ("手 
         続き呼出し") 表記法で記述する。ホスト実装は、これらの呼出しが
         意味する論理的な情報の流れをサポートしなければならないが、そ 
         の呼出し自身を文字通りに実装する必要は無い。例えば、多くの実 
         装体は、共通のデータ構造にアクセスを共有させることにより、ト 
         ランスポート層と IP 層の結合を反映している。これらのデータ構 
         造は、明示的な手続き呼出しというよりはむしろ、必要な情報の大 
         半を渡すための代用品である。

         一般に、このドキュメントの各々の主要なセクションは、以下のサ 
         ブセクションで構成される。

         (1) 導入

         (2) プロトコルウォークスルー -- プロトコル規定のドキュメント 
             をセクション毎に考察し、誤りを修正し、曖昧な、あるいは不 
             適当に定義された要件に言及し、さらに明確化し説明を加えて 
             いる。

         (3) 特定の問題 -- ウォークスルーに含まれなかったプロトコル設 
             計と実装の問題について論じる。

         (4) インタフェース -- 次の上位層へのサービスインタフェースに 
             ついて論じる。

         (5) 要約 -- このセクションの要件の要約を含む。

         このドキュメント中の多くの個々のトピックの配下に、"DISCUSSION"
         か "IMPLEMENTATION" というラベルが付いた挿入句的な説明がある。
         この説明は、この前の要件テキストを明確化したり、説明を加える 
         ことを意図している。また、起こり得る将来の方向性や開発に対す 
         る幾つかの提案も含んでいる。実装説明は、実装者が考慮する必要 
         のある提案されたアプローチを含む。

         要約セクションは、テキストへのガイドとインデクスになることを 
         意図しているが、かなり短く不完全である。要約は、完全な RFC と
         は切り離して使用したり参照すべきではない。

      1.3.2 要件

         このドキュメントでは、各々の特定の要件の重要性を定義するため 
         に使用される単語は、大文字で記述される。これらの単語とは、

         *    "MUST"

              この単語、あるいは形容詞 "REQUIRED" は、その項目は規定の
              絶対的な要件であることを意味する。

         *    "SHOULD"

              この単語、あるいは形容詞 "RECOMMENDED" は、特定の環境に 
              おいて、この項目を無視する正当な理由があるかもしれないこ
              とを意味する。しかし、完全な実装について理解すべきであり、
              異なる方法を選択する前に慎重に比較考察すべきである。

         *    "MAY"

              この単語、あるいは形容詞 "OPTIONAL" は、この項目が本当に
              任意であることを意味する。あるベンダは、例えば特定の市場
              が必要としているという理由で、あるいは製品を拡張したいと
              いう理由でその項目を含めることを選択してもよい。また、別
              のベンダは同じ項目を省略してもよい。

         もし実装するプロトコルの一つ以上の MUST 要件を満たさなければ、
         その実装体は準拠していない。プロトコルの全ての MUST 要件と   
         SHOULD 要件を満たしている実装体は、"無条件に準拠" と呼ばれる。
         プロトコルの MUST 要件は全て満たしているが、SHOULD 要件は全て
         満たしているわけではない実装体は、"条件付きで準拠" と呼ばれる。

      1.3.3 用語

         このドキュメントは、以下の技術用語を使用する。

         セグメント (Segment)
              セグメントは、TCP プロトコルにおけるエンドツーエンド転送
              の単位である。セグメントは、TCP ヘッダとそれに続くアプリ
              ケーションデータで構成される。セグメントは、IP データグ 
              ラムの中にカプセル化されて送信される。

         メッセージ (Message)
              下位層プロトコルのこの説明では、メッセージはトランスポー
              ト層プロトコルの単位である。特に、TCP セグメントはメッセ
              ージである。メッセージは、トランスポートプロトコルヘッダ
              とそれに続くアプリケーションデータで構成される。インター
              ネットを通じてエンドツーエンドで送信するために、メッセー
              ジをデータグラムの中にカプセル化しなければならない。

         IP データグラム (IP Datagram)
              IP データグラムは、IP プロトコルにおけるエンドツーエンド
              転送の単位である。IP データグラムは、IP ヘッダとそれに続
              くトランスポート層データ、すなわち IP ヘッダとそれに続く
              メッセージで構成される。

              インターネット層の説明 (セクション 3) では、"データグラ 
              ム" という用語に修飾子が無ければ、IP データグラムを指す 
              ものと解釈すべきである。

         パケット (Packet)
              パケットは、インターネット層とリンク層間のインタフェース
              で渡すデータの単位である。パケットは完全な IP データグラ
              ムであるか、IP データグラムのフラグメントであってもよい。

         フレーム (Frame)
              フレームは、リンク層プロトコルにおける転送の単位であり、
              リンク層ヘッダとそれに続くパケットで構成される。

         接続されたネットワーク (Connected Network)
              ホストがインタフェースしているネットワークは、そのホスト
              に関係する "ローカルネットワーク" あるいは "サブネットワ
              ーク" として大抵知られている。しかし、これらの用語は混乱
              を招く可能性があるので、このドキュメントでは "接続された
              ネットワーク" という用語を使用する。

         マルチホーム (Multihomed)
              もしホストが複数の IP アドレスを持っていたら、それはマル
              チホームと呼ばれる。マルチホームについての議論は、以下の
              セクション 3.3.4 を参照されたい。

         物理ネットワークインタフェース (Physical network interface)
              これは、接続されたネットワークへの物理インタフェースであ
              り、(恐らくユニークな) リンク層アドレスを持つ。単一ホス 
              ト上の複数の物理ネットワークインタフェースは、同じリンク
              層アドレスを共有してもよいが、同じ物理ネットワーク上の異
              なるホストでは、アドレスはユニークでなければならない。

         論理 [ネットワーク] インタフェース
         (Logical [network] interface)
              論理 [ネットワーク] インタフェースは、ユニークな IP アド
              レスによって識別される、接続されたネットワークへの論理的
              なパスと定義する。セクション 3.3.4 参照。

         特定宛先アドレス (Specific-destination address)
              ブロードキャストであれマルチキャストであれ、これはデータ
              グラムの有効な宛先アドレスである。セクション 3.2.1.3 参 
              照。

         パス (Path)
              ある時間は、特定の送信元ホストから特定の宛先ホストへの  
              IP データグラムは、通常同じゲートウェイの道筋を横断する。
              この道筋について、"パス" という用語を使用する。パスは単 
              一方向であり、所定のホストのペア間の二つの方向において別
              々のパスを持つことは、一般的ではない。

         MTU
              最大転送単位、すなわち転送可能な最も大きいパケットのサイ
              ズ

         フレーム、パケット、データグラム、メッセージ、セグメントとい 
         った用語は、以下の概略図によって示されている。

         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 謝辞

      このドキュメントは、大学や研究機関の代表者、ベンダ、政府機関の代
      理人を含む、インターネットプロトコルの専門家の大きなグループから
      の寄与とコメントを反映している。基本的には、インターネット技術作
      業団体 (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)。

      この一覧からたまたま漏れているかもしれない寄与者を含め、皆に感謝
      したい。

2. リンク層

   2.1  導入

      全てのインターネットシステムのホストとゲートウェイの両方は、リン
      ク層プロトコルで同じ要件を持つ。これらの要件は "インターネットゲ
      ートウェイの要件" [INTRO:2] チャプタ 3 で示されており、このセク 
      ションの資料を増やしている。

   2.2 プロトコルウォークスルー

      無し

   2.3 特定の問題

      2.3.1 トレーラープロトコル折衝

         リンク層カプセル化のトレーラープロトコル [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 応答
              と一緒に常に送信してもよい。

      2.3.2 アドレス解決プロトコル -- ARP

         2.3.2.1 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) タイムアウト -- キャッシュエントリを、たとえ使用 
                     されていても定期的にタイムアウトする。キャッシュ 
                     エントリが "リフレッシュ" された時は (ターゲット 
                     アドレスに関わらず、当該システムからのブロードキャ
                     ストの送信元フィールドを観測することによって)、こ
                     のタイムアウトを再開すべきである。プロクシ ARP 環
                     境では、タイムアウトは 1 分のオーダである必要があ
                     る。

                 (2) ユニキャストポーリング -- ポイントツーポイント   
                     ARP 要求を定期的に送信することによって、リモート 
                     のホストを積極的にポーリングし、もし N 回続けて  
                     ARP 応答の受信が無ければ、そのエントリを削除する。
                     これも、タイムアウトは分のオーダであるべきであり、
                     通常 N は 2 である。

                 (3) リンク層通知 -- もしリンク層ドライバが送信の問題 
                     を検出したら、それに対応する ARP キャッシュエント
                     リを削除する。

                 (4) 上位層通知 -- 送信の問題を示すために、インターネッ
                     ト層からリンク層への呼出しを提供する。この呼出し 
                     の効果は、対応するキャッシュエントリを無効化する 
                     ことである。この呼出しは、トランスポート層からイ 
                     ンターネット層への "ADVISE_DELIVPROB()" 呼出し   
                     (セクション 3.4 参照) に類似している。実際、     
                     ADVISE_DELIVPROB ルーチンは、ARP キャッシュエント
                     リを無効化するためのリンク層通知ルーチンを順々に 
                     呼び出す。

                 (1) と (2) のアプローチは、分オーダ以下の ARP キャッ 
                 シュタイムアウトを伴うものである。プロクシ ARP が無い
                 場合は、このタイムアウトが短いと、大規模なイーサネッ 
                 ト上で顕著なトラフィックのオーバーヘッドを生み出す。 
                 従って ARP キャッシュタイムアウトを延ばすよう、ホスト
                 を設定する必要があるかもしれない。

         2.3.2.2 ARP パケットキュー

            リンク層は同じ未解決の IP アドレス宛ての各一セットのパケッ
            トの、少なくとも 1 つの (最新の) パケットを (破棄するので 
            はなく) 保持して、アドレスが解決された時に保持したパケット
            を送信すべきである (SHOULD)。

            DISCUSSION:
                 この推奨に従わないと、全ての交換の一番最初のパケット 
                 が失われることになる。上位層プロトコルは、一般に再送 
                 によってパケット損失に対処することができるが、パケッ 
                 ト損失はパフォーマンスにかなり影響する。例えば、TCP  
                 オープン要求が損失すると、初期ラウンドトリップ時間の 
                 見積りが膨らんでしまう。ドメイン名システム等の UDP ベ
                 ースのアプリケーションでは、影響がより重大である。

      2.3.3 イーサネットと IEEE 802.2 カプセル化

         イーサネットでの IP カプセル化は RFC894 [LINK:3] で規定され、
         RFC1042 [LINK:4] は IEEE 802 ネットワークにおける IP カプセル
         化を規定する。RFC1042 は、[INTRO:2] のセクション 3.4 の議論を
         詳述し、置き換えている。

         10Mbps のイーサネットケーブルに接続される全てのインターネット
         ホストは、

         o    MUST be able to send and receive packets using RFC-894
              encapsulation;

         o    RFC894 のカプセル化を使用したパケットを送受信できなけれ 
              ばならない (MUST)。

         o    RFC894 パケットと混ざった RFC1042 パケットを受信できるべ
              きである (SHOULD)。

         o    RFC1042 のカプセル化を使用したパケットを送信できてもよい
              (MAY)。

         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 ゲートウェイを通じなければ通信できないことに注意 
              されたい。さらに、リンク層ブロードキャストの問題があるた
              めに、両形式をサポートするホストが、自動的にどちらの形式
              が送信されたかを検知することは実用的ではないし、あるいは
              可能ですらない。

   2.4 リンク/インターネット層インタフェース

      IP 層とリンク層間のパケット受信インタフェースは、入力パケットが 
      リンク層ブロードキャストアドレス宛てか否かを示すためのフラグを含
      まなければならない (MUST)。

      DISCUSSION:
           IP 層は、通常リンク層アドレスを知らないが (全ての異なるネッ
           トワーク媒体は、通常異なるアドレス形式を持つので)、ブロード
           キャストケーブル媒体上のブロードキャストアドレスは、重要で 
           特別なケースである。セクション 3.2.2 を参照されたい。特にブ
           ロードキャストストームに関しては DISCUSSION を参照されたい。

      IP 層とリンク層間のパケット送信インタフェースは、5 ビットの TOS 
      フィールド (セクション 3.2.1.6 参照) を含まなければならない     
      (MUST)。

      リンク層は、その宛先の ARP キャッシュエントリが存在しないという 
      理由だけで、IP に宛先未到達エラーを通知してはならない (MUST NOT)。

   2.5 リンク層要件要約

                                                  |       | | | |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|

3. インターネット層プロトコル

   3.1 導入

      頑強さの指針 "受信するものには寛大であれ、送信するものには慎重で
      あれ" は、インターネット層では特に重要である。一つの誤った動作を
      するホストによって、他の多くのホストのインターネットサービスが拒
      否される可能性がある。

      インターネット層で使用されるプロトコル標準は、

      o    RFC791 [IP:1] は IP プロトコルを定義しており、インターネッ 
           トの体系の導入を記述している。

      o    RFC791 [IP:2] は、IP のルーティング、診断、エラー機能を提供
           する ICMP を定義している。ICMP メッセージは IP データグラム
           の中にカプセル化されるが、ICMP プロセスは IP 層の一部と見な
           される (通常 IP 層の一部として実装される)。セクション 3.2.2
           を参照されたい。

      o    RFC950 [IP:3] は、アドレス体系に対して必須のサブネット拡張 
           を定義する。

      o    RFC1112 [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 層の機能が将来増加されることが期待される。

      通常のデータグラムに対して、その処理は率直である。入力データグラ
      ムに対して、IP 層は以下を行なう。

      (1) データグラムが正しい形式かをチェックする。

      (2) データグラムがローカルホスト宛てかをチェックする。

      (3) オプションを処理する。

      (4) 必要ならば、データグラムを組み立てる。

      (5) カプセル化されたメッセージを適切なトランスポート層プロトコル
          モジュールに渡す。

      出力データグラムに対して、IP 層は以下を行なう。

      (1) トランスポート層で設定されていないフィールドを全て設定する。

      (2) 接続されたネットワーク上の正しい第一ホップを選択する ("ルー 
          ティング" と呼ばれる処理)。

      (3) 必要であり、かつ意図的な分割を実装しているならば (セクション
          3.3.3 参照)、データグラムを分割する。

      (4) 適切なリンク層ドライバにパケットを渡す。

      もしホストが複数の IP アドレスを持っていたら、それはマルチホーム
      と呼ばれる。マルチホームはかなりの混乱と複雑さをプロトコルスイー
      トにもたらし、インターネット体系だけでは全ての問題に対処しきれな
      い分野である。マルチホームには、以下の二つの異なる問題の領域があ
      る。

      (1) ローカルマルチホーム -- ホスト自身がマルチホーム化されている。

      (2) リモートマルチホーム -- ローカルホストはリモートのマルチホー
          ム化されたホストと通信する必要がある。

      ペア RFC [INTRO:1] で論じられているように、現在リモートマルチホ 
      ームは、アプリケーション層で処理しなければならない (MUST)。ホス 
      トはローカルマルチホームをサポートしてもよく (MAY)、それはこのド
      キュメント、特にセクション 3.3.4 で論じられている。

      別のホストによって生成されたデータグラムを転送するホストは全てゲ
      ートウェイとして動作し、ゲートウェイ要件 RFC [INTRO:2] に示され 
      ている規定にも適合しなければならない。組み込みゲートウェイコード
      を含むインターネットホストは、ゲートウェイ機能を不可にする設定ス
      イッチを持たなければならず (MUST)、このスイッチはデフォルトでは 
      非ゲートウェイモードでなければならない (MUST)。非ゲートウェイモ 
      ードの場合、一つのインタフェースを通じて到着したデータグラムは、
      そのホストがシングルホームかマルチホームかに関わらず、別のホスト
      やゲートウェイ (もしそれが送信元経路でなければ) に転送しない。も
      しホストが一つ以上のインタフェースを持っていなければ、マシンのオ
      ペレータがサービスを提供したくないかもしれないし、それを行なう権
      限が無いかもしれないので、ホストソフトウェアは自動的にゲートウェ
      イモードに移行してはならない (MUST NOT)。

      以下で、あるケースで規定される動作は、受信したパケットを "黙って
      破棄する" ことである。これは、データグラムを破棄する以外の処理は
      行なわず、結果的にホストは何の ICMP エラーメッセージも送信しない
      ことを意味する。しかし、問題の診断のために、黙って破棄したデータ
      グラムの内容を含め、ホストはエラーのログを採取する機能を提供すべ
      きであり (SHOULD) (セクション 1.2.3 参照)、イベントを統計数に記 
      録すべきである (SHOULD)。

      DISCUSSION:
           異常なデータグラムを黙って破棄することは、一般に "ブロード 
           キャストストーム" を避けることを意図している。

   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 までの、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,  }

                 内部のホストループバックアドレス。この形式のアドレス 
                 は、ホストの外側に表れてはならない (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)。入力データグラムは、データグラムの 
            宛先アドレスフィールドが以下のものであれば、そのホスト宛て
            である。

            (1) ホストの IP アドレス (の一つ)

            (2) 接続されたネットワークにおいて正しい IP ブロードキャス
                トアドレス

            (3) ホストが入力した物理インタフェース上で、マルチキャスト
                グループのメンバであるアドレス

            大半の目的では、ブロードキャストかマルチキャストアドレス宛
            てのデータグラムは、あたかもホストの IP アドレスの一つに宛
            てられていたかのように処理される。"特定宛先のアドレス" と 
            いう用語は、ホストのローカル IP アドレスと同等なものとして
            使用される。もしヘッダがブロードキャストかマルチキャストア
            ドレスを含まなければ、特定宛先のアドレスは IP ヘッダ中の宛
            先アドレスであると定義される。含む場合は、特定宛先はデータ
            グラムが到着した物理インタフェースに割り当てられた IP アド
            レスである。

            ホストは、このセクションにて不正な IP 送信元アドレスを含む
            入力データグラムを黙って破棄しなければならない (MUST)。こ 
            のチェックは、IP 層かトランスポート層の各プロトコルによっ 
            て行なわれる。

            DISCUSSION:
                 ユニキャストデータグラムのリンク層ブロードキャストに 
                 よって、あるいは混乱や設定誤りのあるゲートウェイかホ 
                 ストによって、アドレスに誤りのあるデータグラムが生じ 
                 るかもしれない。

                 インターネットホストにおける 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)。

            DISCUSSION:
                 あるインターネットプロトコルの専門家は、ホストが前の 
                 データグラムと同じ複製を送信する時、新しい複製は元と 
                 同じ識別子値を含むべきであると主張した。これには二つ 
                 の利点が提案されている。(1) もしデータグラムが分割さ 
                 れ、そのフラグメントの幾つかが消失したら、受信側は完 
                 全なデータグラムを元のフラグメントと複製から再構成で 
                 きるかもしれない。(2) 輻輳したゲートウェイは、キュー 
                 からの重複したデータグラムを破棄するために、IP 識別子
                 フィールド (とフラグメントオフセット) を使用するかも 
                 しれない。

                 しかし、インターネットにおけるデータグラム損失のよく 
                 見られるパターンは、再送されたフラグメントが組立の穴 
                 を埋める可能性に肯定的ではない。他のメカニズム (再送 
                 時の TCP 再パケット化) は、同じデータグラムの再送を避
                 ける傾向にある [IP:9]。従って、同じ識別子フィールドの
                 再送は有効であるとは思われない。また、UDP のようなコ 
                 ネクションレス型トランスポートプロトコルの場合、同じ 
                 データグラムの同じ識別子値を保持するために、アプリケ 
                 ーションプログラムとの協調が必要になるだろう。

         3.2.1.6  サービスタイプ: RFC-791 セクション 3.2

            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 で提案されたマッピング 
                 は現在廃止されている。

         3.2.1.7  生存時間: RFC-791 セクション 3.2

            ホストは 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 倍である

         3.2.1.8  オプション: RFC-791 セクション 3.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)。もし実装するならば、以下の規則が
                 適用される。

                 o    発呼側ホストは、インターネットアドレスフィールド
                      が予め指定されていないか、一番目の予め指定された
                      アドレスがホストのインタフェースアドレスならば、
                      タイムスタンプオプションにタイムスタンプを記録し
                      なければならない (MUST)。

                 o    宛先ホストは (可能ならば)、オプションをトランス 
                      ポート層に渡すか、処理するために ICMP に渡す前に、
                      タイムスタンプオプションに現在のタイムスタンプを
                      追加しなければならない (MUST)。

                 o    タイムスタンプの値は、ICMP タイムスタンプメッセ 
                      ージについてセクション 3.2.2.8 で規定された規則 
                      に従わなければならない (MUST)。

      3.2.2 インターネット制御メッセージプロトコル -- ICMP

         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 エラーメッセージ

         *    宛先が IP ブロードキャストか IP マルチキャストアドレスで
              あるデータグラム

         *    リンク層ブロードキャストとして送信されたデータグラム

         *    最初ではないフラグメント

         *    送信元アドレスが単一のホストを定義していないデータグラム、
              例えば 0 アドレスやループバックアドレス、ブロードキャス 
              トアドレス、マルチキャストアドレス、クラス E アドレスの 
              データグラム

         注記: これらの制限は、このドキュメントの他の個所で示されてい 
         る ICMP エラーメッセージ送信に関するいかなる要件よりも優先さ 
         れる。

         DISCUSSION:
              これらの要件は、ホストがブロードキャストデータグラムの応
              答で ICMP エラーメッセージを返却した結果発生する "ブロー
              ドキャストの嵐" を防ぐだろう。例えば、存在しないポートへ
              のブロードキャスト UDP セグメントは、その宛先ポートのク 
              ライアントが無い全てのマシンにより、ICMP 宛先未到達デー 
              タグラムの洪水が引き起こされるかもしれない。大規模なイー
              サネット上では、その結果発生する衝突により、一秒間以上ネッ
              トワークが無効になる可能性がある。

              接続されたネットワーク上のブロードキャストでは、全てのデ
              ータグラムは、その IP 宛先として正しい IP ブロードキャス
              トアドレスを持つべきである (セクション 3.3.6 参照)。しか
              し、幾つかのホストはこの規則に違反している。従って、ブロ
              ードキャストデータグラムを確実に検出するために、ホストは
              IP 層のブロードキャストアドレスだけでなく、リンク層のブ 
              ロードキャストもチェックする必要がある。

         IMPLEMENTATION:
              これは、リンク層がリンク層ブロードキャストを受信した時に
              IP 層に通知することを必要とする。セクション 2.4 を参照さ
              れたい。

         3.2.2.1  宛先未到達: RFC-792

            以下の追加コードがここで定義される。

                    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 参照)。

         3.2.2.2  リダイレクト: RFC-792

            ホストは ICMP リダイレクトメッセージを送信すべきではない  
            (SHOULD NOT)。リダイレクトはゲートウェイが送信するものであ
            る。

            リダイレクトメッセージを受信したホストは、ルーティング情報
            をそれに従って更新しなければならない (MUST)。全てのホスト 
            は、ホストとネットワークの両方のリダイレクトを受諾し、以下
            のセクション 3.3.1.2 で規定されているように処理する準備を 
            しなければならない (MUST)。

            もし指定された新しいゲートウェイアドレスが、リダイレクトが
            到着したのと同じ接続された (サブ) ネット上に無い 
            [INTRO:2, Appendix A] か、もしリダイレクトの送信元が指定さ
            れた宛先に対して現在の第一ホップゲートウェイでない (セクショ
            ン 3.3.1参照) ならば、そのリダイレクトメッセージを黙って破
            棄すべきである (SHOULD)。

         3.2.2.3 送信元損失: RFC-792

            ホストは、組立バッファや他の資源の不足によって、入力データ
            グラムを強制的に破棄する点に近づくか到達したら、送信元損失
            メッセージを送信してもよい (MAY)。送信元損失をいつ送信する
            かについての提案は、[INTRO:2] のセクション 2.2.3 を参照さ 
            れたい。

            もし送信元損失メッセージを受信したら、IP 層はそれをトラン 
            スポート層 (あるいは ICMP 処理) に通知しなければならない  
            (MUST)。一般に、トランスポートやアプリケーション層は、どの
            プロトコルにおいても送信元損失に対して応答し、一連のデータ
            グラムを同じ宛先に送信でき、これを可能にするのに十分な状態
            情報を効率的に維持できるメカニズムを実装すべきである      
            (SHOULD)。TCP と UDP による送信元損失の取り扱いについては、
            セクション 4 を参照されたい。


            DISCUSSION:
                 送信元損失は、ターゲットホストやデータグラムのパス中 
                 のゲートウェイが生成するかもしれない。送信元損失を受 
                 信したホストは一定時間送信を抑え、徐々に送信レートを 
                 再び増やすべきである。送信元損失に応答するメカニズム 
                 はトランスポート層 (TCP のようなコネクション型プロト 
                 コルの場合) や、アプリケーション層 (UDP の上位に位置 
                 するプロトコルの場合) にあってもよい。

                 データグラムの送信レートを制御することによって、IP 層
                 が送信元損失に直接応答するメカニズムが提案されている 
                 [IP:14] が、この提案は現在実験的なものであり、推奨は 
                 されていない。

         3.2.2.4 時間超過: RFC-792

            受信した時間超過メッセージはトランスポート層に渡さなければ
            ならない (MUST)。

            DISCUSSION:
                 ゲートウェイは TTL フィールドの満了によってデータグラ
                 ムを破棄した時、時間超過コード 0 (一時的) のメッセー 
                 ジを送信するだろう。これは、ゲートウェイのルーティン 
                 グループか小さ過ぎる初期 TTL 値のいずれかを示す。

                 ホストは、タイムアウトになって不完全なデータグラムを 
                 破棄した宛先ホストから、時間超過コード 1 (組立タイム 
                 アウト) のメッセージを受信するかもしれない。以降のセ 
                 クション 3.3.2 を参照されたい。将来、このメッセージの
                 受信は、分割せずにパス上に送信できる最大データグラム 
                 サイズを検出するための、"MTU 検出" 手続きの一部になる
                 かもしれない。

         3.2.2.5 パラメタ問題: RFC-792

            ホストはパラメタ問題メッセージを生成すべきである (SHOULD)。
            受信したパラメタ問題メッセージはトランスポート層に渡さなけ
            ればならず (MUST)、ユーザに通知してもよい (MAY)。

            DISCUSSION:
                 ICMP パラメタ問題メッセージは、特に別の ICMP パラメタ
                 問題メッセージによってカバーされない問題に対して、送 
                 信元ホストに送信される。パラメタ問題メッセージの受信 
                 は、ローカルかリモートの実装エラーを通常示す。

            パラメタ問題メッセージの新たな変形は、以下に定義される。
              Code 1 = 必要なオプションが省略されている。

            DISCUSSION:
                 この変形はセキュリティオプションの省略で、軍事コミュ 
                 ニティで使用されている。

            3.2.2.6 エコー要求/応答: RFC-792

            全てのホストはエコー要求を受信し、それに対応するエコー応答
            を送信する 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)。

         3.2.2.7 情報要求/応答: RFC-792

            ホストは、これらのメッセージを実装すべきではない (SHOULD  
            NOT)。

            DISCUSSION:
                 情報要求/応答のペアは、起動時に IP ネットワーク番号の
                 検出を可能にするために、ディスクレスワークステーショ 
                 ンのような自己設定システムをサポートすることを意図し 
                 ていた。しかし、RARP と BOOTP プロトコルは、ホストが 
                 自分の IP アドレスを検出するためのより良いメカニズム 
                 を提供している。

         3.2.2.8 タイムスタンプとタイムスタンプ応答: RFC-792

            ホストは、タイムスタンプとタイムスタンプ応答を実装してもよ
            い (MAY)。もし実装するならば、以下の規則に従わなければなら
            ない (MUST)。

            o    ICMP タイムスタンプサーバ機能は、受信した全てのタイム
                 スタンプメッセージにタイムスタンプ応答を返却する。も 
                 しこの機能を実装するならば、遅延の変化が最小限になる 
                 よう設計 (例えば、ユーザプロセスへのスケジューリング 
                 時の遅延を避けるためにカーネルに実装する) すべきであ 
                 る (SHOULD)。

            以下のタイムスタンプのケースは、対応する ICMP エコーの規則
            に従って処理されるものである。

            o    IP ブロードキャストや IP マルチキャストアドレスへの  
                 ICMP タイムスタンプ要求メッセージは、黙って破棄しても
                 よい (MAY)。

            o    ICMP タイムスタンプ応答の IP 送信元アドレスは、対応す
                 るタイムスタンプ要求メッセージの特定の宛先アドレスと 
                 同じでなければならない (MUST)。

            o    もし ICMP エコー要求で送信元経路オプションを受信した 
                 ら、返却経路を反転して、タイムスタンプ応答メッセージ 
                 の送信元経路オプションとして使用しなければならない   
                 (MUST)。

            o    もしタイムスタンプ要求で経路記録やタイムスタンプオプ 
                 ションを受信したら、これらのオプションは現在のホスト 
                 を含めるように更新し、タイムスタンプ応答メッセージの 
                 IP ヘッダに含めるべきである (SHOULD)。

            o    受信したタイムスタンプ応答メッセージは、ICMP ユーザイ
                 ンタフェースに渡さなければならない (MUST)。

            タイムスタンプ値の好ましい形式 ("標準的な値") は、世界時 0
            時からのミリ秒単位でである。しかし、この値をミリ秒の精度で
            提供することは困難かもしれない。例えば、多くのシステムは、
            1 秒間に 50,60 回の回線周波数でのみ更新するクロックを使用 
            している。従って、ある程度は、以下の "標準値" が許されてい
            る。

            (a) "標準値" は、1 秒間につき少なくとも 15 回更新しなけれ 
                ばならない (MUST)。(すなわち最大 6 つの低位ビットは未 
                定義でもよい)。

            (b) "標準値" の正確さは、CPU クロックのオペレータセットの 
                正確さに近くなければならない (MUST)。すなわち 2,3 分以
                内で正しい。

         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)。すなわち、接続されたネットワークはサブネット
                化されていないと仮定する。

            (c) 受信した一つ目のアドレスマスク応答メッセージは、特定の
                ローカル IP アドレスに対応するアドレスマスクを設定する
                ために使用しなければならない (MUST)。これは、たとえ一 
                つ目のアドレスマスク応答メッセージが "望まれない" とし
                ても真である。その場合ブロードキャストされていて、アド
                レスマスク要求の再送を中止した後に到着するかもしれない。
                一旦、アドレスマスク応答によってマスクが設定されたら、
                以降のアドレスマスク応答メッセージは (黙って) 無視しな
                ければならない (MUST)。

            逆に、もしアドレスマスクメッセージが不使用ならば、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 である。

      3.2.3 インターネットグループ管理プロトコル IGMP

         IGMP [IP:4] は、特定のマルチキャストグループでホストのメンバ 
         ーシップを確立するために、単一のネットワーク上でホストとゲー 
         トウェイとの間で使用されるプロトコルである。ゲートウェイはマ 
         ルチキャストルーティングプロトコルと共に、インターネットに渡 
         る IP マルチキャストをサポートするためにこの情報を使用する。

         この時点では、IGMP の実装はオプションであり、詳細な情報につい
         てはセクション 3.3.7 を参照されたい。IGMP が無くても、ホスト 
         は接続されたネットワークのローカルなマルチキャストに参加する 
         ことができる。

   3.3 特定の問題

      3.3.1 出力データグラムのルーティング

         IP 層は、送信する各データグラムに対して正しい次ホップを選択す
         る。もし宛先が接続されたネットワーク上に在れば、そのデータグ 
         ラムを宛先ホストに直接送信する。さもなくば、接続されたネット 
         ワーク上のゲートウェイに振り分けなければならない。

         3.3.1.1 ローカル/リモート決定

            宛先が接続されたネットワーク上に在るか否かを決定するために、
            以下のアルゴリズムを使用しなければならない (MUST)。
            ([IP:3] 参照)

            (a) アドレスマスク (特にマルチホーム化されたホストのローカ
                ル IP アドレスで) は、対応する IP アドレスのネットワー
                ク番号とサブネット番号フィールドを選択する 32 ビットマ
                スクである。

            (b) もしアドレスマスクによって抽出された IP 宛先アドレスビッ
                トが、同じマスクによって抽出された IP 送信元アドレスビッ
                トと一致したら、宛先はそれに対応する接続されたネットワ
                ーク上に在り、データグラムは直接宛先ホストに送信される。

            (c) もし一致しなければ、宛先はゲートウェイを通じなければア
                クセスできない。ゲートウェイの選択については、以下
                (3.3.1.2) で説明されている。

            特別なケースの宛先アドレスについては、以下のように扱われる。

            *    限定されたブロードキャストかマルチキャストアドレスの 
                 場合、単にデータグラムを適切なインタフェースのリンク 
                 層に渡す。

            *    (ネットワークかサブネットの) 直接ブロードキャストの場
                 合、データグラムは標準的なルーティングアルゴリズムを 
                 使用することができる。

            ホスト IP 層は最小のネットワーク環境で、特にゲートウェイが
            存在しない時に、正しく動作しなければならない (MUST)。例え 
            ば、もしホストの IP 層が、初期化のために少なくとも 1 つの 
            ゲートウェイを見つけると主張したら、そのホストは単一の孤立
            したブロードキャストネット上で動作することができないだろう。

         3.3.1.2 ゲートウェイの選択

            同じ宛先に一連のデータグラムを効率的に振り分けるために、送
            信元ホストは、次ホップゲートウェイへのマッビングの "経路  
            キャッシュ" を保持しなければならない (MUST)。ホストはデー 
            タグラムを振り分けるために、このキャッシュについて以下の基
            本的なアルゴリズムを使用する。このアルゴリズムは、基本的な
            ルーティング負荷をゲートウェイに置くよう設計されている
            [IP:11]。

            (a) もし経路キャッシュが特定の宛先について何の情報も含んで
                いなければ、ホストは "デフォルトの" ゲートウェイを選択
                し、データグラムをそこに送信する。また、対応する経路  
                キャッシュエントリも生成する。

            (b) もしそのゲートウェイが宛先への最善の次ホップでなければ、
                ゲートウェイはそのデータグラムを最善の次ホップゲートウェ
                イに転送し、送信元ホストに ICMP リダイレクトメッセージ
                を返却する。

            (c) リダイレクトを受信したら、ホストは適切な経路キャッシュ
                エントリ中の次ホップゲートウェイを更新する。よって以降
                の同じホストへのデータグラムは、直接最善のゲートウェに
                送られるだろう。

            宛先アドレスに対して適切なサブネットマスクは通常分からない
            ので、ネットワークリダイレクトメッセージをホストリダイレク
            トメッセージと同様に扱うべきである (SHOULD)。すなわち、そ 
            の宛先ホスト (のみ) のキャッシュエントリを新たなゲートウェ
            イとして更新 (あるいは、もしそのホストのエントリが存在しな
            ければ作成) する。

            DISCUSSION:
                 この推奨は、ゲートウェイ要件 [INTRO:2] に違反して、サ
                 ブネット化されたネットワークでネットワークリダイレク 
                 トを誤って送信するゲートウェイに対する防御のためであ 
                 る。

            宛先ホストアドレスの経路エントリキャッシュが存在しない (し
            かも宛先ホストが接続されたネットワーク上に存在しない) 時、
            IP 層は自分の "デフォルト" ゲートウェイのリストからゲート 
            ウェイを抽出しなければならない (MUST)。IP 層は、複数のデフォ
            ルトゲートウェイをサポートしなければならない (MUST)。

            余分な機能として、ホスト IP 層は "静的経路" のテーブルを実
            装してもよい (MAY)。各々の静的経路は、ICMP リダイレクトに 
            よって上書きしてもよいか否かを示すフラグを含んでもよい    
            (MAY)。

            DISCUSSION:
                 ホストは通常、開始するために少なくとも一つのデフォル 
                 トゲートウェイを知る必要がある。この情報は設定ファイ 
                 ルか、さもなくば BOOTP プロトコル等のホスト開始シーケ
                 ンスから獲得できる ([INTRO:1] 参照)。

                 ホストは認識した新しいゲートウェイを全て記録すること 
                 によって、デフォルトゲートウェイのリストを増やせるこ 
                 とが提案されている。例えば、ホストはリダイレクトされ 
                 た全てのゲートウェイを記録できる。そうした機能は、恐 
                 らく幾つかの環境では効果的であるが、他の場合には問題 
                 の原因になるかもしれず (例えば、ゲートウェイは全て等 
                 しいとは限らない)、推奨されない。

                 静的経路は通常、特定の宛先ホストかネットワークから特 
                 定の次ホップゲートウェイにマッピングする前設定であり、
                 サービスタイプにも依存しているかもしれない (次のセク 
                 ション参照)。静的経路は一般の自動ルーティングメカニズ
                 ムを上書きし、例外的な状況を扱うためにシステム管理者 
                 によって設定される。しかし、ルーティング情報は設定変 
                 更時や装置障害時の潜在的な障害の元である。

         3.3.1.3 経路キャッシュ

            各々の経路キャッシュエントリは、以下のフィールドを含む必要
            がある。

            (1) ローカル IP アドレス (マルチホーム化されたホストにおい
                て)

            (2) 宛先 IP アドレス

            (3) サービスタイプ

            (4) 次ホップゲートウェイ IP アドレス

            フィールド (2) は宛先ホストの完全な IP アドレスでもよいし、
            宛先ネットワーク番号だけでもよい (MAY)。フィールド (3) の 
            TOS は含むべきである (SHOULD)。

            このキャッシュ内のルックアップ手続きでのマルチホーム化の含
            意についての議論は、セクション 3.3.4.2 を参照されたい。

            DISCUSSION:
                 経路キャッシュにサービスタイプフィールドを含み、ホス 
                 ト経路アルゴリズムでそれを考慮することは、サービスタ 
                 イプルーティングがインターネットで一般的に使用される 
                 将来にとって必要なメカニズムを提供する。セクション 
                 3.2.1.6 を参照されたい。

                 各々のルートキュッシュエントリは、インターネットパス 
                 の終端を定義する。接続するパスは任意の方法で動的に変 
                 わるかもしれないが、パスの転送特性は、一つの一般的な 
                 ホスト-ホストのトランスポートコネクションよりも、より
                 長い間ほぼ一定のまま留まる傾向がある。従って、経路   
                 キャッシュエントリは、パス特性に基づいてデータをキュッ
                 シュに貯めるための自然な場所である。そのような性質の 
                 例としては、最大非分割データグラム長 (セクション 
                 3.3.3 参照) や、トランスポートプロトコルによって計測 
                 されるラウンドトリップ遅延の平均値がある。このデータ 
                 は通常上位層プロトコル、例えば TCP、あるいは UDP を使
                 用するアプリケーションによって集められ、使われる。こ 
                 の方法でパス特性をキャッシュに貯める実験が、現在進行 
                 中である。

                 経路キャッシュは宛先ホストアドレスのみをキーとすべき 
                 か、ホストアドレスとネットワークアドレスの両方を許す 
                 べきかについての合意は無い。ホストアドレスのみを使用 
                 したい人は、以下を主張している。

                 (1) セクション 3.3.1.2 で要求されているように、リダイ
                     レクトメッセージは通常、宛先ホストアドレスに基づ 
                     いてキー化されたエントリに由来するものであり、最 
                     も単純で一般的なスキームは常にホストアドレスを使 
                     う。

                 (2) IP 層は複雑にサブネット化された環境では、ネットワ
                     ークアドレスに対するアドレスマスクを必ずしも知ら 
                     ないかもしれない。

                 (3) ホストアドレスのみを使用すれば、宛先アドレスを純 
                     粋な 32 ビット番号として使用することができる。そ 
                     れにより、インターネット体系はホストに何の変更も 
                     かけずに、将来容易に拡張できるかもしれない。

                 それに対する意見は、経路キャッシュの中に宛先ホストと 
                 ネットワークの混在を許すことである。

                 (1) メモリ空間を節約する。

                 (2) データ構造が単純になり、デフォルトや静的経路と容 
                     易にキャッシュを結合できる (下記参照)。

                 (3) 前に論じられているように、パスのプロパティをキャッ
                     シュに置くための効果的な場所を提供する。

            IMPLEMENTATION:
                 キャッシュは、同時に使用するかもしれない宛先ホストの 
                 最大個数のエントリを含むのに、十分な大きさを持つ必要 
                 がある。

                 経路キャッシュエントリは、置換するエントリを選択する 
                 ために使用する制御情報も含むかもしれない。これは例え 
                 ば、"最近使用した" ビットや使用回数、最後に使用された
                 タイムスタンプ等の形式である。診断目的のために、エン 
                 トリの最終更新時間を含むことが推奨される。

                 実装体は、全ての送信データグラムに対して経路キャッシュ
                 を走査するオーバヘッドを減らしたいかもしれない。これ 
                 は、走査スビードを上げるためのハッシュテーブルで実現 
                 してもよいし、コネクション型トランスポートプロトコル 
                 に適切なキャッシュエントリについての "ヒント" や一時 
                 ハンドルを与えて、各々の後続データグラムを IP 層に渡 
                 すことによって実現してもよい。

                 経路キャッシュやデフォルトゲートウェイの一覧や静的経 
                 路のテーブルは概念的に異なると説明したが、実際面では 
                 一つの "ルーティングテーブル" データ構造にまとめても 
                 よい。

         3.3.1.4 ゲートウェイ障害検出

            IP 層は、経路キャッシュに一覧化されている "次ホップ" ゲー 
            トウェイの障害を検出し、代替ゲートウェイを選択 (セクション
            3.3.1.5 参照) できなければならない (MUST)。

            ゲートウェイ障害検出は、RFC-816 [IP:11] で詳細についてカバ
            ーされている。幾つかの禁じられたパスや将来有望な技術はある
            が、今までの経験では、全体的に満足のいく完全なアルゴリズム
            は作成されていない

            *    機能しているという明確な指示が無いとき、ある特定のゲ 
                 ートウェイをいつまでも使用すべきではない (SHOULD NOT)。

            *    "ping" のような活性プローブ (例えば、ICMP エコー要求/
                 応答の交換の使用) は高価で規模が貧弱である。特に、ホ 
                 ストは第一ホップのゲートウェイの状態を、単に絶え間な 
                 くゲートウェイを ping することによって積極的にチェッ 
                 クしてはならない (MUST NOT)。

            *    ゲートウェイの状態を確かめることが唯一の効果的な方法 
                 である場合でも、トラフィックがゲートウェイに送信され 
                 ていて、そのゲートウェイが機能していることを示す明確 
                 な指示が何も無い場合に限り、ping を使用しなければなら
                 ない (MUST)。

            *    ping を避けるために、インターネット層の上位層や下位層
                 は、ゲートウェイが活性 (ゲートウェイが OK) か非活性  
                 (ゲートウェイが障害) かの情報が利用できる場合、経路  
                 キャッシュエントリの状態についての "アドバイス" を与 
                 えることができるべきである (SHOULD)。

            DISCUSSION:
                 もし、実装体がゲートウェイ障害や再ルーティングを検出 
                 するための適切なメカニズムを含まなければ、ゲートウェ 
                 イ障害によって、明らかにデータグラムが "ブラックホー 
                 ル" の中に消えていく可能性がある。この障害は、ユーザ 
                 に混乱を非常に招きやすく、ネットワーク部局によるデバッ
                 グが非常に困難である。

                 ゲートウェイ障害検出メカニズムは、ホストや第一ホップ 
                 ゲートウェイに受け入れられない負荷の要因になってはな 
                 らない。ゲートウェイ障害検出のタイムスケジュールや受 
                 け入れられる負荷についての正確な制約は、ホストの目的 
                 の性質によって幾分変わるかもしれないが、ホストは通常、
                 代替ゲートウェイが選択できる前にトランスポート層のコ 
                 ネクションが破棄されない程度の早さで、障害になった第 
                 一ホップゲートウェイを検出する必要がある。

                 プロトコルスタックの他の層からアドバイスを渡すことは 
                 層間のインタフェースを複雑にするが、それはゲートウェ 
                 イ障害検出の望ましいアプローチである。アドバイスは
                 IP/TCP 体系のほぼ全ての部分から来れるが、主にトランス
                 ポート層とリンク層から来ることが期待される。これは、 
                 ゲートウェイのアドバイスのためのあり得る送信元である。

                 o    TCP やコネクション型トランスポートプロトコルは、
                      否定的なアドバイスを与えられるべきである。例えば
                      過渡の再送がトリガになる。

                 o    TCP は (新たな) データを確認する時、肯定的ななア
                      ドバイスを与えてもよい。たとえ経路は非対称かもし
                      れなくても、新たなデータの ACK は確認されたデー 
                      タが正常に送信されたに違いないことを証明する。

                 o    特定のゲートウェイからの ICMP リダイレクトメッセ
                      ージは、ゲートウェイについての肯定的なアドバイス
                      として使用すべきである。

                 o    信頼性をもってホスト障害を検出し通知するリンク層
                      情報 (例えば ARPANET 宛先障害メッセージ) は、否 
                      定的なアドバイスとして使用すべきである。

                 o    ARP 障害や ARP マッピングの再評価は、対応する IP
                      アドレスの否定的なアドバイトとして使用してもよい。

                 o    特定のリンク層アドレスからのパケットの到着は、こ
                      のアドレスのシステムが活性である証拠である。しか
                      し、この情報をゲートウェイに関するアドバイスに換
                      えるには、リンク層アドレスを IP アドレスにマッピ
                      ングする必要があり、経路キャッシュによって指し示
                      されているゲートウェイに対する IP アドレスをチェッ
                      クする必要がある。これは、恐らく極めて非効率的だ
                      ろう。

                 受信した全てのデータグラムに対して肯定的なアドバイス 
                 を与えると、実装体に受け入れられない負荷の要因になる 
                 かもしれないことに注意されたい。

                 アドバイスは、IP 層への全てのインタフェースに必要なア
                 ーギュメントを使用して渡されるが、幾つかのトランスポ 
                 ートとアプリケーション層プロトコルは正しいアドバイス 
                 を導き出すことができない。従って、これらのインタフェ 
                 ースはアドバイスに対して中立の値を許さなければならな 
                 い。なぜなら、常に肯定的や常に否定的なアドバイスは不 
                 正な動作を導くからである。

                 一般的に使用されているが推奨されない、ゲートウェイ障 
                 害検出のための別の技術が存在する。この技術は、ゲート 
                 ウェイがお互いにブロードキャストしているインターネッ 
                 トゲートウェイプロトコル (IGP) のデータグラムを、受動
                 的に受信 ("盗聴") するホストに依存する。このアプロー 
                 チには、ゲートウェイが使用してもよい ([INTRO:2] 参照)
                 全ての内部ゲートウェイプロトコルを、ホストが解釈する 
                 必要があるという欠点がある。加えて、ブロードキャスト 
                 ネットワーク上でしか働かない。

                 現在、ping (すなわち ICMP エコーメッセージの使用) は、
                 ゲートウェイプローブのために絶対的に必要とされるメカ 
                 ニズムである。ping が成功すれば、アドレスを持つインタ
                 フェースと、それが割り付けられたマシンの起動が保証さ 
                 れる。しかし、そのマシンがホストに対するゲートウェイ 
                 であることは保証しない。もしリダイレクトや他の証拠が、
                 マシンがゲートウェイであることを示していれば、ping の
                 正常は、そのマシンが起動していてさらにゲートウェイで 
                 あることを示すというのが、一般的な推定である。しかし 
                 ホストは、ゲートウェイが転送かリダイレクトするパケッ 
                 トを黙って破棄するので、この仮定は時々失敗する。この 
                 問題を避けるためには、開発中の新たな ICMP メッセージ 
                 が "あなたはゲートウェイか ?" を尋ねるだろう。

            IMPLEMENTATION:
                 以下の特定のアルゴリズムが提案されている。

                 o    経路キャッシュによって指し示されている各々のゲー
                      トウェイに、"再振り分けタイマ" を割り当てる。そ 
                      のタイマの初期値 Tr は、トランスポートコネクショ
                      ンがタイムアウトする前にゲートウェイ障害を検出で
                      きるくらい小さい値でなければならない。

                 o    肯定的なアドバイスを受けたら、再振り分けタイマを
                      Tr に再設定する。否定的なアドバイスを受けたら、 
                      再振り分けタイマを減らすか 0 にする。

                 o    IP 層がデータグラムを振り分けるために特定のゲー 
                      トウェイを使用したら、必ず対応する再振り分けタイ
                      マをチェックする。もしタイマが満了したら (0 にな
                      ったら)、IP 層はゲートウェイに ping を送信し、直
                      後にデータグラムを送信する。

                 o    ping (ICMP エコー) は必要ならば最大 N 回送信され
                      るだろう。もし N 回試みた ping の応答が全くなけ 
                      れば、そのゲートウェイは障害であると仮定し、障害
                      のあるゲートウェイを指し示している全てのキャッシュ
                      エントリに対して、新しい第一ホップゲートウェイを
                      選択する。

                 Tr の大きさは利用可能なアドバイスの量に反比例する。Tr
                 は、以下を保証する大きさにすべきであることに注意され 
                 たい。

                 *    いかなる ping も、ホストからゲートウェイに送信さ
                      れる全てのパケットよりも低い割合 (例えば 10% 以 
                      下) である。

                 *    ping はめったに起こらない (例えば 3 分毎)

                 推奨されているアルゴリズムは、キャッシュエントリ自身 
                 ではなく、経路キャッシュエントリによって指し示されて 
                 いるゲートウェイに関係するので、二つのレベルのデータ 
                 構造 (恐らく ARP と同等かキャッシュに似ている) が経路
                 キャッシュを実装するために望ましいかもしれない。

         3.3.1.5 新たなゲートウェイ検出

            もし障害ゲートウェイが現在のデフォルトでなければ、IP 層は 
            即座にデフォルトゲートウェイに切り替えることができる。もし
            障害が起きたのが現在のデフォルトならば、IP 層は障害のある 
            経路に対して新しい経路を確立するために、異なるデフォルトゲ
            ートウェイ (一つ以上のデフォルトを知っていることを想定) を
            選択しなければならない (MUST)。

            DISCUSSION:
                 ゲートウェイが障害になった時、接続されたネットワーク 
                 上の他のゲートウェイは、何らかの内部ゲートウェイルー 
                 ティングプロトコルを通じて障害のことを知るだろう。し 
                 かしこれは即座に行われるわけではない。なぜならゲート 
                 ウェイルーティングプロトコルは、技術的に通常 30 〜 60
                 秒の調整時間を持つからである。もしゲートウェイが障害 
                 に応諾する前に、ホストが代替ゲートウェイに切り替えた 
                 ら、新しい対象ゲートウェイは恐らく、データグラムを障 
                 害の起きたゲートウェイに転送し、障害ゲートウェイを指 
                 し示しているホストにリダイレクトを返送するだろう (!)。
                 ゲートウェイの調整時間の間、ホスト経路キャッシュの内 
                 容に急速な揺れが結果的に生じるだろう。こうした揺れを 
                 避けるために、ゲートウェイ障害のロジックはヒステリシ 
                 スメカニズムを含むべきであると提案されている。しかし、
                 経験上ではそうした揺れによる害は見られていない。なぜ 
                 なら、ゲートウェイのルーティング情報が障害を解決する 
                 まで、ホストのサービスが復旧できないからである。

            IMPLEMENTATION:
                 新たなデフォルトゲートウェイを選択する一つの実装技術 
                 は、ホストの一覧中のデフォルトゲートウェイを単純にラ 
                 ウンドロビンすることである。もう一つの方法は、ゲート 
                 ウェイを優先度順でランク付けし、現在のゲートウェイが 
                 優先度の最も高いものでない時、より優先度の高いゲート 
                 ウェイがサービスを回復したことを検出するために、それ 
                 らにゆっくりと "ping" することである。この ping は、 
                 非常に低いレート、例えば 1 秒間に 0.005 回で行うこと 
                 ができる。

         3.3.1.6 初期化

            以下の情報は設定可能でなければならない (MUST)。

            (1) IP アドレス

            (2) アドレスマスク

            (3) 優先度レベルを持つデフォルトゲートウェイの一覧

            この設定データを手動で入力する方法を提供しなければならない
            (MUST)。さらに、この情報を動的に決めるために複数の方法を用
            いることができる。[INTRO:1] の "ホスト初期化" のセクション
            を参照されたい。

            DISCUSSION:
                 あるホスト実装は、どのゲートウェイが存在するかを知る 
                 ために、ブロードキャストネットワーク上でのゲートウェ 
                 イプロトコルの "盗聴" を使用している。デフォルトゲー 
                 トウェイ検出のための標準的な方法は作成中である。

      3.3.2 組立

         IP 層は IP データグラムの組立を実装しなければならない (MUST)。

         我々は、EMTU_R (効率的な受信 MTU) によって組立てられる最大の 
         データグラム長を明示している。これは時々、"組立バッファ長" と
         呼ばれる。EMTU_R は 576 以上でなければならない (MUST)、あるい
         は設定可能であるか無限にすべきである (SHOULD)、あるいは接続さ
         れたネットワークの MTU 以上であるべきである (SHOULD)。

         DISCUSSION:
              幾つかのアプリケーション層プロトコルは、576 よりも大きい
              EMTU_R 値を必要とするので、EMTU_R を固定値に制限すること
              はコードに組み込むべきではない。

         IMPLEMENTATION:
              実装体は、各々のデータグラムで隣接する組立バッファを使用
              してもよいし、組立てられたデータグラム長に明確な制限をか
              けない、より複雑なデータ構造を使用してもよい。後者のケー
              スの場合、EMTU_R は "無限" であると言われる。

              論理的に、組立は各々のフラグメントを、パケットバッファに
              適切なオフセットで単純にコピーすることによって実現される。
              継続的な再送において、パケット化は異なるが同じ組立て Id 
              を使用するならば、フラグメントは部分的に重複してもよい。

              組立の巧妙な部分は、データグラムの全てのバイトの組立が完
              了した時を決めるための記録方式である。記録方式のためにデ
              ータ空間を追加する必要のない Clark のアルゴリズム [IP:10]
              を推奨する。しかし [IP:10] とは反対に、一番目のフラグメ 
              ントヘッダは、起こり得る ICMP 時間超過 (組立タイムアウ  
              ト) メッセージに含めるために保存する必要がある。

         トランスポート層が MMS_R、受信して IP データグラムに組立てら 
         れる最大メッセージ長、を知ることができるメカニズムが存在しな 
         ければならない (MUST) (セクション 3.4 の GET_MAXSIZES を参照 
         されたい)。もし EMTU_R が無限でないならば、MMS_R の値は以下に
         よって算出される。

            MMS_R = EMTU_R - 20

         なぜなら、20 は IP ヘッダの最小値だからである。

         組立タイムアウトは存在しなければならない (MUST)。組立タイムア
         ウト値は、残りの TTL から設定するのではなく固定値にすべきであ
         る (SHOULD)。その値は 60 秒から 120 秒までの間にすることが推 
         奨される。もしこのタイムアウトが満了したら、部分的に組立てた 
         データグラムは破棄し、(もしフラグメント 0 を受信していたら)  
         送信元ホストに ICMP 時間超過メッセージを送信しなければならな 
         い (MUST)。

         DISCUSSION:
              IP 規約は、組立タイムアウトは IP ヘッダから取得する残り 
              の TTL であるべきと述べているが、ゲートウェイは通常 TTL 
              を所要時間ではなく単純なホップ数として扱うので、これはう
              まく働かない。もし組立タイムアウトが小さ過ぎると、データ
              グラムは不必要に破棄され、通信が失敗するだろう。少なくと
              もタイムアウトは、インターネットに渡る典型的な最大遅延の
              同程度の大きさである必要がある。現実的な最小組立タイムア
              ウトは 60 秒だろう。

              キャッシュを、トランスポートプロトコルが様々な宛先に対し
              て計測するラウンドトリップ時間保持し、これらの値を効率的
              な組立タイムアウト値を動的に決めるために使用することが提
              案されている。このアプローチについては、さらに検討が必要
              である。

              もし組立タイムアウトの設定値が大き過ぎると、受信側ホスト
              のバッファ資源の拘束時間が長過ぎて、MSL (最大セグメント 
              生存時間) [TCP:1] が必要よりも大きくなるだろう。MSL は最
              大レートを制御し、それで分割されたデータグラムを 16 ビッ
              トの Ident フィールドの異なる値を使用して送信できる。大 
              きい MSL は最大レートを低下させる。TCP [TCP:1] 規約は、 
              任意に MSL として 2 分の値を想定している。これは、効率的
              な組立タイムアウト値の上限を設定する。

      3.3.3 分割

         オプションで IP 層は、出力データグラムを意図的に分割するため 
         のメカニズムを実装してもよい (MAY)。

         IP 送信元と宛先アドレスとおそらく TOS のある特定の組み合わせ 
         に対して送信してもよい IP データグラムの最大長を、EMTU_S ("有
         効送信 MTU : effective MTU for sending") として示す。

         ホストは、トランスポート層が所定の {送信元、宛先、TOS} の三つ
         の組み合わせ (セクション 3.4 GET_MAXSIZES 呼び出し参照) に対 
         して送信してもよい MMS_S、最大トランスポート層メッセージ長を 
         認識することができるメカニズムを実装しなければならない (MUST)。
         もしローカルな分割が行われなければ、 MMS_S の値は以下の通り。

            MMS_S = EMTU_S - 

         そして、EMTU_S はデータグラムの送信元アドレスに対応するネット
         ワークインタフェースの MTU 以下でなければならない。もし IP が
         トランスポート層によって挿入された幾つかのオプションに加え、 
         自身の目的のために IP オプションを挿入するための空間を確保し 
         なければ、この式にある  は 20 である。

         ローカルな分割を実装しないホストは、トランスポート層 (TCP の 
         場合) かアプリケーション層 (UDP の場合) が IP 層から MMS_S を
         取得し、MMS_S の長さを超えるデータグラムを送信しないことを保 
         証しなければならない (MUST)。

         ローカルな分割を避け、パス沿いの全てのゲートウェイにおいて分 
         割を避けられるサイズの EMTU_S を選択することが一般的に望まし 
         い。パス沿いの最小 MTU を実際に知らない場合、IP 層は、宛先ア 
         ドレスが接続されたネットワーク上に存在しない時は必ず 
         EMTU_S <= 576 を使用すべきであり、存在する場合は接続されたネッ
         トワークの MTU を使用すべきである (SHOULD)。

         各々の物理インタフェースの MTU は、設定可能でなければならない
         (MUST)。

         ホスト IP 層実装は "全サブネット MTU" という設定フラグを所持 
         してもよい (MAY)。それは、他のネットワークではなく同じネット 
         ワーク内の異なるサブネット上の宛先のために使用すべき、接続さ 
         れたネットワークの MTU を示す。従ってこのフラグは EMTU_S を選
         択するために、サブネットアドレスマスクではなくネットワークク 
         ラスのマスクを使用させる。マルチホーム化されたホストでは、各 
         々のネットワークインタフェースに対して "全サブネット MTU" フ 
         ラグが必要である。

         DISCUSSION:
              データ送信時に使用するための正しいデータグラム長を抽出す
              ることは、複雑な話題である [IP:9]。

              (a) 通常、ホストは (ヘッダとデータを含めて) 576 バイトよ
                  りも大きい IP データグラムを受け入れる必要がない。よ
                  って、宛先ホストに関する明示的な知識や事前の調整なし
                  で、ホストはより大きなデータグラムを送信してはならな
                  い。従って、MMS_S はトランスポート層プロトコルが送信
                  してもよいデータグラム長の上位境界のみである。たとえ
                  MMS_S が 556 を超える場合でも、トランスポート層は宛 
                  先ホストに関する知識がないならば、メッセージを 556  
                  バイトに制限しなければならない。

              (b) あるトランスポートプロトコル (たとえば TCP) は、他方
                  の終端が受信して組立てることができる最大データグラム
                  について、明示的に送信者に通知するための方法を提供す
                  る [IP:7]。それに相当するメカニズムは IP 層には存在 
                  しない。

                  576 より大きい EMTU_R を想定するトランスポートプロト
                  コル (セクション 3.3.2 参照) は、同じプロトコルを実 
                  装しているもう一方のホストに、より大きなサイズのデー
                  タグラムを送信することができる。

              (c) 理想的にホストは、所定の宛先に対する EMTU_S を、いか
                  なる分割も避けるためにパス沿いの全ネットワークの最小
                  MTU に制限すべきである。IP 分割は規則上は正しいが、 
                  一つのフラグメントの損失が、セグメント中の全てのフラ
                  グメントを再送しなければならないことを意味するので、
                  重大なトランスポートプロトコルのパフォーマンス問題を
                  起こし得る [IP:9]。

              インターネットにおけるほぼ全てのネットワークは現在、576 
              かそれ以上の MTU をサポートしているので、非ローカルネッ 
              トワークに送信するデータグラムの場合、576 を使うことを強
              く推奨する。

              ホストは所定のパス上の MTU を、0 オフセットのデータグラ 
              ムフラグメントを送信し、受信側が組立をタイムアウトする  
              (それは完結できない!) のを待ち、ICMP 時間超過メッセージ 
              を返却することによって決定できることが提案されている。こ
              のメッセージは、最も大きい残存するフラグメントヘッダを本
              体部に含む。より直接的な方法が実験されているが、まだ採用
              はされていない (例えば RFC1063 参照)。

      3.3.4 ローカルなマルチホーム化

         3.3.4.1 導入

            マルチホーム化されたホストは複数の IP アドレスを持つ。それ
            は "論理インタフェース" としてのものであると考えてもよい。
            論理インタフェースは、一つ以上の物理インタフェースに結び付
            いてもよく、これらの物理インタフェースは同じか別のネットワ
            ークに接続してもよい。

            以下は、マルチホーム化の重要なケースである。

            (a) 複数の論理ネットワーク

                インターネット体系は、各々の物理ネットワークが単一の  
                IP ネットワーク (あるいはサブネット) 番号を持つことを 
                想定している。しかし、LAN 管理者は時々この想定を破って、
                物理的に接続されたネットワークにつき複数の論理ネットワ
                ークを持つ LAN を運用することが効果的であると認識しつ 
                つある。

                もしそのようなネットワークに接続されたホストが、N 個の
                異なる論理ネットワークの各々のトラフィックを処理するよ
                う設定されたら、ホストは N 個の論理ネットワークを持つ 
                だろう。これらは単一の物理インタフェースを共有すること
                ができるか、あるいは同じネットワークへの N 個の異なる 
                物理インタフェースを使用してもよい。

            (b) 複数の論理ホスト

                ホストが、全てが同じ <ネットワーク番号> 部 (と、もしあ
                れば、同じ <サブネット番号> 部) を持つ複数の IP アドレ
                スを持つ場合、その論理インタフェースは "論理ホスト" と
                呼ばれる。これらの論理インタフェースは、一つの物理イン
                タフェースを共有してもよいし、同じ物理ネットワークへの
                別々の物理インタフェースを使用してもよい。

            (c) 単純なマルチホーム

                この場合、各論理インタフェースは別々の物理インタフェー
                スにマッピングされ、各物理インタフェースは異なる物理ネッ
                トワークに接続される。"マルチホーム化" という用語は、 
                元々このケースにのみ適用されていたが、現在はより一般的
                に適用されている。

                組み込みゲートウェイ機能を持つホストは、一般に単純なマ
                ルチホーム化のケースに相当する。しかし、ホストは組み込
                みゲートウェイを含まずに、すなわちデータグラムを一方の
                接続ネットワークからもう一方に転送せずに、単にマルチホ
                ーム化してもよいことに注意されたい。

                このケースは、最も難しいルーティング問題をもたらす。イ
                ンタフェースの選択 (すなわち第一ホップネットワークの選
                択) は、パフォーマンスやインターネットの外部の到達可能
                性にさえ、重大な影響を与えるかもしれない。

            最後に、マルチホーム化ではないもう一つの可能性を注記する。
            直接接続されたマシン間に代替物理パスを提供することによって、
            それらの間の信頼性やスループットを上げるために、一つの論理
            インタフェースを複数の物理インタフェースに結び付けてもよい
            例えば、二つのシステムは複数のポイントツーポイント回線によ
            って接続してもよい。これは "リンク層多重化" と呼ばれる。リ
            ンク層多重化では、リンク層上のプロトコルは複数の物理インタ
            フェースが提供されていることを知らない。リンク層のデバイス
            ドライバが、多重化と物理インタフェースを渡るパケットのルー
            ティングに責任を持つ。

            インターネットプロトコル体系では、トランスポートプロトコル
            のインスタンス ("エンティティ") は自身のアドレスを持たない
            が、代わりに一つのインターネットプロトコル (IP) アドレスを
            使用する。これは IP、トランスポート、アプリケーション層、 
            それらの間のインタフェースに密接な関係を持つ。特にアプリケ
            ーションソフトウェアは、マルチホーム化されたホストの複数の
            IP アドレスを知らなければならないかもしれない。その他の場 
            合はネットワークソフトウェアの中で選択できる。

         3.3.4.2 マルチホーム化の要件

            マルチホーム化されたホストからデータグラムを送信する際に、
            以下の一般的な規則が IP 送信元アドレスの選択に適用される。

            (1) もし、受信したデータグラムの応答としてデータグラムを送
                信するならば、その応答の送信元アドレスは要求の特定宛先
                のアドレスとすべきである (SHOULD)。上位層におけるより 
                特定の要件については、セクション 4.1.3.5 とセクション 
                4.2.3.7 と [INTRO:1] の "一般的な問題" のセクションを 
                参照されたい。

                さもなくば、送信元アドレスを選択しなければならない。

            (2) アプリケーションは、コネクションか要求を起動するために
                送信元アドレスを明示的に指定できなければならない      
                (MUST)。

            (3) そのような規定が無いならば、ネットワークソフトウェアは
                一つの送信元アドレスを選択しなければならない。この選択
                の規則は、以下で説明されている。

            マルチホーム化に関連して、以下の二つの主要件の問題がある。

            (A) 
                ホストは、宛先アドレスが受信した際の物理インタフェース
                に対応していない入力データグラムを黙って破棄してもよい
                (MAY)。

            (B) 
                ホストは、データグラムの IP 送信元アドレスに対応する物
                理インタフェースを通る IP データグラムだけを送信するこ
                とに制限してもよい (MAY)。

            DISCUSSION:
                 インターネットホストの実装者は、マルチホーム化のため 
                 に二つの異なる概念的なモデルを使用した。それは、次の 
                 議論で詳しく要約化されている。このドキュメントは、ど 
                 のモデルが望ましいかという立場に立ってはいない。各々 
                 立場を持っているようである。この両面性が、(A) と (B) 
                 が任意であるという問題で反映されている。

                 o    強い ES モデル

                      強い ES (終端システム、すなわちホスト) モデルは、
                      ホスト/ゲートウェイ (ES/IS) の区別を強調する。従
                      って、上記 (A) と (B) の問題は、してもよい (MAY)
                      から、しなければならない (MUST) に代わる。それは、
                      同じ物理ホスト内の一セットの論理ホストとしてマル
                      チホーム化されたホストをモデル化する傾向がある。

                      (A) に関連して、強い ES モデルの提案者は、自動的
                      なインターネットルーティングメカニズムは、宛先ア
                      ドレスに対応しない物理インタフェースにデータグラ
                      ムを振り分けられないことを注意している。

                      強い ES モデルの下では、出力データグラムのための
                      経路算出は以下のマッピングである。

                         route(src IP addr, dest IP addr, TOS)
                                                        -> gateway

                      この場合、送信元アドレスは、対応する物理インタフェ
                      ース上で直接到達できるゲートウェイを選択するため
                      のパラメタとして含まれる。このモデルは、各々の  
                      IP アドレスに対して、少なくとも一つのデフォルト 
                      ゲートウェイが一般にあることを、複数のゲートウェ
                      イが存在することがむしろ望ましいことを論理的に要
                      求していることに注意されたい。

                 o    弱い ES モデル

                      この観点は、ES/IS の区別を強調しない。従って、  
                      (A) と (B) の問題は、してもよい (MAY) から、して
                      はならない (MUST NOT) に代わる。このモデルは、ゲ
                      ートウェイルーティングプロトコルを盗聴するホスト
                      にとって、より自然かもしれない。そして、ゲートウェ
                      イ機能が組み込まれたホストにとって必要である。

                      弱い ES モデルは、リダイレクトメカニズムを失敗さ
                      せるかもしれない。もしデータグラムが、宛先アドレ
                      スに対応していない物理インタフェースに送出された
                      ら、第一ホップゲートウェイは、いつリダイレクトを
                      送信する必要があるか分からないだろう。一方、もし
                      ホストが組み込みゲートウェイ機能を持っていれば、
                      リダイレクトを聞かずともルーティング情報を持って
                      いる。

                      弱い ES モデルでは、出力データグラムのための経路
                      算出は以下のマッピングである。

                         route(dest IP addr, TOS) -> gateway, interface

         3.3.4.3 送信元アドレスの選択

            DISCUSSION:
                 初期コネクション要求 (例えば TCP "SYN" セグメント) か、
                 データグラムサービス要求 (例えば UDP ベースのキュエ  
                 リ) を送信する時、マルチホーム化されたホスト上のトラ 
                 ンスポート層は、どの送信元アドレスを使用するかを知っ 
                 ている必要がある。もしアプリケーションがそれを指定し 
                 なければ、トランスポート層は概念的な以下のマッピング 
                 を実行して IP 層に尋ねなければならない。

                     GET_SRCADDR(remote IP addr, TOS)
                                               -> local IP address

                 ここでの TOS はサービスタイプの値 (セクション 3.2.1.6
                 参照) であり、その結果は望ましい送信元アドレスである。
                 このマッピングを実装するにあたり、以下の規則が提案さ 
                 れている。

                 (a) もし、リモートのインターネットアドレスが、ホスト 
                     が直接接続されている (サブ) ネットの一つの上に在 
                     るならば、対応するインタフェースがダウンしている 
                     ことを認識していなければ、対応する送信元アドレス 
                     を選択する。

                 (b) あるネットワークインタフェースを通じて、指定され 
                     た宛先ネットワークへの活性経路が存在するか否かを 
                     チェックするために、経路キャッシュを調べてもよい。
                     存在する場合、そのインタフェースに対応するローカ 
                     ル IP アドレスを選択する。

                 (c) もしあれば、同様に静的経路のテーブルを調べる (セ 
                     クション 3.3.1.2)。

                 (d) デフォルトゲートウェイを調べる。もしこれらのゲー 
                     トウェイが異なるインタフェースに割り当てられてい 
                     たら、最も優先度が高いゲートウェイに対応するイン 
                     タフェースを選択する。

                 将来、所定の宛先に対して使用する最善のネットワークに 
                 ついて、マルチホーム化されたホストが、接続された全て 
                 のネットワーク上のゲートウェイにアドバイスを依頼する 
                 ための、定義された方法があるかもしれない

            IMPLEMENTATION:
                 この処理はデータグラムルーティング (セクション 3.3.1 
                 参照) と本質的には同じであることに注意されたい。従っ 
                 て、ホストはこの二つの機能の実装を併用できるかもしれ 
                 ない。

      3.3.5 送信元経路の転送

         下記の制限を条件に、ホストは送信元経路内の中間ホップとして振 
         舞い、送信元経路付きデータグラムを指定された次のホップに転送 
         してもよい (MAY)。

         しかし、このゲートウェイ同様の機能を実行する際、ホストは送信 
         元経路付きデータグラムを転送するゲートウェイの全ての関連規則 
         [INTRO:2] に従わなければならない (MUST)。これは次の特定の機能
         を含み、このドキュメントで前に規定された、これに対応するホス 
         ト機能を上書きする

         (A) TTL (セクション 3.2.1.7 参照)

             TTL フィールドを減算し、ゲートウェイのために [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 参照)

              タイムスタンプオプションを含む送信元経路付きデータグラム
              を転送するホストは、このオプションの規則に従って、現在の
              タイムスタンプをそのオプションに追加しなければならない  
              (MUST)。

         送信元経路付きデータグラムのホスト転送を制限する規則を定義す 
         るために、もし次ホップがデータグラムが到達する際に同じ物理イ 
         ンタフェースを通るならば "ローカル送信元ルーティング" という 
         用語を、さもなくば "非ローカル送信元ルーティング" という用語 
         を使用する。

         o    ホストは何の制限も無く、ローカル送信元ルーティングを実行
              することが許される。

         o    非ローカル送信元ルーティングをサポートするホストは、転送
              を不可にするための設定可能なスィッチを持たなければならず
              (MUST)、デフォルトは転送不可でなければならない (MUST)。

         o    ホストは、非ローカル転送を制限する設定可能な指針フィルタ
              [INTRO:2] のための、全てのゲートウェイ要件を満たさなけれ
              ばならない (MUST)。

         もしホストが、完成していない送信元経路が付いているが、何らか 
         の理由により転送できないデータグラムを受信したら、ホストは   
         ICMP 宛先未到達メッセージ (コード 5、送信元経路障害) を返却す
         べきである (SHOULD)。

      3.3.6 ブロードキャスト

         セクション 3.2.1.3 は、4 つの IP ブロードキャストアドレス形式
         の標準を定義した。

           制限付きブロードキャスト: {-1, -1}

           直接ブロードキャスト: {<ネットワーク番号>, -1}

           サブネット直接ブロードキャスト:
                               {<ネットワーク番号>,<サブネット番号>,-1}

           全サブネット直接ブロードキャスト: {<ネットワーク番号>,-1,-1}

         ホストは、入力データグラムの宛先アドレスにおいて、これらのい 
         ずれの形式も認識しなければならない (MUST)

         -1 の代わりに 0 を用いる、非標準のブロードキャストアドレス形 
          式を使用するホスト* のクラスがある。全てのホストは、これらの
          非標準のブロードキャストアドレスを、入力データグラムの宛先ア
          ドレスとして認識して受け入れるべきである (SHOULD)。ホストは 
          オプションで、各物理インタフェースに対して、ブロードキャスト
          アドレスの 0 か -1 形式を選択するための設定オプションを持っ 
          てもよい (MAY)。しかし、このオプションはデフォルトで標準
          (-1) の形式にすべきである (SHOULD)。
_________________________
*4.2BSD Unix とその派生。4.3BSD にはない。

         ホストがデータグラムをリンク層ブロードキャストアドレスに送信 
         するとき、IP 宛先アドリスは正しい IP ブロードキャストか IP マ
         ルチキャストアドレスでなければならない (MUST)。

         ホストは、リンク層ブロードキャストを経て受信したが、IP マルチ
         キャストかブロードキャスト宛先アドレスを示していないデータグ 
         ラムを、黙って破棄すべきである (SHOULD) (セクション 2.4 参照)。

         ホストは、接続されたネットワークにブロードキャストするための 
         制限付きブロードキャストアドレスを使用すべきである (SHOULD)。

         DISCUSSION:
              直接ブロードキャストアドレスではなく制限付きブロードキャ
              ストアドレスを使用することは、システムの頑強性を改善する。
              問題は大抵、過多なブロードキャストアドレス (セクション  
              3.2.1.3 参照) を解釈しないマシンや、どのブロードキャスト
              アドレスを使用しているかについて異なる考えを持つマシンに
              よって引き起こされる。後者の主要な例は、サブネット化を解
              釈しないが、サブネット化されたネットに接続されているマシ
              ンである。接続されたネットワークでサブネットブロードキャ
              ストを送信すると、それらのマシンに混乱を及ぼし、他のホス
              トへのメッセージとしてそれを見る可能性がある。

              制限付きブロードキャストアドレス宛てのデータグラムを、マ
              ルチホーム化されたホストの全てのインタフェースから送信す
              べきか否かについて議論されている。この規約では、その問題
              について触れていない。

      3.3.7 IP マルチキャスト

         ホストは、クラス D の IP アドレスからリンク層アドレスへのマッ
         ピングが指定されている (下記参照) 全ての接続されたネットワー 
         ク上で、ローカルな IP マルチキャストをサポートすべきである   
         (SHOULD)。ローカルな IP マルチキャストのサポートは、マルチキャ
         ストデータグラムの送信やマルチキャストグループへの加入、マル 
         チキャストデータグラムの受信を含む。これは、オプションである 
         IGMP プロトコル自身を除き、[IP:4] の全てのサポートすることを 
         意味する。

         DISCUSSION:
              IGMP は、複数のネットワークに渡る IP マルチキャストをサ 
              ポートするために必要な情報を持つ、マルチキャストルーティ
              ングができるゲートウェイを提供する。この時点では、マルチ
              キャストルーティングゲートウェイは実験的な段階であり、広
              く利用できない。マルチキャストルーティングゲートウェイを
              持つネットワークに接続していないか、他のネットワーク上で
              起動されたマルチキャストデータグラムを受信する必要がない
              ホストにとっては、GMP の目的は無いので、現在はオプション
              である。しかし、ローカルブロードキャストアドレス付けの望
              ましい代替手段として、ローカルネットワークのマルチキャス
              トアドレスへ、IP 層によるアクセスを提供する目的のために、
              [IP:4] の残りの部分が現在推奨されている。マルチキャスト 
              ルーティングゲートウェイがより広く利用可能になった時、将
              来的には、IGMP が推奨されるようになるだろう。

         もし IGMP が実装されなければ、ホストは IP 層が初期化された時 
         に "全ホスト" グループ (224.0.0.1) に加入し、IP 層が活性であ 
         る間はメンバのままでいるべきである (SHOULD)。

         DISCUSSION:
              "全ホスト" グループへの加入は、たとえ IGMP が実装されて 
              いなくても、ゲートウェイ検出プロトコルなどの、厳密にロー
              カルなマルチキャストの使用をサポートするだろう。IP クラ 
              ス D アドレスとローカルアドレスのマッピングは、以下のタ 
              イプのネットワークについて規定されている。

         o    [IP:4] で定義されているイーサネット/IEEE 802.3

         o    ブロードキャストをサポートするが、マルチキャストをサポー
              トしていないネットワーク。IP クラス D アドレスは全て、ロ
              ーカルブロードキャストアドレスにマッピングされる。

         o    ポイントツーポイント回線 (SLIP や HDLC 回線など) のタイ 
              プ。マッピングの必要ない。全ての IP マルチキャストデータ
              グラムは、そのままローカルなフレームの中で送信される。

         他のタイプのネットワークでのマッピングは、将来規定される予定 
         である。

         ホストは、上位レベルプロトコルかアプリケーションが、接続され 
         たネットワークのどのホストが IP マルチキャストアドレスをサポ 
         ートしているかを決定する方法を提供すべきである (SHOULD)。

      3.3.8 エラー通知

         実用的である場合は必ず、ホストはエラー検出時に ICMP エラーデ 
         ータグラムを返却しなければならない (MUST)。ICMP エラーメッセ 
         ージの返却が明示的に禁止されている場合は除く。

         DISCUSSION:
              データグラムネットワークにおける共通的な現象は、"ブラッ 
              クホール状態" である。それは、データグラムは送出されるが、
              何も戻ってこないことである。エラーデータグラムが無ければ、
              ユーザが問題が何であるか見つけることが困難である。

   3.4 インターネット/トランスポート層インタフェース

      IP 層とトランスポート層の間のインタフェースは、オプションやサー 
      ビスタイプ、生存時間を含む、IP 層の全てのメカニズムへの完全なア 
      クセスを提供しなければならない (MUST)。トランスポート層は、これ 
      らのインタフェースパラメタを設定するためのメカニズムを持つか、ア
      プリケーションから渡すためのパスを提供しなければならない (MUST)。

      DISCUSSION:
           たとえそのメカニズムがインターネット (例えば TOS) は現在効 
           果を持たなくても、アプリケーションは適用可能なこれらのメカ 
           ニズムを使用することが推奨される。これにより、これらのメカ 
           ニズムが有効になった時に、ホストソフトウェアの大規模な改造 
           無しで、即座に効果を持つことができる。

      我々はここで、トランスポート層と IP 層との間の概念的なインタフェ
      ースを、手続き呼び出しのセットとして規定する。これは RFC791
      [IP:1] のセクション 3.3 の情報の拡張である。

      *    データグラムの送信

                SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt
                     => result )

           パラメタは RFC791 で定義されている。Id パラメタを渡すのはオ
           プションである。セクション 3.2.1.5 を参照されたい。

      *    データグラムの受信

                RECV(BufPTR, prot
                     => result, src, dst, SpecDest, TOS, len, opt)

           パラメタは、以下を除いて全て RFC791 で定義されている

                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

                (パラメタは 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 メッセージが上位に渡される。

           o    宛先未到達

           o    送信元損失

           o    エコー応答 (もしエコー要求が IP 層で起動されていなけれ
                ば、ICMP ユーザインタフェースに向けて)

           o    タイムスタンプ応答 (ICMP ユーザインタフェースに向けて)

           o    時間超過

      DISCUSSION:
           将来、このインタフェースに、IP 層とトランスポート層の間でパ
           スデータ (セクション 3.3.1.3 参照) を渡すことが追加されるか
           もしれない

   3.5 インターネット層要件要約


                                                 |        | | | |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
-------------------------------------------------|--------|-|-|-|-|-|--
                                                 |        | | | | | |
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:                                             |        | | | | | |
  0 の TTL を持つパケットの送信                  |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| | | | |
  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| | | | |
  完結した SR を持つデータグラムを TL に渡す     |3.2.1.8c|x| | | | |
  正しい (非冗長) 返却経路を生成                 |3.2.1.8c|x| | | | |
  複数の SR オプションを一つのヘッダで送信       |3.2.1.8c| | | | |x|
                                                 |        | | | | | |
ICMP:                                            |        | | | | | |
未知のタイプの ICMP メッセージを黙って破棄       |3.2.2   |x| | | | |
  元のデータグラムの 8 オクテット以上を含める    |3.2.2   | | |x| | |
      受信したものと同じオクテットを含める       |3.2.2   |x| | | | |
  ICMP エラーをトランスポートプロトコルに demux  |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| | | | |
    エコークライアント                           |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
    TS 応答の送信元として特定のアドレスを使用    |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| | | |
    初期化時に Adr Mask 応答をブロードキャスト   |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| |
  絶え間無くゲートウェイを 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| | | | |
  オフネットの宛先には最大 576 で送信            |3.3.3   | |x| | | |
  全サブネット MTU 設定フラグ                    |3.3.3   | | |x| | |
                                                 |        | | | | | |
マルチホーム化:                                  |        | | | | | |
  特定の宛先アドレスと同じアドレスで応答         |3.3.4.2 | |x| | | |
  アプリがローカル IP アドレスを選択可能         |3.3.4.2 |x| | | | |
  "誤った" インタフェースの d'gram を黙って破棄  |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
    非ローカル SRing の gwy アクセス規則を満たす |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| | | | |
  リンク層 b'cast で IP b'cast/m'castアドレス使用|3.3.6   |x| | | | |
  リンク層のみの b'cast データグラムを黙って破棄 |3.3.6   | |x| | | |
  接続ネットで制限付き b'cast アドレス使用       |3.3.6   | |x| | | |
                                                 |        | | | | | |
マルチキャスト:                                  |        | | | | | |
  ローカル 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) 組込みゲートウェイ機能を持たないか、送信元経路でないならば


4. トランスポートプロトコル

   4.1 ユーザデータグラムプロトコル - UDP

      4.1.1 導入

         ユーザデータグラムプロトコル UDP [UDP:1] は、最小限のトランス
         ポートサービスのみ - 保証無しのデータグラム送信 - を提供し、 
         アプリケーションが IP 層のデータグラムサービスに直接アクセス 
         する手段を与える。UDP は TCP のサービスレベルを必要としない、
         あるいは TCP からは利用できない通信サービス (マルチキャストや
         ブロードキャスト送信など) を使用したいアプリケーションによっ 
         て使用される。

         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)。

            DISCUSSION:
                 現在、UDP を通じて渡す必要がある唯一のオプションは、 
                 送信元経路、経路記録、タイムスタンプである。しかし、 
                 将来新しいオプションが定義されるかもしれず、UDP はア 
                 プリケーションとやりとりするオプションの形式や内容を 
                 仮定する必要はないし、仮定すべきではない。ただし、IP 
                 層のセキュリティオプションについては例外である。

                 UDP に基づくアプリケーションは、要求データグラムから 
                 送信元経路を獲得し、それに対応する応答を送信するため 
                 に、反転した経路を提供する必要があるかもしれない。

         4.1.3.3 ICMP メッセージ

            UDP は、IP 層から受信した全ての ICMP エラーメッセージをア 
            プリケーション層に渡さなければならない (MUST)。少なくとも 
            概念上は、ERROR_REPORT ルーチンへの upcall で実現してもよ 
            い (セクション 4.2.4.1 参照)。

            DISCUSSION:
                 UDP データグラムの送信により発生した ICMP エラーメッ 
                 セージは、非同期で受信されることに注意されたい。ICMP 
                 エラーメッセージの受信を望む UDP ベースのアプリケーショ
                 ンは、これらのメッセージが到着した時に、これらを多重 
                 分離するのに必要な状態を保持する責任がある。例えばア 
                 プリケーションは、この目的のために受信処理をペンディ 
                 ングし続けてもよい。またアプリケーションは、前に同じ 
                 ポートを使用して生じた、遅れた ICMP エラーメッセージ 
                 による混乱を回避する責任がある。

         4.1.3.4 UDP チェックサム

            ホストは、UDP チェックサムの生成と評価を行う機能を実装しな
            ければならない (MUST)。UDP チェックサムを生成するか否かに 
            ついては、アプリケーションが任意に制御できてもよい (MAY)  
            が、デフォルトはチェックサム有りでなければならない (MUST)。

            もし、0 でなく正しくないチェックサムが付与された UDP デー 
            タグラムを受信したら、UDP はそのデータグラムを黙って破棄し
            なければならない (MUST)。チェックサムの無い UDP データグラ
            ムを破棄すべきか、アプリケーションに渡すかについては、アプ
            リケーションが任意に制御できてもよい (MAY)。

            DISCUSSION:
                 ローカルエリアネットワーク内でしか実行されない幾つか 
                 のアプリケーションは、効率化のために UDP チェックサム
                 無しを選択した。UDP チェックサム無しの正当性について 
                 は、これまで非常に多く議論されている。

            IMPLEMENTATION:
                 UDP チェックサムには、共通的な実装誤りがある。TCP    
                 チェックサムとは異なり、UDP チェックサムはオプション 
                 である。チェックサムが無いことを示すために、UDP ヘッ 
                 ダのチェックサムフィールドで値 0 が送信される。もし送
                 信側が実際に 0 の UDP チェックサムを算出したら、全て 
                 1 (65535) にしてチェックサムを送信しなければならない。
                 0 と 65535 は 1 の補数計算では等しいので、受信側で特 
                 殊な動作は必要無い。

         4.1.3.5 UDP マルチホーム

            UDP データグラムを受信したとき、その特定宛先アドレスはアプ
            リケーション層に渡さなければならない (MUST)。

            アプリケーションプログラムは、UDP データグラムの送信で使用
            するために、IP 送信元アドレスを指定できるか、あるいは未指 
            定に (その場合、ネットワークソフトウェアが適切な送信元アド
            レスを選択するだろう) できなければならない (MUST)。選択さ 
            れた送信元アドレスをアプリケーション層に通知する方法が存在
            すべきである (SHOULD)。(例えば、アプリケーションは後で、対
            応するインタフェースからのみ応答データグラムを受信できる)。

            DISCUSSION:
                 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)。従って、
         UDP を使用するアプリケーションは、このドキュメントのセクショ 
         ン 3.4 で規定されている、GET_SRCADDR(), GET_MAXSIZES(),      
         ADVISE_DELIVPROB(), RECV_ICMP() 呼び出しの機能を必要とする。 
         例えば、{インタフェース、リモートホスト、TOS} の三つの特定の 
         組で、有効な最大の UDP 最大データグラム長を知るために、      
         GET_MAXSIZES() を使うことができる。

         アプリケーション層プログラムは、送信する UDP データグラムの  
         IP オプションだけでなく、TTL と TOS 値も設定できなければなら 
         ず (MUST)、これらの値は透過的に IP 層に渡さなければならない。
         UDP は受信した TOS をアプリケーション層まで渡してもよい (MAY)。

      4.1.5 UDP 要件要約


                                                 |        | | | |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
-------------------------------------------------|--------|-|-|-|-|-|--
                                                 |        | | | | | |
    UDP                                          |        | | | | | |
-------------------------------------------------|--------|-|-|-|-|-|--
                                                 |        | | | | | |
UDP がポート未到達を送信                         |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| | | | |
 - アプリ層がローカル IP アドレスを指定可能      |4.1.3.5 |x| | | | |
 - アプリ層が wild ローカル 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| | |


   4.2 転送制御プロトコル -- TCP

      4.2.1 導入

         転送制御プロトコル TCP [TCP:1] は、インターネットスイートの基
         本的な仮想回線トランスポートプロトコルである。TCP は信頼性が 
         あり順序正しい、オクテット (8 ビットバイト) の全二重ストリー 
         ムの送信を提供する。TCP は、信頼性のあるコネクション型トラン 
         スポートサービス、例えばメール (SMTP)、ファイル転送 (FTP)、仮
         想端末サービス (Telnet) 等を必要とするアプリケーションによっ 
         て使用される。これらのアプリケーション層プロトコルに対する要 
         件は、[INTRO:1] で規定されている。

      4.2.2 プロトコルウォークスルー

         4.2.2.1 よく知られたポート: RFC-793 セクション 2.7

            DISCUSSION:
                 TCP は、0 〜 255 の範囲のポート番号を "よく知られた" 
                 ポートとして予約し、そのポートはインターネット全体で 
                 標準化されているサービスにアクセスするために使用され 
                 る。ポート空間の残りは、アプリケーションプロセスに自 
                 由に割り当てることができる。現在のよく知られたポート 
                 定義は、"番号割り当て" [INTRO:6] というタイトルの RFC
                 で一覧化されている。新しいよく知られたポートを定義す 
                 るための必要条件は、新しい実装を可能にするために提案 
                 されたサービスを、十分詳細に RFC でドキュメント化する
                 ことである。

                 幾つかのシステムは、TCP ポート空間、予約ポートの三つ 
                 目の区分を追加することによって、この規定を拡張してい 
                 る。それは通常、オペレーティングシステム特有のサービ 
                 スとして使用される。例えば予約されたポートは、256 か 
                 らシステムに依存する上限値の間にあるかもしれない。幾 
                 つかのシステムは更に、それらのポートの値で TCP コネク
                 ションをオープンすることを特権ユーザにのみ許可するこ 
                 とによって、よく知られ、予約されたポートを保護するこ 
                 とを選択する。これは、全てのホストがそれらの低い番号 
                 のポートをこの方法で保護するとは仮定しない限り、完全 
                 に効率的である。

         4.2.2.2 プッシュの使用: RFC-793 セクション 2.8

            アプリケーションが、一連の SEND 呼び出しを PUSH フラグを設
            定せずに発行する時、TCP はそれを送信せずに、内部でデータを
            集めてもよい (MAY)。同様に、PSH ビットの無い一連のセグメン
            トを受信した時、TCP は受信するアプリケーションには渡さずに、
            内部的にデータをキューイングしてもよい (MAY)。

            PSH ビットはレコードマーカではなく、セグメント境界には依存
            しない。あり得る最長のセグメントを送信するために、送信側は
            データをパケット化する時、継続する PSH ビットを破棄すべき 
            である (SHOULD)。

            TCP は、SEND 呼び出し上で PUSH フラグを実装してもよい     
            (MAY)。もし PUSH フラグが実装されていなければ、送信側 TCP 
            は (1) データをいつまでもバッファに溜めこんではならず、(2)
            最後にバッファ溜めたセグメントに PSH ビットを設定しなけれ 
            ばならない (MUST) (例えば、キューイングされた送信すべきデ 
            ータがもう存在しないとき)。

            RFC-793 のページ 48, 50, 74 での議論は、受信した PSH フラ 
            グをアプリケーション層に渡さなければならないことを誤って意
            味している。受信した PSH フラグをアプリケーション層に渡す 
            ことは、現在オプション (OPTIONAL) である。

            アプリケーションプログラムは、通信デッドロックを避けるため
            にデータの配送を強制する必要があるときは常に、論理的に    
            SEND 呼び出しで PUSH フラグを設定する必要がある。しかしパ 
            フォーマンスを向上するために (セクション 4.2.3.4 参照)、  
            TCP は可能であれば常に最大長のセグメントを送信すべきである
            (SHOULD)。

            DISCUSSION:
                 SEND 呼び出しで PUSH フラグを実装していない場合、例え
                 ば、アプリケーション/TCP インタフェースが純粋なストリ
                 ーミングモデルを使用している場合、効率的なサイズのセ 
                 グメントを生成するために小さなデータフラグメントを集 
                 める責任は、部分的にアプリケーション層が負う。

                 通常、対話型アプリケーションプロトコルは、各コマンド 
                 や応答シーケンスで、少なくとも最後の SEND 呼出しでは 
                 PUSH フラグを設定しなければならない。FTP のような大量
                 転送プロトコルは、ファイルの最後のセグメントや、バッ 
                 ファのデッドロックを避ける必要がある場合に PUSH フラ 
                 グを設定すべきである。

                 受信側では、PSH ビットにより、バッファに溜まったデー 
                 タをアプリケーションに強制的に配送する (たとえバッファ
                 が一杯になるまで受信していなくても)。逆に PSH ビット 
                 を付与しないことは、アプリケーションプロセスを呼び起 
                 こす不要な呼び出しを避けるために使用できる。これは大 
                 規模なタイムシェアリングホストにとって、重要なパフォ 
                 ーマンスの効率化となりえる。PSH ビットを受信側アプリ 
                 ケーションに渡すことにより、アプリケーション内で同様 
                 な効率化が可能になる。

         4.2.2.3 ウィンドウサイズ: RFC-793 Section 3.1

            ウィンドウサイズは符号無し整数として扱わなければならない  
            (MUST)。さもなくば大きなウィンドウサイズは負のウィンドウと
            して見え、TCP は動かないだろう。実装体はコネクションレコー
            ド中の送受信ウィンドウサイズに対して 32 ビットフィールドを
            確保し、全てのウィンドウ算出を 32 ビットで行うことが推奨さ
            れる (RECOMMENDED)。

            DISCUSSION:
                 TCP ヘッダのウィンドウフィールドは、高速で遅延の大き 
                 いパスでは小さ過ぎることが判明している。ウィンドウサ 
                 イズを拡張するために、実験的な TCP オプションが定義さ
                 れている。例として [TCP:11] を参照されたい。そのよう 
                 な拡張の採用を見越して、TCP 実装者はウィンドウを 32  
                 ビットとして扱うべきである。

         4.2.2.4 緊急ポインタ: RFC-793 セクション 3.1

            二番目のセンテンスは誤りである。緊急ポインタは、緊急データ
            のシーケンス中の最終オクテット (最終 + 1 ではない) のシー 
            ケンス番号を指す。ページ 56 (最後のセンテンス) の説明が正 
            しい。

            TCP は、如何なる長さの緊急データのシーケンスもサポートしな
            ければならない (MUST)。

            TCP は緊急ポインタを受信し、前に未処理の緊急データが無い場
            合、あるいは緊急ポインタがデータストリームの先を指している
            場合は必ず、アプリケーション層に非同期に通知しなければなら
            ない (MUST)。アプリケーションが、どの位コネクションから読 
            むべき緊急データが残っているかを知るための方法、あるいは少
            なくとも緊急データをもっと読むべきか否かを決めるための方法
            が存在しなければならない (MUST)。

            DISCUSSION:
                 緊急メカニズムはどんなアプリケーションでも使用してよ 
                 いが、通常それは "中断" タイプのコマンドを Telnet プ 
                 ログラムに送信するために使用される ([INTRO:1] の 
                 "Telnet 同期シーケンスの使用" セクション参照)。

                 非同期の、あるいは "帯域外" 通知により、アプリケーショ
                 ンは "緊急モード" に入り、TCP コネクションからデータ 
                 を読むことができる。これにより、通常の入力バッファが 
                 未処理のデータで一杯になったアプリケーションに、制御 
                 コマンドを送信することが可能になる。

            IMPLEMENTATION:
                 セクション 4.2.4.1 で規定されている一般的な
                 ERROR-REPORT() 呼び出しは、緊急データの到着をアプリケ
                 ーションに通知することができるメカニズムである。

         4.2.2.5 TCP オプション: RFC-793 セクション 3.1

            TCP は如何なるセグメント中の TCP オプションも受信できなけ 
            ればならない (MUST)。TCP は、実装していない如何なる TCP オ
            プションも、異常無く無視しなければならず (MUST)、オプショ 
            ンは長さフィールドを持つ (将来定義されるだろう全ての TCP  
            オプションは、長さフィールドを持つ) と仮定する。TCP は、不
            正なオプション長 (例えば 0) を、クラッシュせずに処理する準
            備ができていなければならない (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 オプションのサイズであ 
                 る。

            MSS オプションで送信される MSS 値は、以下の値以下でなけれ 
            ばならない。

               MMS_R - 20

            MMS_R は受信 (組立) 可能なトランスポート層メッセージの最大
            長である。TCP は、MMS_R と MMS_S を IP 層から獲得する。セ 
            クション 3.4 の一般的な呼び出し GET_MAXSIZES を参照された 
            い。

            DISCUSSION:
                 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) ページ 68 と図 8 に合意するには、SYN-SENT から
                SYN-RECV への矢印には "snd SYN,ACK" というラベルが付く
                はずである。

            (b) 受動的オープン (テキストページ 70 参照) 後に RST 受信 
                という条件下で、SYN-RCVD 状態から LISTEN  状態への矢印
                があり得る。

            (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)。

            DISCUSSION:
                 もし二つのアプリケーションがお互いに同時に接続するこ 
                 とを試みたら、コネクションは 2 本ではなく 1 本しか生 
                 成されないことは、時々実装者を驚かせる。これは意図的 
                 な設計決定であった。これを "修正" しようとしてはなら 
                 ない。

         4.2.2.11 古い重複 SYN からの回復: RFC-793 セクション 3.4,
            ページ 33

            TCP 実装は、受動的 OPEN か能動的 OPEN のいずれの結果でコネ
            クションが SYN_RCVD 状態に達したかを憶えていなければならな
            い (MUST) ことに注意されたい。

         4.2.2.12 RST セグメント: RFC-793 セクション 3.4

            TCP は、受信した RST セグメントがデータを含むことを可能に 
            すべきである (SHOULD)。

            DISCUSSION
                 符号化されて RST の原因を説明している ASCII テキスト 
                 を、RST セグメントに含められることが提案されている。 
                 そのようなデータについては、まだ標準が確立されていな 
                 い。

         4.2.2.13 コネクションのクローズ: RFC-793 セクション 3.5

            TCP コネクションは、二つの方法で終了してもよい。(1) FIN ハ
            ンドシェークを使用した TCP クローズシーケンス。(2) 一つ以 
            上の RST セグメントが送信されて、コネクション状態が即座に 
            破棄される "アボート" 。もし TCP コネクションがリモートサ 
            イトによりクローズされたら、コネクションが正常にクローズさ
            れたかアボートされたかをローカルアプリケーションに通知しな
            ければならない (MUST)。

            正常な TCP クローズシーケンスは、バッファに溜まったデータ 
            を確実に両方向に配送する。TCP コネクションの二つの方向はそ
            れぞれ独立してクローズされるので、コネクションが "半クロー
            ズ"、すなわち片方向しかクローズされないことはあり得る。そ 
            してホストは、半クローズコネクション上で、オープン方向にデ
            ータを送信し続けることが許されている。

            ホストは、"半二重" の TCP クローズシーケンスを実装してもよ
            い (MAY)。その場合、CLOSE を呼び出したアプリケーションは、
            そのコネクションからデータを読み続けることができない。もし、
            そのようなホストが、受信データがまだ TCP で未処理の間に   
            CLOSE 呼び出しを発行したり、または CLOSE が呼び出された後 
            に新しいデータが受信されたら、TCP はデータが消失したことを
            示すために RST を送信すべきである (SHOULD)。

            コネクションが能動的にクローズされた場合、TCP は 2×MSL   
            (最大セグメント生存時間) の時間だけ TIME-WAIT 状態に留まら
            なければならない (MUST)。しかし TCPは、以下の条件下で     
            TIME-WAIT 状態から直接コネクションを再オープンして、リモー
            ト TCP からの新しい SYN を受け入れてもよい (MAY)。

            (1) 前のコネクションの化身で使用された最も大きいシーケンス
                番号よりも大きい初期シーケンス番号を、新しいコネクショ
                ンに対して割り当てる。

            (2) もし SYN が古い重複であることが判明したら TIME-WAIT 状
                態に戻る。

            DISCUSSION:
                 TCP の全二重データ保護クローズは、類似した ISO トラン
                 スポートプロトコル TP4 には含まれない機能である

                 恐らく、ある特定のオペレーティングシステムの I/O モデ
                 ルに合わないため、あるシステムは半クローズのコネクショ
                 ンを実装しなかった。これらのシステムでは、一度アプリ 
                 ケーションがクローズを呼び出したら、そのコネクション 
                 から入力データを読みこむことができない。これは "半二 
                 重" TCP クローズシーケンスと呼ばれる。

                 TCP の上品なクローズアルゴリズムは、2×MSL のタイムア
                 ウト時間すなわち 4 分間、コネクション状態がコネクショ
                 ンの (少なくとも) 一方の終端で定義されたまま残る必要 
                 がある。この間、コネクションを定義する (リモートソケッ
                 トとローカルソケットの) 組み合わせはビジーであり、再 
                 利用することができない。指定ポートの組み合わせが占有 
                 されている時間を短くするために、幾つかの TCP は
                 TIME-WAIT 状態で新しい SYN の受け入れを許可している。

         4.2.2.14 データ通信: RFC-793 セクション 3.7, ページ 40

            RFC793 が書かれてから、効率的なデータ通信を達成するための 
            TCP アルゴリズムに関して多大な作業があった。現ドキュメント
            の後半のセクションは、いつデータを送信するか (セクション  
            4.2.3.4)、いつ肯定応答を送信するか (セクション 4.2.3.2)、 
            いつウィンドウを更新するか (セクション 4.2.3.3) を決定する
            ために必要な、あるいは推奨される TCP アルゴリズムについて 
            説明している。

            DISCUSSION:
                 ある重要なパフォーマンスの問題は、"ばかげたウィンドウ
                 症候群" あるいは "SWS" [TCP:5] である。ウィンドウの変
                 化が永続的なパターンで小さく増加すると、結果的に極端 
                 に貧弱な TCP パフォーマンスを招く。SWS を回避するアル
                 ゴリズムは、送信側 (セクション 4.2.3.4) と受信側 (セ 
                 クション 4.2.3.3) の両方について、以降で説明している。

                 簡単に言うと、SWS は受信側が新しい受信バッファ空間が 
                 データ受信で利用可能になる時に必ずウィンドウの右端を 
                 拡大し、送信側がデータをさらに送信する [TCP:5] ために、
                 小さいか否かに関わらずウィンドウを増加することによっ 
                 て引き起こされる。その結果、たとえ送信側と受信側の両 
                 方が、そのコネクションに対して大きなバッファ空間を持 
                 っていたとしても、小さなデータセグメントを送信するパ 
                 ターンに固定化される可能性がある。SWS は大量のデータ 
                 を送信する間にのみ発生し得る。もしコネクションが無活 
                 動状態になったら、その問題は消えるだろう。それは、ウィ
                 ンドウ管理の典型的で簡単な実装により引き起こされるが、
                 以下に示す送信側と受信側のアルゴリズムによって、それ 
                 は回避されるだろう。

                 もう一つの重要な TCP パフォーマンスの問題は、幾つかの
                 アプリケーション、特に一度に 1 文字のホストにリモート
                 ログインにおいて、1 オクテットのデータセグメントのス 
                 トリームを送信する傾向がある。デッドロックを回避する 
                 ために、そのようなアプリケーションからの TCP SEND 呼 
                 び出しは全て、アプリケーションによって明示的に、さも 
                 なくば TCP によって暗黙的に "push" を指定しなければな
                 らない。その結果、各々 1 データオクテットを含む TCP  
                 セグメントのストリームになるかもしれない。それはイン 
                 ターネットを非常に非効率的に使用させ、インターネット 
                 輻輳の一因となる。セクション 4.2.3.4 で規定されている
                 Nagle アルゴリズムは、この問題に対する簡単で効果的な 
                 解決方法を提供する。それは、Telnet コネクション上で文
                 字を凝集する効果を実際に持つ。これは単一文字をエコー 
                 するのに慣れたユーザを驚かせるかもしれないが、ユーザ 
                 の受けは問題になっていない。

                 Nagle アルゴリズムと送信 SWS 回避アルゴリズムは、パフォ
                 ーマンスの改善に補助的な役割を果たす。Nagle アルゴリ 
                 ズムは、送信すべきデータが少ししか増えない小さいセグ 
                 メントの送信を防ぎ、SWS 回避アルゴリズムは、小さなセ 
                 グメントによってウィンドウの右端を少し増やすことを防 
                 ぐ。

                 軽率な実装体は、受信したデータセグメントにつき 2 個以
                 上の肯定応答セグメントを送信するかもしれない。例えば、
                 受信側が全てのデータセグメントに対して即座に肯定応答 
                 を返すと仮定する。その後、アプリケーションプログラム 
                 がデータを消費して、利用可能な受信バッファ空間を再び 
                 増やすとき、受信側は送信側のウィンドウを更新するため 
                 に 2 個目の肯定応答を送信するかもしれない。極端なケー
                 スは、リモートログインサービスのために Telnet プロト 
                 コルを使用した TCP コネクション上の単一文字セグメント
                 で発生する。幾つかの実装体で、1 文字の各入力セグメン 
                 トにより 3 個の返却セグメントが生成されることが見られ
                 る。それぞれ、(1) 肯定応答 (2) ウィンドウの 1 バイト 
                 加算 (3) エコーされた文字である。

         4.2.2.15 再送タイムアウト: RFC-793 セクション 3.7, ページ 41

            RFC793 で提案されている再送タイムアウトのためのアルゴリズ 
            ムは、不適切であることが知られている。以下のセクション
            4.2.3.1 参照。

            インターネット輻輳と TCP 再送の安定性に関する Jacobson
            [TCP:7] による最近の作業により、"スロースタート" を "輻輳 
            回避" と結びつけた送信アルゴリズムが作成された。TCP はこの
            アルゴリズムを実装しなければならない (MUST)。もし再送され 
            たパケットが元のパケットと同じならば (それは、データ境界が
            変更されていないだけでなく、ヘッダのウィンドウと確認フィー
            ルドも変更されていないことを暗黙的に意味する)、同じ IP 識 
            別子フィールドを使用してもよい (MAY)。(セクション 3.2.1.5 
            参照)

            IMPLEMENTATION:
                 ある TCP 実装者は、データストリームを "パケット化" す
                 る、すなわち元のセグメントを送信し、それが確認される 
                 までこれらのセグメントを "再送キュー" にキューイング 
                 する時、セグメント境界を取り出すことを選択した。もう 
                 一つの設計は (より簡単かもしれない)、各データを送信ま
                 たは再送する時までパケット化することを先延ばしにする 
                 ことである。それにより、セグメント再送キューが存在し 
                 ない。

                 セグメント再送キューの実装において、最初の再送タイム 
                 アウトが発生したときに、肯定応答を待っているセグメン 
                 トを再パケット化することによって TCP パフォーマンスが
                 向上するかもしれない。すなわち、合った出力セグメント 
                 が、一つの最大長のセグメントにまとめられ、新しい IP  
                 識別子値が付与される。そして TCP は、このまとめたセグ
                 メントが確認されるまで再送キューに保持する。しかし、 
                 もし再送キューにある最初の二つのセグメントが、一つの 
                 最大長セグメントのサイズを超えるならば、TCP は元の IP
                 識別子フィールドを使用して、最初のセグメントだけを再 
                 送するだろう。

         4.2.2.16 ウィンドウ管理: RFC-793 セクション 3.7, ページ 41

            TCP 受信側はウィンドウを縮小、すなわちウインドウの右端を左
            側に動かすべきではない (SHOULD NOT)。しかし、送信側 TCP は
            ウィンドウ縮小に対して頑強でなければならない (MUST)。それ 
            が原因で、"使用可能なウィンドウ" (セクション 4.2.3.4 参照)
            が負の値になるかもしれない。

            もしこれが起きたら、送信側は新しいデータを送信すべきでない
            (SHOULD NOT) が、SND.UNA と SND.UNA+SND.WND の間の古い未確
            認のデータを正常に再送すべきである (SHOULD)。送信側は
            SND.UNA+SND.WND を超える古いデータも再送してよい (MAY) が、
            もしウィンドウの右端を超えたデータが確認されていなければ、
            そのコネクションをタイムアウトすべきではない (SHOULD NOT)。
            もしウィンドウが 0 に縮小されたら、TCP は標準の方法で (次 
            のセクション参照) プローブしなければならない (MUST)。

            DISCUSSION:
                 もし大きなウィンドウで送信した直後にウィンドウが縮小 
                 したら、多くの TCP 実装体は混乱する。TCP はデータグラ
                 ムが再順序付けられる可能性があるにもかかわらず、最も 
                 最近のウィンドウ更新を選択するための検出能力を持って 
                 いることに注意されたい。結果的に、シーケンス番号も確 
                 認番号も増えないならば、前に申し出たものよりも小さい 
                 ウィンドウでウィンドウを更新することを無視してもよい。

         4.2.2.17 ゼロウィンドウのプローブ: RFC-793 セクション 3.7, ページ 42

            (申し出された) ゼロウィンドウのプローブは、サポートしなけ 
            ればならない (MUST)。

            TCP は申し出された受信ウィンドウをずっと閉じたままにしても
            よい (MAY)。受信側 TCP が、プローブセグメントの応答で肯定 
            応答を送信し続ける限り、送信側 TCP はコネクションをオープ 
            ンしたままにしなければならない (MUST)。

            DISCUSSION:
                 データを含まない ACK (肯定応答) セグメントは、TCP に 
                 よって確実に送信されるとは限らないことを憶えておくこ 
                 とは極めて重要である。もしゼロウィンドウプローブがサ 
                 ポートされていなければ、ウィンドウを再びオープンする 
                 ACK セグメントが消失した時、そのコネクションが永久に 
                 ハングアップするかもしれない。

                 ゼロウィンドウのオープン遅延は通常、受信側アプリケー 
                 ションが自分の TCP からデータを取ることを止めるときに
                 発生する。例えば、プリンタデーモンアプリケーションに 
                 ついて考えれば、プリンタの紙切れが原因で止められる。

            送信側ホストは、ゼロウィンドウプローブが再送タイムアウト期
            間中 (セクション 4.2.2.15 参照) に存在するとき、まず始めに
            ゼロウィンドウプローブを送信すべきである (SHOULD)。そして、
            継続的なプローブ間の間隔を指数的に増やすべきである        
            (SHOULD)。

            DISCUSSION:
                 この手続きは、もしゼロウィンドウ状態がウィンドウを開 
                 ける更新を含んでいる ACK セグメントの消失によるものな
                 らば、遅延を最小化する。ここでは規定されないが、ある 
                 最大の時間間隔を持つ指数的なバックオフが推奨される。 
                 この手続きは再送アルゴリズムと同様であり、実装体に二 
                 つの手続きを統合することは可能かもしれない。

         4.2.2.18 受動的 OPEN 呼び出し:  RFC-793 セクション 3.8

            受動的 OPEN 呼び出しは、LISTEN 状態で新しいコネクションレ 
            コードを生成するか、エラーを返却する。それは、以前に生成さ
            れたコネクションレコードに何ら影響を及ぼしてはならない    
            (MUST NOT)。

            複数の共同作業ユーザをサポートする TCP は、同じローカルポ 
            ートを持つコネクションブロックが、SYN-SENT か SYN-RECEIVED
            状態にある間に、アプリケーションがそのポートを LISTEN する
            ことを機能的に可能にする OPEN 呼び出しを提供しなければなら
            ない (MUST)。

            DISCUSSION:
                 幾つかのアプリケーション (例えば SMTP サーバ) は、同 
                 時に複数のコネクション確立の試みを処理する必要がある 
                 かもしれない。以前のコネクション確立の試みが 3 方向ハ
                 ンドシェークを行うのと同時に、新しいコネクションをリッ
                 スンする手段を提供することによって、コネクション確立 
                 の試みが失敗する可能性が減る。

            IMPLEMENTATION:
                 同時オープンの許容可能な実装体は、複数の受動的 OPEN  
                 呼び出しを許してもよい。あるいは、単独の受動的 OPEN  
                 呼び出しによる LISTEN 状態のコネクションの "クローズ"
                 を許してもよい。

         4.2.2.19 生存時間: RFC-793 セクション 3.9, ページ 52

            RFC793 は、TCP が TTL=60 で TCP セグメントを送信することを
            IP 層に要求すべきであると規定した。これは廃止され、TCP セ 
            グメントの送信で使用される TTL 値は設定可能でなければなら 
            ない (MUST)。この議論については、セクション 3.2.1.7 を参照
            されたい。

         4.2.2.20 イベント処理: RFC-793 セクション 3.9

            厳密な要件ではないが、TCP は順序の異なる TCP セグメントを 
            キューイング可能であるべきである (SHOULD)。70 ページの第一
            パラグラフの最後のセンテンスの "may" を "should" に変更す 
            る。

            DISCUSSION:
                 幾つかの小規模なホスト実装は、バッファ空間が制限され 
                 ているためにセグメントのキューイングを省略した。この 
                 省略は、単一セグメントの消失により以降のセグメント全 
                 てが "順序の異なって" 現れるため、TCP のスループット 
                 に有害な影響を及ぼすかもしれない。

            通常、受信したセグメントの処理として、可能なときは必ず ACK
            セグメントを統合するよう実装しなければならない (MUST)。例 
            えば、もし TCP が一連のキューイングされたセグメントを処理 
            しているならば、ACK セグメントを送信する前に全て処理しなけ
            ればならない (MUST)。

            以下に、RFC793 のイベント処理セクションに関する誤りの訂正 
            と注意事項について詳述する。

            (a) CLOSE 呼び出し、CLOSE-WAIT 状態、ページ 61。CLOSING で
                はなく LAST-ACK 状態に遷移する。

            (b) LISTEN 状態、SYN のチェック (ページ 65, 66)。もしセグ 
                メントのセキュリティ/コンパートメントか優先度が誤って 
                いたら、リセットを送信する。そのテキスト中のリセットの
                形式が誤っている。以下とすべき。

                   

            (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。
                もし SEG.ACK =< SND.UNA ならば、ACK が重複している
                (= が省略されていた)。同様に、
                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)。

            DISCUSSION:
                 RFC-793 (ページ 74 参照) は、順序通りでないセグメント
                 を受信した時、すなわち、SEG.SEQ が RCV.NXT に等しくな
                 かった時に、ACK セグメントを送信すべきか否かについて 
                 曖昧であった。

                 順序通りでないセグメントに対して ACK を送信する理由の
                 一つは、"高速再送" として知られている実験的なアルゴリ
                 ズムをサポートするためである。このアルゴリズムでは、 
                 再送タイマが満了する前にセグメントが消失したことを推 
                 理するために、送信側が "冗長な" ACK を使用する。送信 
                 側は、同じ SEG.ACK の値を持ち、同じウィンドウの右端を
                 持つ ACK を受信した回数を数える。もし、そのような ACK
                 をしきい値を超えた回数分受信したら、SEG.ACK から始ま 
                 るオクテットを含むセグメントが消失したものと仮定して、
                 タイムアウトを待たずに再送する。しきい値はセグメント 
                 を並び替える見込みの、インターネットにおける最大を補 
                 償して選択される。高速再送アルゴリズムについては、ど 
                 の程度有効であるかを決定するだけの十分な経験はまだ無 
                 い。

      4.2.3 特定の問題

         4.2.3.1 再送タイムアウトの計算

            ホスト TCP は再送タイムアウトを ("RTO")を計算するために、 
            Karn のアルゴリズムと Jacobson のアルゴリズムを実装しなけ 
            ればならない (MUST)。

            o    なだらかなラウンドトリップ ("RTT") 時間を算出するため
                 の Jacobson のアルゴリズムは、変化量の簡単な計測を組 
                 み込んでいる。[TCP:7]

            o    RTT の大きさを選択するための Karn のアルゴリズムは、 
                 曖昧なラウンドトリップ時間がなだらかなラウンドトリッ 
                 プ時間の計算を誤らせないことを保証する。[TCP:6]

            実装体は同じセグメントの継続的な RTO 値に対して、"指数的な
            バックオフ" も含まなければならない (MUST)。SYN セグメント 
            の再送は、データセグメントと同じアルゴリズムを使用すべきで
            ある (SHOULD)。

            DISCUSSION:
                 RFC793 で規定された RTO の計算方法には、二つの既知の 
                 問題があった。第一に、再送があった時に正確な RTT の計
                 測が困難なことである。第二に、なだらかなラウンドトリッ
                 プ時間を算出するためのアルゴリズムが適切でないことで 
                 ある [TCP:7]。なぜならは、RTT 値の変動が小さく、一定 
                 であるという仮定は誤りだからである。これらの問題は、 
                 それぞれ Karn と Jacobson のアルゴリズムによって解決 
                 された。

                 これらの改善を使用することによるパフォーマンスの増加 
                 は、顕著に劇的に変化する。RTT の変化量の計測を組み込 
                 むための Jacobson のアルゴリズムは、通常のパケット長 
                 の変化が RTT のバリエーションを大きくするような低速回
                 線上では特に重要である。あるベンダは、Jacobson の変動
                 アルゴリズムを実装することによって、9.6kb の回線上の 
                 回線使用率が 10% から 90% に向上したことを見出してい 
                 る。

            新しいコネクションで見積りパラメタを利用するために、以下の
            値を使用すべきである (SHOULD)。

            (a) RTT = 0 秒。

            (b) RTO = 3 秒。(なだらかな変化量は、この RTO に結果的に到
                る値に初期化される)。

            推奨される RTO の上限値と下限値が、大規模なインターネット 
            では不適切であることが知られている。下限値は (高速 LAN に 
            適応させるために) 秒の数分の一で計測すべきであり、上限値は
            2*MSL、すなわち 240 秒にすべきである。

            DISCUSSION:
                 経験上、これらの初期値が効率的であり、ともかく Karn  
                 と Jacobson のアルゴリズムは、TCP の振舞いを初期パラ 
                 メタの選択に効率的に無反応にすることが分かっている。

         4.2.3.2 いつ ACK セグメントを送信するか

            TCP データセグメントのストリームを受信しているホストは、受
            信するデータセグメントにつき、1 つ以下の ACL (肯定応答) セ
            グメントを送信することによって、インターネットとホストの両
            方の効率を増すことができる。これは "遅延 ACK" [TCP:5] とし
            て知られている。

            TCP は遅延 ACK を実装すべきである (SHOULD) が、ACK を過度 
            に遅らせるべきではない。遅延は 0.5 秒以下でなければならず 
            (MUST)、フルサイズのセグメントの場合は、少なくとも毎秒セグ
            メントに対して ACK が存在すべきである (SHOULD)。

            DISCUSSION:
                 遅延 ACK はアプリケーションに、ウィンドウを更新し、お
                 そらく即座に応答を送信する機会を与える。特にキャラク 
                 タモードのリモートログインの場合、遅延 ACK によって、
                 サーバによって送信されるセグメントの個数が 3 の約数  
                 (ACK, ウィンドウ更新、エコー文字が全て 1 つのセグメン
                 トに結合される) だけ減らすことができる。

                 さらに、ある大規模な複数ユーザのホストでは、遅延 ACK 
                 は実質的に、処理されるパケットの総個数を減らすことに 
                 よって、プロトコル処理のオーバヘッドを減らすことがで 
                 きる [TCP:5]。しかし、ACK の過度の遅延は、ラウンドト 
                 リップのタイミングとパケット "クロッキング" アルゴリ 
                 ズム [TCP:7] の邪魔をする可能性がある。

         4.2.3.3 いつウィンドウを更新するか

            受信側の TCP は、SWS 回避アルゴリズムを含まなければならな 
            い (MUST)。[TCP:5]

            IMPLEMENTATION:
                 受信側の SWS 回避アルゴリズムは、ウィンドウの右端をい
                 つ進めてもよいかを決定する。これは慣例で "ウィンドウ 
                 更新" として知られている。現在のウィンドウを含んでい 
                 る ACK セグメントを、いつ実際に受信側に送信するかを決
                 定するためには、このアルゴリズムと遅延 ACK アルゴリズ
                 ム (セクション 4.2.3.2 参照) を組み合わせる。ここでは、
                 RFC793 の表記方法を使用する。そのドキュメントの図 4  
                 と図 5 を参照されたい。

                 受信側 SWS のソリューションは、たとえデータを小さいセ
                 グメントでネットワークから受信しても、ウィンドウの右 
                 端 RCV.NXT+RCV.WND を少しの増加で更新することを避ける
                 ことである。

                 受信バッファ空間の総量が RCV.BUFF であると仮定する。 
                 ある時点でのこの総量の RCV.USER オクテットは、受信さ 
                 れ確認されたデータと結びついているが、ユーザプロセス 
                 がまだ消費していない。コネクションが活動していなけれ 
                 ば、RCV.NXT = RCV.BUFF であり、RCV.USER = 0 である。

                 データが到着して確認された時に、ウィンドウの右端を固 
                 定化する場合、バッファ空間全体よりも小さい値を申し出 
                 る必要がある。すなわち、受信側は RCV.NXT が増える時に、
                 RCV.NXT+RCV.WND を一定に保つ RCV.WND を示さなければな
                 らない。従って、バッファ空間全体の RCV.BUFF は、通常 
                 三つの部分に分割される。


                 |<------- RCV.BUFF ---------------->|
                      1             2            3
             ----|---------|------------------|------|----
                        RCV.NXT               ^
                                           (Fixed)

             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) によって課せられる制限も受ける。

            DISCUSSION:
                 Nagle アルゴリズムは、一般に次の通り。

                      もし未確認のデータがあれば (すなわち 
                      SND.NXT > SND.UNA)、未確認のデータが確認されるか、
                      TCP がフルサイズのセグメント (Eff.snd.MSS バイト、
                      セクション 4.2.2.6 を参照されたい) を送信できる 
                      まで、送信側 TCP は全てのユーザデータをバッファ 
                      リングする。

                 幾つかのアプリケーションは (例えばリアルタイムの表示 
                 ウィンドウ更新)、Nagle アルゴリズムを使用しない必要が
                 ある。それにより、小さいデータグラムセグメントを最大 
                 の割合で送出することができる。

            IMPLEMENTATION:
                 送信側の SWS 回避アルゴリズムは受信側のよりも難しい。
                 なぜなら、送信側は受信側のバッファ空間の総量 RCV.BUFF
                 を (直接的には) 知らないからである。うまく動作させる 
                 ために発見されたアプローチは、送信側が Max(SND.WND)、
                 コネクション上でそれまで見られた最大送信ウィンドウを 
                 算出して、RCV.BUFF の概算としてこの値を使用することで
                 ある。不幸にもこれはあくまで概算であり、受信側は如何 
                 なる時でも RCV.BUFF のサイズを減らすことができる。デッ
                 ドロックを結果として招くことを避けるために、SWS 回避 
                 アルゴリズムを無効にして、データの送信を強制するため 
                 のタイムアウトを持つ必要がある。実際は、このタイムア 
                 ウトは滅多に発生しないはずである。

                 "使用可能なウィンドウ" [TCP:5] は:

                      U = SND.UNA + SND.WND - SND.NXT

                 すなわち、申し出されたウィンドウから、送信したが確認 
                 されていないデータの総量を引いたものである。もし D が
                 送信側 TCP でキューイングされているが、まだ送信されて
                 いないデータの総量ならば、以下の規則のセットが推奨さ 
                 れる。

                 以下の条件に合致したらデータを送信する:

                 (1) もし最大サイズのセグメントが送信できるならば、す 
                     なわち以下ならば

                           min(D,U) >= Eff.snd.MSS;

                 (2) あるいは、もしデータがプッシュされ、全てのキュー 
                     イングされたデータが今送信できるならば、すなわち 
                     以下ならば

                          [SND.NXT = SND.UNA and] PUSHED and D <= U

                      (角括弧内の条件は Nagle アルゴリズムによって課せ
                      られる)

                 (3) あるいは、もし少なくとも最大ウィンドウの分数 Fs  
                     が送信できるならば、すなわち以下ならば

                          [SND.NXT = SND.UNA and]

                                  min(D.U) >= Fs * Max(SND.WND);

                 (4) あるいは、もしデータが PUSH され、無効タイムアウ 
                     トが発生したら

                 この Fs は、推奨された値が 1/2 の分数である。無効タイ
                 ムアウトは 0.1〜1.0 秒の範囲であるはずである。このタ 
                 イマを、ゼロウィンドウのプローブ (セクション 
                 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 を "無限" に設定してもよく、切断す
                るタイミングをユーザに制御させられる。

            (e) 
                R2 の前に R1 に達したら、TCP はアプリケーションに配送 
                の問題を通知すべきである (SHOULD)。(もしそのような情報
                がアプリケーションによって利用不能でないならば。セクショ
                ン 4.2.4.1 参照)。これによって、例えばリモートログイン
                (ユーザ Telnet) アプリケーションプログラムが、ユーザに
                知らせることができる。

            R1 の値は、少なくとも現在の RTO で、3 回の再送に相当すべき
            である (SHOULD)。R2 の値は少なくとも 100 秒に相当すべきで 
            ある (SHOULD)。

            TCP コネクションをオープンする試みは、SYN セグメンの過度の
            再送か RST セグメントの受信、ICMP ポート未到達で失敗する可
            能性がある。SYN 再送は、アプリケーション層に通知することを
            含め、データの再送で規定されている一般的な方法で処理しなけ
            ればならない (MUST)。

            しかし、R1 と R2 の値は SYN とデータセグメントでは異なって
            もよい。特に SYN セグメントに対する R2 は、少なくとも 3 分
            間、セグメントの再送を提供できるほど、十分大きな値を設定し
            なければならない (MUST)。無論アプリケーションは、より早く 
            コネクションをクローズする (例えばオープンの試みを諦める) 
            ことができる。

            DISCUSSION:
                 幾つかのインターネットパスはかなりの設定時間を要し、 
                 そうしたパスの数は将来増えると思われる。

         4.2.3.6 TCP Keep-Alives

            この実行は一般には受け入れられていないが、実装者は TCP の 
            実装体に "keep-alive" を含めてもよい (MAY)。もし 
            keep-alive が含まれるならば、アプリケーションは各々の TCP 
            コネクションに対して、その使用/未使用を指定できなければな 
            らず(MUST)、デフォルトは未使用でなければならない (MUST)。

            keep-alive パケットは、ある間隔内にコネクションでデータや 
            肯定応答パケットを受信しない時にのみ送信しなければならない
            (MUST)。その間隔は設定可能でなければならず (MUST)、デフォ 
            ルトは 2 時間以上でなければならない (MUST)。

            データを含んでいない ACK セグメントは、TCP によって信頼で 
            きる送信がされていないことを覚えておくことは、極めて重要で
            ある。もし keep-alive メカニズムを実装する場合、ある特定の
            プローブに対して応答が無いことを、コネクションが死んだもの
            と解釈してはならない (MUST NOT)。

            実装体は、データが付かない keep-alive セグメントを送信すべ
            きである (SHOULD)。しかし、誤った TCP 実装体との互換性のた
            めに、一つのごみオクテットを含んだ keep-alive セグメントを
            送信するよう、設定可能であってもよい (MAY)。

            DISCUSSION:
                 "keep-alive" メカニズムは、コネクションがさもなくばア
                 イドルである時に、送信すべきデータが無くても、コネク 
                 ションのもう一方の終端を定期的にプローブする。TCP の 
                 規定は keep-alive メカニズムを含んでいない。なぜなら 
                 ば、(1) 一時的なインターネット障害の間に、完全に有効 
                 なコネクションを切断する可能性がある。(2) 不要な帯域 
                 を消費する。("もし誰もそのコネクションを使っていなけ 
                 れば、それが有効であるか否かなど誰が気にするだろうか 
                 ")。(3) パケット課金のインターネットパスでお金がかか 
                 る。

                 しかしながら、幾つかの TCP 実装は、keep-alive メカニ 
                 ズムを含めている。アイドルコネクションがまだ活性であ 
                 ることを確認するために、これらの実装体は相手の TCP か
                 ら応答を引き出すことを意図したプローブセグメントを送 
                 信する。そのセグメントは通常 SEG.SEQ = SND.NXT-1 を含
                 み、ごみデータを 1 オクテット含んでも含まなくてもよい。
                 平穏なコネクションは SND.NXT = RCV.NXT である。よって、
                 この SEG.SEQ はウィンドウの範囲外である。従って、この
                 プローブによって受信側は肯定応答セグメントを返却する 
                 ことになり、コネクションがまだ活性であることが確認で 
                 きる。もし相手が、ネットワークの分断やクラッシュによ 
                 ってそのコネクションを落としていたら、相手は肯定応答 
                 セグメントではなく RST で応答するだろう。

                 不幸にも、幾つかの誤って動作する TCP 実装体は、セグメ
                 ントがデータを含んでいなければ、SEG.SEQ = SND.NXT-1  
                 を持つセグメントに対して応答しない。代替手段として実 
                 装体は、相手がごみデータオクテットを付けない 
                 keep-alive パケットに対して、正しく応答したか否かを決
                 めることができる。

                 TCP keep-alive メカニズムは、もしクライアントがネット
                 ワーク障害の間にクラッシュするかコネクションをアボー 
                 トしたら、いつまでもハングしてリソースを不必要に消費 
                 するサーバアプリケーションでのみ発行すべきである。

         4.2.3.7 TCP マルチホーム

            マルチホーム化さけたホスト上のアプリケーションが、積極的に
            TCP コネクションをオープンする時にローカル IP アドレスを指
            定しないならば、TCP は (一番最初の) SYN を送信する前に、ロ
            ーカル IP アドレスの選択を IP 層に依頼しなければならない  
            (MUST)。セクション 3.4 の GET_SRCADDR() 関数を参照されたい。

            それ以外の時は、このコネクション上で前のセグメントが送信あ
            るいは受信されており、TCP は直前のセグメントで使われていた
            ものと同じローカルアドレスを使用しなければならない (MUST)。

         4.2.3.8 IP オプション

            受信したオプションが IP 層から TCP に渡される時、TCP は理 
            解できないオプションを無視しなければならない (MUST)。

            TCP はタイムスタンプと経路記録オプションをサポートしてもよ
            い (MAY)。

            アプリケーションは積極的に TCP コネクションをオープンする 
            時に、送信元経路オプションを指定できなければならない      
            (MUST)。そしてこれは、データグラムで受信した送信元経路より
            も優先しなければならない (MUST)。

            TCP コネクションを受動的に OPEN して、完全な IP 送信元経路
            オプション (返却経路を含む) 付きのパケットが到着した時、  
            TCP は返却経路を保存して、このコネクションに送信するセグメ
            ントでそれを使用しなければならない (MUST)。もし以降のセグ 
            メントで異なる送信元経路が到着したら、後者の定義が前者を上
            書きすべきである (SHOULD)。

         4.2.3.9 ICMP メッセージ

            TCP は IP 層から渡される ICMP エラーメッセージに基づいて、
            エラーを生成したコネクションに向けて動作しなければならない
            (MUST)。必要な合流化情報は、ICMP メッセージ内に含まれる IP
            ヘッダの中で見つけることができる。

            o    送信元消失

                 TCP は、そのコネクションへの送信を送らせることによっ 
                 て、送信元消失に反応しなければならない (MUST)。送信元
                 消失に対して推奨される (RECOMMENDED) 手続きは、あたか
                 も再送タイムアウトが発生したかのように "スロースター 
                 ト" を実行することである。

            o    宛先未到達 -- コード 0, 1, 5

                 これらの宛先未到達メッセージはソフト異常の状態を示し 
                 ているので、TCP はそのコネクションをアボートしてはな 
                 らず (MUST NOT)、その情報をアプリケーションで利用可能
                 とすべきである (SHOULD)。

                 DISCUSSION:
                      TCP はソフト異常の状態を ERROR_REPORT ルーチンの
                      上位呼び出しで、アプリケーション層に直接通知する
                      ことができる。さもなくば TCP コネクションがタイ 
                      ムアウトしなければ、そのメッセージを表してアプリ
                      ケーションに通知することがほとんどできない。

            o    宛先未到達 -- コード 2-4

                 これらはハード異常の状態である。よって、TCP はそのコ 
                 ネクションをアボートすべきである (SHOULD)。

            o    時間超過 -- コード 0, 1

                 これは、宛先未到達のコード 0, 1, 5 と同じ方法で扱うべ
                 きである (上記参照)。

            o    パラメメタ問題

                 これは、宛先未到達のコード 0, 1, 5 と同じ方法で扱うべ
                 きである (上記参照)。

         4.2.3.10 リモートアドレス検査

            TCP 実装体は、不正なリモート IP アドレス (例えばブロードキャ
            ストやマルチキャストアドレス等) に対して、ローカル OPEN 呼
            び出しのエラーとして拒否しなければならない (MUST)。

            不正な送信元アドレスを持つ入力 SYN は、TCP か IP 層のいず 
            れかによって無視しなければならない (MUST) (セクション
            3.2.1.3 参照)。

            TCP 実装は、ブロードキャストかマルチキャストアドレスに宛て
            られた入力 SYN セグメントを、黙って破棄しなければならない 
            (MUST)。

         4.2.3.11 TCP トラフィックパターン

            IMPLEMENTATION:
                 TCP プロトコル規定 [TCP:1] は、コネクション上のメッセ
                 ージフローを制御するアルゴリズム、パケット化やウィン 
                 ドウの管理、肯定応答の送信等を設計する際の自由度を実 
                 装者に与えている。TCP は幅広いトラフィックパターンに 
                 適応しなければならないので、これらの設計の決定は難し 
                 い。経験上 TCP 実装者は、以下の二つの極端なトラフィッ
                 クパターンについての設計を確かめる必要があることが判 
                 明している。

                 o    単一文字のセグメント

                      たとえ送信側が Nagle アルゴリズムを使用していて 
                      も、TCP コネクションがリモートログインのトラフィッ
                      クを低遅延 LAN を横切って送る場合、受信側は通常、
                      単一文字のセグメントのストリームを受信するだろう。
                      もしリモート端末のエコーモードが有効ならば、受信
                      側のシステムは通常、受信時に各々の文字をエコーす
                      る。

                 o    大容量転送

                      TCP が大容量転送で使用されている時、データストリ
                      ームは (ほぼ) 全て有効 MSS のサイズのセグメント 
                      で構成すべきである。TCP は、バイト (オクテット) 
                      単位でシーケンス番号空間を使用するが、大容量転送
                      モードでは、TCP はセグメントだけを数えるシーケン
                      ス空間を使用するかのような処理であるべきである。

                 更に経験上では、単一の TCP は効果的かつ効率的に、これ
                 ら二つの極端なケースを扱えることが判っている。

                 新しい TCP 実装を検査するための最も重要なツールは、パ
                 ケットトレースプログラムである。他の TCP 実装との様々
                 なトラフィックパターンをトレースし、その結果を注意深 
                 く検証する重要性は、非常に数多くの経験が物語っている。

         4.2.3.12 効率性

            IMPLEMENTATION:
                 幅広い経験則より、効率的な TCP の実装に対して以下の提
                 案が導き出される。

                 (a) データをコピーしてはならない

                     大容量データ転送では、CPU に集中する主要なタスク 
                     は、ある場所から別の場所にデータをコピーして、デ 
                     ータのチェックサムを計算することである。TCP デー 
                     タのコピー回数を最小化することは非常に重要である。
                     根本的なスピードの制限は、メモリバスを通じてデー 
                     タをフェッチすることかもしれないので、コピーと   
                     チェックサム計算を併用し、一回のメモリフェッチで 
                     両方を実行することは効果的かもしれない。

                 (b) ハードウェア組込みチェックサム計算ルーチン

                     優れた TCP チェックサム計算ルーチンは、単純で定義
                     そのままの実装よりも 2 倍から 5 倍速い。多大な注 
                     意と賢いコーディングはしばしば必要であり、チェッ 
                     クサムを計算するコードを "強烈に高速" にすること 
                     が望ましい。[TCP:10] 参照

                 (c) 最も一般的なケースのコード

                     TCP プロトコル処理は複雑であるが、大半のセグメン 
                     トについては、ほんのわずかで簡単な決定を行えばよ 
                     い。最も一般的なケースで決定する回数を最小化する 
                     よう、主要な行をコーディングすることによって、セ 
                     グメント毎の処理は非常にスピードアップするだろう。

      4.2.4  TCP/アプリケーション層インタフェース

         4.2.4.1 非同期通知

            軽度な TCP エラー状態をアプリケーションに通知するメカニズ 
            ムが存在しなければならない (MUST)。これは一般に、トランス 
            ポート層から非同期に上位呼び出しされる [INTRO:7]、アプリケ
            ーション提供の ERROR_REPORT ルーチンを想定している。

               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)。

            DISCUSSION:
                 これらのエラー通知は通常、多くのアプリケーションによ 
                 って害なく無視できるソフトエラーを反映している。これ 
                 らのエラー通知呼び出しは、デフォルトでは "無効" にす 
                 べきであると提案されているが、これは要件ではない。

         4.2.4.2 サービスタイプ

            アプリケーション層は、コネクション上で送信されるセグメント
            にサービスタイプ (TOS) を指定できなければならない (MUST)。
            要件ではないが、アプリケーションはコネクションが生存中は  
            TOS を変更できるべきである (SHOULD)。TCP はコネクション上 
            にセグメントを送信する時、現在の TOS 値を変更せずに IP 層 
            に渡すべきである (SHOULD)。

            TOS はコネクションの各方向毎に独立して指定されるので、受信
            側アプリケーションは ACK セグメントで使用する TOS を指定す
            るだろう。

            TCP は最も最近受信した TOS をアプリケーションに渡してもよ 
            い (MAY)。

            DISCUSSION:
                 幾つかのアプリケーション (例えば SMTP) は、コネクショ
                 ンが生存中に通信の性質を変更するので、TOS の指定を変 
                 更したいかもしれない。

                 RFC793 で既定された OPEN 呼び出しもまた、呼び出し側が
                 送信元経路や経路記録やタイムスタンプなどの IP オプショ
                 ンを指定できるパラメタ ("オプション") を含んでいるこ 
                 とに注意されたい。

         4.2.4.3 フラッシュ呼び出し

            幾つかの TCP 実装は FLUSH 呼び出しを含んでいる。それは、ユ
            ーザが SEND 呼び出しを発行したが、まだ現在の送信ウィンドウ
            の右にあり、TCP の送信キューに溜まっているデータを空にする。
            すなわち、シーケンス番号の同期を失わず、可能な限りのキュー
            イングされている送信データをフラッシュする。これは、telnet
            の "アボート出力" 機能で効果的である。

         4.2.4.4 マルチホーム化

            RFC793 のセクション 2.7 と 3.8 で概説されているユーザイン 
            タフェースは、マルチホーム化のために拡張する必要がある。  
            OPEN 呼び出しはローカル IP アドレスの指定を可能にするため 
            に、以下の任意のパラメタを持たなければならない (MUST)。

                OPEN( ... [local IP address,] ... )

            DISCUSSION:
                 幾つかの TCP ベースのアプリケーションは、ある特定のコ
                 ネクションを使用するためのローカル IP アドレスを指定 
                 する必要がある。例えば FTP がそれに該当する。

            IMPLEMENTATION:
                 "ローカル IP アドレス" パラメタが指定された受動的    
                 OPEN 呼び出しは、そのアドレス向けのコネクション要求の
                 受信を待つ。もしそのパラメタが未指定ならば、受動的   
                 OPEN は全てのローカル IP アドレス向けのコネクション要
                 求の受信を待ち、使用されている特定のアドレスへのコネ 
                 クションのローカル IP アドレスをバインドする。

                 能動的 OPEN 呼出しでは、指定された "ローカル IP アド 
                 レス" パラメタは、コネクションをオープンするために使 
                 用される。もしそのパラメタが未指定ならば、ネットワー 
                 クソフトウェアは、そのコネクションに対する適切なロー 
                 カル IP アドレスを選択するだろう (セクション 3.3.4.2 
                 参照)。

      4.2.5 TCP 要件要約

                                                 |        | | | |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
-------------------------------------------------|--------|-|-|-|-|-|--
                                                 |        | | | | | |
プッシュフラグ                                   |        | | | | | |
  プッシュ無しデータを集める/キューイングする    |4.2.2.2 | | |x| | |
  送信側は継続する PSH フラグを破棄する          |4.2.2.2 | |x| | | |
  SEND 呼び出しが PUSH を指定可能                |4.2.2.2 | | |x| | |
    もし不可: 送信側がいつまでもバッファに溜める |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| | | | |
  ゼロウィンドウで送信側が OK conn をタイムアウト|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| | | | |
  536 でなければ MSS オプションを送信する        |4.2.2.6 | |x| | | |
  常に MSS オプションを送信する                  |4.2.2.6 | | |x| | |
  送信 MSS のデフォルトが 536 である             |4.2.2.6 |x| | | | |
  有効送信セグメント長を算出する                 |4.2.2.6 |x| | | | |
                                                 |        | | | | | |
TCP チェックサム                                 |        | | | | | |
  送信側がチェックサムを計算する                 |4.2.2.7 |x| | | | |
  受信側がチェックサムをチェックする             |4.2.2.7 |x| | | | |
                                                 |        | | | | | |
クロック駆動の初期シーケンス選択を使用する       |4.2.2.9 |x| | | | |
                                                 |        | | | | | |
コネクションのオープン                           |        | | | | | |
  同時オープンの試みをサポートする               |4.2.2.10|x| | | | |
  SYN-RCVD に達するときに最後の状態を覚えている  |4.2.2.11|x| | | | |
  受動的オープン呼び出しが他の呼び出しを妨げる   |4.2.2.18| | | | |x|
  同じポートを同時に LISTEN する機能             |4.2.2.18|x| | | | |
  必要なら SYN の送信元アドレスを IP に尋ねる    |4.2.3.7 |x| | | | |
    さもなくば conn のローカルアドレスを使用     |4.2.3.7 |x| | | | |
  bcast/mcast IP アドレス向けにオープンする      |4.2.3.14| | | | |x|
  bcast/mcast アドレスへのセグメントを黙って破棄 |4.2.3.14|x| | | | |
                                                 |        | | | | | |
コネクションのクローズ                           |        | | | | | |
  RST がデータを含む                             |4.2.2.12| |x| | | |
  コネクションのアポートをアプリケーションに通知 |4.2.2.13|x| | | | |
  コネクションの半二重クローズ                   |4.2.2.13| | |x| | |
    データ消失を示すために RST 送信              |4.2.2.13| |x| | | |
  2×MSL 秒間 TIME-WAIT 状態にいる               |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| | | |
    APL が 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| | | | |
                                                 |        | | | | | |
Keep-alive パケットの送信:                       |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| | | | |
  - デフォルトは少なくとも 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) -> アプリケーションに通知   |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| | | |
  時間超過 => アプリに通知、アボートしない       |4.2.3.9 | |x| | | |
  パラメタ問題 => アプリに通知、アボートしない   |4.2.3.9 | |x| | | |
                                                 |        | | | | | |
アドレス違反                                     |        | | | | | |
  不正な IP アドレスへの OPEN 呼び出しを拒否する |4.2.3.10|x| | | | |
  不正な IP アドレスからの SYN を拒否する        |4.2.3.10|x| | | | |
  bcast/mcast アドレスへの SYN を黙って破棄する  |4.2.3.10|x| | | | |
                                                 |        | | | | | |
TCP/アプリケーションインタフェースサービス       |        | | | | | |
  エラー通知メカニズム                           |4.2.4.1 |x| | | | |
  APL がエラー通知ルーチンを無効にできる         |4.2.4.1 | |x| | | |
  APL が送信での TOS を指定できる                |4.2.4.2 |x| | | | |
    IP に変更無しで渡す                          |4.2.4.2 | |x| | | |
  APL がコネクションの間に TOS を変更できる      |4.2.4.2 | |x| | | |
  受信した TOS をアプリケーションに渡す          |4.2.4.2 | | |x| | |
  FLUSH 呼び出し                                 |4.2.4.3 | | |x| | |
  OPEN で任意のローカル IP アドレスパラメタ      |4.2.4.4 |x| | | | |
-------------------------------------------------|--------|-|-|-|-|-|--
-------------------------------------------------|--------|-|-|-|-|-|--

脚注:

(1) "ALP" はアプリケーション層プログラムを意味する。

5. 参照

導入部の参照


[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.

     このドキュメントは、定期的に新しい RFC 番号で再発行される。最新の
     版を使用しなければならない。

[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.

     このドキュメントは、定期的に新しい RFC 番号で再発行される。最新の
     版を使用しなければならない。

[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.


二次的な参照:

[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,
     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: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.

     この RFC は、IEEE 802 ネットワークの使用を計画しているインターネッ
     ト実装者向けに、非常に多くの重要な情報を含んでいる。

IP 層の参照


[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.

     この規約は RFC963 で更新され、インターネットプロトコルを規定する 
     ことを意図しているが、重大な省略がある (例えば、必須要件であるサ 
     ブネット拡張 [IP:3] や、オプションのマルチキャスト拡張 [IP:4] な 
     ど)。また古くもある。現在のドキュメントは全体的に正式ではあるが、
     もし矛盾があるならば、RFC-791, RFC-792, RFC-950 を正式とみなさな 
     ければならない。

[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.

     TCP 最大セグメント長オプションと IP データグラム長との間の関係を 
     論じ、明確化している。

[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.

     この役に立つドキュメントは、インターネットフラグメンテーションに 
     よって起こる問題について論じ、代わりの解決方法を提示している。

[IP:10] "IP Datagram Reassembly Algorithms," D. Clark, RFC-815, July
     1982.

     これと次のドキュメントは、全ての実装者が読むべきである。

[IP:11] "Fault Isolation and Recovery," D. Clark, RFC-816, July 1982.

二次的な IP 層の参照:

[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.

     この RFC は最初に直接ブロードキャストアドレスを規定した。しかし大
     半の RFC は、ホストではなくゲートウェイを心配した。

UDP の参照

[UDP:1] "User Datagram Protocol," J. Postel, RFC-768, August 1980.

TCP の参照


[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.

     RFC 964 によって改訂されたこの規約は、RFC 793 [TCP:1] と同じプロ 
     トコルを規定することを意図している。もし矛盾があるならば RFC-793 
     を有効とし、このドキュメントが両方に対して正式とみなさなければな 
     らない。

[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.

二次的な TCP の参照:

[TCP:8] "Modularity and Efficiency in Protocol Implementation," D.
     Clark, RFC-817, July 1982.

[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 送信元アドレスの偽造に対する防御をほと
   んど提供していない。従って、データグラムの IP 送信元アドレスの認証 
   に基づく如何なるセキュリティメカニズムも、疑い深く取り扱うべきであ 
   る。しかし制限された環境では、幾つかの送信元アドレスのチェックが可 
   能であるかもしれない。例えば、他のインターネットへのゲートウェイが、
   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) に関するセクションで言及されている。

作者のアドレス

  Robert Braden
  USC/Information Sciences Institute
  4676 Admiralty Way
  Marina del Rey, CA 90292-6695

  Phone: (213) 822 1511

  EMail: Braden@ISI.EDU

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

<META> その文書に関する情報(メタ情報)を指定する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る