要約

  • RFC 1481はCIDRを、32ビットIP空間の寿命を延ばし、目前の経路表問題に対処する中間策として位置づけた。長期解は別途検討中だった。
  • アドレス割り当てと経路集約は同時に進む必要があったが、IAB、IANA/InterNICと登録機関、ルータベンダー、ネットワーク運用者は、それぞれ異なる実行面を握っていた。

二ページの文書ができたこと、できなかったこと

RFC 1481は短い。CIDRの目的を述べ、基本要素を二つに分け、移行期の危険を示し、IABの支持を記録する。さらにIANAとInterNIC、ルータベンダー、ネットワーク運用者の行動を支持すると明記した。

この声明は無意味な飾りではない。共同体に方向を示し、別々の組織が投資判断をしやすくした。アドレス管理者は配布方法を変える根拠を得られ、ベンダーは機能開発を優先でき、運用者は更新を計画できた。

ただし、文書自身は情報提供であってインターネット標準を定めないとした。現在のRFC Editorの記録はHistoricと表示するが、これは後世の文書状態であり、1993年7月の稼働状況ではない。

IABの声明が証明するのは支持である。どの組織にどのブロックが渡ったか、どのルータOSがプレフィックスを扱えたか、どの運用者が集約を設定したか、結果として経路表がどう変化したかは、それぞれ別の記録を要する。

延命策には二つの時計があった

RFC 1481はCIDRを「当面」の戦略と呼び、既存の32ビットアドレス空間の寿命を延ばすものとした。同時に、技術共同体が適切な長期解に取り組んでいることを前提に置いた。

RFC 1338は、クラスB番号の枯渇、ソフトウェアと人間が管理できない経路表増大、32ビット空間そのものの最終的な枯渇を区別した。CIDRが直接狙ったのは差し迫った最初の二つである。RFC 1380は、この中間作業をROADのより広い検討の中に置いた。

延命に成功すれば、長期設計のための時間が生まれる。一方で、危機感が薄れ、長期決定を先延ばしする誘因も生まれる。したがって、CIDRの開始時刻と長期解の未決定期間を一つの時計にまとめてはいけない。

後のRFC 1752はIPngの勧告を記録した。その後発の決定を、まだ長期解を特定していないRFC 1481へ遡及させることはできない。

割り当てだけ先に進むと表は膨らむ

RFC 1481はCIDRを二要素で表した。アドレス空間の割り当て管理と、経路情報を集約する仕組みである。これは独立した二機能ではなく、互いに入力を供給する組だった。

小規模ネットワークを連続したブロックから割り当てれば、提供者は一つの大きなプレフィックスで複数の宛先を表現できる。しかし、ルータと経路プロトコルが任意長プレフィックスを扱えなければ、多数のクラスC番号が個別経路として現れる。

RFC 1481は、集約が追いつかないまま割り当て方式を変えると経路表が爆発すると警告した。RFC 1338も、新しいアドレス計画は早く始められる一方、実効的な集約にはドメイン間プロトコルの変更が必要で、ずれた期間には表が急増し得ると述べた。逆に、無クラス対応プロトコルだけを導入しても、割り当てが散在したままならまとめる構造がない。

移行の健全性は「CIDR対応済み」というチェック欄では測れない。二つの系統の進捗差を測る必要がある。

登録機関は将来の集約可能性を配った

RFC 1466はIANA、Internet Registry、地域登録機関の役割を示した。地域登録機関には広い承認と公平性を求め、クラスCブロックを地理的集約に適合させる方針を記した。RFC 1367は管理指針の実施予定を提示した。

アドレス割り当ては単なる番号払い出しではなくなった。提供者のブロックから受け取ることは、その提供者の集約に入れる可能性を得ることだった。同時に、提供者変更時の再番号付けや、例外経路の必要性も将来へ持ち込んだ。

ここでも証拠は分かれる。方針文書は規則を示す。日程は予定を示す。時刻付き台帳は実際の割り当てを示す。しかし、いずれもルータが経路を広告したことを示さない。

誰が正当に配分できるのか、公平性をどう守るのか、需要をどう確認するのかも別問題である。CIDRは制度判断を技術的スケーラビリティの条件にしたが、制度をビット列へ還元したわけではない。

ベンダーは仕様と実行の間を所有した

ベンダーへの言及は、文書から稼働コードまでに独立した仕事があることを認めている。ルータは先頭ビットからクラスを推測する設計を離れ、宛先とマスクを保存し、最長一致を実行し、無クラスの到達性を交換し、必要な例外を壊さずに集約しなければならなかった。

RFC 1518の記録とRFC 1519の記録は、後に出版された割り当て設計とCIDR仕様を残す。仕様の完成度が上がっても、特定のソース、ビルド、ハードウェア、試験結果、既知障害は自動的には現れない。

製品資料の「対応」は可用性の主張である。実装の証明には成果物と試験が要る。ネットワークでの採用を証明するには、さらに導入記録が要る。

運用者はきれいな階層に例外を開けた

運用者はリリースを選び、変更リスクを負い、経路ポリシーを設定し、隣接網ごとの広告を決めた。同じ機能を持つソフトウェアでも、運用判断が違えば見える経路は違う。

RFC 1338は二つの例外を詳しく扱った。マルチホーム組織は複数提供者から明示的な経路を必要とする。提供者を変更した組織は、再番号付けが終わるまで、旧提供者の集約により具体的な経路で穴を開ける。冗長性と契約移動の自由は、完全な集約と緊張する。

RFC 1482の記録はNSFNETという特定環境のCIDR計画を指す。局所的な実装計画として重要だが、インターネット全体の実施証明ではない。

運用を立証するなら、導入バージョン、設定差分、候補経路、選択経路、転送表、生成した集約、相手別の広告とフィルタを時刻付きで残す必要がある。それでも世界全体の効果を論じるには、観測範囲を明示した時系列が別に要る。

推薦から結果まで、証人は入れ替わる

最低限でも六種類の証拠がある。IAB文書は推薦を、登録台帳は資源決定を、ビルドと試験は実行能力を、設定記録は局所導入を、相手側観測は境界通過を、測定系列は系全体の変化を支える。

一つ前の証拠を借りて空白を埋めることはできない。「支持された」「製品に入った」「設定された」「広告された」「表が抑制された」は、異なる主語と異なる時刻を持つ文である。

Heng Luの稼働コード優位、局所的将来決定と自発的採用、現実の層に関する議論は、この証人交代を理解する助けになる。象徴的な支持は行動を同期させるが、各主体の決定権を吸収しない。

RFC 1481は安全性を論じていないと明記した。成果測定も載せていない。それでも、この短い文書は重要だった。中央命令なしに共同方向を作り、その先の現実を分散したまま前進させたからである。

出典