Sasha RomijnのNRTMv4草案は意図と違う規則を書いていた

要約

IRRDの開発者・初代メンテナーであるSasha Romijnは、IRRミラーを同期させるNRTMv4の共著者でもある。
IRRDとRIPE NCCが別々に実装すると挙動が食い違った。Romijnが草案を読み直すと、書かれた規則は自分の意図と異なっていた。
IESGの査読者はIPv6の例で route と route6 の誤りを指摘した。2026年11月2日時点で、IETF文書はRFC Editorの最終承認待ちだ。

Sasha Romijnは、RIPE NCCがNRTMv4を誤って実装したと思った。草案を読み直して、違う場所を見つけた。文面が彼女の意図を表していなかった。

Romijnは独立系開発者で、IRRDバージョン4を最初に開発し、保守してきた。NRTMv4の共著者でもある。このプロトコルはInternet Routing Registry（IRR）の記録を権威データベースからミラーへ運ぶ。ネットワーク運用者はIRR情報を経路フィルターやネットワーク設定に使うため、ローカルのミラーが最新かどうかを把握したい。

従来のNRTMv3では、データベース全体のダンプと、その後の差分取得が別々の仕組みだった。シリアル番号は接続先のサーバーインスタンスに依存し、ミラーが追いついているかを確かめる手掛かりも弱かった。NRTMv4はHTTPSでスナップショットと差分ファイルを配信し、署名付きの更新通知ファイルにそれらのハッシュを記載する。クライアントは署名を検証し、受け取ったファイルのハッシュを照合できる。

草案が試されたのは、著者自身のコードだけではなかった。RomijnとRIPE NCCはそれぞれ実装を進めた。挙動が合わなかったとき、彼女はまずRIPE NCC側の実装を疑った。IRRDは彼女が意図した規則に従っていたが、草案には別の規則が書かれていた。異なるコードを並べたことで、初期版の草案にあった問題が見つかった。

別の問題は、例の中に残っていた。route はIPv4の経路オブジェクト、IPv6には route6 が必要だ。IESGの査読者がこの取り違えを見つけた。障害が起きたのではない。実装者がその例を仕様の指示として使う前に、査読で止まった。

2026年5月のRIPE 92で、Romijnは五つの実装が相互運用できたと報告した。RIPE NCCは本番でNRTMv4を使い、IRRDはクライアントとサーバーの両方に対応しているという。RIPEの現行ドキュメントには本番の通知ファイルと公開鍵が載っている。11月2日時点で、IETF Datatrackerはバージョン-11をRFC Editorのキューに掲載し、最終承認待ちとしている。

プロトコルは、作者の実装が動けば完成するわけではない。別のチームが同じ文章から異なるコードを作れるかどうかが、文章の精度を試す。経路登録データを運ぶ仕組みでは、その読み違いを本番運用より先に見つける価値がある。