要約

  • RFC 5142 は Mobility Header の type 12 を定義し、認可されたホームエージェントからモバイルノードへ切替を指示できるようにする。
  • 保守、負荷分散、機能分離は想定例だが、いつ誰を動かすかというトリガーは規格外のローカル判断である。
  • メッセージは優先順位付きの代替 IPv6 アドレスを示せるほか、空のリストでホームエージェント探索を指示できる。
  • IPsec はメッセージの送信元と完全性を保護するが、移行先の容量やサービス可能性までは保証しない。
  • 現在のホームエージェントが送信した場合、旧バインディングを削除する Binding Update が確認応答として働く。
  • その応答は旧側からの退出を示すだけで、新しい制御状態や通信経路への到着を示さない。
  • 探索、Home Address、セキュリティ確立、新規バインディング、トンネル、パケット、アプリ結果には個別の証跡が必要である。
  • 応答がなくても旧側はノード状態を推測せず、バインディング寿命が切れるまでサービスを続けるべきである。
  • 送信速度は新側の資源フィードバックに従うか、登録受入能力より十分低く設定し、既定上限は毎秒一件である。
  • 異なるホームプレフィックスへの移動は Home Address を変え、登録成功後も既存接続を失わせ得る。
  • Binding Acknowledgement の受理は制御面の証拠であり、転送やエンドツーエンド継続の証明ではない。
  • 経営判断では、旧経路を可能な限り保持し、到着側の観測を基準に段階的な移行を統治する必要がある。

出発件数では移行を管理できない

旧ホームエージェントが過負荷になれば、何件の切替メッセージを送ったかは簡単に数えられる。百件送れば、百件分の負荷を逃がしたように見える。しかし移行先では、候補選択、IKE/IPsec、Binding Update の検証、状態作成、トンネル設定が一件ずつ待っている。送信件数は受入件数ではない。

RFC 5142 はこの非対称性を明示する。新ホームエージェントの資源と追加の切替メッセージの間にフィードバックループを置くか、新規登録を処理できる速度より十分に低い上限を設ける。既定最大値は一秒に一件である。

重要なのは数値そのものより制御方向である。出発側の都合で速度を決めず、到着側が証明できる余力で決める。切替は共有メッセージ一つで完了する中央命令ではなく、複数のローカル判断を結ぶ最小限の調整である。

候補アドレスは予約票ではない

Home Agent Switch は Mobility Header type 12 のメッセージである。現在のホームエージェントを使うのをやめ、別のホームエージェントを取得するようモバイルノードへ伝える。保守、負荷分散、機能別の分散、リナンバリングが利用場面として挙げられる一方、切替時期を決めるバックエンドは規格の範囲外である。

メッセージには代替ホームエージェントの IPv6 アドレスを並べられる。Mobile IPv6 の Home Agent Preference に従い、同じ優先度の候補はランダム化される。先頭がサービス不能なら次へ進む。アドレス数がゼロなら、モバイルノード自身が探索を行う。

このリストが伝えるのは試行順序であり、容量の確保ではない。候補が現在到達可能か、そのノードを認可するか、同じ Home Address を維持できるかは後で判明する。Binding Refresh Advice が旧バインディング削除までの時間を四秒単位で示しても、期限までの完了は保証されない。

したがって証跡には、候補順、優先度、同順位の並べ替え、各候補の失敗理由、Advice の期限を残す必要がある。最後の状態だけでは、探索が失敗したのか、認可が失敗したのかを区別できない。

正しい署名は正しい行き先を意味しない

切替メッセージはホームエージェントとモバイルノードの IPsec Security Association で保護される。ESP の完全性保護が必要で、候補リストを隠す必要があれば機密性も利用できる。現在のホームエージェントでない送信者でも、適切な SA を持てばメッセージを送り、通常は自分自身を候補として示す。

この保護は重要である。設定された相手が保護バイトを送ったこと、途中で改変されていないことを確認できる。だが、送信時の負荷判断が妥当だったこと、新側に空きがあること、新しい鍵確立が成功すること、実パケットが通ることは確認できない。

暗号的な真正性と運用上の適切性を同じフラグにしてはならない。送信権限、切替根拠、対象ノード選定、移行先の受入判断は別の責任と証跡を持つ。

旧側の確認は新側の証明にならない

現在のホームエージェントからメッセージを受けたモバイルノードは、その利用を停止し、旧バインディングを削除する Binding Update を送る。RFC 5142 では、この更新が Home Agent Switch の確認応答として機能する。

確認という語が誤解を招きやすい。ここで確認されたのは、旧側の指示が一定段階まで処理され、旧関係を削除する制御メッセージが返ったことである。代替候補の探索、新 SA、新バインディング、転送状態はまだ証明されていない。

現在のホームエージェントではない相手が切替を送った場合、その相手とのホームバインディングを作る Binding Update が確認になる。前者は旧側の削除、後者は新側への作成要求であり、意味は異なる。作成要求は拒否され得るし、Binding Acknowledgement で受理されても、トンネルやパケットは後段に残る。

運用状態は「確認済み」一つではなく、旧バインディング削除、新候補選択、SA 確立、新規要求、受理、トンネル設定、最初のパケット、アプリ継続に分けるべきである。各観測者が見た以上の結果を主張させない。

応答なしは状態ではない

送信者は必要な Binding Update を得るまで再送する。初期値は五秒で、指数バックオフし、二十秒を上限とする。その後も低い頻度で無期限に続けられる。

最大待機を超えても旧バインディングが残っていれば、ホームエージェントはモバイルノードの状態を推測すべきではない。バインディングの寿命が終わるまでサービスを続ける。この規則は、観測不能を勝手な成功や離脱へ変換しないための安全装置である。

沈黙の原因には、往路または復路の損失、ノード停止、探索失敗、SA 確立の遅延、候補の拒否、ローカル判断がある。旧バインディングの期限切れも、新側が動いた証拠にはならない。期限切れは古い状態の終了であって、新しい状態の成立ではない。

探索から実通信までの空白

Mobile IPv6 のブートストラップは、ホームエージェントアドレス、Home Address、認可情報、登録に必要な IPsec SA の取得を含む。RFC 5026 はこれらを分離し、RFC 6610 と RFC 6611 は発見またはプロビジョニングの方法を示す。RFC 4640 はブートストラップ全体の問題を整理する。

切替メッセージはこれらを自動生成しない。新しい相手との IKE/IPsec を成立させ、Binding Update を送り、受理結果を得て、トンネルと経路を作り、パケットを観測する必要がある。さらに利用者やアプリの継続性を主張するなら、その層の観測が要る。

異なるホームプレフィックスを選ぶと Home Address が変わり、既存接続が失われる可能性がある。RFC 5142 はその場合の利用を避け、負荷分散では同じプレフィックスを持つホームエージェントを推奨する。新規登録の成功と既存接続の継続は、同じ成功ではない。

目的側の実測を閉ループにする

有効なフィードバックは、単なる CPU 利用率より広い。IKE 待ち時間、Binding Acknowledgement の拒否、バインディング作成時間、トンネル確立時間、候補切替回数、最初のパケットまでの時間を含めるべきである。旧バインディングの残り寿命と比較し、間に合わなければ新規切替を止める。

新しい経路の遅延、損失、並べ替えも監視対象になる。ホームエージェントが健全でも、異なる経路特性がトランスポートを悪化させることがある。制御面の成功率だけを最適化すると、利用者が受け取る結果を悪化させながらダッシュボードだけが改善する。

出典

  1. RFC 5142 HTML
  2. RFC 5142 テキスト
  3. RFC Editor の記録
  4. IETF Datatracker
  5. 文書履歴
  6. RFC 5142 の Errata 検索
  7. IANA Mobility Parameters
  8. RFC 3775:IPv6 Mobility Support
  9. RFC 6275:IPv6 Mobility Support
  10. RFC 4301:IP Security Architecture
  11. RFC 4303:Encapsulating Security Payload
  12. RFC 4877:IKEv2/IPsec を用いる Mobile IPv6
  13. RFC 5026:Mobile IPv6 ブートストラップ
  14. RFC 6611:統合シナリオのブートストラップ
  15. RFC 6610:ホーム情報発見の DHCP オプション
  16. RFC 4640:Mobile IPv6 ブートストラップ問題
  17. RFC 4192:IPv6 ネットワークのリナンバリング
  18. 最小初期仕様、将来判断の局所化、自発的採用
  19. 現実の層、象徴的権力、明晰さ
  20. Running Code の優位