Network Working Group J. Mogul (Stanford) Request for Comments: 950 J. Postel (ISI) August 1985 Internet Standard Subnetting Procedure Status Of This Memo この RFC は、ARPA インターネット社会のプロトコルを規定する。もしサ ブネットが実装されるならば、これらの手続きに従うことが強く推奨され る。このメモの配布は制限されない。 概要 このメモは、インターネットネットワークの "サブネット" の利用法につ いて論じている。それは、論理的に目にみえる一つのインターネットネッ トワークのサブセクションである。管理上、または技術上の理由により、 多くの組織は一連のインターネットネットワーク番号を獲得する代わりに、 一つのインターネットネットワークを複数のサブネットに分割することを 選択した。このメモは、サブネットを使用するための手続きを規定する。 これらの手続きはホスト (例えばワークステーション) のためのものであ る。サブネットゲートウェイ間で使用される手続きについては、完全には 説明されていない。サブネット標準の重要な動機や背景の情報は、RFC-940 [7] に記載されている。 謝辞 このメモは RFC-917 [1] に基づいている。多くの人がここに説明されてい る概念の発展に寄与した。特に J. Noel Chiappa, Chris Kent, Tim Mann は重要な提案を行ってくれた。Zaw-Sing Su, Mike Karels, the Gateway Algorithms and Data Structures Task Force (GADS) により、このメモを 作成する際の追加寄書が寄せられた。 1. 動機 インターネット世界の元々の観点は、二つのレベルの階層であった。上の レベルはインターネット全体で、下のレベルは各々自身のネットワーク番 号を持つ個々のネットワークである。インターネットは階層的なトポロジ を持っておらず、むしろアドレスの解釈が階層的であるということである。 この二つのレベルのモデルでは、各ホストはそのネットワークを単一のエ ンティティとして見る。すなわち、ネットワークは一連のホストが接続さ れる "ブラックボックス" として扱われるだろう。 この観点は単純で力強いことが判明しているが、数多くの組織がこれを不 適切と考え、インターネットアドレスの解釈に三つ目のレベルを追加した。 この観点では、与えられたインターネットネットワークは、サブネットの 集まりに分割される。 三つのレベルのモデルは、適度な大きさの組織に属しているネットワーク で有効である (例えば、1 つ以上のビルを持つ大学や企業)。そこでは、 "ローカルエリア" をカバーするために、1 個以上の LAN ケーブルを使用 する必要がしばしばある。そして、各々の LAN をサブネットとして扱って もよい。 組織がキャンパスをカバーするために一本以上のケーブルを使用するのは、 幾つかの理由がある。 - 異なる技術: 特に研究環境では、一種類以上の LAN が存在するかも しれない。例えば、組織はイーサネットやリングネットワークをサポ ートする幾つかの装置を持っているかもしれない。 - 技術の制限: 大半の LAN の技術は電気的なパラメタに基づいて、接 続されるホストの個数やケーブルの全体長に対して制限を課している。 これらの制限、特にケーブル長を超えることは容易である。 - ネットワーク輻輳: LAN 上のホストの小規模なサブセットが、帯域の 大半を占有することは有り得る。この問題を解決する共通的な解決方 法は、ホストを上位相互通信のグループに分割し、これらのグループ を別々のケーブル上に置くことである。 - ポイントツーポイントリンク: 時々、例えば大学構内のような "ロー カルエリア" は、好ましい LAN 技術を使用して接続するにはあまり にかけ離れた二つの場所に別れることがある。この場合、高速なポイ ントツーポイントリンクが、幾つかの LAN を接続するかもしれない。 一つ以上の LAN を使用せざる得ない組織は、インターネットアドレスを割 り当てるのに三つの選択肢がある。 1. 各々のケーブルに対して、別々のインターネットネットワーク番号 を取得する。サブネットは全く使用しない。 2. 組織全体に一つのネットワーク番号を使用するが、ホストがどの LAN 上にあるかにかまわずにホスト番号を割り当てる ("透過的なサ ブネット")。 3. 一つののネットワーク番号を使用し、LAN にサブネット番号を割り 当てることによって、ホストのアドレス空間を分割する ("明示的な サブネット")。 これらのアプローチには各々欠点がある。一番目は、新規のプロトコルや プロトコルの修正は必要が無いが、インターネットルーティングテーブル のサイズの爆発を結果として引き起こす。自側の接続についての内部詳細 情報は、自組織の外側ではほとんどあるいは全く使用されないが、あらゆ る所に広められる。特に幾つかの現在のゲートウェイ実装ではルーティン グテーブル用の空間を大きく持たないので、この問題を避けた方が望まし い。 二番目のアプローチは、LAN の集まりを一つのインターネットネットワー クに見せるための取り決めやプロトコルが必要になる。例えば、各々のイ ンターネットアドレスがハードウェアアドレスにアドレス解決プロトコル (ARP: Address Resolution Protocol) を使用して変換される LAN 上では、 LAN 間のブリッジに、自側でないターゲットに対する ARP 要求を遮断する ことによって実現される。(RFC-925 [2]) 参照)。しかしこれは、全ての LAN 技術で可能であるとは限らない。特に、ARP プロトコルが現在使用さ れていない所や、LAN がブロードキャストをサポートしていなければ可能 ではない。より基本的な問題は、ブリッジはホストがどの LAN 上にいるか を発見しなければならず、恐らくこれはブロードキャストアルゴリズムを 使用して行われる。LAN の数が増えるにつれて、ブロードキャストのコス トも増える。さらにネットワーク上のホストが増えるにつれて、ブリッジ に必要とされる変換キャッシュのサイズも大きくなる。 三番目のアプローチは、明示的にサブネットをサポートすることである。 これには欠点があり、既存のインターネットプロトコルを修正することに なるため、既に使用されている IP 実装の変更が必要になる (もしこれら の実装がサブネット化されたネットワーク上で使用されるならば)。しかし、 これらの修正は相対的に小さく、一旦修正されたらこの問題に対して簡潔 で効率的な解決を生み出す。さらに、このアプローチでは、サブネット化 されていないネットワーク上の既存のホストと非互換になる、いかなる変 更も回避する。 さらに、適切な設計上の選択がなされたら、RFC-917 [1] で説明されてい るように、サブネット化されていないネットワーク上にあると思われるホ ストを、サブネット化されたネットワーク上で使用することが可能である。 これは、サブネットを明示的にサポートするようホストの幾つかを修正す ることができない場合や、徐々に移行することを望む場合に便利である。 2. サブネットアドレス付けの標準 このセクションでは最初に、サブネットをサポートするためのインターネ ットアドレスの解釈について説明する。次にサブネットをサポートするた めのホストソフトウェアへの変更について述べる。最後に、所定のネット ワーク上で、何のアドレス解釈が使用されているか (何のアドレスマスク が使用されているか) を検知する手続きを提供する。 2.1. インターネットアドレスの解釈 組織がインターネットネットワーク番号を割り当て、ネットワークをサ ブネットの集合に分割し、ホストアドレスを割り当てたいと想定する。 どのように行うべきだろうか。インターネットアドレスの "ローカルア ドレス" 部の割り当てには少し制限があるため、サブネット番号を表す ためのアプローチが幾つか提案された。 1. 可変長フィールド: ローカルアドレス部の数個のビットがサブネ ット番号として使用される。このフィールドのサイズは、所定の ネットワークでは固定サイズになるが、ネットワーク全体では可 変である。もしフィールド長が 0 ならば、サブネットは使用さ れていない。 2. 固定長フィールド: もしサブネットが使用されていれば、ある特 定のビット数 (例えば 8) がサブネット番号として使用される。 3. 自己符号化可変長フィールド: ネットワーク番号フィールドの幅 (すなわちクラス) が高次ビットによって符号化されるのと同様 に、サブネットフィールドの幅が符号化される。 4. 自己符号化固定長フィールド: 特定の個数のビットがサブネット 番号として使用される。 5. マスクビット: ローカルアドレスフィールドのどのビットがサブ ネット番号を示しているかを識別するために、ビットマスク (" アドレスマスク") を使用する。 これらの 5 つのスキームから一つを選択する為に、どのような評価基 準を使用すればよいか。そして、他のいかなる情報も参照せずにサブネ ット化されたネットワークを参照しているか否かを、インターネットア ドレスを検査して通知することは可能だろうか。 自己符号化の興味深い特徴は、ネットワークのアドレス空間を異な るサイズのサブネットに分割できることである。通常は、アドレス 空間の半分の一つのサブネットと一セットの小さなサブネットであ る。 例えば、クラス C のネットワークを考えてみる。それは、大規 模なサブネットであるか否かを示す 1 ビットと、小規模のサブ ネットを識別するための追加の 3 ビットを持つ自己符号化スキ ームを使用するとする。もし一番目のビットが 0 ならば、これ は大規模なサブネットであり、もし一番目のビットが 1 ならば、 後続のビット (この例では 3) が小規模のサブネットを識別する。 128 個のホストアドレスを持つ 1 つのサブネットと、16 個のホ ストアドレスをそれぞれ持つ 8 個のサブネットが存在する。 サブネット化の標準を確立するために、自己符号化スキームのパラ メタと解釈をインターネット全体で固定化し、一貫させなければな らない。 全てのネットワークはサブネット化されると想定する。これにより、 他のいかなる情報も参照せずにアドレスを解釈できる。 これは重要な利点であり、インターネットアドレスを与えれば、 二つのアドレスが同一のサブネット上に存在するか否かを実装体 が決定するのに付加情報は必要ない。しかしこれは、欠点である とも言える。ローカルアドレス部で任意のビットを使用している 既存のホスト番号を持つネットワークでは、問題を引き起こすか もしれない。言い換えると、ホストアドレスの割り当てとは独立 して、ネットワークがサブネット化されているか否かを制御でき るほうが便利である。 代替手段は、アドレスとは別に保持された、ネットワークがサブネ ット化されているという事実を持つことである。もし誰かが何かに よってネットワークがサブネット化されていることを検出したら、 標準の自己符号化サブネット化ネットワークアドレス規則に従い、 さもなくば非サブネット化ネットワークアドレス付け規則に従う。 もし自己符号化スキームを使用しなければ、固定長フィールドスキーム を使用する理由はない。なぜなら、いかなる場合でもサブネットが使用 されているか否かを示すには、ネットワーク毎に "フラグ" が存在しな ければならないからである。論理型ではなく整数 (サブネットフィール ド長かアドレスマスク) を使用する追加コストは、ごくわずかである。 アドレスマスクスキームを使用する利点は、各々の組織が比較的少ない ローカルアドレスのビットを、サブネットとホスト番号に割り当てるた めの最善な方法を選択できることである。従って、我々はアドレスマス クスキームを選択する。これは最も柔軟なスキームであるが、他と同様 に実装するのにコストがかかる。 例えば、インターネットアドレスは以下のように解釈される。 フィールドは IP [3] で定義され、 フィールドは少なくとも 1 ビット以上であり、 フィ ールド長は所定のネットワークにおいて固定である。 フィールドは、さらに構造化する必要はない。もし フィールド長が 0 ならば、そのネットワークはサブ ネット化されていない (すなわち [3] の解釈が使用される)。 例えば、 6 ビットのサブネットフィールド長を持つクラス B のネット ワークでは、アドレスは以下の様に区切られる。 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0| NETWORK | SUBNET | Host Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ サブネットを識別するビットはビットマスクによって指定されるので、 アドレスに隣接する必要はない。しかし、サブネットビットはローカル アドレスの最上位ビットに隣接した位置にあることが推奨される。 特別なアドレス: 番号割当てのメモ [9] より。 "あるコンテキストにおいて、特定のホストの識別子ではなく、 機能的な意味を持つ固定のアドレスを持つことは有効である。こ のような利用法が求められる時、アドレス 0 は "このネットワ ーク" 中の "これ" の意味として解釈される。全て 1 のアドレ スは "全てのホスト" の中の "全て" の意味として解釈される。 例えば、アドレス 128.9.255.255 は、ネットワーク 128.9 上の 全てのホストの意味として解釈できる。あるいは、アドレス 0.0.0.37 は、このネットワークのホスト 37 の意味として解釈 で きる。" これらの特別なアドレス解釈を、サブネット化されたネットワーク で保持し拡張することは有効である。これはサブネットフィールド が全て 0 と 全て 1 の値は、実際の (物理的な) サブネットに割当 ててはならないことを意味する。 上記の例では、6 ビット長のサブネットフィールドは 0 と 63 以外のいかなる値を持ってもよい。 サブネット化されていないネットワークでは、ホストのアドレスに 何の影響も新たな制限も無いことに注意されたい。 2.2. サブネットをサポートするためのホストソフトウェアへの変更 IP の大半の実装では、出力データグラムを扱うモジュールに、ローカ ルネットワークの宛先に直接データグラムを送信できるか、あるいはゲ ートウェイに送信しなければならないかを決定するためのコードが存在 する。 通常、そのコードは以下のようなものである。 IF ip_net_number(dg.ip_dest) = ip_net_number(my_ip_addr) THEN send_dg_locally(dg, dg.ip_dest) ELSE send_dg_locally(dg, gateway_to(ip_net_number(dg.ip_dest))) (もしコードが複数のネットワーク接続をサポートしているならば、も っと複雑になるだろう。しかし、これは現在の議論には無関係であ る。) サブネットをサポートするために、my_ip_mask と呼ばれる 1 個以上の 32 ビットサイズに格納する必要がある。これは、IP ネットワーク番号 に対応するフィールドのビットセットを持つビットマスクであり、サブ ネット番号フィールドに対応するビットセットを追加する。 その場合、コードは以下のようになる。 IF bitwise_and(dg.ip_dest, my_ip_mask) = bitwise_and(my_ip_addr, my_ip_mask) THEN send_dg_locally(dg, dg.ip_dest) ELSE send_dg_locally(dg, gateway_to(bitwise_and(dg.ip_dest, my_ip_mask))) 勿論、条件評価式の一部は事前に算出できる。 比較を実行する時にサブネットフィールドビットを考慮するため、 "gateway_to" 関数を修正する必要があるかもしれないし、必要ないか もしれない。 複数接続するホストをサポートするために、上記のコードは "my_ip_addr" と "my_ip_mask" を、インタフェース毎に保持するよう 修正できる。その場合条件評価式は、各々のインタフェースに対して評 価しなければならない。 2.3. アドレスマスクの検出 ホストは、接続されているサブネット上で何のアドレスマスクが使用さ れているかをどのようにして決定できるだろうか。この問題はインター ネットホストの他の幾つかの "ブートストラッピング" の問題: ホスト はどのように自分のアドレスを決定するか、どのようにゲートウェイを ローカルネットワークで位置づけるか、という問題に類似している。3 つの全てのケースにおいて、2 つの基本的な解決方法がある。それは "ハード組み込み" 情報とブロードキャストベースのプロトコルである。 ハード組み込み情報は、ネットワークとは独立してホストで利用できる。 それは内部に組み込んでもよいし、(望ましくは) ディスクファイルに 格納してもよい。しかし、ますます共通的に行われつつある、LAN 上で ブートロードされるディスクレスワークステーションのケースでは、い ずれの "ハード組み込み" 情報の解決方法も十分ではない。 その代わり、大半の LAN 技術はブロードキャストをサポートしている ので、より良い方法は、新たにブートされたホストが、必要な情報のた めの要求をブロードキャストすることである。例えば、自身のインター ネットアドレスを決定するために、ホストは "逆アドレス解決プロトコ ル (RARP: Reverse Address Resolution Protocol)" [4] を使用しても よい。 しかし、新たにブートされたホストはたいてい複数の要素 (例えば自分 の IP アドレス、ゲートウェイのハードウェアアドレス、ドメイン名サ ーバの IP アドレス、サブネットアドレスマスク等) を採集する必要が あるので、可能ならばこれら全ての情報を、ネットワーク上に数多くの ブロードキャストを流すのではなく、一回の要求で獲得できる方がよい。 ディスクレスワークステーションをブートするために設計されたメカニ ズムは、必要な情報 (例えば RFC-951 [8] 参照) を含む、ホスト毎に 特定な設定ファイルをロードすることもできる。1 つのブロードキャス トメッセージだけを使用して、ブートサーバからホストを処理するのに 必要な全ての要素を獲得することは、可能であり望ましいことである。 ホストが異なる処理でアドレスマスクを検出する必要がある場合、以下 のメカニズムが提供される。 アドレスマスク情報を提供するために、ICMP プロトコル [5] を拡 張して、ICMP メッセージタイプの新しいペア、"アドレスマスク要 求" と "アドレスマスク応答" を追加する。これらは、ICMP メッセ ージの "情報要求" と "情報応答" と同様なものである。これらの 詳細については、付録 I で説明されている。 これらの新しい ICMP メッセージの使用は、ホストがブートされる 時、"アドレスマスク要求" メッセージをブロードキャストすること を意図している。このメッセージを受信したゲートウェイ (あるい はゲートウェイの代わりに動作するホスト) は、"アドレスマスク応 答" で応答する。もし、その要求中にどのホストが送信したかの指 定が無ければ (すなわち IP の送信元アドレスが 0)、その応答もま たブロードキャストされる。要求したホストはその応答を受信して、 サブネットフィールド長を決定するだろう。 いかなる LAN でも "アドレスマスク応答" で送信できる値は一つし かないので、要求したホストが受信した応答を、送信した要求に対 して照合する必要はない。同様に、一つ以上のゲートウェイが応答 しても問題はない。ホストのリブートは頻繁に行われないことが想 定されるので、このプロトコルを使用することによるネットワーク 上のブロードキャストの負荷は小さいはずである。 もしホストが一つ以上の LAN に接続されていたら、各々の LAN に対し アドレスマスクを検出しなければならない。 一つの潜在的な問題は、たとえ適切な回数分トライしてもアドレスマス クを検出できなければ、ホストは何を行うべきかである。この状況には、 三つの解釈が考えられる。 1. 他の全てのネットワークから (永久的に) 独立したローカルネッ トワークが存在する。 2. サブネットが使用されず、アドレスマスクを供給するホストがな い。 3. ローカルネットワーク上の全てのゲートウェイが (一時的に) ダ ウンしている。 一番目と二番目の状況は、アドレスマスクがインターネットネットワー ク番号のマスクと等しいことを意味する。三番目の状況は、適当な値が 何かを決定する方法が存在しない。従って最も安全なのは、インターネ ットネットワーク番号のマスクと等しいマスクを選択することである。 これは、後で誤りであることが判明するかもしれないが、サブネット以 外は成功するので、送信の妨げにはならないだろう。ホストが誤った選 択から回復することは可能である。ゲートウェイは立ち上がった時に " アドレスマスク応答" をブロードキャストすべきである。そしてホスト は、想定したものとは異なるメッセージを受信した時、受信した値に合 わせるためにマスクを変更すべきである。ホストやゲートウェイは、" 想定した" 値に基づく "アドレスマスク応答" を送信すべきではない。 最後に、ホストはアドレスマスクを発見するために、この ICMP プロト コルを使用する必要はないことに注意されたい。不揮発性メモリを持つ ホストが格納された情報 (ブートサーバからの設定ファイルを含む) を 使用することは、非常に効率的である。 付録 I. アドレスマスク ICMP アドレスマスク要求とアドレスマスク応答 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP フィールド Addresses アドレスマスク要求メッセージ中の送信元アドレスは、アドレス マスク応答メッセージの宛先になるだろう。アドレスマスク応答 メッセージを作成するために、要求の送信元アドレスは応答の宛 先アドレスになり、応答の送信元アドレスには応答者のアドレス が設定され、タイプコードは AM2 に変更され、アドレスマスク フィールドにアドレスマスクの値が挿入され、チェックサムが再 計算される。しかし、もし要求メッセージの送信元アドレスが 0 ならば、応答メッセージの宛先アドレスはブロードキャストを示 さなければならない。 ICMP フィールド: Type アドレスマスク要求メッセージは AM1。 アドレスマスク応答メッセージは AM2。 Code アドレスマスク要求メッセージは 0。 アドレスマスク応答メッセージは 0。 Checksum チェックサムは、ICMP タイプから開始される ICMP メッセージ の 1 の補数の合計の 1 の補数である。チェックサムを計算する 際は、チェックサムフィールドは 0 としなければならない。こ のチェックサムフィールドは、将来置き換わるかもしれない。 Identifier 要求と応答の照合を助けるための識別子。0 でも良い。 Sequence Number 要求と応答の照合を助けるためのシーケンス番号。0 でも良い。 Address Mask 32 ビットマスク 説明 アドレスマスク要求を受信したゲートウェイは、要求を受信したサ ブネットにおいて、サブネットとネットワークを区別する 32 ビッ トマスクを、アドレスマスクフィールドに設定して返却しなければ ならない。 もし要求側ホストが自分自身の IP アドレスを知らなかったら、送 信元フィールドを 0 としてもよく、その応答はブロードキャストさ れるはずである。しかしこのアプローチは、ネットワーク上に余分 なブロードキャストの負荷を高めるので、可能な限り避けるべきで ある。応答がブロードキャストされた時でさえも、サブネットのア ドレスマスクは一つしか存在し得ないので、要求と応答を照合する 必要はない。"Identifier" と "Sequence Number" フィールドは無 視できる。 タイプ AM1 は、ゲートウェイかホストから受信される。 タイプ AM2 は、ゲートウェイか、ゲートウェイの代わりとして 動作しているホストから受信される。 付録 II. 例 これらの例は、ICMP アドレスマスク要求とアドレスマスク応答メッセージ を使用して、どのようにホストがアドレスマスクを検出できるかを示して いる。以下の例では、アドレス 255.255.255.255 は "この物理メディアへ のブロードキャスト" [6] を示す。 1. クラス A のネットワークの場合 このケースでは、要求側ホストがクラス A のネットワーク 36.0.0.0 上にあり、アドレス 36.40.0.123 を持ち、36.40.0.62 にゲートウェイ があり、8 ビット長のサブネットフィールドを使用する。つまりアドレ スマスクは 255.255.0.0 である。 我々が推奨する最も効果的な方法は、ホストが最初に自分自身のアドレ スを検出し (恐らく "RARP" [4] を使用する)、その後で 255.255.255.255 に ICMP 要求を送信することである。 Source address: 36.40.0.123 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 するとゲートウェイは、要求したホストに直接応答を返すことが出来る。 Source address: 36.40.0.62 Destination address: 36.40.0.123 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.0.0 36.40.0.123 がディスクレスワークステーションで、自分自身のホスト 番号も知らないと仮定する。以下のデータグラムを送信することができ る。 Source address: 0.0.0.0 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 36.40.0.62 はこのデータグラムを認識し、以下のデータグラムを応答 しなければならない。 Source address: 36.40.0.62 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.0.0 ゲートウェイは、できるだけ最も狭い範囲のブロードキャストを使用し て応答することに注意されれたい。たとえ狭い範囲であっても、ブロー ドキャストの過剰な使用は、サブネット上の全てのホストに対して不要 な負荷をもたらす。よって、"匿名" (0.0.0.0) の送信元アドレスの使 用は最小限に留めなければならない。 もしブロードキャストが許されていないならば、ホストは隣接するゲー トウェイに関する組み込み情報を持っているものと仮定する。この場合、 36.40.0.123 は以下のデータグラムを送信しなければならない。 Source address: 36.40.0.123 Destination address: 36.40.0.62 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 36.40.0.62 は前のケースと全く同じ応答を返さなければならない。 Source address: 36.40.0.62 Destination address: 36.40.0.123 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.0.0 2. クラス B のネットワークの場合 このケースでは、要求側ホストがクラス B のネットワーク 128.99.0.0 上にあり、アドレス 128.99.4.123 を持ち、128.99.4.62 にゲートウェ イがあり、6 ビット長のサブネットフィールドを使用する。つまりアド レスマスクは 255.255.252.0 である。 このホストは、ICMP 要求を 255.255.255.255 に送信する。 Source address: 128.99.4.123 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 するとゲートウェイは、要求したホストに直接応答を返すことが出来る。 Source address: 128.99.4.62 Destination address: 128.99.4.123 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.252.0 ディスクレスワークステーションの場合、ホストは以下を送信する。 Source address: 0.0.0.0 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 128.99.4.62 はこのデータグラムを認識し、以下のデータグラムを応答 しなければならない。 Source address: 128.99.4.62 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.252.0 もしブロードキャストが許されていなければ、128.99.4.123 は以下を 送信する。 Source address: 128.99.4.123 Destination address: 128.99.4.62 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 128.99.4.62 は前のケースと全く同じ応答を返さなければならない。 Source address: 128.99.4.62 Destination address: 128.99.4.123 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.252.0 3. クラス C のネットワークの場合 (隣接していないサブネットビットの例) このケースでは、要求側ホストがクラス C ネットワーク 192.1.127.0 上にあり、192.1.127.19 のアドレスを持ち、192.1.127.50 のゲートウェ イが存在し、そのネットワークでは 3 ビットのサブネットフィールド (01011000) が使用されると仮定する。すなわちアドレスマスクは 255.255.255.88 である。 ホストは 255.255.255.255 に以下の ICMP 要求を送信する。 Source address: 192.1.127.19 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 その場合、ゲートウェイは直接要求側ホストに応答を返すことが出来る。 Source address: 192.1.127.50 Destination address: 192.1.127.19 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.255.88. ディスクレスワークステーションの場合、ホストは以下を送信する。 Source address: 0.0.0.0 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 192.1.127.50 はこのデータグラムを受信し、以下のデータグラムで応 答しなければならない。 Source address: 192.1.127.50 Destination address: 255.255.255.255 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.255.88. もしブロードキャストが許されていないならば、192.1.127.19 は以下 を送信する。 Source address: 192.1.127.19 Destination address: 192.1.127.50 Protocol: ICMP = 1 Type: Address Mask Request = AM1 Code: 0 Mask: 0 192.1.127.50 は、前のケースと全く同じもので応答しなければならな い。 Source address: 192.1.127.50 Destination address: 192.1.127.19 Protocol: ICMP = 1 Type: Address Mask Reply = AM2 Code: 0 Mask: 255.255.255.88 付録 III. 用語 ブリッジ(Bridge) 二つ以上の管理上区別されないが物理的には別のサブネットに接続され たノードで、必要時に自動的にデータグラムを転送する。しかし、その 存在は他のホストには認識されない。"ソフトウェアリピータ" と呼ば れることもある。 ゲートウェイ(Gateway) 二つ以上の管理上区別されるネットワークやサブネットに接続されたノ ードで、ホストはそこにデータグラムを送信する。 ホストフィールド(Host Field) 特定のホストを示すために使用されるインターネットアドレスのビット フィールド。 インターネット(Internet) IP プロトコルを使用して接続されたネットワークの集まり。 ローカルアドレス(Local Address) インターネットアドレスの残りのフィールド ([3]で定義されているも の) ネットワーク(Network) 単一のインターネットネットワーク (サブネットに分割されていてもい なくてもよい) ネットワーク番号(Network Number) インターネットアドレスのネットワークフィールド。 サブネット(Subnet) インターネットネットワークの部分的な集合を形成する一つ以上の物理 的なネットワーク。サブネットはインターネットアドレスで明示的に識 別される。 サブネットフィールド(Subnet Field) サブネット番号を表すインターネットアドレス中のビットフィールド。 このフィールドを生成するビットは、アドレス内でで連続している必要 はない。 サブネット番号(Subnet Number) ネットワーク内でサブネットを識別する番号。 付録 IV. 割当て番号 以下の割り当て番号が、サブネットをサポートするのに使用されるプロト コルパラメタとして割り当てられる。この割り当て番号が必要とされるの は、ICMP (Internet Control Message Protocol) [5] だけである。 ICMP Message Types AM1 = 17 AM2 = 18 参照 [1] Mogul, J., "Internet Subnets", RFC-917, Stanford University, October 1984. [2] Postel, J., "Multi-LAN Address Resolution", RFC-925, USC/Information Sciences Institute, October 1984. [3] Postel, J., "Internet Protocol", RFC-791, USC/Information Sciences Institute, September 1981. [4] Finlayson, R., T. Mann, J. Mogul, M. Theimer, "A Reverse Address Resolution Protocol", RFC-903, Stanford University, June 1984. [5] Postel, J., "Internet Control Message Protocol", RFC-792, USC/Information Sciences Institute, September 1981. [6] Mogul, J., "Broadcasting Internet Datagrams", RFC-919, Stanford University, October 1984. [7] GADS, "Towards an Internet Standard Scheme for Subnetting", RFC-940, Network Information Center, SRI International, April 1985. [8] Croft, B., and J. Gilmore, "BOOTP -- UDP Bootstrap Protocol", RFC-951, Stanford University, August 1985. [9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-943, USC/Information Sciences Institute, April 1985.