要約

  • RFC 917は標準ではなく、スタンフォードで1982年初めから使われていたIPサブネットを記録した。1984年の報告値は約330ホスト、18サブネットだった。
  • スタンフォードは既存のPupネット番号をIPサブネットに対応させた。RFC 917はネットワークごとの幅を許す方式を提案し、RFC 950が1985年にホスト手順を標準化した。

標準文書が出た日を、運用が始まった日と見なすと、RFC 917の記録を読み違える。ジェフリー・モーグルが1984年10月に出した『Internet Subnets』は、議論と改善案を求める提案だった。その本文は、スタンフォードでIPサブネットが1982年初めから使われていたと記す。執筆時点の規模は約330ホスト、18サブネット、同程度の数のサブネット・ゲートウェイだった。

足場になったのは既存のPup網だ。スタンフォードは1979年から複数の実験用EthernetでPupを運用していた。IP導入時に8ビットのサブネット番号を選び、それぞれをEthernet上のPupネットワーク番号に対応させた。Pupの8ビット・ホスト番号もIPのホスト欄に引き継がれた。新しいアドレス構造は、旧来の識別子や経路表を一挙に捨てる形ではなかった。

ゲートウェイの動作も単純な移行ではない。Pupしか理解しないゲートウェイは、Pupの経路表に従ってIPデータグラムを転送したが、IPヘッダーのTime-to-Liveは更新しなかった。一方、複数ネットワークに接続され、ゲートウェイを兼ねるInternetホストはTTLを調整した。モーグルはこの運用で転送ループの不具合は見られなかったと報告する。これはスタンフォードの観察値であり、TTLを扱わなくてもよいという一般則ではない。

IP経路表はPupの経路表と同じ更新過程で維持し、Pupのネット番号をIPサブネット番号へ読み替えた。後に10 Mbit/s Ethernetを加えた際、ゲートウェイはARPを使う方式に変更され、未改修のホストを接続できた。拡張の焦点はアドレス欄だけでなく、既存機器が新しいリンクに参加できる境界にもあった。

MITは別の制約から出発した。ネットワーク番号がクラスに分かれる前、すべてのローカルリンクに別々のIPネット番号を割り当てれば、利用可能な空間のかなりの部分を使う。そこでMITはネット番号を一つに保ち、24ビットの「残り」をサブネット、ゼロ固定の予約欄、ホストに8ビットずつ分けた。サブネット番号はCHAOSの番号と揃えた。ゲートウェイ間の動的経路交換は計画されたものの実装されず、静的表が残った。ICMP Host Redirectを使うことで、ホスト側の変更を抑えた。

RFC 917は、可変幅、固定幅、自己符号化の可変幅と固定幅という四方式を比べた。提案したのは、同一ネットワーク内では幅を一定にし、ネットワークごとには選択を変えられる方式である。アドレスを見ればサブネットの有無が分かる自己符号化は便利に見える一方、既存のホスト番号を制約し、ローカルアドレス空間も減らしかねない。何ビットをサブネットに割くかは、組織側に残された。

ディスクレス端末がその幅を知るにはどうするか。RFC 917はICMPのAddress Format RequestとAddress Format Replyを提案したが、不揮発性設定を使う選択肢も残す。ゲートウェイから応答がなくても端末は幅ゼロと仮定して起動し、後にゲートウェイが実際の値を知らせれば修正できる。RFC 950の後年のAddress Maskメッセージとは別の提案である。

1985年4月のRFC 940は、ベンダーごとに方式が違えば混在環境のホストが互換にならないという問題を明示した。8月のRFC 950はRFC 917を基礎に、サブネットを使う場合のホスト手順を強く推奨する標準となる。ただしゲートウェイ間の手順は完全には定めていない。実運用、共通案、標準化の順序を分けて読む必要がある。

Heng LuのNote 64は、共通の最小ルールと組織ごとの選択を考えるための編集上のレンズだ。モーグルやスタンフォード、MIT、Postelの意図を示す史料ではない。