RFC950 - Internet Standard Subnetting Procedure

この 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 の集まりを一つのインターネットネットワークに見せるための取り決めやプロトコルが必要になる。例えば、各々のインターネットアドレスがハードウェアアドレスにアドレス解決プロトコル (ARP: Address Resolution Protocol) を使用して変換される LAN 上では、 LAN 間のブリッジに、自側でないターゲットに対する ARP 要求を遮断することによって実現される。(RFC-925 [2]) 参照)。しかしこれは、全ての LAN 技術で可能であるとは限らない。特に、ARP プロトコルが現在使用されていない所や、LAN がブロードキャストをサポートしていなければ可能ではない。より基本的な問題は、ブリッジはホストがどの LAN 上にいるかを発見しなければならず、恐らくこれはブロードキャストアルゴリズムを使用して行われる。LAN の数が増えるにつれて、ブロードキャストのコストも増える。さらにネットワーク上のホストが増えるにつれて、ブリッジに必要とされる変換キャッシュのサイズも大きくなる。

三番目のアプローチは、明示的にサブネットをサポートすることである。これには欠点があり、既存のインターネットプロトコルを修正することになるため、既に使用されている IP 実装の変更が必要になる (もしこれらの実装がサブネット化されたネットワーク上で使用されるならば)。しかし、これらの修正は相対的に小さく、一旦修正されたらこの問題に対して簡潔で効率的な解決を生み出す。さらに、このアプローチでは、サブネット化されていないネットワーク上の既存のホストと非互換になる、いかなる変更も回避する。

さらに、適切な設計上の選択がなされたら、RFC-917 [1] で説明されているように、サブネット化されていないネットワーク上にあると思われるホストを、サブネット化されたネットワーク上で使用することが可能である。これは、サブネットを明示的にサポートするようホストの幾つかを修正することができない場合や、徐々に移行することを望む場合に便利である。

2. サブネットアドレス付けの標準

このセクションでは最初に、サブネットをサポートするためのインターネットアドレスの解釈について説明する。次にサブネットをサポートするためのホストソフトウェアへの変更について述べる。最後に、所定のネットワーク上で、何のアドレス解釈が使用されているか (何のアドレスマスクが使用されているか) を検知する手続きを提供する。

2.1. インターネットアドレスの解釈

組織がインターネットネットワーク番号を割り当て、ネットワークをサブネットの集合に分割し、ホストアドレスを割り当てたいと想定する。どのように行うべきだろうか。インターネットアドレスの "ローカルアドレス" 部の割り当てには少し制限があるため、サブネット番号を表すためのアプローチが幾つか提案された。

これらの 5 つのスキームから一つを選択する為に、どのような評価基準を使用すればよいか。そして、他のいかなる情報も参照せずにサブネット化されたネットワークを参照しているか否かを、インターネットアドレスを検査して通知することは可能だろうか。

自己符号化の興味深い特徴は、ネットワークのアドレス空間を異なるサイズのサブネットに分割できることである。通常は、アドレス空間の半分の一つのサブネットと一セットの小さなサブネットである。

例えば、クラス C のネットワークを考えてみる。それは、大規模なサブネットであるか否かを示す 1 ビットと、小規模のサブネットを識別するための追加の 3 ビットを持つ自己符号化スキームを使用するとする。もし一番目のビットが 0 ならば、これは大規模なサブネットであり、もし一番目のビットが 1 ならば、後続のビット (この例では 3) が小規模のサブネットを識別する。128 個のホストアドレスを持つ 1 つのサブネットと、16 個のホストアドレスをそれぞれ持つ 8 個のサブネットが存在する。

サブネット化の標準を確立するために、自己符号化スキームのパラメタと解釈をインターネット全体で固定化し、一貫させなければならない。

全てのネットワークはサブネット化されると想定する。これにより、他のいかなる情報も参照せずにアドレスを解釈できる。

これは重要な利点であり、インターネットアドレスを与えれば、二つのアドレスが同一のサブネット上に存在するか否かを実装体が決定するのに付加情報は必要ない。しかしこれは、欠点であるとも言える。ローカルアドレス部で任意のビットを使用している既存のホスト番号を持つネットワークでは、問題を引き起こすかもしれない。言い換えると、ホストアドレスの割り当てとは独立して、ネットワークがサブネット化されているか否かを制御できるほうが便利である。

代替手段は、アドレスとは別に保持された、ネットワークがサブネット化されているという事実を持つことである。もし誰かが何かによってネットワークがサブネット化されていることを検出したら、標準の自己符号化サブネット化ネットワークアドレス規則に従い、さもなくば非サブネット化ネットワークアドレス付け規則に従う。

もし自己符号化スキームを使用しなければ、固定長フィールドスキームを使用する理由はない。なぜなら、いかなる場合でもサブネットが使用されているか否かを示すには、ネットワーク毎に "フラグ" が存在しなければならないからである。論理型ではなく整数 (サブネットフィールド長かアドレスマスク) を使用する追加コストは、ごくわずかである。アドレスマスクスキームを使用する利点は、各々の組織が比較的少ないローカルアドレスのビットを、サブネットとホスト番号に割り当てるための最善な方法を選択できることである。従って、我々はアドレスマスクスキームを選択する。これは最も柔軟なスキームであるが、他と同様に実装するのにコストがかかる。

例えば、インターネットアドレスは以下のように解釈される。

<network-number><subnet-number><host-number>

<network-number> フィールドは IP [3] で定義され、<host-number> フィールドは少なくとも 1 ビット以上であり、<subnet-number> フィールド長は所定のネットワークにおいて固定である。<subnet-number> や <host-number> フィールドは、さらに構造化する必要はない。もし <subnet-number> フィールド長が 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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

サブネットを識別するビットはビットマスクによって指定されるので、アドレスに隣接する必要はない。しかし、サブネットビットはローカルアドレスの最上位ビットに隣接した位置にあることが推奨される。

"あるコンテキストにおいて、特定のホストの識別子ではなく、機能的な意味を持つ固定のアドレスを持つことは有効である。このような利用法が求められる時、アドレス 0 は "このネットワーク" 中の "これ" の意味として解釈される。全て 1 のアドレスは "全てのホスト" の中の "全て" の意味として解釈される。例えば、アドレス 128.9.255.255 は、ネットワーク 128.9 上の全てのホストの意味として解釈できる。あるいは、アドレス 0.0.0.37 は、このネットワークのホスト 37 の意味として解釈できる。"

これらの特別なアドレス解釈を、サブネット化されたネットワークで保持し拡張することは有効である。これはサブネットフィールドが全て 0 と全て 1 の値は、実際の (物理的な) サブネットに割当ててはならないことを意味する。

上記の例では、6 ビット長のサブネットフィールドは 0 と 63 以外のいかなる値を持ってもよい。

サブネット化されていないネットワークでは、ホストのアドレスに何の影響も新たな制限も無いことに注意されたい。

2.2. サブネットをサポートするためのホストソフトウェアへの変更

IP の大半の実装では、出力データグラムを扱うモジュールに、ローカルネットワークの宛先に直接データグラムを送信できるか、あるいはゲートウェイに送信しなければならないかを決定するためのコードが存在する。

(もしコードが複数のネットワーク接続をサポートしているならば、もっと複雑になるだろう。しかし、これは現在の議論には無関係である。)

サブネットをサポートするために、my_ip_mask と呼ばれる 1 個以上の 32 ビットサイズに格納する必要がある。これは、IP ネットワーク番号に対応するフィールドのビットセットを持つビットマスクであり、サブネット番号フィールドに対応するビットセットを追加する。

比較を実行する時にサブネットフィールドビットを考慮するため、"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 に対しアドレスマスクを検出しなければならない。

一つの潜在的な問題は、たとえ適切な回数分トライしてもアドレスマスクを検出できなければ、ホストは何を行うべきかである。この状況には、三つの解釈が考えられる。

一番目と二番目の状況は、アドレスマスクがインターネットネットワーク番号のマスクと等しいことを意味する。三番目の状況は、適当な値が何かを決定する方法が存在しない。従って最も安全なのは、インターネットネットワーク番号のマスクと等しいマスクを選択することである。これは、後で誤りであることが判明するかもしれないが、サブネット以外は成功するので、送信の妨げにはならないだろう。ホストが誤った選択から回復することは可能である。ゲートウェイは立ち上がった時に "アドレスマスク応答" をブロードキャストすべきである。そしてホストは、想定したものとは異なるメッセージを受信した時、受信した値に合わせるためにマスクを変更すべきである。ホストやゲートウェイは、"想定した" 値に基づく "アドレスマスク応答" を送信すべきではない。

最後に、ホストはアドレスマスクを発見するために、この 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 でも良い。

説明

アドレスマスク要求を受信したゲートウェイは、要求を受信したサブネットにおいて、サブネットとネットワークを区別する 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 要求を送信することである。

するとゲートウェイは、要求したホストに直接応答を返すことが出来る。

36.40.0.123 がディスクレスワークステーションで、自分自身のホスト番号も知らないと仮定する。以下のデータグラムを送信することができる。

36.40.0.62 はこのデータグラムを認識し、以下のデータグラムを応答しなければならない。

ゲートウェイは、できるだけ最も狭い範囲のブロードキャストを使用して応答することに注意されれたい。たとえ狭い範囲であっても、ブロードキャストの過剰な使用は、サブネット上の全てのホストに対して不要な負荷をもたらす。よって、"匿名" (0.0.0.0) の送信元アドレスの使用は最小限に留めなければならない。

もしブロードキャストが許されていないならば、ホストは隣接するゲートウェイに関する組み込み情報を持っているものと仮定する。この場合、36.40.0.123 は以下のデータグラムを送信しなければならない。

36.40.0.62 は前のケースと全く同じ応答を返さなければならない。

2. クラス B のネットワークの場合

このケースでは、要求側ホストがクラス B のネットワーク 128.99.0.0 上にあり、アドレス 128.99.4.123 を持ち、128.99.4.62 にゲートウェイがあり、6 ビット長のサブネットフィールドを使用する。つまりアドレスマスクは 255.255.252.0 である。

するとゲートウェイは、要求したホストに直接応答を返すことが出来る。

ディスクレスワークステーションの場合、ホストは以下を送信する。

128.99.4.62 はこのデータグラムを認識し、以下のデータグラムを応答しなければならない。

もしブロードキャストが許されていなければ、128.99.4.123 は以下を送信する。

128.99.4.62 は前のケースと全く同じ応答を返さなければならない。

3. クラス C のネットワークの場合 (隣接していないサブネットビットの例)

このケースでは、要求側ホストがクラス C ネットワーク 192.1.127.0 上にあり、192.1.127.19 のアドレスを持ち、192.1.127.50 のゲートウェイが存在し、そのネットワークでは 3 ビットのサブネットフィールド (01011000) が使用されると仮定する。すなわちアドレスマスクは 255.255.255.88 である。

その場合、ゲートウェイは直接要求側ホストに応答を返すことが出来る。

ディスクレスワークステーションの場合、ホストは以下を送信する。

192.1.127.50 はこのデータグラムを受信し、以下のデータグラムで応答しなければならない。

もしブロードキャストが許されていないならば、192.1.127.19 は以下を送信する。

192.1.127.50 は、前のケースと全く同じもので応答しなければならない。

付録 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] だけである。

参照

[3] Postel, J., "Internet Protocol", RFC-791, USC/Information Sciences Institute, September 1981.

[9] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-943, USC/Information Sciences Institute, April 1985.

Internet Standard Subnetting Procedure

Status Of This Memo

概要

謝辞