要約

  • HMIPv6はRCoAを地域内で安定させ、現在のLCoAへの転送責任をMAPに置いた。
  • MAPドメインを越える移動では、旧MAPの一時転送と新MAPのbindingが並存するため、退役にはタイマーではなく新経路の実測が必要になる。

一つの時刻では表せない切替

移動ノードが新しいMAPドメインへ入る。新しいRegional Care-of Addressを得て、現在のon-link Care-of Addressとのbindingを作る。MAPはBinding Acknowledgementを返す。運用画面はここを「完了」と記録しやすい。

しかし旧MAPへ向かっていたパケットは消えない。RFC 5380は、ノードが旧MAPに新しい位置を通知し、飛行中のパケットを転送させる手順を認めている。管理者はドメイン外転送を制限できる一方、条件を満たす隣接ドメインへの転送は推奨される。

つまり、切替後しばらくは旧MAPと新MAPが異なる意味で正しい。旧MAPは過去の宛先に到着したパケットを救い、新MAPは現在のRCoAとLCoAを実現する。home agentやcorrespondent nodeのbindingも別の時刻に更新される。

「完了時刻」を一つだけ保存すると、この責任分担が消える。

安定したRCoAは移動をなくさない

同じMAPドメイン内では、ノードはLCoAだけを更新し、RCoAを保つ。遠隔の相手はローカル移動を知らなくてよい。信号量が減り、時間に敏感な処理を近いアンカーで終えられる。

この透明性は、MAPのbinding cacheが正しいことを前提にしている。RCoA宛てのパケットをMAPが捕捉し、現在のLCoAへカプセル化して送り、ノードが受信して復号ではなくデカプセル化し、上位層へ渡す。外から見える住所が同じでも、実現する経路は更新されている。

したがってRCoAの不変性は結果ではなくインターフェースである。実際の連続性は、現在のMAP、LCoA、binding lifetime、トンネルと端点処理によって毎回作り直される。

確認応答の意味を広げない

ローカルBinding Updateが受理されると、MAPはbindingを保存し、正しいBinding Acknowledgementを返す。ノードはその応答を待ってからRCoAをhome agentや相手へ登録すべきであり、外側のbinding lifetimeはMAP側の寿命を超えてはならない。

この順序は重要だが、確認応答はデータ配送の署名ではない。MAPがRCoAを正しく捕捉できるか、LCoAへの経路が生きているか、セキュリティ関連が使用可能か、パケットがトンネル後のMTUに収まるか、アプリケーションが処理したかは別の観測を要する。

運用記録では、要求送信、受理、cache保持、最初の転送、最初の受信、最初の有用なトランザクションを分けるべきである。早い段階の成功を後段の名前で呼ぶと、障害時に同じ制御操作だけを繰り返すことになる。

旧MAPの退役条件

旧MAPを長く残せば安全とは限らない。古い転送状態は余分な依存関係となり、誤った宛先や不要なトンネルを維持し得る。早く消せば飛行中のパケットを失う。

退役には少なくとも三種類の証拠が必要だ。新MAPがbindingを受理したという制御証拠、新経路で双方向パケットが観測されたという転送証拠、そして代表的なアプリケーション処理が継続したというサービス証拠である。さらに旧MAPの受信カウンタが排出されたことを確認できれば、時間だけに頼らず終了できる。

規格は特定の運用製品や障害を主張していない。ここでの判断は、規格が明示する複数状態から導かれる運用上の境界である。

広告の選好は現在の健康状態ではない

MAP optionにはグローバルアドレス、prefix、distance、operator preference、valid lifetimeが含まれる。ノードは保存した候補からMAPを選ぶ。Preferenceは方針、distanceは選択材料であり、必ずしも実データ経路の測定値ではない。

Valid lifetimeがゼロなら、そのMAPを選んではならず、既存bindingは失われたとみなし、代替を探す。代替がなければHMIPv6を使わない。これは明確な撤回である。

一方、ゼロでないことは容量、損失、cache鮮度、トンネル到達性を証明しない。「撤回されていない」を「正常」と表示する監視は、広告契約と実測を混同している。

MTUは移行の外側にいない

ノードとMAPの間では入出力ともにトンネルを使う。さらにhome agentを経由すれば二重カプセル化が起こり得る。RFC 5380は、上位層に提供できるMTUを計算する際にこのオーバーヘッドを考慮するよう求める。

小さなBinding Updateと応答が通っても、大きな業務パケットが通るとは限らない。制御面が正しく、bindingが新しく、住所が安定していても、MTUやPacket Too Bigの経路で配送が止まる可能性がある。これは特定障害の断定ではなく、検証項目を示す規格上の事実である。

切替試験は小さなpingだけでなく、実際のカプセル化後サイズを代表するパケットを含む必要がある。

認証された状態にも範囲がある

ノードとMAPの関係には相互認証、完全性、replay保護が必要である。MAPは有効なon-link prefixの一覧を持ち、外部のLCoAを管理上拒否できる。これは誰がどの位置を登録できるかを制御する。

しかし認証はトンネルの配送を証明しない。許可されたprefixは無線リンクの状態を証明しない。保護された更新はアプリケーション継続を証明しない。強いセキュリティは狭い主張を強くするのであり、主張の範囲を広げるものではない。

複数アンカーと現在地の真実

RFC 7429は、HMIPv6が遠い中央アンカーへの信号を減らす一方、anchor discovery、selection、relocation、context transferに課題を残すと整理した。RFC 5380自身も複数MAPや複数RCoAを認めるが、一つのMAP由来RCoAを別MAPのcare-of addressとして登録する多段階を禁じる。不要な多重カプセル化を避けるためである。

アンカーが複数あるほど、セッションごとに「どのアドレスをどのアンカーが現在実現しているか」を保持する必要がある。候補一覧は現在状態の台帳ではない。

Heng LuのRunning-Code Primacyを当てはめれば、文書上のbinding可能性と、現在のパケットが実際に通った事実を分けることになる。旧MAPは、役割を終えたという証拠が得られるまで一時的な本番基盤である。

問題は新住所を得たかではない。旧アンカーをいつ、どの証拠で退役させるのかである。

情報源