要約

  • prop-164-v005はIPv6 allocationの最小値を/32から/40へ下げ、より小さいnibble整列ブロック、返却・縮小、将来拡張用の予約を導入する案だ。
  • prop-170-v001は/32を維持し、申請者が明示的に求め、既存の需要審査が必要量を認めた後に限ってallocationを整列する。
  • 8月18日の両影響評価は、二案がともにコンセンサスを得れば衝突回避の文面修正が必要だとする。164のみ、170のみ、両方、どちらもなしを会議前に示すべきだ。

同じ単語が別の入口を隠す

NOG Allianceの一覧は、prop-164とprop-170をAPNIC 62で扱う別々の提案として掲載している。見出しが似ていても、選択対象は違う。

prop-164-v005の現行文はallocationの入口を変える。現行の/32より小さく、/40まで申請できるようにし、/32、/36、/40という四ビット刻みを使う。さらに、一部の既存保有者が余剰を返してブロックを縮小する道と、後日の拡張に備えて近接空間を疎に配置・予約する仕組みを持つ。

prop-170-v001の現行文は入口を変えない。既存のneeds-based assessmentを通った要求について、申請者が望む場合に整列されたallocationを出す。最小/32は残り、assignmentには適用されず、既存保有者に一律の返却やrenumberingを求めない。

したがって「十六進数で扱いやすい」という賛意だけでは答えにならない。条件付き整列には賛成しながら/40の新しい最小値には反対できるし、小規模allocationには賛成しながらprop-170の拡張処理には疑問を持てる。

prop-164の履歴も、この差を示す。Mail Archiveに残る旧版は、大きすぎるallocationか、下流のsub-allocationを適切に記録できない小さなassignmentかという問題から始まった。JPNICの解説もallocationとassignmentの違いを中心に説明した。その後、提案値は/36から/40へ移り、返却と予約が加わった。判断対象は増えている。

8月18日の注意書きは政策問題である

影響評価が示す実装も同じではない。

prop-164の影響評価は約9か月と見込み、小さいallocation、既存ブロックの縮小、予約処理をレジストリに追加する必要がある。既存の/32を/36にも下げられるのか、それとも/40だけか、隣接空間が取れない場合はどうするか、現在のsparse allocationで十分ではないかという確認事項が残る。

prop-170の影響評価は約6か月で、需要審査を残したまま整列要求を扱う手順と内部ガイドを更新する。最小値とassignmentの範囲は変えない。

その上で両評価は、二案がともにコンセンサスを得た場合、矛盾を避けるため文面を改める必要があると記す。

用語、番号、参照を直すのは編集である。だが、最小値、返却資格、予約義務、適用範囲を後から選ぶのは実質的な政策判断だ。どれもレジストリが作れる状態と、会員が得られる選択肢を変える。

過去の議論を一括りにできない理由もここにある。日本コミュニティからの意見には、/32から/36へ下げても次に/40の議論が繰り返されるのではないか、節約効果は十分かという問いがあった。SANOGの資料は、より正確な登録情報という目的を示した。いずれもprop-164の下限を論じた証拠であり、prop-170の条件付き整列への包括的な委任ではない。

四つの結果を先に書く

prop-164のみでは、新しい最小値、許される刻み、返却・縮小条件、予約、隣接空間がない場合、既存保有者の扱いを示す。prop-170の整列工程は自動的に入らない。

prop-170のみでは/32が残る。整列要求、検証済み需要、最終prefixを分け、assignmentが対象外であること、連続拡張できない場合を示す。/40の入口や返却権は発生しない。

両方なら、実際の統合条文が必要だ。定義が重なるとき何が優先するのか。既存保有者は/36、/40、どちらにも縮小できるのか。近接空間は政策上の予約か、運用上の努力か。予約部分が使えないとき、どの規定に従うのか。後日の「整合化」は答えではない。

どちらもなしなら現行基準を維持する。コンセンサスがないことを内部ガイドによる実装許可に変えてはならない。

統合案が間に合わない場合は、二つの判断を独立させればよい。両方への支持が出ても、実質的な統合条文は改めて公開し、読む機会を設ける。これなら編集者は決定を実装するだけで、新しい決定を作らない。

技術上の整然さと権限を分ける

nibble boundaryは四ビット、つまり十六進数一桁に一致する。prefixの読解、分割、文書化、自動化には有用だ。RFC 6177も、すべてのIPv6 end siteに一つのサイズを当てる考えを退けている。

ただし、役割は別だ。コミュニティは証拠を出し提案を評価する。議長は特定版についてコンセンサスを判断する。事務局は影響を分析し、採択された規則をシステムに実装する。保有者はアドレス計画を作り、経路を運用する。WhoisとRDAPが示すのは委任状態であって、BGP広告や全アドレスの利用を証明するものではない。

Heng Luの「Minimum Initial Specification」が示す規律は、共通層を相互運用に必要な範囲へ絞り、将来の選択を実装者に残すことだ。allocation policyを否定する話ではない。共有状態をどこまで変え、何を運用者に残すのかを明示せよという話である。

本稿はAPNIC 62の結果を予測しない。新しい版や統合案が出る可能性があり、6か月、9か月は条件付きの見積もりだ。実際の申請者が得るprefixや経路への影響もまだ分からない。

確認できるのは、衝突が会議前に見つかった一方、その解決案がまだ公開の判断対象になっていないことだ。四行の表を出し、各条項がどの提案に由来するか示せば、nibbleという一語に二つの権限を背負わせずに済む。

情報源