要約

  • RFC 1797はネットワーク39を1995年5月1日から12月1日までの実験用に指定し、旧クラスA空間を小さなプレフィックスとして扱えるかを試した。
  • Fルートの一時インターフェース 39.13.229.241 は38日間の約4億件という報告対象問い合わせの半数を大きく超えて受けたが、これは全経路の互換性証明ではない。
  • 旧アドレス 192.5.5.241 を並行稼働させたことで、古い起動情報を持つクライアントを切り捨てずに、新経路へ実負荷をかけられた。

変更しない利用者も移行設計の一部だった

Fルートサーバーを新しい Net 39 アドレスだけに切り替えていれば、実験は見かけ上単純になっただろう。しかし失敗の意味は曖昧になる。旧アドレスを持つクライアントが応答を得られないとき、問題はクラスA空間の分割なのか、単に root.cache が更新されていないのかを切り分けにくい。

RFC 1879は従来の 192.5.5.241 を残した理由を明記している。多くの利用者は起動用データを更新せず、削除すれば黒穴を作るおそれがあった。新しい 39.13.229.241 を追加し、双方を動かすことで、更新速度の異なる利用者を同時刻の切替に従わせずに済んだ。

一時アドレスは実際に使われた。報告書に引用された断片では、38日間に約4億件の問い合わせが処理され、その半数を大きく超える量が新インターフェースへ届いた。設定ファイルに一行あるという証拠ではない。経路、到達、DNSサービス、応答という複数の層を通った運用上の受領書である。

ただし対象期間、集計範囲、発信元の全分布は示されていない。この数字から全ルーター、全ホスト、全パスの互換性を導くことはできない。新しい入口が有用な規模で働いたという問いには答えるが、世界全体の採否を決める投票ではない。

期限付きのアドレス空間

RFC 1797が指定した実験期間は1995年5月1日から12月1日までだった。IANAは終了後にネットワーク39を再割当てできると記されていた。参加者が得たのは、永久の所有権ではなく、共同資源を用いた限定的な試験機会だった。

背景にはCIDRへの移行がある。固定されたA、B、Cクラスはアドレス利用と経路集約に限界を生んでいた。明示的なプレフィックス長は別の構造を提供したが、クラスを前提にするルーティングプロトコル、装置、設定は一夜で消えなかった。

RFC 1797は二つの割当て方式を提案した。第一方式は参加者のAS番号の下位15ビットをアドレスの一部に反映し、追加のアドレス登録なしで早く開始できるようにした。AS番号取得への不適切な誘因になり得る点も文書自身が認めた。第二方式では別領域からIANAが可変長プレフィックスを割り当てる構想だった。

実際に委任されたのは第一方式だけである。したがって、RFC 1879の成功評価は第二方式を検証した証拠ではなく、想定されたすべての可搬性試験を実行した記録でもない。

現在のIANA表では 039/8 は2011年1月からAPNICに割り当てられている。これは後年の独立した割当てであり、1995年の参加者との継続性を示さない。むしろ実験指定が本当に終了し、番号が共通の割当て過程へ戻ったことを示す。

有用なサービスが古い仮定を引き出した

RFC 1797は人気のあるWebやFTPサービスを置くよう求めた。結果報告にはFinger、HTTP、Telnet、FTP、Gopher、Kerberos、印刷、X、DNSが並ぶ。準備された疎通試験だけでは現れない依存関係を、実利用に近いトラフィックで露出させるためだった。

そこで旧来のクラス推定が姿を現した。意図された 39.1.28.0/24 が、古典的設定によって 39/8 全体の経路として告知された。RIPv1もプレフィックス長を保持できず、クラスAの経路を出し得た。これは悪意ある乗っ取りではない。古い規則が、新しい意図より優先された事例である。

登録簿に正しい委任が書かれていても、装置が同じプレフィックスを送るとは限らない。運用者の意図、設定、実際の告知、隣接者が受理した経路、パケットの配送、アプリケーション応答は別々の事実である。RFC 1879が記したRIPE-181の初期問題も、登録された権威と生きた告知を合わせるための作業が必要だったことを示す。

当時の装置設定には、自動集約やclassfulな転送仮定を避ける手段があった。これは現在向けの設定手順ではない。歴史的な価値は、標準の概念だけでなく、インストール済みソフトウェアの具体的挙動が互換性を決めたという点にある。

手作業で直せることの限界

参加者は明示経路や個別調整でいくつかの問題を回避できた。期間限定の実験を前へ進めるには有効だったが、多数のプロバイダーと出口を持つ日常運用には拡張しにくい。

RFC 1879はプロバイダー間協力を重大な弱点とし、特に複数出口では手動の方法が持続しないと述べる。局所的な修理が可能であることと、その修理を常時必要としないアーキテクチャであることは別だ。

報告が「成功したように見える」と慎重に結論した意味はここにある。通常のインターネットレジストリ慣行で委任されるなら、旧クラスA空間を分割できる。失敗を消した勝利宣言ではなく、成立条件を付けた判断だった。

Heng LuのRunning-Code Primacyを今日の分析枠として用いれば、RFCと登録は試験可能性を作り、告知、問い合わせ、応答が運用上の権威を与えたと読める。最小初期仕様と自発的採用の枠組みは、共通資源を期限付きにし、実装判断を各運用者に残し、拡大を観測後に決める構造を説明する。Reality Layersは登録、設定、パケット、サービスを混同しないよう求める。

これは当時の著者の用語を推測するものではない。Net 39の核心は、新しい入口を十分に本物にしながら、古い入口を壊さなかった点にある。変更しない利用者を失敗者として処罰せず、その存在を測定すべき移行条件として扱った。その可逆性があったからこそ、実験は現実の負荷に耐えられた。

情報源