要約

  • RFC 1380 は即時の運用措置、短期の CIDR、中期のアドレス枯渇対策、長期の Internet layer 研究を分けた。しかし開始は順番待ちにせず、すべて今すぐとした。
  • CIDR は既存アドレス体系の時間を買う施策だった。同時に policy、protocol、implementation、deployment を要し、長期案から技術者を奪う可能性も明記された。
  • recommendation、改善した指標、移行計画、architecture の選択、稼働結果は別の記録であり、一つの「解決済み」にまとめられない。

問題は三つ、時計も三つ

RFC 1380 は、Class B network number の不足、routing table の爆発、そして 32-bit IP address space の将来的な枯渇を並べた。成長は共通していても、発現時期と直し方は異なる。

中規模組織へ複数の Class C を渡せば Class B を節約できる一方、経路は増える。高性能 router は entries を多く保持できるが、増加を生む割当構造は残る。広いアドレス空間も、集約を欠けば、同じ routing 問題を広い空間へ移すだけである。

文書は hardware/protocol limit と human limit も分離した。memory、processing、update bandwidth は装置の制約であり、policy に沿う configuration と traffic monitoring は運用者の負担である。Merit NSFNET routing database と network-number assignment が約12か月で倍増していたという記述は、時点と観測面を持つ証拠だ。全 router の census でも、予測の的中証明でもない。

ROAD は結論そのものではなかった

ROAD は恒久的な通常の IETF working group ではなく、一回限りの special group だった。Santa Fe 後に集まり、対面と email で検討し、San Diego で報告した。その後の BOF、open plenary、個別 WG へ課題を渡すための器である。

だから ROAD の報告が、後の標準、番号割当、製品実装、現場移行を一括して決定したわけではない。RFC 1380 自体も Informational であり、IESG deliberations の preliminary report と名乗る。審議が存在した証拠であって、Internet Standard や execution record ではない。

近い期限に対して ROAD は CIDR を支持した。しかし bigger addresses について単一案は選ばれなかった。短期問題には範囲を限定できる介入が見え、長期問題には transition impact と implementation evidence が不足していた。この非対称こそ判断の中身だった。

phase の名前は順番を意味しない

RFC 1380 は、一つの新しい Internet layer が短期 scaling と address exhaustion と advanced function をすべて解き、近い限界より先に選択・実装・配備されるという期待を退けた。大きな installed base を変える時間も必要だった。

そこで immediate、short-term、mid-term、long-term の四段階を置く。ただし本文は、全 phase を直ちに始め、連続して実行してはならないと強調する。

これは staffing の原則でもある。「緊急」は、全員を一番近い火事へ送ることではない。終了時期の異なる各 horizon に責任者と開始点を与えることだ。長期班が暫定策の終了を待てば、暫定策はその前に users、tools、budgets、dependencies を持ち、次の installed base になる。

immediate は solved の同義語ではない

即時策は、より厳格な address assignment、allocation と aggregation の整合、未使用 Class B の回収、重要地点の router 強化、topology engineering だった。新 protocol を待たずに始められる。RFC 1380 は同時に、どれも問題を解かず、到来を遅らせるだけだと書いた。

成果の意味を拡張してはいけない。assignment policy の変更は規則の変更を示す。回収は特定資源が戻ったことを示す。upgrade は特定地点の capacity を示す。一つの vantage で table が小さくなれば、そこでの relief を示す。address exhaustion、operator workload、migration risk の終結を単独で示すものはない。

負担の移動もある。申請者は追加 evidence を出し、registry は judgment を増やし、operator は equipment cost を負う。topology の単純化は backup path や path quality と交換される場合がある。host protocol を変えない政策でも、制度的な跡は残る。

CIDR は複数主体の連鎖だった

RFC 1338 は supernetting を、Class B と table growth を遅らせて long-term solution まで橋渡しする短期策として描いた。「少なくとも三年」という見込みは planning assumption であり guarantee ではない。

benefit には、集約可能な address allocation、network-mask pair を運ぶ inter-domain protocol、router 実装と配備、non-CIDR domain や IGP との境界処理が必要だった。multihoming と provider change は more-specific route を残す。割当だけを先行し classless routing が遅れれば、移行期に table growth が加速し得る。

RFC 1380 はこのため、operational addressing plan、BGP extension、IDRP の検討、deployment planning を分けた。CIDR は現行 scheme の table explosion を抑え、Class B pressure を弱め、address exhaustion への時間を買う。単独の switch でも無償の猶予でもない。

RFC 1519 は後に CIDR 文書を改訂し、短期の bridge という位置付けを保った。文書の更新は specification の変化を示すが、実際の relief は adoption、topology、exception、vantage、期間を結合して初めて評価できる。

橋を造る人は目的地も造る

RFC 1380 が目立たせた第一のコストは transition trauma だった。Internet layer の replacement や extension は vendors、operators、users に及ぶ。short/mid-term choice は、その痛みを減らすか、long-term への滑らかな path を残さなければならない。

第二は opportunity cost である。interim measure の development と deployment は、long-term solution を含む別作業から resource を移す。同じ engineers、testbeds、change windows、operator attention は、計画名が違っても二重に使えない。

買った時間と使った能力を同じ ledger に置く必要がある。十八か月の余裕を得ても migration team を二年間占有すれば、局所の成功と programme 全体の効果は逆を向く。RFC 1380 は後年の数値を持たないが、interim choice の前に diversion を考慮せよと要求した。

urgency の前に criteria を置く

IESG は bigger-address proposal の transition impact が不明な段階で final recommendation を出さなかった。既存 operational infrastructure、protocol、routing、assignment、performance、change control の ownership、management、security、training cost を検討対象にした。Appendix B は提案ごとの point-by-point response、影響する device/function 別の変更、implementation experience を求めた。

call for proposals、Internet-Draft、public review、presentation、IESG recommendation、IAB decision は別々の artifact である。timetable は誰が何を出すかを定めても、候補の正しさを先に認定しない。

IPv6 は後日の別決定だった

RFC 1719 は、IPDecide BOF が firm direction の欠如を明らかにしたと記す。IESG に IPng recommendation の責任を置き、process の事前公開と community comment を求めた。urgency も assignment rate、policy、CIDR savings、development、fielding、migration time を結合して見積もるものになった。

RFC 1752 が1995年に別の recommendation を記録した。revised SIPP を IPng の基礎とし、protocol、autoconfiguration、transition、coexistence/testing を別作業にし、version number 6 を IPv6 と呼ぶとした。

これは RFC 1380 に IPv6 選択が隠れていたことを意味しない。むしろ、長期選択には別の evidence、open process、accountable recommendation が要ったことを示す。recommendation も universal migration、IPv4 retirement、現場 outcome の証明ではない。

出典と限界

この記事は RFC 1338、RFC 1380、RFC 1519、RFC 1719、RFC 1752 の公式本文だけを用いる。そこから当時の problem statement、recommendation、criteria、document succession は確認できる。現在の特定 network、全 forecast の精度、全 milestone の完了、特定 implementation、authorized local change、measured result は確認できない。

確認できる結論は限定的だ。1992年には既に、urgent relief と long-term replacement は別の作業でありながら同時に始めるべきだと記録されていた。interim measure には benefit、resource consumption、exit path の三記録が要る。どれかを欠けば、買った時間だけが見え、支払った未来が消える。