概要
- RFC 1466 のクラスフルな閾値と段階的な Class C ルールは RFC 2050 のクラスレスフレームワークに取って代わられたが、1993 年の計画には地域委任、申請者情報開示、裁量的レビューに関する期限切れ条項（サンセット）が含まれていなかった。
- 公開記録は、テキスト上の再発と 1993 年時点のフォームレベルでの実装を示しているが、リクエスト、拒否、例外、監査、控訴、結果の分母を欠いているため、後の制度的持続性は運用証拠なしに 1993 年の計画に帰属させることはできない。
タイトルは仮説であり、引用ではない
「一時的」という形容詞は本記事の遡及的仮説である。1993 年 5 月の計画であるRFC 1466では、「一時的」「暫定的」「サンセット」のいずれの表現も使われていない。割り当てルールに有効期限は設定されておらず、関連する地域機関の再検討スケジュールも示されていない。その結論では、勧告は枯渇を遅らせるものであり、無期限に延期するものではないと述べられている。これは限定的な技術的有効性を確立するものであり、制度的な期限が約束されていたことを確立するものではない。
この区別は不可欠である。なぜなら RFC 1466 は複数の異なる介入を組み合わせていたからだ。それは望ましいクラスフルネットワーク番号、特に Class B ユニットの不足に対処した。将来の番号計画のためにアドレス空間を予約しようとした。新たに登場した集約技術が連続ブロックを使用できるように Class C の割り当てを調整した。ますます国際化するユーザーに対応する手段として地理的に分散した登録を提案した。申請者にネットワーク計画の開示を求め、レジストリに例外を判断する権限を残した。
これらの介入が同じ寿命を共有していたわけではない。クラスフルなテストは、すでに圧力を受けていた技術環境に結びついていた。地理的な Class C ブロックは、一部は管理上の配置であり、一部は集約の準備だった。申請者の開示とレジストリの判断は、再利用可能な管理能力だった。地域組織は、当初の Class B 対 Class C 問題がもはや割り当てサイズを決定しなくなった後でも、申請者へのサービスを継続することができた。
計画の冒頭では、ネットワーク番号の需要が過去 2 年間で著しく増加したと説明されていた。インターネットレジストリを主要かつデフォルトのレジストリとして維持しつつ、適格な組織がブロックと割り当て責任を受け取ることを提案していた。その掲げられたサービスの目的はグローバルな多様性であり、申請者に近いレジストリの方が現地の言語や慣習をよりよく理解できるかもしれないという考えだった。技術的な目的は枯渇とルーティングの圧力に関するものだった。これらの議論は一つの文書に収束したが、それらを一つの切り離せない任務として扱うべきではない。
RFC 1466 は Informational として公開された。そのアブストラクトは、Federal Engineering Planning Group、Intercontinental Engineering Planning Group の共同議長、および RIPE の間で、勧告を支持する一般的な合意があったと記録している。これは指名された技術グループによるレビューの証拠ではあるが、インターネットサービスプロバイダ、ネットワーク加入者、申請者を代表する分母ではなく、オペレータ全体の同意を証明するものではない。
また、RFC 1466 は後にこれに関連付けられるようになるすべての地域的な発展を生み出したわけではない。この文書は、提案が採択される前に RIPE NCC が Class C ブロックを受け取っていたことを述べている。後の回顧的説明であるRFC 7020は、責任を地域機関に委任する提案を RFC 1366 まで遡って追跡している。したがって、RFC 1466 は、既に発展しつつあった地域プロセスに特定の条項を成文化、改訂、関連付けたものである。それを単独で地域管理を創設したと説明するのは安全ではない。
有用な問いは、計画全体が恒久的になったかどうかというよりも狭い。どの技術ルールが権威を失ったのか？どの管理能力が後のテキストに再登場したのか？どの条項が申請者によって使用される日付入りの形式に到達したのか？どの制度的役割が変更された技術的根拠の下で再び記述されたのか？そして、テキスト上の系譜から継続的な運用や因果関係の主張へと移行するには、どのような証拠が必要だろうか？
クラスフル単位での不足
RFC 1466 の冒頭の数字は、その単位が個々のアドレスではなくネットワーク番号だったため、誤って読み取られやすい。文書は 1992 年 5 月時点の割り当て統計を再掲している。Class A の行は 126 のネットワーク番号ユニット総数と 49 が割り当て済みと記載されている。表には 38 パーセントと印刷されているが、計算は49 / 126 = 38.888889%であり、38 ではなく 39 パーセントに丸められる。この不一致は、公開された表の特徴として保存されるべきであり、数学的に正確な結果に黙って変換されるべきではない。
Class B の行は、16,383 のネットワーク番号ユニットと 7,354 が割り当て済みと記載されている。ここでは7,354 / 16,383 = 44.887994%であり、印刷された 45 パーセントと一致する。Class C の行は、2,097,151 のネットワーク番号ユニットと 44,014 が割り当て済みと記載されている。その比率44,014 / 2,097,151 = 2.098752%は、整数パーセンテージで表すと印刷された 2 パーセントと一致する。
これらの比率はいずれも、接続されたホスト、対応した申請者、承認されたリクエスト、アナウンスされたプレフィックス、アドレス使用率、拒否、同意を測定するものではない。それらは、割り当てられたクラスフルなネットワーク番号スロットを、該当するクラスについて印刷された分母と比較しているに過ぎない。Class A、Class B、Class C はホストアドレス値の量が根本的に異なるため、行同士を交換可能に扱うことはできない。
RFC 1466 は別途、Class A は全 IP ホストアドレスの 50 パーセント、Class B は 25 パーセント、Class C は約 12 パーセントを占めると特徴付けている。理論上の Class C の割合は、IPv4 空間全体の 12.5 パーセントである。このアドレス空間の分布は、Class C ネットワーク番号ユニットのわずか約 2 パーセントしか割り当てられていなくても、懸念が依然として強かった理由を説明するのに役立つ。当面の問題は、単純にすべての未加工の IPv4 値の数え上げではなかったのだ。
クラスフルアドレッシングは、組織に急激に不連続な選択肢を提供した。Class C ネットワークには 256 の未加工アドレス値が含まれていた。当時の慣習的なネットワーク識別子とブロードキャスト識別子の扱いの下では、254 の使用可能なホスト識別子を提供した。Class B ははるかに大きなホストフィールドを提供した。そのため、多くの組織は、たとえ予測されるホスト数が Class B の容量の一部に過ぎなくても、多数の Class C ネットワークを結合する運用上の複雑さよりも Class B を好んだ。
結果として生じた不足には少なくとも三次元あった。第一に、Class B ネットワーク番号ユニットは、その有限な数に対して急速に消費されつつあった。第二に、大きな割り当てはそのアドレス容量のかなりの部分を未使用のままにする可能性があった。第三に、一つの Class B を多数の Class C ネットワークで置き換えることは、集約技術とトポロジがそれらのネットワークをまとめて表現することを許可しない限り、ルーティングエントリを増大させる可能性があった。
RFC 1466 はこの三つすべてに対処したが、単一の指標でではない。その Class B 制限は望ましいクラスフルユニットを温存した。その Class C スケジュールは、予測された必要性を連続割り当てに変換した。その地理的ブロックは、潜在的な集約と互換性のある管理構造を作り出した。その地域レジストリ条項は、これらのルールを適用する作業を分散した。この計画は、不足管理と制度設計を結びつけた。なぜなら、誰かが予測を受け取り、ネットワークアーキテクチャを評価し、機密情報を保護し、例外が正当化されるかどうかを決定しなければならなかったからだ。
これは不足に形成された応答であり、単なる工学的限界の表ではなかった。予測が証拠となると、割り当てはそれを解釈できる機関に依存することになった。複数の連続ネットワークが単一の Class B を置き換えると、割り当て者はブロックサイズと位置を決定しなければならなかった。地理的区分が主要責任の基盤となると、技術的な配分計画は同時にサービス関係も組織化した。
しかし、数字はその解釈がどこまで行けるかを制約する。この表は、あるネットワーク番号がなぜ割り当てられたかについて何も語っていない。申請の母集団、受け入れられた計画と拒否された計画の比較、計画を変更または撤回した申請者の説明は一切提供されていない。これらの統計は、ポリシーが書かれたクラスフルな設定を確立するが、個々の条項の効果を確立するものではない。
Class B の門
この計画で最も明示的な割り当ての門は Class B リクエストに関するものだった。それ以前のガイダンスは、サブネット化された Class B を複数の Class C ネットワークよりも優先していた。RFC 1466 は、複数の Class C が実用的な場合にはその優先順位を逆転させ、Class B ネットワーク番号の不足と多くの組織によるそれらの不十分な利用を引き合いに出した。
Class B を求める組織は、二つの結合基準を満たすことが期待された。32 以上のサブネットと 4,096 以上のホストを文書化したサブネット計画、そして Class C ネットワークのブロックがその設計にとって合理的でない理由を示すエンジニアリング計画を提出しなければならなかった。計画には今後 24 ヶ月間の予測ホスト数とサブネットあたりのホスト数を記載しなければならなかった。
閾値は重要だったが、それらは自動的に権利が発生するものではなかった。4,096 以上のホストなしに 32 以上のサブネットだけでは、提案された結合を満たさなかった。4,096 以上のホストがあっても、必要なサブネット構造なしでは同様だった。数値条件が示されたとしても、レジストリは依然として、そのエンジニアリング上の説明がより稀少なクラスフルユニットを正当化するかどうかを評価しなければならなかった。
用語は判断を中心に据えていた。申請者は Class C ブロックがエンジニアリング上合理的でないことを示さなければならなかった。レジストリは、申請が正当化されるかどうか、そして計画が Class B に値するかどうかを決定した。もしそうでなければ、説明された代替案は Class C ネットワーク番号のブロックだった。提出された計画は厳重に秘密として保持され、申請の判断のみに使用されることになっていた。
RFC 1466 は例外も保持していた。提案された Class B 基準を満たさなくても、組織が Class C ブロックを使用できない可能性があることを認めていた。そのような申請者はエンジニアリング上の制約を説明することができた。テキストは許容可能なトポロジをすべて列挙したり、証拠に重みを割り当てたり、レビュアーの判断を排除する公式を公開したりしなかった。
申請者より上のレベルでは、中央インターネットレジストリは、コミュニティサービスを改善する場合、小さな Class B ブロックを地域レジストリに割り当てることができた。より具体的な再割り当てガイダンスを発行し、ブロックの説明責任を要求し、申請者のエンジニアリング計画を受け取り、ガイドラインとの整合性を監査することができた。これらの条項は、権限を与えられた行為者と可能な監督形態を特定している。それらは、監査が行われたこと、どの程度の頻度で検討されたか、またはどのような結果が生じたかを示すものではない。
したがって、この取り決めは技術的前提、割り当て基準、制度的基準、例外を含んでいた。技術的前提は Class B の不足と不十分な利用だった。通常の基準は、サブネットとホストの閾値を 24 ヶ月のエンジニアリング計画と組み合わせたものだった。制度的基準は、その計画を評価し保護するレジストリの能力だった。例外は、提案された閾値の範囲外のケースでもエンジニアリング上の理由で検討されることを許可した。
その負担は非対称的だった。申請者は不確かな将来の成長を文書化されたアーキテクチャに変換しなければならなかった。レジストリは、その予測が信頼できるかどうか、そして複数の Class C が実用的かどうかについて裁量権を保持した。この非対称性は単に割り当てデータベースから生じたのではなく、要求者とレビュアーの間の証拠に基づく関係に書き込まれていたのだ。
それでも、後のあらゆる申請者情報の要求をこの Class B ルールの存続と形容するのは誤りだろう。当初のテストは、クラスフルな代替案が 2 年間の視野で実現可能かどうかを問うものだった。1996 年 11 月までに、公開されたフレームワークはプレフィックス長、使用率、段階的な割り当てを使用するようになった。予測レビューは再発したが、レビューの対象とその時間的視野は変化した。管理機能の継続は、当初の閾値の継続ではない。
連続 Class C と集約の算術
RFC 1466 は、可能な限り複数の Class C を割り当てることで Class A および Class B ユニットを温存しようとした。この対応はそれ自体がルーティング問題を生み出した。各 Class C が別々に現れると、ルーティングエントリの数が急速に増加する可能性があった。そのため、計画では Class C ユニットを集約と互換性のある、2 の累乗の連続ブロックに配置した。
地理的区分は正しい単位で記述されなければならない。RFC 1466 は、192.0.0.0 から 207.255.255.255 の範囲を 8 つのブロックに分割し、各ブロックは 2 つの先頭オクテット値をカバーしていた。各ブロックには 131,072 の Class C ネットワーク番号ユニットが含まれていた：2 × 65,536。これは理論上の 2,097,152 ユニットの Class C ネットワーク番号空間の 6.25 パーセントである。また、131,072 × 256 = 33,554,432の未加工 IPv4 アドレスでもある。
Class C ユニットの理論上の分母 2,097,152 は、RFC 1466 の割り当て表に印刷された 2,097,151 の合計とは異なる。この違いは、あたかも両方が同じ計算から来たかのように扱って隠蔽されるべきではない。表はそのクラスフルな在庫を報告しており、6.25 パーセントのブロックシェアは理論上の 21 ビット Class C ネットワーク番号フィールドから導かれる。
計画は、ほとんど未割り当ての Class C 範囲の上半分、208.0.0.0 から 223.255.255.255 を追って通知があるまで予約していた。下半分では、192.0.0.0 から 193.255.255.255 は、そこの割り当てが実装よりも前から存在したため、マルチリージョナルと記述された。ヨーロッパは 194–195 ブロック、北米は 198–199、中南米は 200–201、太平洋リムは 202–203 を受け取った。他の 3 つの 2 オクテットブロックは柔軟性のために保持された。
RFC 1466 は、この分割を主に管理的なものであり、分散レジストリの基礎を築くものと呼んだ。また、潜在的なアドレス集約技術と互換性があるように設計されていた。互換性というのが正しい主張のレベルである。地理的な連続性だけではルーティング集約は引き起こされなかった。ブロックを一つのルートとしてアナウンスできるかどうかは、ネットワークトポロジ、プロバイダ関係、ルーティングポリシー、そして実際に展開された技術に依存していた。
これらの広範なブロック内で、計画は組織が必要とするエンドシステムアドレスの 24 ヶ月の予測に基づく段階的スケジュールを使用した。256 アドレス未満は 1 つの Class C に、512 未満は 2 つに、1,024 未満は 4 つに、2,048 未満は 8 つに、4,096 未満は 16 に、8,192 未満は 32 に、16,384 未満は 64 の連続 Class C ネットワークにマッピングされた。
これらの閾値は生のアドレスブロックサイズを参照していた。それらを使用可能なホストの例と暗黙のうちに混同すべきではない。1 つの Class C は 256 の生の値を含むが、当時の慣習的な使用可能ホスト識別子は 254 である。32 の Class C は 8,192 の生の値を含む。32 の別個の Class C ネットワークとして扱うと、8,128 のそのような使用可能ホスト識別子を含む。64 の Class C は 16,384 の生の値と 16,256 のクラスフルな使用可能ホストスロットを含む。同じ連続アドレススパンは単一の/18プレフィックスに対応するが、そのプレフィックス表記は生の値と別個の Class C ネットワークに適用される使用可能ホストの慣習との区別を消し去るものではない。
スケジュールには例外があった。加入者のネットワークが論理的に異なる LAN で構成されており、デフォルトのブロックを使用するのが困難な場合、基準をローカルネットワークごとに適用することができた。RFC 1466 は、10 のイーサネットに分散された 600 のホストの例を挙げ、場合によっては 10 の Class C 割り当てが生じる可能性を示した。また、サブネット化が可能な場合の過度な浪費に対して警告し、レジストリがエンジニアリング上の説明を要求することを許可した。
4,096 を超える一意のアドレスを必要とする加入者は Class B の資格を得る可能性があったが、地域レジストリはより大きな Class C ブロックの要求を受け入れることができた。64 の連続 Class C が通常の最大ブロックとして記述され、逸脱はケースバイケースで決定された。したがって、スケジュールは構造化されてはいたが、機械的ではなかった。
この条項は、計画が既に形式的に使用していたクラスラベルを超えつつあったことを明らかにしている。その割り当て用語は Class C のままであったが、2 の累乗、ビット単位の連続性、18 ビットプレフィックスは、クラスレス表現を指し示していた。計画は保全とルーティング圧力の間の緊張を解決したわけではなく、後のルーティング技術がそれを管理できるように割り当てを配置したのだ。
遡及的な視覚的ソースは、欠けている因果関係の橋渡しを提供できない。CAIDA のVisual History of Internet IPv4 Address Allocationsは 2020 年 7 月 18 日に公開された。その記載された方法は、IANA IPv4 アドレス空間ファイルと RFC をソース基盤として、割り当てを規制する組織によってアドレスブロックをグループ化している。公開資料は、再現可能な歴史的ソーススナップショット、割り当てイベントの分母、除外、申請者記録、決定理由を提供していない。これは CAIDA の遡及的グループ化を示すことはできるが、RFC 1466 が割り当てを引き起こしたこと、レジストリが代替案を拒否したこと、申請者がフォールバックルートを使用したか拒否したことを示すことはできない。
地域サービス、委任責任、そして中央フォールバック
RFC 1466 の地域条項は、ますます多様化するインターネットへのサービス対応として最初に正当化された。コミュニティに近い場所に位置するレジストリは、現地の言語や慣習で申請者により良くサービスできるかもしれない。ヨーロッパ、北米、中南米、太平洋リムは、委任が検討できる十分に成熟した地域として挙げられた。
近接性だけでは十分ではなかった。候補組織は、その地理的地域のネットワーキング権威によって正当化され、十分に確立され、レジストリ機能を超えて認識されていることが期待された。安定し、タイムリーで信頼性の高いサービスのために適切なリソースを投入しなければならなかった。IANA とインターネットレジストリのガイドラインに従い、資格と再割り当て戦略を中央と調整することが求められた。
計画はまた、地域レジストリは偏りがなく、ネットワークプロバイダと加入者に広く認識されるべきだと述べた。効率的で公正な再割り当てのためには、その地域レベルで一つのレジストリが重要であると考えた。これらの声明は機関選定の基準であった。それらは、影響を受けるすべてのプロバイダや加入者が候補を承認したことの証明ではない。この文書は、「ネットワーキング権威」や認識、レビューグループの支持に関する構成員の分母を提供していない。
選定されると、地域レジストリは IANA とインターネットレジストリによって、地理的領域での登録サービスを提供する権限を与えられた。それが存在する場合、関連する Class C ブロックからの割り当ての主要責任がそれに委任されることができた。指定された権威が存在しない場合、中央レジストリがデフォルトのままであった。
計画は地域チャネルをテキスト上絶対的なものにはしなかった。申請者は中央インターネットレジストリに直接連絡することができた。状況に応じて、申請者は地域レジストリに紹介される可能性もあったが、中央レジストリは必要であればどのネットワーク加入者にもサービスを提供する用意があると述べた。
そのフォールバックは 1993 年のアーキテクチャの一部として残されなければならない。これにより、この文書が無条件の排他的管轄権の付与として書き換えられるのを防ぐ。同時に、その実際的な重要性は不明である。RFC 1466 は「必要である」を定義せず、執行可能なサービステストを確立せず、紹介に関する意見の相違がどのように解決されるかを明示しなかった。情報源は計画にルートが存在したことを確認するが、その頻度、アクセス可能性、申請者の結果を明らかにするものではない。
RIPE NCC の採択前の立場は、RFC 中心の因果関係をさらに制限する。RFC 1466 は、RIPE NCC が提案の採択前に既に 193.0.0.0 から 193.255.255.255 の Class C ブロックを受け取っており、新しいガイドラインの下でその範囲内で割り当てることに同意していたことを記録している。したがって、計画はその基準を既存の委任に付加したのであり、無からその委任を作り出したのではない。
RFC 7020 の回顧的説明は、歴史的詳細をすべて解決することなく、この点を補強する。それは RFC 1366 が地域団体への責任委任を提案し、RFC 1466 と RFC 2050 を経た継承を指摘している。また、番号レジストリシステムは RFC 2050 以降に大きく変化したと述べている。これは 2013 年の Informational 文書に認知された系譜を確立するが、1993 年から後の 5 レジストリシステムまで変わらなかった任務を確立するものではない。
擁護可能な 1993 年の主張は、RFC 1466 が地域委任者の資格を成文化し、地理的な Class C ブロックと主要な地域責任を結びつけ、中央フォールバックを保持したということである。それはサービス、割り当て、調整を発展途上の制度構造の中に結びつけた。後に地域階層が、より良いサービスを提供したためか、委任されたリソースを保持したためか、中央の作業負荷を軽減したためか、あるいは置き換えるコストが高くなったために存続したのかについては、条項自体を超えた証拠が必要である。
RIPE 95: 日付入りのフォームレベル実装
European IP Network Number Application Form and Supporting Notes, RIPE 95は、より具体的だが厳しく限定された視点を提供する。1993 年 10 月 1 日に発行され、1993 年 12 月 30 日までのみ有効と記載されていた。これは、その期間中の特定のヨーロッパのフォームと規定された提出経路の証拠であり、無期限に有効なルールブックではない。
その冒頭では、InterNIC がブロックを RIPE NCC に委任し、RIPE NCC がそれを地域インターネットレジストリに委任するという分散配置が説明されていた。申請者はまず地域レジストリを通じて申請するよう指示された。インターネットサービスプロバイダの顧客はそのプロバイダに連絡し、そのようなプロバイダがいない申請者は適切な非サービスプロバイダの地域レジストリに向かうよう指示された。正しい経路がわからない者は RIPE NCC に相談することができた。このフォームは一般に、不確実性を第一段階の地域経路を迂回する理由として認めていなかった。
Class B リクエストはより明確なエスカレーションをたどった。申請者は地域レジストリを通じて提出した。地域レジストリがリクエストを正当と判断した場合、資料を RIPE NCC に転送し、RIPE NCC だけがその記載された取り決めの下でヨーロッパにおける Class B 番号を割り当てた。これは規定された経路とレビューレベルの証拠である。転送され、拒否され、変更されたリクエストの数の証拠ではない。
このフォームは情報を公開の管理資料と秘密の技術資料に分けていた。公開フィールドは、ネットワーク名、組織の説明、国、管理および技術連絡先、住所、通信詳細をカバーしていた。秘密としてマークされ、公開 RIPE データベースから除外された技術セクションは、要求されたクラスと数量、現在のマシン数、1 年後と 2 年後のマシン推定数、現在および予測サブネット、インターネット接続状況、既存のネットワーク番号、ネットワークが運用される国を尋ねていた。
その例は生と使用可能の区別を可視化している。フォームは、1 つの Class C を最大 254 ホスト、2 つを 508、4 つを 1,016、8 つを 2,032、16 を 4,064、32 を 8,128 と記載していた。これらは、Class C ネットワークごとに 2 つの識別子を除外した当時の慣習的な使用可能ホスト最大値である。それらは RFC 1466 の Class C あたり 256 アドレス値という生のスケジュールを変更するものではない。
2 つを超える Class C のリクエストには、より完全なネットワーク記述が必要だった。申請者は、サブネットサイズ、トランジットネットワーク、ターミナルサーバを説明するよう求められた。既存の割り当ても重要だった。追加の空間を求める組織は、使用済みおよび未使用のネットワーク番号、インストールされたサブネット、接続されたホスト、その他の構造的事実を説明することが期待された。記載された目的は、効率的な使用と、可能な限り連続した割り当てを行い、ルーティング情報を集約できるようにすることだった。
Class B リクエストについては、RIPE 95 は世界的な不足のために基準は極めて厳格であると述べていた。ホスト推定は、従業員数、地理的分布、ホストタイプなどの情報によって裏付けられることになっていた。申請者は、なぜ連続 Class C がその設計をサポートできないのかを説明しなければならなかった。管理的な利便性は明示的に割り引かれた。複数の Class B リクエストには、地域レジストリと RIPE NCC の両方を納得させることができる詳細な正当化が必要だった。
これは、ポリシー文書だけよりも一つの限定的な命題に対してより強力な証拠である。RFC 時代の情報要件は、ヨーロッパにおいて日付入りの申請者フォームに到達した。フィールドは、予測マシン、サブネット、以前の割り当て、接続性がレビュアーにどのように可読化されたかを示している。第一段階の地域経路と Class B エスカレーションは、規定された管理パスを特定する。
フォームは裁定にとってははるかに弱い証拠である。完了した申請、紹介、承認、拒否、撤回の分母を含んでいない。類似した 2 人の申請者が同様に扱われたかどうか、レビュアーがすべてのフィールドに従ったかどうか、例外がどのように理由付けられたか、予測が後でチェックされたかどうか、申請者がプロセスを正当なものと見なしたかどうかは示していない。標準フォームは、一貫した決定を実証することなく、期待される開示を示すことができる。
また、1996 年までの継続性を確立することもできない。その有効期限は明示的である。後のフォームが個々のフィールドを保持、変更、削除した可能性があるが、その結論には後の手段が必要である。したがって、RIPE 95 は一つの日付入りの観察にとどめるべきである。1993 年後半のヨーロッパに限定された、1993 年アーキテクチャの一部のフォームレベル実装である。
1996 年 11 月: テキスト上の置き換えであり、瞬間的なイベントではない
1996 年 11 月、RFC 2050は明示的に RFC 1466 を廃止し、置き換えた。Best Current Practice 12 として公開され、以前のガイドラインと手続きは経験に照らして更新・修正されたと述べている。テキスト上、継承は明白である。
そのステータスノートには正確さが求められる。インターネットエンジニアリングステアリンググループは、承認はそのポリシーが現在のレジストリ割り当て実践を正確に表しているとの信念を反映していると述べた。ノートはすぐに、承認は IESG の支持や推奨を構成するものではないと付け加えた。また、さらなる議論の後、1997 年 12 月に再評価されることを予期していた。
このノートは、公開された成文化と主張された現在の実践の主張を支持する。それは、別個の制度的保持決定を認証したり、レジストリ全体での一様な実装を確立したり、すべての条項が公開と同時に発効したことを証明したりするものではない。RFC のステータス、廃止、主張された実践、実装は別個の命題である。
技術的変更は相当なものだった。RFC 2050 は、保全、ルータビリティ、登録という三つの目標を中心に配分を組織化した。保全は、運用上の必要性に基づく公正な配分と備蓄の防止を意味した。ルータビリティは、ルーティングのスケーラビリティを支援する階層的な配分を意味し、一方で割り当てられたアドレスがルーティングされることを保証することを明示的に拒否した。登録は、一意性を保持しトラブルシューティングを支援する公開記録の維持を意味した。
文書は、これらの目標が互いに、またエンドユーザーやサービスプロバイダの利益と衝突する可能性があることを認めた。個々のケースにおける分析と判断を求めた。したがって、後の裁量は、単に Class B 対 Class C 問題を繰り返すのではなく、新たに明確化された三目標の基盤を持っていた。
RFC 2050 は、IANA、地域レジストリ、ローカルレジストリの確立された階層を記述した。当時、InterNIC、RIPE NCC、APNIC の三つの地域レジストリを挙げていた。この 1996 年の記述を後の 5 レジストリの地理に置き換えるべきではない。地域レジストリは大きな地政学的領域で活動し、ローカルレジストリを調整し、IANA の権威の下で地域インターネットコミュニティの合意を得て設立されたと記述された。
割り当ては今や明示的にクラスレスだった。地域レジストリは CIDR がサポートするビット境界でブロックを発行した。割り当ては Class B や Class C としてではなく、プレフィックス長によって行われた。管理的な利便性のために行われたクラスフルな前提には特別な正当化が必要だった。以前は Class B を受け取ると記述されたかもしれない組織は、そのサイズが正当化される場合、歴史的なアドレスクラスに関係なく、代わりに/16プレフィックスを受け取ることになる。
プロバイダ階層がルータビリティの中心となった。特定のルーティング条件（適格なマルチホーミングや定義された主要交換点への直接接続を含む）を満たすインターネットサービスプロバイダは、その地理的領域の地域レジストリから空間を要求することができた。指定された地域レジストリを持たないプロバイダは、別の地域レジストリに連絡することができ、そのレジストリはリクエストを処理するか紹介することができた。他のプロバイダは通常、割り当てがプロバイダ集約に適合するように、上流プロバイダから空間を取得するよう指示された。
この文書は、レジストリによって直接発行されたアドレスは、グローバルにルーティング可能である可能性が最も低いものの一つであると警告した。プロバイダには、顧客割り当てを接続期間中のローンとして扱い、顧客がプロバイダを変更する際のリナンバリングを検討するよう奨励した。これは RFC 1466 の広範な地理的 Class C グリッドとは異なる集約と割り当ての関係であった。
新しいサービスプロバイダに対して、RFC 2050 はスロースタートを規定した。初期割り当ては最小限とし、即時の実証された要件に基づくものとされた。後のブロックは、地域レジストリが使用率を検証した後に増加する可能性があった。親レジストリが初期および後続のサイズを決定した。予測顧客数はほとんど影響せず、追加割り当ては約 3 ヶ月分の割り当てをカバーすることを意図していた。
このプロバイダ割り当てルールは、エンドエンタープライズ割り当てガイドラインとは別個に保たれなければならない。エンドエンタープライズに対して、RFC 2050 は 25 パーセントの即時使用率と 1 年以内の 50 パーセント使用率を掲げた。使用率は、接続されたホストをネットワーク上の可能な総ホスト数で割ったものと定義された。組織はその 1 年予測に高い信頼性を示し、裏付け文書を提供しなければならなかった。トポロジは例外を正当化することができたが、割合は一般的なガイドラインとして提示された。
後の文書はネットワークエンジニアリング計画も要求した。割り当ての前に、レジストリはサブネットマスク、サブネットあたりのホスト数、トポロジ、ルーティング計画、プロトコル制限を調査し、サブネットとホスト情報は少なくとも 1 年分をカバーすることとされた。部門や子会社にわたる以前のアドレス割り当てを説明しなければならなかった。レジストリは裏付け証拠や組織の身元を確認する情報を要求することができた。
これらの情報要求は、高いレベルでは 1993 年のアーキテクチャに似ているが、変更されたテストに役立った。RFC 1466 は、24 ヶ月の予測を使用して、複数の Class C が合理的かどうかを判断し、段階的なクラスフルブロックを選択した。RFC 2050 は、即時の必要性、1 年間の使用率、以前の使用証拠、プレフィックスサイジング、プロバイダ集約、段階的割り当てを使用した。申請者は依然として情報を提供したが、その情報はもはや同じ割り当て質問に答えていなかった。
監査権限も変更された。RFC 1466 は、中央レジストリが地域の Class B エンジニアリング計画を監査することを許可した。RFC 2050 は、すべてのアドレスリクエストは、地域レジストリが適切と見なす手段による監査と検証の対象となると述べた。虚偽の情報は、割り当ての無効化と割り当てられたアドレスのフリープールへの返却を支持する可能性があった。地域レジストリは、セカンドオピニオンを要求するサイズ閾値を設定することができた。
機密性とレビュールートはより完全に記述された。申請者によって機密と特定された情報は、機密として扱わなければならなかった。割り当てレジストリがプライバシーを保証できない場合、その親が割り当てを行うことができた。割り当て決定に不満を持つ組織は、親レジストリに控訴する書面の権利を持ち、他の手段が尽きた後には最終的に IANA にまで控訴が可能であるとされた。
これらは公開された権限と保護手段であった。それらが含まれていることは、監査の選択、控訴の頻度、逆転率、実際のアクセスについて何も語っていない。しかし、それらは後のフレームワークが単にクラス名を取り除いた RFC 1466 ではないことを示している。それは割り当てを CIDR、プロバイダ階層、使用率、スロースタート、検証、控訴を中心に再構築した。
したがって、テキスト上の廃止は重要である。1996 年 11 月以降、権威ある公開ベースラインは RFC 2050 であり、黙って継続する RFC 1466 ではない。同様に、公開は、すべての地域フォーム、レビュアーの習慣、ソフトウェアツール、申請者チャネルが変更された日付を示すことはできない。ルールの継続性と制度の継続性は別々に評価されなければならない。
見かけ上の持続性に対する四つの説明
RFC 1466 に関連付けられた三つの広範な特徴は、そのクラスフルな仕組みが権威を失った後にも再登場した。地域組織、申請者情報の負担、裁量的レビューである。それらの再発は、それ自体の原因を特定するものではない。
四つの説明が検討に値する。第一は、継続する技術的必要性である。一意の割り当て、有限のアドレスプール、ルーティング集約は、Class B 問題が変化した後でも、調整されたレジストリと証拠に基づくレビューを独立して正当化することができる。
第二は、委任された責任である。アドレスブロック、記録、下流レジストリに対する義務を保持する組織は、後継の RFC が現れたときに消滅しない実際的な責任を持っていた。継続は、以前のテキストへの愛着ではなく、正確な割り当てと運用サービスを維持する必要性を反映しているかもしれない。
第三は、切り替えコストと行政的惰性の組み合わせである。既存のスタッフ、フォーム、データベース、機密チャネル、エスカレーション関係、申請者の知識は、制度の置き換えを高コストにする。そのメカニズムはインフラが存在すればもっともらしいが、もっともらしさは測定ではない。レビューされた情報源は、移行の価格を設定したり、拒否された代替案を文書化したりしていない。
第四は、後のテキスト上の成文化である。RFC 2050 は、クラスレスフレームワークの下で地域階層、申請者の文書化、検証、控訴を記述した。これは、後の著者が広範な管理機能を再記述し、再編成したことを示している。これは、責任主体、保持された 1993 年の条項、保持の理由、実装日を特定する認証された決定記録よりも弱い。
これらの説明は互いに排他的ではない。継続する技術的必要性は委任された責任と共存することができる。有用な制度は置き換えにコストがかかることもある。後の成文化は、実践を通じて発展した取り決めを創設するのではなく認識することができる。証拠は各可能性の選択的テストを許可するが、因果関係の数値的配分は許可しない。
地理的グリッド後の地域組織
正確な 1993 年の条項は、適格な地域組織を広範な Class C ブロック内の主要責任と結びつけつつ、中央のデフォルトサービスと直接的なフォールバックを保持した。その技術的設定は、潜在的な集約と互換性のあるクラスフルな割り当てだった。その制度的設定は、地理的に分散したサービスの発展モデルだった。
1996 年までに、RFC 2050 は地域レジストリを三層階層の確立されたコンポーネントとして記述した。IANA がそれらに割り当てを行い、それらはローカルレジストリを調整し、ローカルレジストリとプロバイダは下流ユーザーにサービスを提供した。メカニズムはもはや、地域組織と一つの 2 オクテット Class C ブロックとの単純なペアリングではなかった。それは CIDR 割り当て、プロバイダベースのアドレッシング、再割り当て記録、階層的レビューを含んでいた。
後のテキストは、1993 年の資格リスト全体を繰り返さなかった。言語と慣習、レジストリ機能外での正当性、地域ごとに単一の地域組織、必要に応じた普遍的な中央サービスは、同じ形式では再記述されなかった。代わりに RFC 2050 は、地域インターネットコミュニティの合意、IANA の権威、ローカルレジストリの調整に言及した。
期間内の観察された証拠は限定的なままである。RIPE 95 は 1993 年後半の欧州のローカル対地域の取り決めを示している。RFC 2050 は 1996 年 11 月に地域階層を成文化し、IESG ノートの制限の下で、それを現在のレジストリ実践として特徴付けている。RFC 7020 は後に、大規模なその後の変更を記録しつつ、制度的系譜を認識している。
継続する技術的必要性は、RFC 中心の因果関係に対する強力な代替案である。アドレスの一意性は調整を必要とし、集約は階層的配分から利益を得た。地域サービスは中央の作業負荷を軽減し、レビュアーを申請者により近く配置することができた。これらの必要性はいずれも、1993 年の Class C マップの継続使用に依存していなかった。
委任された責任ももっともらしい。RIPE NCC は RFC 1466 の採択前に既にブロックを保持していた。地域レジストリとローカルレジストリがアドレス空間を保持し、記録を維持し、下流組織にサービスを提供した後では、突然の置き換えにはデータ、権威、技術機能の移転が必要だっただろう。情報源はこれらの責任が存在したことを示しているが、それぞれがどのような完全な手段で維持されたかを確立していない。
切り替えコストは、RIPE 95 に見られるフォームレベルのインフラによって示唆される。申請者は、認知されたチャネル、公開・秘密フィールド、地元連絡先、Class B レビューのエスカレーションルートを持っていた。これらの取り決めを置き換えることは努力を要するだろう。レビューされた証拠は、提案された代替案がコストが過剰と見なされたために拒否されたことを示していない。
後の成文化が最も明確な文書的事実である。RFC 2050 は、異なる割り当て体制の下で階層を公開した。これをテキスト上の再採用と呼ぶことは、公開を明確な保持決定や普遍的な運用の証明と誤解することを避ける。
中央フォールバックは、不変の継続性の主張が最も鋭く失敗する点である。RFC 1466 は、必要ならば中央レジストリが加入者にサービスを提供すると述べた。RFC 2050 は代わりに、通常のプロバイダおよび地域チャネル、指定された地域レジストリが存在しない場合のクロスリージョナルな連絡、機密性のための親の介入、階層的控訴を記述した。これらの上位レベルのメカニズムは、以前の保証と同じではない。
情報源は、RFC 1466 のフォールバックが頻繁に使われたか、稀に使われたか、狭められたか、変形されたか、休眠状態にあったかを示していない。また、その執行可能性や実際的な利便性も確立していない。安全な結論は、地域管理は公開された形で持続したが、その技術的基盤とサービス階層は変化したということである。役割は存続したが、1993 年の割り当てグリッドとフォールバック文言は、それと共に明らかに不変のまま存続しなかった。
クラスフル閾値後の申請者開示
RFC 1466 は、Class B 申請者に対して、サブネットとホストの予測を提示し、なぜ Class C が合理的でないかを説明し、24 ヶ月のエンジニアリング計画を開示することを要求した。その Class C スケジュールも、必要なエンドシステムアドレスの 2 年間の推定に依存していた。RIPE 95 は、関連する要求を、現在および将来のマシン、サブネット、接続性、以前の割り当て、ネットワーク構造をカバーするフィールドに変換した。
RFC 2050 は、リクエストが自己検証的ではないという一般的な命題を保持した。レジストリは、ネットワーク計画、トポロジ、ルーティング、以前の使用、期待される使用率に関する証拠を調査した。さらなる割り当てを求めるプロバイダは、使用を実証しなければならなかった。エンドエンタープライズは、即時および 1 年の使用率期待に直面した。裏付けが要求されることがあった。
実行するアクターはレベルによって異なった。ローカルレジストリやプロバイダが通常のリクエストを受け取ることができた。地域レジストリは、より大きな割り当てや直接割り当てをレビューすることができた。親レジストリは、機密性、セカンドオピニオン、控訴に関与することができた。申請者は依然として制度的評価に依存していたが、レビュー機関と証拠目的は多様であった。
メカニズムは、フォームの再発が示唆する以上に変化した。1993 年には、2 年間の予測が Class B の適格性と 2 の累乗の Class C ブロックの間で選択した。1996 年には、新しいプロバイダは即時の必要性に基づく最小限の空間から始め、追加のプロバイダ空間は使用率検証後の約 3 ヶ月分をカバーした。エンドエンタープライズは、接続ホストを可能ホストで割った即時および 1 年の使用率に対して評価された。
このシフトは、プロバイダに対する投機的成長の役割を実質的に減少させた。RFC 2050 は、予測顧客基盤が親レジストリの割り当てにほとんど影響を与えないと述べた。歴史的使用と段階的必要性がより重要になった。情報収集は存続したが、その論理はクラスフルユニットの選択から、時間をかけたクラスレス割り当ての制御へと移行した。
継続する不足は独立した説明を提供する。有限のプールと不確かな需要は、以前のフォームが存在しなくても、申請者に証拠を求める理由を生み出す。ルータビリティは別の理由を追加する。トポロジとプロバイダ関係は、プレフィックスが集約に貢献できるかどうかに影響する。したがって、後の情報負担は、継承された習慣ではなく、現在の技術的条件によって正当化される可能性がある。
既存の管理能力は、依然としてもっともらしい貢献者である。レビュアーは既に機密計画、以前の割り当て、予測の扱い方を知っていた。申請者は既に標準化された質問に遭遇していた。変更された技術的テストは、馴染みのあるチャネルに挿入されることができた。これは適応性の信憑性のある説明であり、惰性が後のルールを引き起こしたことの証明ではない。
公開された成文化が再び最も確実な結果である。RFC 2050 は、新しいフレームワークの下で文書化を要求した。記事は、テキスト上の再発と 1993 年のフォームレベル実装を確立することができる。1993 年から 1998 年の期間にわたる同じフォームの中断されない使用、安定したレビュアー実践、一貫した効果を確立することはできない。
したがって、制度的な残存は特定の閾値の存続よりも狭い。永続的な特徴は、申請者がネットワーク証拠を提供し、レジストリが共有リソースとルーティングの目的に対してそれを解釈する要求アーキテクチャだった。32 サブネット、4,096 ホスト、24 ヶ月のテストは、一般的な割り当て文法としては存続しなかった。
異なる技術目標の下で再成文化された裁量
RFC 1466 は、いくつかの点で判断を留保した。Class A 割り当ては IANA の裁量に委ねられた。提案された閾値外の Class B 申請者は、Class C が技術的に使用不能であると主張することができた。Class C 割り当ては、ローカルネットワーク構造が正当化する場合、デフォルトスケジュールから逸脱することができた。より大きな Class C ブロックや他の例外はケースバイケースで決定された。
その可能な監査は、地域の Class B 割り当てを支持するエンジニアリング計画に対する中央レジストリの監視に関係していた。権限は許容的だった。レジストリは説明責任を要求し、監査することができた。その文言は行動する裁量を確立するが、行動が頻繁または体系的だった証拠ではない。
RFC 2050 は裁量をより広範に再成文化した。保全、ルータビリティ、登録は互いに、また個々の利益と衝突する可能性があった。レジストリは判断を行使することが期待された。トポロジ上の考慮は使用率ガイドラインからの逸脱を正当化することができた。ルーティング効率、以前の割り当て履歴、ネットワーク計画はケースバイケースで評価された。地域閾値を超えるとセカンドオピニオンが要求されることがあった。
後の文書はまた、すべてのリクエストが監査と検証の対象であり、割り当てが虚偽の情報に基づいている場合には無効化を許可すると述べた。同時に、機密性義務と控訴ルートを正式化した。公開されたアーキテクチャは、レビュアーの権限と、上位レビューのための明示された手段を組み合わせた。
これは RFC 1466 の不変の継続ではなかった。以前の判断はクラス選択、複数 Class C の実現可能性、クラスフルスケジュールからの逸脱に集中していた。後の判断はプレフィックス長、即時の必要性、使用率、プロバイダ集約、ルーティング確率、クラスレスネットワーク設計に関係していた。類似した制度的動詞は異なる技術的対象を隠していた。
継続する必要性はここで特に説得力がある。固定された閾値はあらゆるトポロジを表すことができず、保全はルーティング集約と衝突する可能性がある。専門家の判断は、ケースが異なるために持続する可能性があり、組織が以前の実践を放棄できないからではない。
管理的継承は依然として重要かもしれない。既に計画を受け取り、機密情報を保護する装備を持つレジストリは、使用率とルーティング証拠にまでレビューを拡張することができた。階層的委任も複数レベルに判断を配置した。しかし、情報源は、レビュアーが文書上の断絶を越えて安定した解釈文化を適用したかどうかを明らかにしていない。
後の成文化はテキストに観察可能である。運用上の一貫性はそうではない。書かれた例外は非定型ケースが検討される可能性があると言うが、例外の頻度や方向性を明らかにしない。監査権限は権力を特定するが、選択方法、調査結果、結果を明らかにしない。書かれた控訴ルートは救済手段を特定するが、アクセス可能性、使用、逆転を確立しない。
したがって、適切な残存の主張は機能的かつ限定的である。リソース保全とネットワーク設計に対するレジストリの裁量は RFC 2050 の下で再登場し、より広範な監査文言と書面による控訴規定を伴った。実質的な基準は変化し、証拠は後の裁量が RFC 1466 によって引き起こされたか、一様に行使されたかを示していない。
公開された記録が確立するもの ― そして保留するもの
文書のシーケンスはいくつかの点で明確である。RFC 1466 は 1993 年 5 月に Informational 計画として公開された。それはクラスフルな統計、Class B テスト、連続 Class C スケジュール、地域資格基準、ケースバイケースの例外、直接的な中央フォールバックを含んでいた。また、RIPE NCC が採択前に Class C ブロックを保持していたことも認めていた。
1993 年 12 月 30 日まで有効な RIPE 95 は、現在および予測ネットワーク情報を要求し、第一段階のローカルレジストリルートを規定する欧州のフォームを示している。RFC 2050 は 1996 年 11 月に BCP 12 として公開され、明示的に RFC 1466 を置き換え、クラスレス割り当て、プロバイダ階層、スロースタート、使用率レビュー、検証、控訴を成文化した。RFC 7020 は、大規模なその後の変更を認めつつ、2013 年の遡及的系譜を提供した。
記録は、単位が文書からケースに変わると薄くなる。レビューされたどの情報源も、総リクエスト数、承認、拒否、撤回、例外、監査、控訴、直接 IR 連絡、紹介、放棄されたリクエストについての分母を提供していない。申請者が最初にどのチャネルを使ったか、どの証拠が要求されたか、レビュアーがどのように推論したか、どのブロックが割り当てられたか、例外が適用されたかどうか、監査が行われたかどうか、控訴が結果を変えたかどうかを示すリンクされた母集団は存在しない。
集約割り当て記録は、これらの事実のすべてを回復することはできない。発行されたブロックは割り当て結果を特定するが、拒否された代替案、撤回されたリクエスト、失敗した申請者、レビュアーの動機、リクエストが到着した経路を特定しない。規制組織によるブロックの遡及的グループ化は、どのルールが個々の割り当てを引き起こしたかを特定できない。
欠落している分母は、主張を異なる方法で制限する。直接 IR のケースがなければ、1993 年のフォールバックは堅牢、名目上、または非実用的と分類できない。例外の母集団がなければ、公開された閾値は実際の規則性に変換できない。監査記録がなければ、権限は執行頻度に変換できない。控訴記録がなければ、書かれた救済手段はアクセスや効果について評価できない。
RFC 2050 周辺の同時代の通信は、異なる質問に答えるだろう。後継者は、以前の条項を経験に照らして更新・修正したと述べたが、ここでレビューされた情報源は、著者が何を保持しようと意図し、何を時代遅れと見なしたか、あるいは何が既に使用されなくなっていたかについての完全な条項ごとの説明を提供していない。テキスト上の置き換えは継承を証明する。それはすべての置き換え動機を開示するものではない。
これらの記録の不在は、同意、反対、公正、失敗の証拠ではない。それは推論の境界である。文書は、機関が何を公開したか、1993 年後半の一つのフォームが申請者に何を提供するよう求めたか、1996 年の後継者がレジストリシステムをどのように記述したかを示している。それらは母集団全体の運用履歴を確立しない。
その境界は、後の遡及的説明が系譜を認識しているからといって、制度的持続性を単純に仮定するという逆の誤りからも保護する。系譜は広範な改訂を含むことができる。RFC 2050 はクラスフル閾値を置き換え、割り当て単位をプレフィックス長に変更し、スロースタートを正式化し、集約をプロバイダと CIDR を中心に再構築した。RFC 7020 自体が、システムは 1996 年以降に大きく変化したと述べている。
限定的な回答
RFC 1466 はテキスト上、一時的ではなかった。有効期限、暫定ラベル、制度的サンセットを提供しなかった。勧告は枯渇を遅らせるだけだというその声明は、技術的救済の限界を説明したものであり、地域委任、申請者開示、レジストリ判断がクラスフル割り当てと共に期限切れになるという約束ではなかった。
しかし、それは 1996 年 11 月にテキスト上、廃止された。RFC 2050 はその Class B テスト、地理的 Class C アルゴリズム、24 ヶ月のクラスフルスケジュールを実質的に置き換えた。プレフィックス長割り当て、CIDR 境界、プロバイダ階層、スロースタート、検証された使用率、1 年間のエンドエンタープライズ予測が公開されたフレームワークとなった。
1993 年計画に関連するいくつかの管理能力は再登場した。地域組織は IANA と下流レジストリの間の公開された位置を占めた。申請者はネットワーク証拠の提供を続けた。レジストリは、異なる基準の下で、不足、トポロジ、集約を判断し続けた。RIPE 95 はフォームレベル実装の一例を提供し、RFC 2050 は後の成文化と現在の実践に関する主張を提供する。
情報源は、RFC 1466 がそれらの能力を持続させた原因となったことを確立しない。地域管理はその採択前に既に発展しつつあった。継続する技術的必要性、委任された責任、切り替えコスト、行政的惰性、後の成文化は、もっともらしく重なり合う説明として残る。記録はそれらの因果的重みを配分しない。
したがって、最終的な区別は鋭い。RFC 1466 はテキスト上、一時的ではなく、1996 年にテキスト上、廃止された。そして公開された証拠は、限定的なフォームレベル実装と後の成文化を示すが、1993 年計画がそれに帰属する運用上の持続性を引き起こしたことを証明しない。