要約

  • RFC 1475 の前方向経路識別子は、発行した次ホップのルーターにだけ意味がある64ビットの私有参照であり、原則としてホップごとに書き換えられた。
  • ゼロや無効値は通常の宛先検索に戻し、集約、経路変更、フロー、プロトコル変換は新しい判断を必要とした。
  • Experimental RFC、CATNIP への発展、Historic 化は文書史を示すが、実装、配備、個々のパケットの通過経路を証明するものではない。

名前が先に作る誤解

1993年6月の RFC 1475 は、TP/IX、別名 Internet Protocol version 7 を記述した。アドレスを拡張し、トランスポート層を手直しし、データグラム転送と高速な経路・フロー処理を組み合わせようとした提案である。各データグラムには forward route identifier という64ビット欄が置かれた。

名称だけを見ると、送信元が選んだ完全な経路をパケットが携帯するように読める。ある地点で値を採取すれば経路が分かり、同じ値なら同じ道を通った、と考えたくなる。だが仕様の動詞は「記述する」ではなく「渡す」「検証する」「置き換える」である。

ルーターは自分の内部経路を示す値を上流の隣接装置へ通知した。その値はテーブルの添字でも、実際のメモリーアドレスでもよいとされた。受け取る上流装置にとっては不透明で、理解する必要はない。次にそのルーターへパケットを送る際、借りた値を返せばよい。

つまり、識別子は経路の公的な名前ではない。発行者が管理する状態への私有ハンドルである。ビット列はネットワークを移動しても、意味の所有権は移動しない。

A、B、Cで別々のものを指す

RFC の例では、ホスト X と Y の間にルーター A、B、C が並ぶ。C は Y への経路を B に通知し、C 内部の識別子を添える。B はそれを解読せずに保存する。次に B は C 経由の経路を作り、B 内部の別の識別子を A に知らせる。

X が最初のデータグラムを出すとき、欄はゼロである。A は通常どおり宛先アドレスを検索し、B への経路を選び、B から借りた値を書いて転送する。B は自分の値として解釈し、C への経路を得る。そして欄を C の値で上書きする。C はその値を使い、最終区間では欄を消す。Y は自分の宛先アドレスを認識し、経路識別子を無視する。

欄の位置と長さは変わらないのに、A の出口では B の状態を、B の出口では C の状態を指す。宛先では必須の意味を持たない。同じ64ビット値が二台のルーターで無関係な対象を指すことも、異なる値が同じ物理リンクへ進めることもあり得る。

このためパケットキャプチャだけでは足りない。識別子を発行した装置、経路表の世代、対象宛先、検証時刻、選択した出口、置換後の値を結びつけなければ、「経路」という言葉に必要な連続性は復元できない。

ゼロは失敗ではなく、判断の依頼だった

ゼロは「到達経路なし」を表さない。利用できる借用ハンドルがないので、現在のルーターが通常の宛先検索を行う、という意味だった。X の初回送信でも、変換の後でも、ゼロは正常な出発点になり得る。

無効な識別子も同じ経路に戻る。RFC は、特に値がメモリーアドレスになり得るため、範囲やアラインメントを検査し、参照先の経路がデータグラムの宛先と一致するかも確認すべきだとした。検証に失敗すれば、値を黙って無視し、ゼロと同じく通常検索を行う。

これは高速化と正しさを分ける設計である。識別子は検索を省略できるが、宛先とローカル経路表が回復時の権威として残る。値が有効だったという記録も、転送先が受信したことや最終配送を示さない。単に、その瞬間のローカル参照として受理された可能性を示すだけである。

集約と「レールの敷き直し」

経路集約では、識別子が集約エントリーまでしか特定できない場合がある。構成する経路が分岐するルーターに到着すると、より具体的な宛先を調べ、下流の経路を選び、その次ホップ用の識別子を書かなければならない。借りた知識の粒度が不足する地点で、高速経路は終わる。

経路が飛行中に変わる場合、RFC はどこかのルーターが各データグラムをどう「re-rail」するか決める必要があると述べた。値を携帯していても、経路表の変化は止まらない。識別子が発行時には正しくても、到着時の状態では古いかもしれない。

この表現は重要である。パケットは完成済みの線路図を持つのではない。変動する分散システムの次の駅へ、前の判断に由来する手掛かりを運ぶ。駅側にはそれを拒否し、分岐を選び直す権限が残る。

フローという名も証明を増やさない

TP/IX では経路識別子の代わりにフロー識別子を使うこともできた。各ルーターは、フロー構築時の経路を指す私有フローオブジェクトを保持できる。データグラムはフローに入り、また外れることができた。

しかし経路 ID とフロー ID の区別方法もルーター内部の私事だった。送信者からは不透明で、暗黙に次ホップだけが理解する。非ゼロ値が見えたからといって、帯域予約、容量、サービス品質、配送結果まで証明されたことにはならない。発行装置の型情報と状態、関連経路、利用時刻、転送結果が別に必要である。

RFC 1475 はセキュリティを議論していないとも明記した。範囲や宛先の妥当性検査は、認証、認可、完全性の保証ではない。内部ハンドルを資格証明に読み替える根拠はない。

RAP の通知には時刻があった

対になる RFC 1476 は、RAP という経路配布手順を定めた。Add Route は、通知した時点で送信者の転送データベースに実際にロードされている経路を示さなければならない。受信側は、その通知に含まれる64ビット値を相手へ返すデータグラムに入れる。

これは単なる将来の約束より強いが、時刻に拘束される。「通知時にロード済み」は「その後も常に有効」ではない。Purge Route は経路を削除し、さらに配布した相手へ撤回させる。文書はローカル削除の前に purge を送るのが望ましいとしつつ、その順序を必須にはできないと認めた。

削除、purge 送信、伝播、飛行中パケットの間には時間差がある。真正な識別子が、過去の通知を正確に表しながら、現在の転送には使えないことがある。RFC 1476 の情報記録 は文書の来歴を示すが、この運用上の隙間を埋めない。

変換点ではゼロに戻した

TP/IX は IPv4 と IPv7 の装置を任意の順で更新できるよう、変換を想定した。「Don't Convert」オプションは線上のルーターによる変換を制御したが、受信ホスト内部の処理まで同じ意味で禁止できるわけではなかった。異なる道を通ったフラグメントが別々の変換点に着けば失われることもある。ハイブリッド IPv7 アドレスを持つだけでは、ネイティブ IPv7 実装とも言えない。

IPv4 から IPv7 への変換では、前方向経路識別子をゼロに設定した。変換器は解釈不能な私有ハンドルを別の体系へコピーして、偽の連続性を作らなかった。次の領域に新しい判断を要求したのである。アドレス、版、変換、フラグメント、識別子、配送は、それぞれ別の記録として扱う必要がある。

Historic は文書の結論である

RFC Editor の情報ページ は現在 RFC 1475 を Historic とする。RFC 1752 は TP/IX が CATNIP へ発展した経緯を記録し、CATNIP は選定には不完全すぎると評価して、128ビット SIPP を IPng の基礎に推薦した。RFC 6814 は、廃れた IPv4 オプションを整理する際に RFC 1475 を正式に廃止した。RFC 791 は IPv4 の基準文書として残った。

これらは提案、評価、文書上の選択を確定する。だが、部品を実装した者が一人もいなかったことや、特定の実験網で何が起きたかまでは示さない。逆に、RFC として出版された事実も、本番配備の証拠にはならない。

仕様、推奨、実行コード、装置状態、観測パケット、配送結果は別の現実層にある。RFC 1475 の識別子が教えるのは、便利な名詞ほど、どの装置が、いつ、何を実行したかという動詞へ戻して読む必要があるということだ。

情報源