要約

  • RFC 9510 は1バイトを5ビットの指数部と3ビットの仮数部に分け、ミリ秒から年単位までを表す。表現できない値は直下の値へ丸める。
  • 既存の Interest Lifetime と Recommended Cache Time の1バイト形式を再利用するため、同じビット列でも旧実装と更新済み実装では意味が大きく変わる。
  • 判断可能な証拠には、TLVそのものだけでなく、送受信ソフトウェア、各ホップでの変換、PIT／キャッシュの実動作、パケット観測までが必要である。

問題は時計のずれではない。辞書が二つあることである。

ローリング更新中の CCNx 網を、一つの Interest が通る。Interest Lifetime の長さは1バイトだ。旧フォワーダーは、その値を0から255ミリ秒までの整数として読む。次のフォワーダーは RFC 9510 に対応しており、同じ8ビットを5ビットの指数部と3ビットの仮数部に分ける。前者がすぐ破棄する状態を、後者は年単位で保持し得る。

RFC 9510 が解こうとした課題は明確だ。CCNx の意味論と従来の TLV メッセージ形式を、帯域も電力も厳しい環境で使うには、64ビット時間値が重い場合がある。低電力無線への ICN 適応はコンパクト表現の実用性を示し、ICN の研究課題は制約環境が本質的な設計対象であることを示している。

採用された表現は RFC 5497 の考え方を引き継ぐ。符号ビットを持たない対数型で、ゼロ付近は細かく、遠くなるほど精度を譲って範囲を稼ぐ。最大コードは125,829,120秒、ほぼ4年である。正確に表せない時刻は、入力を超えない最も近い値に切り下げる。したがって、符号化は中立な収納箱ではなく、明示的な近似判断を含む。

新しい型番号を作らなかった理由

この仕様は新しい TLV を割り当てず、既存型の長さ1を新形式の合図にした。IANA の CCNx レジストリに追加作業がないのは、そのためだ。

後方互換性の問題は仕様自身が認めている。判断の背景には、RFC 8569 と RFC 8609 が Experimental であること、主な対象が比較的小規模なセンサー／IoT網であること、対象フィールドが署名ハッシュ外のホップ単位情報であること、対応フォワーダーなら旧新形式を再符号化できることがある。これは「混在しても安全」という意味ではない。管理可能な領域なら一斉更新も選べる、という前提付きの判断である。

Interest Lifetime では誤読が左右非対称に見えて、どちらも危険だ。旧ノードがコンパクト値を読むと最大255ミリ秒になり、PIT エントリーを想定より早く解放し得る。更新済みノードが旧方式の短い整数を読むと、最大で約4年の値となり、状態空間を占有し得る。短すぎる障害と長すぎる障害を、同じ構文検査は見分けられない。

Recommended Cache Time は別の壊れ方をする。新方式では1バイトは相対時間であり、受信時刻から絶対期限を作り、次ホップへの送信時に残り時間を再符号化する。旧方式では8バイトの絶対時刻だったため、長さ1は構造／構文エラーとして破棄すべき値である。破棄しない旧実装なら、1970年直後の時刻のように過去として読む。キャッシュ効率だけでなく、パケット受理そのものが分岐する。

触れていない時間を混同しない

Signature Time と Expiry Time は圧縮対象ではない。どちらも Content Object のセキュリティ包絡に含まれる絶対時刻であり、RFC 9510 は意味と安全性を保つ現実的なコンパクト化がないとして除外した。ホップごとに書き換えられる Lifetime／Cache Time と、署名された絶対時刻を同じ「鮮度」指標へまとめてはならない。

Recommended Cache Time は内容の真正性を証明しない。Expiry Time はあるキャッシュが実際にいつ消去したかを証明しない。署名が正しくても、中間フォワーダーが1バイトをどの規則で読んだかは分からない。運用証拠は、この違いを残す必要がある。

証拠はホップごとに積む

最初に保存するのは、パケット識別子、TLV型、長さ、原始バイトである。次に、送信側のビルド、機能設定、符号化判断、受信側のビルドと解釈規則を加える。その後に受信時刻、復号された期間、絶対期限、再符号化を記録する。PIT の生成・解放、キャッシュの受入れ・破棄・退避はさらに別のレシートだ。最後にパケット追跡とアプリケーション観測を置く。

公式資料も同じように役割を分けて読むべきである。RFC Editor の書誌情報、テキスト版、XML版は公刊内容を固定し、正誤表検索は訂正の有無を示す。Datatracker の履歴、最終ドラフト、参照関係は成立過程を追える。しかし、どれも特定ネットワークの実行記録ではない。

RFC 9510 は IRTF の ICNRG による Experimental RFC で、実験実装と評価のために公刊された。IETF 標準ではない。RFC 7841が説明する通り、IRTF の成果は研究グループの合意を表しても、配備に適するとは限らず、IETF標準過程での正式な地位を持たない。この限定は弱点ではなく、採用権限を正しく置くための境界である。

編集上の視点として、Heng Lu のランニングコード優先、最小初期仕様と自発的採用、現実の層を明示的に用いた。これらは IETF／IRTF の規範ではない。ここでの効用は、仕様上の記号、ソフトウェアの解釈、作られた状態、観測された結果を一つに潰さないことである。