要約

  • RIPE NCCの移行は一度の切替ではなかった。2001年4月23日に新データベースが稼働し、5月14日にauto-dbmがRPSL専用となり、10月15日にRIPE-181の変換経路が終了した。
  • 公開記録は、当時Database Group ManagerだったAndrei Robachevskyを移行に結びつける。2000年にv3の検索仕様を説明し、翌年4月には第一段階の完了を告げる通知に署名した。
  • 登録オブジェクトの形式を変換しても、それだけでアドレス資源の所有者、現在のBGP経路、実際のパケットの行き先が証明されるわけではない。

切替は入口ごとに進んだ

5月14日の告知は利用者の選択肢を明確にした。auto-dbmはRPSL形式のみを受け付ける。RIPE-181を使う更新はauto-181へ送り、そこでRPSLに変換する。ただし、この互換経路も10月15日までである。auto-rpslは引き続きRPSLを受け付け、テスト用データベースにも同じ変更が適用された。

運用担当者に必要だったのは、「移行済みか」という一語の答えではない。送信スクリプトがどの形式を作るか、どのメールアドレスに送るか、そこで何の認証規則が適用されるか、変換経路がいつ閉じるかを確認することだった。資料から、修正が必要だったスクリプトの数や、全利用者で障害が発生したかは分からない。それでも、移行を検証できるインターフェースと期限が公開されていた点は読み取れる。

4月23日の通知では、新版のRIPE Databaseが稼働し、全オブジェクトをRPSLへ自動変換して読み込んだと説明されている。それでも旧形式への入口はすぐ消えなかった。第一段階ではauto-dbmが制限付きでRIPE-181を受け付け、空属性や誤記属性を拒否し、PGP認証をサポートせず、RPSLの認証規則を適用した。auto-rpslはRPSLを直接受け付けていた。つまり、変換対象は記録だけでなく、更新経路と権限の扱いでもあった。

検索仕様は、何を見たかを決める

2000年8月、Database Group Managerとして署名したRobachevskyのメールは、v3の検索機能を列挙し、利用者に意見を求めた。完全一致検索は入力したアドレス範囲と一致するオブジェクトを探す。より広い範囲を探す検索は、その入力を含む最小の上位範囲を返す。-Kはオブジェクトの主キーだけを返す。データベースのsource情報はミラーリング可否やシリアル番号範囲を示し、逆引き検索は管理者・技術担当者などの連絡属性を使える。

これらは記録が正しいと保証する機能ではない。どんな問いをクライアントが立て、どの範囲の情報を受け取るかを定める。主キーだけの応答は自動処理に便利だが、周辺情報を含まない。上位範囲が見つかったことは完全一致の証拠ではない。ミラー用のsource情報も複製インターフェースの説明であって、世界全体の経路を測ったものではない。インターフェース変更だけで、データ本体が同じに見える監視・保守ツールの挙動も変わり得る。

RIPE 38のDatabase WG議事録草稿は、Robachevskyによる20分の移行説明を記録している。検索利用者、更新利用者、スクリプト、ほぼリアルタイムのミラーが、RPSL、アクセス制御、データベース形式、ミラーリングプロトコルに関係すると整理されていた。議事録は草稿と明記されているため、会議で記録された説明の証拠として扱う。移行が全て予定通りに終わったことの唯一の根拠にはしない。その点は後の告知と年次報告で確かめられる。

互換性には期限と負担がある

RIPE NCCの2001年年次報告は、4月23日に始まり10月15日に終わった6カ月の移行として振り返る。この期間、レジストリは変換サービスと告知を担い、オブジェクト管理者は更新生成ツールを見直し、ミラー運用者は形式と同期を確認し、クライアント開発者は応答の意味を確かめる必要があった。公開資料は各組織の費用や作業時間を数えてはいない。一方、レジストリが管理した項目——受け付ける形式、認証規則、入口、互換経路の終了日——は明らかにしている。

共有レジストリを運営する責任は、データを読み込むことだけでは完了しない。利用者には提出形式、更新権限、検索結果の範囲、ミラーの追従方法、暫定経路が消える時期が必要だ。これは公共的な参照サービスを提供する側の義務である。しかし、サービス運営者がその記録に載る資源を所有することや、依存する組織に対する政治的権限を持つことを意味しない。

RFC 2622はこの違いをもう一段明確にする。RPSLはルーティングポリシーを表現する言語であり、maintainerオブジェクトはデータベースの更新を認証する仕組みに関わる。RFCの著者として挙げられているのはAlaettinoglu、Villamizar、Gerich、Kessens、Meyer、Bates、Karrenberg、Terpstraであり、Robachevskyは含まれていない。移行の仕事が記録されていることから、RPSLやRFC 2622を彼が作ったと結論づけることはできない。

登録と経路は別の記録である

RIPE Databaseの登録オブジェクト、Internet Routing Registryのポリシーオブジェクト、BGP観測は、それぞれ異なる問いに答える。変換後の登録は当時データベースが何を保存していたかを示す。RPSLオブジェクトは登録された意図を表す。ルートコレクターは、ある観測地点で特定時刻にBGP広告を見たかもしれない。どの一つも他の二つを代替しない。登録だけでは現在の到達性、パケット配送、法的所有権、全ルーターがポリシーに従っていることを証明できない。

登録が古ければ、データ品質と更新権限を調べる必要がある。経路が消えて見えたなら、別の経路観測を調べる。誰が更新できるか争いがあれば、形式変換では解決しない。この移行の確かな意味はもっと限定的だ。レジストリのインターフェースと責務を利用者が確認できるようにしつつ、記録システムを、その背後の資源や実際のネットワークと同一視しないことにある。

人物像を証拠の範囲にとどめる

2000年8月のメールでは、RobachevskyはDatabase Group Managerとして署名し、v3検索機能を紹介した。2001年4月には第一段階、オブジェクト変換、RIPE-181更新の制限を知らせる通知に署名している。RIPE 38議事録草稿は予定された説明者として彼を挙げる。ここから描けるのは、利用者に移行を伝え、意見を求めた管理者である。彼が変換ソフトを書いた、すべてのルールを単独で決めた、各オブジェクトを検証した、とまでは言えない。

公共の記録基盤を運営する権限には、予測できるアクセスと追跡可能な変更を提供する責任が伴う。しかし、記録システムを動かすことは記録対象を所有することではない。資料がよく示すのは日付、入口、形式、権限の規則である。個々の利用者の費用、全員の移行状況、現在の経路については、この資料群だけでは確定しない。

出典