メッシュWi-Fiの「一瞬の死」を葬る：802.11rがパケットレベルで起こしている魔法
家庭内で移動しながらスマホでビデオ会議をしているとき、ふと音声が途切れる――この「一瞬の死」の正体は、多くの場合、Wi-Fiのローミングにおける再認証プロセスが引き起こすRTTの増大です。
我々インフラ屋にとって、メッシュWi-Fiは単なる「広範囲な電波」ではありません。それは、クライアントが境界を超えた瞬間に発生する、L2/L3の物理的・論理的なハンドオーバーをいかにシームレスに隠蔽するかという「移動体通信の縮図」です。今回は、その核心技術である IEEE 802.11r（Fast BSS Transition: FT）の深淵を覗いてみましょう。
—
なぜ従来のローミングは遅いのか：WPA2/3ハンドシェイクの呪縛
従来のWPA2-PSK環境では、クライアントが新しいAP（Target AP）に接続するたび、4-Way Handshakeがゼロからやり直されます。この間、EAPOL（Extensible Authentication Protocol over LAN）パケットが飛び交い、無線区間でのRTT（Round Trip Time）が嵩みます。
特にセキュリティを重視する環境では、この認証遅延がTCPの輻輳制御アルゴリズムをトリガーし、TCP Slow Startが再発、スループットが劇的に低下する。これが、動画が止まる物理的なメカニズムです。
—
802.11r：PMKキャッシュとプレハンズシェイクの「先読み」技術
802.11r は、この「認証のオーバーヘッド」を排除するために、認証情報の「事前準備」を行います。ここでの主役は PMK-R0 と PMK-R1 という鍵階層です。
- PMK-R0: リソースホルダー（認証サーバーやコントローラー）に保持されるマスターキー。
- PMK-R1: 各AP（アクセスポイント）に配布される、より限定的な鍵。
クライアントが現在のAPから次のAPへ移動する際、802.11r は「プレハンズシェイク」を利用して、Target APとの間で暗号化に必要なキー（PTK）を、現APとの接続が切れる前に生成します。これにより、Target APに到達した瞬間に Reassociation Request を投げるだけで認証が完了し、Authentication フェーズを丸ごとスキップできるのです。
実践：hostapdにおける802.11rの構成例
Linux環境で hostapd を用いてメッシュAPを構築する場合、以下のように設定することでFT（Fast Transition）を有効化できます。
# /etc/hostapd/hostapd.conf
# 802.11rを有効にする
ieee80211r=1
# FTのモードを設定（1: Over-the-Air, 2: Over-the-DS）
# Over-the-DSはAP間バックホール経由で通信するため、低遅延環境では推奨
ft_over_ds=1
# リソースホルダーIDとキー（メッシュ内の全ノードで統一）
mobility_domain=a1b2
r0kh_id=00:11:22:33:44:55
r1kh_id=00:11:22:33:44:55
pmk_r1_push=1—
パケットキャプチャで見る「魔法」の挙動
Wireshark で IEEE 802.11 FT パケットを追跡すると、従来の 4-way handshake が消滅していることが確認できます。代わりに現れるのが FT Reassociation Request です。
ここで注目すべきは、MIC (Message Integrity Code) の生成プロセスです。認証情報が事前キャッシングされているため、無線区間のパケットヘッダーは極限まで圧縮され、認証のステートマシンが大幅に簡略化されています。
もしあなたがネットワークのチューニングを極めるなら、TCP BDP (Bandwidth Delay Product) の算出を忘れないでください。ローミングの瞬間に発生する数ミリ秒のRTTスパイクを考慮し、Linuxカーネルの sysctl でバッファを最適化します。
# TCPバッファの最適化（高遅延・高スループット環境向け）
# 突然のハンドオーバーでTCPスライディングウィンドウが萎縮するのを防ぐ
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"—
セキュリティの「穴」を塞ぐ：脆弱性回避の心得
802.11r は便利ですが、設定を誤ると「認証をバイパスできる」という致命的な脆弱性を生む可能性があります。
1. Mobility Domain IDの厳格化: メッシュ内の全APで同一の Mobility Domain を使用しますが、外部からの不正なローミングリクエストを遮断するため、必ず WPA3-SAE を併用してください。
2. PMKのキャッシュ汚染: r0kh_id や r1kh_id が漏洩すると、不正なAPがクライアントを「なりすまし」で呼び込めるようになります。鍵管理はハードウェアセキュリティモジュール（HSM）や、信頼できるコントローラー内で完結させるのが鉄則です。
結びに：通信の「透明化」を目指して
我々が目指すべきは、Wi-Fiの存在をユーザーに意識させない「通信の透明化」です。802.11r を適切に実装し、パケットの往来を最適化することは、単なる技術的な自己満足ではなく、ユーザーのデジタル体験を一段上のステージへ押し上げるインフラ構築の美学です。
皆さんのメッシュ環境でも、ぜひ tcpdump を片手に、ローミング時のパケットがどのように流れているか確認してみてください。無線という不確定なメディアの上で、いかに論理的な整合性を保ちながらパケットを運び続けるか。その泥臭い探求こそが、エンジニアの醍醐味ではないでしょうか。
コメント