要約

  • 旧6.5.8.2節では、1サイトは一つの/48に含まれる/48の100％を占めるため、75％規則を文字どおり適用すると次のnibble境界である/44に進む。一方、例示は2サイトから/44としており、1サイトは/48だった。
  • Recommended Draftは初期/48を先に確定し、その後を2–12 → /44、13–192 → /40、193–3,072 → /36、3,073–49,152 → /32と整理した。ただし採択済み・実装済みのポリシーではない。
  • /48をIPv6の絶対則にする必要はない。必要なのは、規範文、例示、実装テストが同じ入力に同じ結果を返し、異なる場合には訂正履歴が残る仕組みである。

1サイトと2サイトの間にあった断層

境界試験は単純である。/48の中に数えられる/48は一つ。サイトも一つなら比率は100％になる。旧文は、利用可能な/48の75％をサイト数が超えれば次の大きなnibble境界に進む、と読めた。その出力は/44である。

ところが直後の例示では、/44は「1を超え12以下」のサイト数に対応した。1サイトはその集合に入らず、初期/48に残る。

第三者メールアーカイブに残る2月の改訂文は、この論理矛盾を明記している。改訂の工夫は、75％規則に例外を足すことではなかった。「初期サイズ」ではなく「より大きな初期サイズ」がサイト数で決まる、と構造を変えた。/48を基点に置き、式を複数サイトの領域へ移したのである。

例示は本来、規則を理解しやすくする補助物だ。しかしこの期間、例示は本文が確定できない結果を確定していた。実務が二つの公開出力から一つを選ばなければならなかった。

推奨案が閉じた穴

6月のRecommended Draft全文を保存した独立アーカイブでは、5月20日版の変更が確認できる。初期要件のいずれかを満たす組織は/48を受ける資格がある。より大きいサイズだけが、正当化されたサイト数で決まる。

区間は曖昧な比較文から、2〜12、13〜192、193〜3,072、3,073〜49,152という閉じた表へ変わった。対応するサイズは/44、/40、/36、/32である。さらにassignmentはallocationへ置き換えられた。

同じメッセージに収録された諮問評議会の評価は、この語彙変更が現在の手続に合い、全体の修正は実際の現行運用と一致して運用変更を生まない、と述べる。この説明は重要だが、外部検証済みの統計とは区別すべきである。今回の資料には匿名化された決定標本、過去のサイズ分布、実装試験がない。したがって、実際に誤った割当、遅延、不均一な扱いがあったとは言えない。同時に「変更なし」を独立に再現したとも言えない。

NOG Allianceの一覧はARIN-2025-7をRecommended Draft Policyとして掲載する。これは重要な状態であるが、採択でも発効でもない。本稿は修正案の意味を扱うのであって、現在の権利を告知するものではない。

/48はプロトコルの命令ではない

整った境界表を見ると、/48が技術的必然に見えやすい。RFC 6177は、その読み方を退ける。以前の「多くのエンドサイトは/48」という一律勧告を廃し、サイトの多様性には単一デフォルトでは足りないとした。IETFの役割はアーキテクチャと運用上の指針であり、具体的サイズの選択は運用コミュニティの課題だと整理している。

少数の境界をハードコードして、IPv6をクラスフルな空間のように扱うことにも警告する。CIDRは変わらない。

従って、ARINが対象クラスの単一サイトに/48を選ぶことは否定されない。ただしそれはプロトコル定数ではなく、公開されたポリシー判断である。判断である以上、版、適用範囲、入力、出力、訂正方法が必要になる。

レジストリは公開規則に基づきサイズ帯を判定できる。ネットワークのトポロジー、サブネット設計、成長計画、サービス構成は運用者に残る。プレフィックスを記録する機能から、ネットワーク全体を設計する権限は導けない。

小さな組織ほど説明を買わされる

IPv4 GlobalによるARIN 57の外部分析は、変更自体は小さいが、小規模エンドユーザーの照会や往復を減らし得ると述べる。これは商業的な観測者の期待であり、導入後の測定ではない。それでも費用の発生場所をよく表している。

内部の担当チームは曖昧さを一度解釈すれば繰り返し使える。初めて申請する組織は、その解釈を外から毎回発見しなければならない。大きなチームは専門家を置けるが、単一サイトの小組織には難しい。

負担は4ビットの差ではない。本文、例示、ヘルプ、担当者説明のどれが優先するか分からないことが負担になる。精密なポリシーは、個別メールが始まる前に優先順位を消しておく。

小さな鏡に映る制度

Lu HengのThe Policy Mirrorは、ポリシーマニュアルが制度の自己認識を映すと論じる。狭いレジストリは一意性、記録精度、支配証明、セキュリティ情報、継続性を守る。内部実務が公開規則を超えて運用者の選択を支配し始めれば、境界が変わる。

この案件は資本統制の大事件ではない。むしろ正当なサイズ判定のような小さな機能でも、公開実行が二つあれば内部実務が隠れた最終規則になることを示す。本文修正は権威を公開対象へ戻す。

同時に共通層を増やし過ぎてはならない。資格、通常サイト数、特大サイトの限定的根拠は判定に必要でも、内部構成の詳細までレジストリの判断対象にする必要はない。

ポリシーと実務の一致表

申請案件を公開せずとも、重要な版ごとに次の項目を残せる。

項目 最小限の内容
テキストID 番号、日付、ハッシュ、手続状態。
入力クラス 資格、通常サイト数、特大サイト需要、訂正。
本文出力 規範文だけを実行したプレフィックス。
例示出力 公開表が返すプレフィックス。
実務出力 テストまたは集計で示す適用クラス。
差異処理 差異なし、本文修正、例示修正、実務変更、再審。
限定理由 単一サイト基準、複数サイト閾値、特別需要。
訂正経路 決定者、日付、置換版、異議方法。

これは本稿の監査モデルであり、ARINの既存スキーマではない。機密トポロジーではなく、三つの実行面が一致するかを確認する。

境界ベクトルは四つでよい。通常サイトが1なら/48、2なら/44、12なら/44、13なら/40。各ベクトルを本文、例示、実装に同じテキストハッシュで通す。特大サイトは別ベクトルにし、例外を通常表へ混ぜない。

この方法なら将来の編集も検査できる。assignmentからallocationへの語彙変更だけなら出力は同じであるべきだ。意図した境界変更なら差分が公開判断として見える。

修正を評価し、被害を創作しない

確認できるのは、矛盾が存在し、Recommended Draftが分かりやすく解消したことまでである。採択、実装、実害、誤った決定、運用変更は確認できない。過去の運用が常に同じだったことも独立には再現できない。

次の有用な作業は、最終テキストの指紋と境界試験を残りの手続に付けることだ。採択時には発効版と同じ試験を公表する。前後の出力が一致すれば、「運用変更なし」は信頼要求ではなく観測になる。

単一サイト/48を支えてきた例示の仕事を、これからは規則自身が引き受けるべきである。

情報源

証拠の限界

確認済み：単一サイトでの本文と例示の矛盾、推奨文の明示的境界、運用継続に関する諮問評議会の説明、独立一覧上のRecommended状態、RFC 6177による一律/48の否定。

未確認：採択、実装、実在する不一致案件、遅延、損害、対象件数、過去のサイズ分布、運用変更がないことの独立検証。