要約

  • L2-LinkStatusChanged.indication は閾値を越えた出来事を知らせるが、RFC 5184の例では状態がすぐ回復しても通知は取り消されない。再確認と取消経路が必要である。
  • L2-LinkConnect.confirm(Ack) は処理開始点であり、後続のLinkUp、L3処理、パケット継続性とは別の証拠である。

品質がBADへ落ち、通知が届いた。数百ミリ秒後にはGOODへ戻っていたが、最初の通知は取り消されなかった。コントローラーは候補探索、接続要求、旧リンク切断を順に進め、元のアクセスポイントへ戻る切替を直後に始めた。

これは規格違反ではない。RFC 5184は、LinkStatusChangedを受けたIP層がLinkStatusを読み直し、現在のAPが最適ならハンドオーバーを取り消せると説明する。通知と判断を分ける設計である。

通知は出来事、判断はローカルな権限

この実験的RFCは、Request、Confirm、Indication、Responseの四クラスを定義する。タイプ1は現在情報を照会する。タイプ2はイベント登録後に非同期通知する。タイプ3はリンク接続・切断を要求する。

PoAFoundやLinkStatusChangedはタイプ2である。登録のAckは購読成立を示し、後のIndicationはイベント発生を示す。どちらも「移動せよ」という命令ではない。

RFC 4907も、リンク通知を行動を強制するtriggerではなく、検証可能なhintとして扱うよう勧める。判断権限をIP側に残すことで、リンク技術ごとの観測を利用しつつ誤通知から回復できる。

Ackから完了までは別の状態機械

タイプ3のConfirmは直ちにAckまたはNackを返す。L2-LinkConnectはAck後に開始する。L2ハンドオーバー完了後にLinkUpが通知され、その後L3が自分の処理を行う。

したがって、接続Ackを完了に変換してはいけない。Ack後に認証が失敗する、LinkUpが来ない、IPアドレスが使えない、新ルーターが端末を検出できない、データが片方向だけ届く可能性が残る。

RFC 5568は、Mobile IPv6高速ハンドオーバーがIP手順の遅延を減らしてもリンク切替遅延そのものを改善しないと区別する。トンネルを作っただけでも新リンクで即座に受信できるとは限らない。

LinkUpも技術別の境界にとどまる

RFC 5184のIEEE 802.11例では、APとのassociation確立がLinkUpである。RFC 4907は、LinkUpから対称性や低損失を仮定しないよう警告する。RFC 4957は、Ethernetの物理状態が良好でもbridge domainが転送可能とは限らず、spanning tree完了の通知がない場合を示す。

共通語彙は有用だが、発火条件を保存しなければ比較不能になる。インターフェース種別、ドライバー、認証境界、ブリッジ状態、通知時刻を記録して初めて意味が固定される。

五段階の品質は測定値そのものではない

Conditionは帯域と品質をEXCELLENT、GOOD、FAIR、BAD、NONEへ抽象化する。アルゴリズムは実装依存で、装置間のレベルは独立している。規格自身が、この指標による判断は誤りやすく最適選択を保証しないと述べる。

運用記録にはRSSI、再送、窓幅、平均、閾値、ヒステリシス、buildを残すべきである。抽象値だけでは、通知が現実の変化かアルゴリズム変更か判断できない。

ピンポンは例外ではなく制御系の証拠

RFCの実験ではAP間のping-pongが観測された。閾値は配備環境に依存し、設定不良は誤通知を生む。LinkStatusChangedの抽象化が信頼できない場合、冗長ハンドオーバーになる。

対策は感度をゼロにすることではない。早い通知で準備を開始し、再照会、damping、minimum dwell time、rate limit、取消可能な予約を組み合わせる。旧リンクの破棄は後のcommit pointまで待つ。

攻撃者は正しい形式のイベントを作れる

偽beaconは悪意あるPoAを検出させ、PoAFoundからLinkConnectへ進ませ得る。強弱RSSIを交互に見せればPoAFoundとPoALostを連続させ、サービスを消耗させられる。

イベント形式が正しいことと観測対象が信頼できることは別である。候補の由来、リンク認証、ローカル方針、damping、到達性を結び付けて初めて行動権限が生まれる。

一つの実験結果を一般化しない

RFC 5184の評価は、十ミリ秒間隔のICMPで失われた応答がゼロまたは一つだったと報告する。これは特定testbedの結果であり、全無線、全認証方式、全負荷のSLAではない。

監視は通知から判断、判断からAck、AckからLinkUp、LinkUpからIP ready、そこから最初の双方向サービス成功までを別々に測る。取消・rollbackも同じoperation IDへ結ぶ。

Heng Luの現実層で考えれば、通知名は記号層、実行中のradioとIP stackは実装層、パケット到達は結果層にある。小さな共通仕様を保ちながら、権限はローカルな証拠で進める。取り消されない通知は、取り消せない決定を意味しない。

情報源

  1. RFC 5184 HTML
  2. RFC 5184 テキスト
  3. RFC Editor情報ページ
  4. IETF Datatracker文書ページ
  5. IETF Datatracker履歴
  6. IETF Datatracker参照
  7. RFC 5184正誤表
  8. RFC 4907 リンク通知のアーキテクチャ上の意味
  9. RFC 4907情報ページ
  10. RFC 4957 リンク層イベント通知
  11. RFC 5568 Mobile IPv6高速ハンドオーバー
  12. RFC 5568情報ページ
  13. RFC 5944 IPv4モビリティ
  14. RFC 6275 IPv6モビリティ
  15. RFC 4140 階層型Mobile IPv6
  16. RFC 3819 サブネット設計者への助言
  17. RFC 4968 IPv6リンクモデル分析
  18. Heng Lu：現実の層
  19. Heng Lu：最小仕様と自発的採用
  20. Heng Lu：稼働コードの優先