要約

  • RIPE NCCのRIS四半期計画では、RFC 6396の拡張タイムスタンプに対応し、MRTファイルで1秒未満の時刻を記録するソフトウェア変更が進行中とされている。公開ページに稼働開始日はない。
  • RRC03の5分間のファイルをヘッダーだけ解析すると、188,592件のMRTレコードが300個の整数秒に分布し、すべての秒に複数件があった。細かい時刻は同じ秒内の記録を区別し得るが、時計の誤差や収集装置間の同期を示すものではない。

5分間に188,592件

2026年10月16日04:00 UTC、RIPE RISのRRC03は updates.20261016.0400.gz を公開していた。ファイル名の時刻から始まる5分間のデータだ。MRT共通ヘッダーを調べると、188,592件が300個の整数秒に割り当てられていた。各秒に複数の記録があり、最多の秒は2,432件だった。

これは経路の数でも、経路変更の数でもない。ファイルにはBGP4MPレコードが含まれ、サブタイプによって内容も異なる。今回の集計は12バイトの共通ヘッダーまでにとどめたため、どのメッセージが経路を変えたかは調べていない。ファイル内の並び順も保持されている。したがって、この数字だけで順序の曖昧さや情報の欠落を主張することはできない。

確認できるのは、ひとつの収集装置のひとつのファイルで、多数の別レコードに同じ整数秒が付いていることだ。サブ秒表記が何を増やし得るかを考えるには足りるが、すべてのRISアーカイブやインターネット全体を代表する標本ではない。

RIPE NCCのQ4 2026計画は、第2項「MRTファイルの品質改善」で、RFC 6396の拡張タイムスタンプに対応するソフトウェア変更を挙げている。ページの最終更新は2026年9月17日で、状態は「進行中」。適用日、対象となるRRC、時計誤差の測定、切り替えの検証は公開されていない。同じ計画には、RIB/bviewに残る特定種類の経路停止を防ぐため、処理系に合成BGPホールドタイマーを加える別作業もある。両者を同一の不具合対応や一体の検証とみなす根拠はない。

時刻欄が細かくするもの

RFC 6396の通常のMRT共通ヘッダーでは、UTCの紀元時刻を基準とする4バイトの整数秒を使い、うるう秒は数えない。拡張形式はそこに符号なし32ビットのマイクロ秒オフセットを加える。BGP4MP_ET はその拡張時刻を使うレコードタイプのひとつだ。

同じ整数秒の中でも、生成側が異なるオフセットを付ければ、下流の解析ツールはそれぞれの記録時刻を区別できる。密なイベント列を調べる際に、すべてを同じ秒へ丸めずに済む。これは書式が表現できる粒度を変える改善であり、同一収集装置の記録を調べる研究に有用な可能性がある。

ただし、マイクロ秒欄があることは、誤差もマイクロ秒だという意味ではない。分解能は表せる刻み幅、正確さは基準時刻とのずれ、同期は複数の時計の相対関係を問う。さらに、時刻が受信、処理、ファイルへの書き込みのどの段階で付与されたかという定義も必要になる。欄の桁数だけではどれも分からない。

NTPの性能モデルは、時計オフセット、ジッター、分散、同期距離を別々の量として扱う。これはRISの時計に問題があるという指摘ではない。精密に表現できることと、正確に測れていることが別だからだ。小数点以下を増やしても、読み値の不確かさが自動的に記録されるわけではない。

収集装置ごとの観測範囲

RISのアーカイブが役立つのは、ルートコレクターがどのピアから何を観測したかを保存するからだ。ひとつのRRCがインターネットの全経路を見るわけではない。レコードを読むには、RRC、MRTのタイプとサブタイプ、アーカイブ区間、生成処理の情報が要る。サブ秒時刻は文脈の一部を増やすだけで、離れた観測地点を同期済みの世界時系列に変えるものではない。

RRC03の例は範囲を限定している。5分間の一ファイルを、更新時刻の後に取得し、圧縮データのハッシュを残し、共通ヘッダーだけを解析した。2,432件という最大値は、ひとつの秒に記録が集中していると示すだけだ。経路増加、障害、遅延、あるいはRIPE NCC全体のアーカイブ品質は示さない。リンク先のファイルから数え直せるようにしている。

また、異なるマイクロ秒値を見て、ネットワーク上の出来事の前後を直ちに決めることもできない。タイムスタンプが何を表し、時計がどう調整され、どの程度ずれ得るかを知る必要がある。収集装置が別なら、各時計の相対誤差と異なる観測経路も加わる。時刻の解像度を上げると差は見やすくなるが、比較自体が検証済みになるわけではない。

稼働後に必要な説明

変更の稼働後は、どのRRCとMRTタイプが拡張時刻を出すのか、いつからか、旧形式をどう識別するのかを告知してほしい。タイムスタンプがどのイベントの時刻かも明確にし、パーサー、保存、再出力の各段階でマイクロ秒欄が保持されるかを示す必要がある。

時計の健全性は別の証跡にする。同期や不確かさを観測する方法、その対象範囲と期間が公表されれば、利用者は同一RRC内とRRC間の比較を分けられる。ある指標を公開していない場合、その点を明記すれば、細かい数値が精度保証に見えることを避けられる。

小さな再現可能な試験は十分役立つ。ダウンロード、展開、解析、再出力で時間欄が丸められず、元の並び順が変わらないことを示せばよい。新旧形式が同時に存在する期間の扱いも説明できる。全レコードがマイクロ秒単位で正確だと約束する必要はない。何を記録する変更かを理解できるようにすることが目的だ。

計画された形式の改善そのものには意味がある。しかし、現時点で確認できるのは作業が進行中という記述と、ひとつのファイルで同じ整数秒を共有するレコード数だけだ。項目の意味、対象範囲、時計の不確かさを分けて公開すれば、より細かい時刻は、精度を暗示する記号ではなく解釈可能な測定値になる。

出典