要約

  • classful な解釈では、Class A の一つのサブネットが親全体の経路として扱われ、他の部分がデフォルトを使えなくなる可能性があった。
  • したがって在庫の開放には、レジストリ、プロバイダー、顧客、ピア、集約、未使用部分の廃棄を同時に移行させる必要があった。
  • RFC 2036 が示したのは条件付きの危険と運用案であり、実環境での発生率や成功例ではない。

使えるはずの住所が、経路上では使えなかった

RFC 2036 は、IANA が委任レジストリを通じて、当時まだ割り当てられていなかった Class A の構成部分を classless プレフィックスとして配るという勧告案を論じた。従来の保守的な CIDR 割り当ては、Class C ネットワークを連続してまとめた superblock が中心だった。新しい集約を導入しても、古いクラス境界との整合を残せたからだ。

そのため、フルルートを持たずデフォルトだけを受け取るプロバイダーは、内部で classful な動作を続けられた。連続するクラス単位の経路は、別のプロバイダーが proxy aggregation でまとめられた。しかし Class A の大きな親から切り出した小さなプレフィックスには、この逃げ道がない。

デフォルトと Class A の一つのサブネットを同時に見たルータが、後者を親ネットワーク全体の知識に拡大すると、親の別部分への通信はデフォルトへ戻らない。デフォルトは存在し、他の宛先には働いていても、誤って広げられた経路が先に勝つ。

RFC 2036 がプロバイダーに classless routing を求めた理由はここにある。フルルートを計算するネットワークだけでなく、デフォルト依存のネットワークも対象になった。アドレスを切り出す粒度が、経路ソフトウェアの最低互換性を決めたのである。

サブネット・デフォルトの向きが反転した

非トランジットの顧客ネットワークには、さらに紛らわしい条件があった。クラス境界に合う旧来の割り当てでは、明示的な subnet default をプロバイダー側へ向けると境界ループを招くため、外へ向けないことが必要だった。ところが Class A から切り出した classless 部分を classful IGP で使う例外では、RFC 2036 はその subnet default を通常のデフォルトと同じくプロバイダーへ向けるよう求めた。

向きを変えても危険が消えるわけではない。内部の明示的なサブネット経路がプロバイダーへ漏れ、プロバイダーが正しい集約を代行することがある。レジストリが割り当てたブロック全体を集約し、未使用部分への通信を顧客へ返せば、境界でループする。配備済み部分だけを明示的に経路化すれば、未使用部分へのパケットはデフォルトを渡り歩き、デフォルトを持たない地点で初めて捨てられる。

そこで文書は、割り当てブロック内の未配備部分すべてに sink subnet route を置くよう勧めた。集約は外へ見せる状態を減らし、sink は集約が作る空洞をその場で終わらせる。両方が設定資料にあることと、実際の FIB とパケットが従うことは別の証拠である。

二本目の接続が例外を壊した

外部接続のないドメインなら、classful IGP を続けても影響を閉じ込められる。classless プロバイダーへ一本だけ接続し、正しい subnet default を持つ顧客にも限定例外があった。multi-homing ではそれが成立しない。複数プロバイダーが同じ Class A 親の別々の部分を知らせる可能性があるため、内部経路がプレフィックス長を保持しなければならない。

ピア接続は要件をさらに伝播させる。RFC の例では、classless な stub X と Y の間に classful な Z がトランジットとして存在する。X の部分経路を Z が親全体に拡大して Y へ広告すると、Y がプロバイダーから受け取ったデフォルトは上書きされる。親内の全トラフィックが Z、次いで X へ流れ、非トランジットの X でローカル外として捨てられる。

ここではプロトコルが故障している必要すらない。各装置が古い規則を忠実に実行した結果、新しい割り当て境界と意味が食い違う。自ドメインが classless でも、隣接ドメインがマスクを消せば安全ではない。

レジストリの配布順が移行政策になった

RFC 2036 は初期割り当て先を絞った。すでに classless な内部環境を運用する組織、外部接続のない組織、または classless プロバイダーへ単一接続し subnet default を外向きにできる classful 組織である。ルータ製品には classless/classful モードと、サブネット・デフォルトが通常のデフォルトを追うか sink になるかの明示設定を求めた。ホストも、クラス・サブネット・ホストという分解だけでなく、ローカル・プレフィックスを扱う必要があるとした。

翌月の RFC 2050 は、割り当てが VLSM と classless 技術の利用を前提とし、classful 利用を根拠にした申請は受け入れないと述べた。これは行政的な適格条件が技術移行と結びついた証拠だが、個々の受領者が準備済みだったことの証明ではない。

背景の ALE ワーキンググループは、IPv4 の寿命推計、利用効率、割り当て政策、経路数、回収や renumbering を扱う任務を持ち、1995年に活動を終えていた。RFC 2036 は Class C 側の在庫圧力と、Class A 上半分に残った約4分の1の空間を紹介するが、ALE の生データや配備結果は掲載していない。

Historic という結論が埋めない空白

RFC 2036 は Informational として刊行され、現在は Historic で、RFC Editor の検索では errata がない。RFC 4632 は 2006年、CIDR が全面的に配備され、歴史的な Class A 空間から classless 割り当てを行った経験が6年以上あるとして、この文書を歴史化した。

これは IETF の後年の評価として重要だが、事業者名、製品、障害件数、成功率、移行順序を示さない。RFC 4632 は同時に、集約には一致するが具体経路には一致しないパケットを集約元で null へ捨てるという一般則を残した。RFC 2036 の空洞問題が、後の CIDR アーキテクチャに定着した形である。

現在の IANA IPv4 表には、1996年の未割り当て上半分はもうない。最後の /8 選定や枯渇後配分の公式記録は在庫史を閉じるが、移行中の事故記録にはならない。

検証では六つを分けるべきだ。正確な割り当て、プロバイダーのデフォルトと輸出入、顧客 IGP と subnet default、集約の発火条件と各 sink、すべてのピアでのマスク保持、そして配備・未配備宛先の実際の next hop または廃棄点である。Heng Lu の running-code primacy は、レジストリを否定せず、記録が実行の代理証明にならないよう境界を引く。

出典