要約

  • RFC 3963 は、モバイルルーター一台のバインディングによって複数のモバイルネットワークプレフィックスの接続地点を変え、内部ノードには移動処理を要求しなかった。R フラグ付きで状態ゼロの確認は、転送設定の成立を示すだけで、各ノードの到達性を示さない。
  • 明示モード、暗黙モード、動的ルーティングではプレフィックスの根拠が異なる。したがって運用記録は、認可、経路、トンネル、プレフィックス試験、ノード応答、セッション、サービス結果を分けて保持しなければならない。

車両内のセンサーや端末は、外のアクセス回線が切り替わっても同じアドレスと同じデフォルトゲートウェイを使い続ける。そのゲートウェイがモバイルルーターである。RFC 3963 は 2005 年 1 月、NEMO Basic Support としてネットワーク単位の移動を標準化した。内部ノードにモビリティ機能を配るのではなく、境界の一台に位置変化を集約したのである。

ホームリンクを離れたモバイルルーターは Care-of Address を取得し、ホームエージェントへ Binding Update を送る。R フラグはモバイルルーターとしての処理を要求する印だった。ホームエージェントは安定した Home Address と現在の Care-of Address を結び、許可された Mobile Network Prefix に向けた転送を設定する。両者の間の双方向トンネルが、内部ネットワークの外部接続を運ぶ。

ここで応答の意味を広げてはいけない。状態ゼロかつ R フラグ付きの Binding Acknowledgement は、ホームエージェントが更新を処理し、プレフィックス転送を設定したとモバイルルーターが判断できることを意味する。しかし、背後の端末を個別に検査したわけではない。TCP セッションの継続、アプリケーション権限、サービス完了、最適経路も確認していない。

R フラグは処理種別であり、単独の身分証ではない

モバイルルーターは要求に R を立て、受理したホームエージェントは正の確認に R を立てる。フラグはメッセージの意味を決めるが、送信者を認証する力はない。RFC 3963 は両者のシグナリングを IPsec で認証するよう求めた。保護されたセキュリティアソシエーションが相手を裏付け、その内側で R が要求内容を表現する。

監査記録には「成功」以上のものが要る。Home Address、Care-of Address、シーケンス番号、寿命、H と R、正確なプレフィックスオプション、IPsec の関連、確認状態、トンネル端点、追加・削除された経路を残すべきだ。それでも記録できるのは制御面の処理であり、内部機器の稼働状況ではない。

RFC 3775 は当時の Mobile IPv6 のホスト移動を定義し、RFC 6275 が後にその基盤を改訂した。RFC 3963 は移動端点の後ろにネットワークを置いた。代表するアドレス範囲は広がったが、観測能力まで広がったわけではない。

プレフィックスを知る三つの経路

明示モードでは Binding Update に一つ以上の Mobile Network Prefix オプションを載せる。ホームエージェントは、どのプレフィックスをそのルーターに許可したかを示す Prefix Table と照合できる。複数プレフィックスは一括処理だった。一つでも転送を設定できなければ、どれも転送せず状態 141 で拒否する。権限のないプレフィックスには状態 142 を返す。

全件かゼロかという規則は、一つの確認が部分成功を隠すのを防ぐ。しかし Prefix Table との一致は権限の証拠にすぎない。プレフィックス内の各ノードが存在し、起動し、応答することまでは示さない。

暗黙モードでは要求にプレフィックスオプションを載せない。ホームエージェントは事前設定から対象を決め、情報がなければ状態 143 で拒否する。同じように見える成功応答でも、その根拠が現在のメッセージにある場合と、別の管理系にある場合がある。モード、設定版、所有者、更新時刻を保存しなければ来歴は復元できない。

トンネル上の動的ルーティングは第三の経路を作る。変化に追随できる一方、内部トポロジーを露出しうるため、仕様はルーティングメッセージへの ESP 機密保護を勧めた。「経路あり」だけでは、静的設定、明示要求、暗黙設定、動的学習のどれかが分からない。

静的経路についての注意はさらに鋭い。シグナリング量を減らせても、対応するモバイルルーターが到達不能になった後まで経路が残りうる。ルーティングテーブルは設定上の意図を正しく示しながら、現在の生存性について誤解を招くことがある。

透明性は依存点も集約した

Basic Support では、Mobile Network Node と Correspondent Node の通信はホームエージェントを通る。下りパケットは Care-of Address へカプセル化される。モバイルルーターは、トンネルモード IPsec が代替しない限り外側の送信元がホームエージェントであることを確認し、内側の宛先が Mobile Network Prefix に含まれることを確認してから内部へ渡す。

上りでは、モバイルルーターが内部プレフィックス外の送信元を排除し、ホームエージェントもトポロジー整合性を確認する。これらはアドレス偽装を抑える境界であり、利用者の身元確認やアプリケーション認可ではない。

Basic Support は Mobile Network Prefix の経路最適化を定義しなかった。モバイルルーターが木構造に入れ子になると、ループを避けてもトンネルが重なりうる。RFC 4885、RFC 4886、RFC 4887 は用語、目標、問題を整理し、RFC 4888 は最適化問題、RFC 4889 は解決空間を論じた。到達経路ができたことと、その経路が良いことは別である。

後続仕様は周辺の選択肢を増やした。RFC 5488 と RFC 6276 は NEMO 環境での DHCPv6 プレフィックス委任を扱い、RFC 6089 はフローバインディングを扱う。どの拡張も、最初の Binding Acknowledgement をノード単位の確認には変えない。

文書の来歴は RFC Editor の情報ページ、RFC 3963 の正誤表検索、IETF Datatracker、IANA Mobility Parameters レジストリ で確認できる。そこから分かるのは公開状態、報告済み訂正、割当値であり、特定環境での採用や実装品質ではない。

実務の台帳は段階ごとに作る。移動検出、二つのアドレス、更新内容、プレフィックス根拠、認可、全件処理の判定、確認、IPsec、トンネル、経路変更、内外アドレス検査、プレフィックス試験、ノード応答、セッション、サービス結果を別々に結ぶ。成功が到達した段階だけを成功として扱うためである。

RFC 3963 の革新は、一つのバインディングに多くを運ばせたことだった。その歴史から学ぶべき節度は、一つの応答に多くを証言させないことにある。

出典