要約

  • AFRINICの理事会一覧は決議200605.27を、2オクテットASNから4オクテットASNへの移行方針を承認し、職員に実施を指示した記録として載せている。しかし、AFRINIC-4会合報告は2006年5月17日に提案がなお討議中で「前へ進める」合意に達したとし、方針アーカイブは11月13日から28日までの最終意見募集を記録し、同じ理事会一覧には11月の決議200611.34による別の承認もある。したがって5月か11月の一方だけを「唯一の承認日」とすることはできない。
  • 移行の中身は一斉切替ではない。2007年1月1日からは明示的に求めた場合だけ4オクテット専用番号を出し、通常は2オクテット専用番号を出す。2009年1月1日には既定値を逆転させ、2オクテット専用番号を例外申請にする。2010年1月1日には割り振り上の区別をなくす。この日程はレジストリの受付・割り振り規則であって、各運用者の機器を遠隔で更新する命令ではなかった。
  • 現実の採用を成立させたのは、能力通知、AS_TRANS、経路情報を保つ追加属性、表記と台帳の正規化、そして運用者が試験した実装である。2011年まで残った申請様式の選択肢、2012年に報告された機器非互換による交換、後年の複数RIRにまたがる返却・交換報告は、方針上の期日と現場の準備完了が同じではないことを示す。
  • AFRINICが行えたのは、一意な番号台帳を維持し、割り振りの既定値を変え、記録を公開し、互換性情報と例外手続きを整えることまでである。番号の所有権を創設したのでも、国家のように立法・規制・警察・訴追・裁判・処罰・没収の権限を得たのでもない。移行の実効性は、互換する稼働コードと運用者の採用に宿る。

二つの「承認」を一つの日付に潰してはならない

決議200605.27だけを読めば、話は簡単に見える。AFRINICの2006年理事会記録には、2バイトから4バイトのAS番号への変更を含む複数方針を承認し、職員に実施を指示した趣旨が記されている。番号にも「2006年5月」の痕跡がある。この一行を年表の終点に置けば、5月に方針が成立し、その後は実装だけが残ったという整然とした説明を作れる。

しかし、同時代の文書を並べると、その整然さは崩れる。5月17日のAFRINIC-4会合報告は4オクテットASN提案を討議事項として扱い、議論は多くなかったが好意的で、「前へ進める」合意に達したと記録する。方針アーカイブも同日の合意を記す一方、最終意見募集を11月13日から28日までとしている。そして理事会一覧は、決議200611.34を4オクテットASN方針の承認として別に掲載する。AFRINIC-5の会合報告も、11月末から12月初めの会合の数日前に理事会が承認し、2007年1月1日から利用可能になるという説明を残した。

これは言葉遣いの小さな揺れではない。会合での合意、理事会の実施指示、最終意見募集、後の理事会承認は、監査上それぞれ異なる行為である。保存資料は、なぜ5月と11月の両方に「承認」に相当する記録があるのかを説明していない。5月の決議を誤記と断じる根拠も、11月の決議を単なる追認と決めつける根拠も、二段階の法的手続きだったと断定する根拠もない。許される結論は狭い。5月には理事会が承認と実施指示を記録した。同時に、公開された手続きの痕跡は11月の最終意見募集と別の承認まで続いた。この矛盾そのものを、未解決の監査所見として残すべきだということだ。

提案の起点にも似た問題がある。方針ページ上部の日付は2005年9月22日だが、同ページの履歴は提案が方針メーリングリストへ最初に投稿された日を2005年12月9日としている。どちらかを都合よく「真の作成日」に選ぶのではなく、二つのメタデータを別々に保存する必要がある。後世の要約が単一の開始日、単一の承認日、単一の実装日だけを持つと、討議と決定と運用準備の間にあった時間が消える。移行を検証するには、きれいな物語より、食い違いを含む台帳の方が価値を持つ。

この区別は、理事会の権威を弱めるための言葉遊びではない。むしろ、何をいつ決め、誰が次の作業を担ったかを正確にするためである。決議は組織内の行為を証明できる。会合報告は会合がどう記録されたかを証明できる。方針アーカイブは掲載文と履歴を証明できる。どれも、残るシステムがその日に改修済みだったことまでは証明しない。文書の証明範囲を狭く保つことで、実装責任を「承認済み」という一語の陰に隠さずに済む。

三段階の日程は、命令ではなく既定値の設計だった

移行方針の要点は、番号空間を広げるという抽象論より、申請者が何を受け取るかという既定値の段階的変更にある。方針が扱った2オクテットで表現可能な数値範囲は0から65535であり、4オクテットでのみ表現できる範囲は65536から4294967295だった。4オクテット全体の表現範囲は0から4294967295になる。ただし、これは表現可能な範囲であって、全ての値が自由に割り振れるという意味ではない。プロトコル上、レジストリ上の予約があり、桁幅の拡大は財産権の付与でもない。

第1段階は2007年1月1日である。申請者が明示的に4オクテット専用ASNを求めたときだけ、それを受け取れる。通常の既定値はまだ2オクテット専用ASNだった。これは、準備の整った運用者が先行し、未対応の運用者には狭い番号を残す設計である。いきなり全員を新しい表現幅へ追い込むのではなく、実装と相互接続を試す余地を作った。

第2段階は2009年1月1日である。ここで既定値が反転する。通常は4オクテットASNを出し、2オクテット専用ASNが必要な申請者は明示的に求める。希少な狭い範囲を互換性上の必要がある例外へ回しつつ、新しい番号幅を標準の受付経路にする変更だった。AFRINIC-9の2008年の移行説明は、プールの扱いとこの第2段階を改めて示した。事前告知には、ベンダー、運用者、ピアが改修と試験の時間を得るという価値があった。

第3段階は2010年1月1日である。割り振り時に2オクテット専用か4オクテット専用かを区別せず、4オクテットの統合されたプールから扱うという節目だった。方針は、この変更がASN割り振り方針のほかの部分を変えるものではないとも明記していた。したがって、この移行を申請資格や別の割り振り基準の改定として読むべきではない。また、2010年の日付を「この日までに全ルーター、全フォーム、全WHOIS項目、全監視製品が対応した」という完了証明に読み替えてもならない。

三段階の日程が優れていたという最も強い主張は明快である。有限の2オクテット範囲に対し、長い予告期間を置き、任意の先行申請から始め、2年後に既定値を反転し、その後に区別を外した。全ネットワーク同日切替という危険な旗日を避け、狭い番号を互換性が必要な局面に温存できる。何の日程もなければ、残量が厳しくなってからベンダーと運用者が一斉に対応を迫られ、検証不足のまま変更する費用が高まったはずだ。

だが、反対側の最も強い主張も無視できない。AFRINIC-4では「まだ自分たちには関係が薄い」と受け止めた参加者がいた。手続き記録は5月で閉じず、11月まで延びている。その後も機器非互換と番号交換が報告された。カレンダーは能力を実装しない。私的な調整機関が内部日程だけを根拠に、安全に運用できない番号の使用を事実上強制すれば、番号不足を解く代わりに接続不能という人工的な排除を作る。したがって日程の正当性は、日付それ自体ではなく、測定できる準備状況、説明可能な例外、戻せる導入順序によって支えられなければならない。

互換性は四つの面で成立して初めて意味を持つ

第一は、BGPの通信路における互換性である。4オクテット対応のBGPスピーカーは、能力情報によってその対応を相手に知らせられる。相手の能力に応じた符号化を選べるため、世界中の装置を一日に更新しなくても段階的に接続できる。新しいスピーカーが古い2オクテット対応スピーカーと話すとき、2オクテットに収まらないASNは、従来のAS_PATH上で数値23456のAS_TRANSとして見える場合がある。これは新番号を所有権的に別名へ変える仕組みではなく、古い通信相手が理解できる幅で経路を運ぶための代替表示である。

失われた新しい経路情報を後段の4オクテット対応スピーカーができるだけ復元できるよう、追加の任意・推移的属性が用いられた。ここでは年代を混ぜてはいけない。2005年11月時点で方針議論の技術的背景になったIETF文書は、完成したRFCではなく作業中のInternet-Draftであり、追加属性をNEW_AS_PATH、NEW_AGGREGATORと呼んでいた。2007年5月に公表されたRFC 4893が、後にAS4_PATH、AS4_AGGREGATORという名称で移行機構を標準化した。後の用語を2005年の文書に遡って書き込めば、仕様がいつ固まったかという監査線を壊す。

この機構にも限界があった。古いスピーカーによる経路集約は、元の経路を完全に復元するための情報を捨てることがある。従来のAS_PATHと4オクテット情報を含む属性が矛盾すれば、経路ループやセキュリティ上の危険につながり得る。AS_TRANSが見えたというだけで異常とは限らないが、どこで生じ、追加属性とどう整合し、期待した経路へ復元されたかは観測対象になる。互換性は仕様書のチェック欄ではなく、ピアごとの通信で継続的に確かめる状態である。

第二は、装置とソフトウェアの互換性である。RFC 4893の移行設計は、あるASが4オクテットASNを使い始める前に、そのAS内部のBGPスピーカーが更新されることを前提としていた。AFRINICが番号を発行しても、旧ルーターのソフトウェア、ネットワーク管理システム、経路収集器、設定生成器を更新することはできない。ベンダー版数、対応機能、試験構成、保守時間、復旧手順を運用者が確認しなければ、レジストリ上は正しい番号でも通信上は使えない。

第三は、フィルターやコミュニティーを含む運用慣行の互換性である。16ビットのASNを前提に値を埋め込んだフィルター、監視ルール、プロビジョニング処理、報告書、チケット、顧客管理や課金の項目は、ルーター本体が対応していても別に壊れ得る。従来のコミュニティー運用も16ビット前提を含み、同等の用途には4オクテットAS固有の拡張コミュニティーを検討する必要があった。相手側のピア設定や経路受け入れ規則まで含めて試さなければ、「自社装置は対応」と「到達可能」は一致しない。

第四は、レジストリと記録の互換性である。方針初期には、十進数65546を1.10と表すasdotの例が使われた。その後RFC 5396は、混在表記が運用上の混乱を生んだことを踏まえ、全ASNを単一の十進数で示すasplainを選んだ。同じ番号が1.10と65546の二つの主体に分裂してはならない。台帳は表示文字列とは独立に正規の32ビット整数を保持し、古い原表記も証拠として保存し、検索、WHOIS、経路観測、申請チケット、フィルター、顧客管理の全てで同一値へ往復変換できなければならない。

記録面では桁幅そのものも危険になる。古いデータベースやAPIが16ビットしか受け付けなければ、新しい値を拒否するだけでなく、折り返しや黙った切り捨てを起こし得る。見えるエラーより、別の有効そうな値として保存される方が危険だ。境界値を使った試験、損失を伴う書込みの拒否、移行ログの保存が必要になる。AFRINICの割り振りシステムやWHOISが全範囲を扱えるという公表は検証可能な実装主張だが、外部の監視製品や顧客フォームまで準備できたことの証明ではない。

決議から稼働までをつなぐ証拠

実装監査の中心的な問いは、制度の自己評価に頼らず、方針記録から上流在庫、申請、判断、割り振り、公開台帳、運用者の受入れ、経路での使用、例外、返却や交換までを第三者が再構成できるか、である。理事会決議だけではその連鎖の最初の一部しか埋まらない。提案本文、参照番号、版、公開メタデータ、日付付き写しまたはハッシュを残し、AFRINIC-4の議事、最終意見募集、二つの理事会決議を別々の行為として結び付ける必要がある。

次に、決議が作業へ変換された痕跡が要る。申請フォーム、割り振りエンジン、WHOISのスキーマ、委任統計、公開説明、支援手順について、変更指示、実施日、担当する運用上の役割、試験結果を残す。各割り振りでは、申請者が番号幅の希望を出したか、その日の既定段階は何だったか、正規十進値はいくつか、当時の表示形式は何か、受付と判断の時刻はいつかを追跡する。方針の期日と、フォームやデータベースの実際の変更日が異なるなら、その差を削除せず理由付きで記録する。

上流在庫には具体的な照合点がある。IANAのASNレジストリは、327680から328703までのブロックを2006年11月29日付でAFRINICに割り当てたと記録する。これは第1段階前の上流台帳の一点を証明する。しかし、その日に最初の下流割り振りが行われたことも、その日に経路広告されたことも、番号の所有権が移ったことも証明しない。監査では、この受領ブロックを地域台帳の利用可能、割り振り済み、予約、例外の合計と突き合わせ、調整項目を説明する。

2008年のAFRINIC-9説明は、移行中のプールの扱いと2009年の既定値反転をどう説明したかを見る中間点になる。2012年年次報告によれば、申請フォームから16ビットか32ビットかを選ぶ欄が外れ、共通の32ビットプールから割り振るようになったのは2011年だった。これは2010年の方針節目の一年後である。直ちに「方針が失敗した」とは言えないが、方針上の区別廃止と、受付画面の実装変更が別の時計で進んだことは示す。

2012年5月11日の公開メーリングリスト告知は、AFRINICのシステムが区別のないプールとasplain表記を支えるとの主張を記録した。この告知は日付付きの実装主張として価値があるが、最初に実装された瞬間や、全運用者の互換性を証明しない。同年の年次報告は145件のASNを割り振り、そのうち6件が32ビットだったと述べる。さらに、一部機器の非互換を理由に、上位ビットを使う32ビットASNを、より低い値の32ビットASNへ個別に交換したと報告した。数字と例外の存在は、移行が進んだ証拠であると同時に、摩擦が残った証拠でもある。

2014年のNRO資料は、互換しないルーターのため、一部顧客が4バイトASNを返却または2バイトASNと交換したという複数RIRにまたがる経験を記した。これは一つ一つがAFRINICで起きたと断定する材料ではない。それでも、番号幅の移行が地域固有の書類だけで完結せず、機器更新と相互接続に左右されたという反証にはなる。制度の公表は制度が何を報告したかの証拠であって、独立監査済みの完全性とは区別しなければならない。

交換は、単に古い番号を消して新しい番号を付ける事務処理ではない。旧ASN、新ASN、交換理由、影響した機器、承認の痕跡、公開記録の更新、経路移行、完了確認を二方向に結ぶ必要がある。旧記録を消せば、過去の経路、契約、チケット、障害記録が新番号と結び付かなくなる。交換が例外として正当だったとしても、その履歴を不可視にすれば、技術的な継続性と説明責任の双方を失う。

同じ原則は、経路観測にも当てはまる。申請チケット、割り振り台帳、WHOISまたはaut-num、委任統計、観測された経路が、番号と関係日付で整合するかを調べる。ただし、経路上に見つからないことを直ちに無効性の証拠にしてはならない。未使用、準備中、観測範囲外など、複数の説明があり得る。必要なのは欠落を断罪することではなく、差異を記録し、責任ある担当者が説明し、後に再検証できる状態を作ることである。

記録上の小さな省略が運用事故へ育つ

承認日の圧縮は、単なる歴史記述の問題に見えて、実装責任を曖昧にする。5月だけを起点にすれば、11月の最終意見募集と決議までに何が準備され、何が未決だったかを問えなくなる。11月だけを起点にすれば、5月の理事会が職員に何を指示し、その後の作業がどの権限記録に基づいたかを追えない。システムには「承認日」という単一欄だけを設けず、会合合意、理事会記録、意見募集、実施指示を、出典と状態を伴う別イベントとして保持するべきである。

表記の分裂は、一つのASNを二つの顧客または二つの経路主体と誤認する事故につながる。たとえば、申請台帳が65546、古いチケットが1.10を持ち、検索が文字列の完全一致しか行わなければ、担当者は過去の判断を見落とす。フィルター変更が片方の表記にしか適用されなければ、意図した経路を拒否する可能性もある。対策は表示を一律に塗り替えることではない。正規整数で同一性を固定し、原表記を保存し、変換規則の版と照合結果を残すことである。

桁幅の切り捨てはさらに見つけにくい。入力画面がエラーを返せば利用者は異常に気付けるが、古いデータ型が上位ビットを黙って落とし、別の有効そうな値を保存すれば、WHOIS、請求、監視がそれぞれ異なる相手を指す。割り振りエンジンが正しくても、CSV出力、APIの中継、帳票、外部顧客管理の一か所に16ビット前提が残れば連鎖は切れる。全境界面の項目幅を棚卸しし、損失変換を拒否し、入力値と保存値と再出力値の一致を自動的に確かめる必要がある。

経路復元の曖昧さは、記録問題と通信問題が重なる地点である。古いスピーカーが集約して情報を落とした場合、後段の新しいスピーカーは元のAS経路を完全には再構成できないことがある。従来経路属性と追加属性が食い違えば、どちらを信頼したかによって見える経路が変わり、ループ検出やセキュリティー判断へ影響する。生の更新を残さず、整形後の経路だけを保存すれば、障害後に集約点と情報喪失点を特定できない。したがって監視は最終表示だけでなく、能力交渉、受信属性、変換、選択結果を時系列で結ぶべきだ。

「方針日イコール準備完了」という思い込みは、これらの兆候を一括して見えなくする。2010年の区別廃止を完了宣言として扱えば、2011年のフォーム変更は単なる遅れとして切り捨てられ、2012年の交換は利用者側の失敗として処理されかねない。しかし、フォームの残存と交換は、少なくとも部品ごとの準備が同時ではなかったことを示す。方針の成功を守るには、例外を隠すのではなく、どの部品がいつ対応し、どの制約が残ったかを公開可能な証拠へ変える必要がある。

無言の交換は、障害を一時的に直しても、後の連続性を破壊する。上位ビットを使う番号から別の低い番号へ替えたなら、旧番号を単に「誤り」として削除せず、当時の機器制約、判断者、移行対象、公開記録の更新、旧経路の消失確認を残す。交換前後の双方から相手をたどれなければ、将来の担当者は、二つの記録が同じ運用主体の連続した履歴なのか、無関係な割り振りなのか判断できない。例外処理の質は、交換件数の少なさより、各交換を再構成できるかで測るべきである。

六つの危険に共通するのは、組織の結論だけを保存し、観測可能な途中経過を捨てることである。「承認済み」「対応済み」「交換完了」という状態名は便利だが、何を根拠にそう判断したかを代替しない。日付付き原資料、変更作業、正規値、元表示、試験、例外、担当役割を一つの鎖として残せば、異なる組織でも結論を再計算できる。再計算可能性こそが、台帳の正しさを制度への信頼だけに依存させない統制である。

費用を誰が負担したか

段階移行の便益は共有されても、費用は均等には落ちない。運用者にはルーターとソフトウェアの更新、ラボ試験、保守時間、技術者の作業が生じる。16ビット前提のフィルター、コミュニティー、監視、プロビジョニング、チケット、報告、顧客管理を洗い出す費用もある。相手が新しい番号や属性を解釈できなければ、ピアリングや到達性の障害になる。番号を交換すれば、再設定、対外連絡、記録の突合に追加費用がかかる。

特に古い設備を長く使う小規模ネットワークにとって、既定値の変更は、レジストリ側の番号不足対策の費用を現場へ移す面を持つ。だからこそ、公平な技術移行には、準備状況の指標、試験情報、狭い番号を求める説明可能な例外、交換手続きが必要になる。運用者が費用を負担するからといって、変更自体が不要になるわけではない。反対に、レジストリの判断が大きな実務影響を持つからといって、それが公的規制権限になるわけでもない。影響力と権限は別の軸で測るべきである。

日程を設けない反実仮想では、準備の合図が弱まり、狭い範囲が逼迫してから急な対応が必要になる。2006年に即時の4オクテット使用を事実上義務化する反実仮想では、未対応の機器やピアを持つネットワークが接続から排除されかねない。段階日程だけを設けて証拠を残さない場合、紙の上では完了しても、在庫、WHOIS、表記、経路、顧客システムが食い違う。最も堅い選択は、段階的な既定値と、持ち運べる監査証拠と、稼働コードを基準にした任意の導入を組み合わせることだった。

私的な帳簿係にできること、できないこと

番号調整の共同層が果たすべき役割は薄い。安定した識別子の意味、一意性、衝突処理、通信路での相互運用、持ち運べる証明、版を明示した拡張を共通にする。AFRINICは上流在庫を受け、重複しないASNを記録し、申請の既定値を変え、公開記録を整合させ、試験と例外処理を助けられる。この範囲でも、順序を誤れば現場に大きな損害を与えるため、透明性と説明責任は重い。

だが、住所録を保つ者は、記載した番号の作者でも所有者でもない。AFRINICの台帳行は、ネットワーク、経路、運用者に対する権原証書ではない。理事会決議も、国家の法律、行政規制、警察命令、起訴、裁判、処罰、没収の根拠にはならない。「合意」と記した内部過程だけから、主権や公法上の正統性を導くこともできない。IANAの上流記録、IETFの技術文書、NROの比較説明も、それぞれが記録する事実の証拠であり、公権力の創設証書ではない。

この境界は、現実の相互接続制約を否定するものではない。ピアが理解しない番号を一方的に使えば通信は成立しない。任意採用とは、物理的・技術的制約が消えることではなく、共通層が必要以上に運用判断を奪わないことを意味する。調整機関は互換性の事実を公開し、日程、既定値、例外、記録形式を整える。運用者は自らの機器、ピア、顧客影響を試し、実装する時点と経路を決める。合意が必要なのは実際の相互運用に必要な範囲であり、それを超える将来判断は各運用主体に残る。

最終的に移行を実在させるのは決議文ではない。4オクテットASNを正しく運ぶBGPスピーカー、AS_TRANSと追加属性を矛盾なく扱う実装、同じ番号を同じ主体として扱う台帳、試験結果を見て導入を選ぶ運用者である。決議200605.27は重要な開始記録だった。しかし、それが承認したのは調整手順と実施作業であって、機器の準備完了でも、番号の所有でも、公的な統治権でもなかった。