Cisco Systems Japan Advent Calendar 2025

802.11 を読む前に知っておくと精神が保たれること〜IEEE 802.11 を開いたエンジニアの心境〜

Last updated at 2025-12-19Posted at 2025-12-19

はじめにの前に

この記事は Cisco Systems Japan の有志による Advent Calendar 2025 のシリーズ 1 の
20日目として投稿しています。

はじめに：なぜ802.11を読むことになったのか

Wi-Fiは普段、何も考えずに使っている。
APを置いて、SSIDを作って、認証して、通信できればそれでいい。

しかし、トラブルが起きたときや、
「それって仕様的にどうなってるの？」と聞かれた瞬間、
我々は最終的にある場所へ辿り着く。

―― IEEE 802.11。

ページ数を見て、まず深呼吸する。

約6,000ページ...数百万行...

この記事は、そんな場所に足を踏み入れてしまった人が
少しでも正気を保ったまま帰還するためのメモである。

※ 本記事は、Wi-Fiやネットワークに一度は触れたことがあり、
「仕様書を読んでみようかな」と思った人向けです。

1. 802.11は「全部読まなくていい」

いきなり結論から言う。

802.11は全部読まなくていい。

というか、最初から全部読もうとすると、
だいたい途中で心が折れる。
• 自分が見たいのは認証？Association？
• Management Frame？Action Frame？
• それともPHYの話？

目的が決まっていない状態で読むと、
「これは今の自分に必要な情報なのか？」という疑問だけが増えていく。

まず読むべきなのは本文ではなく Table of Contents, つまり目次。
どの Clause に何が書いてあるかを把握するだけで、
精神的な負荷はかなり下がる。

2. 本文より脚注と Annex と参照が本体

802.11を読み始めて最初に驚くのがこれ。

重要なこと、だいたい脚注か Annex に書いてある。そして参照がとにかく多い。
• NOTE:
• "implementation specific"
• See Annex C

本文だけ読んで「なるほど」と思っていると、
脚注に全否定されていることがある。

例えば RSN IE（RSNE）は、本文だけ読むと「(Re)Association Request には必ず入る」
ように見えるが、実際には dot11RSNAActivated の状態やポリシーに依存する条件付き要件であることが、
後段の記述や NOTE で補足されている。

Annex は「参考情報」扱いだが、
実際には実装者や現場エンジニア向けの現実が詰まっている。
最近は 6GHz 実装理解のため Annex E を読む機会が増えたと思う。Indoor SP なんて実用化される前に deprecate されるってどういうことなんだ。

本文は思想、Annex は現実。
そう割り切ると読みやすくなる。

※ Annex は normative ではないものも多いが、実装や相互接続性を理解する上では
事実上重要な情報源になることが多い、という意味でここでは「本体」と表現している。

3. “shall / should / may” に感情を持たない

802.11を読むと頻繁に出てくる三兄弟。
• shall
• should
• may

意味はだいたいこう。
• shall：原則として*必須（normative requirement）
• should：推奨
• may：任意

※ RFC 2119 の MUST と完全に同一という意味ではなく、IEEE 文脈での必須要件。

ここで重要なのは、感情を持たないこと。

「shall って書いてあるから、どの製品でも動くはず」
という期待は、だいたい裏切られる。

仕様は「こうあるべき」を書いているだけで、
実装は「現実的にどうするか」で決まる。"implementation specific" の魔法がかかってる場合もある。

shall を見て安心しない。
may を見て落胆しない。
それが精神安定のコツ。

4. 仕様通りに実装されていないことは普通にある

もう一つ、最初に知っておくと楽になる事実がある。

仕様通りに実装されていないことは、珍しくない。

理由はいくつもある。
• 既存実装との互換性
• 他ベンダーとの相互接続性
• 過去の仕様との折り合い
• 実装コストと現実的な優先度

ここで言う「実装」は C の付く特定ベンダーを指すものではなく、
複数ベンダー環境で見られる一般論としての話。

その結果、
「仕様上はこうだが、実際にはこう動く」
という世界が生まれる。

これは誰かが悪いという話ではなく、
長年進化してきた規格の宿命みたいなもの。

5. キャプチャが真実とは限らない

Wiresharkで無線キャプチャ (OTA) を開くと、
「見えているものが全て」だと思いたくなる。

でも現実は少し違う。
• デコードされていない IE
• フィルタのかけ間違い
• キャプチャ位置(物理)の違い
• フレームは送られているが見えていないケース
• そもそも違うチャネル取ってた
• そもそも帯域幅間違ってた

「キャプチャに出ていない＝送っていない」
とは限らない。

キャプチャは真実を写すが、
真実のすべてではない。
もちろん、適切な位置・設定で取得されたキャプチャは非常に強力な情報源だが、
それだけで全てを判断すると誤解することがある、という意味。

仕様とキャプチャと実装、
三つを並べて見る視点が必要になる。

6. それでも802.11を読む価値

ここまで読むと、
「じゃあ仕様読む意味あるの？」と思うかもしれない。

ある。かなりある。
• 設計思想が分かる
• 何が「正しくて」、何が「例外」か判断できる
• バグと仕様の切り分けができる
• 議論の共通言語になる

特にトラブルシュートでは、
「仕様的にはこうなっている」という軸があるだけで、
判断がぶれにくくなる。

7. 読むべき章の探し方：802.11 との正しい距離感

IEEE 802.11-2024 は、約 6,000 ページ近い巨大仕様書だ。
ファイルサイズも60MB近いから、開くだけで大変だ。
正直に言って、最初から順番に読むものではない。

精神を保つためには、
「今の自分が、どの Clause を読むべきか」を先に決める
ことが重要になる。

7.1 まず押さえるべき全体構造（Clause レベル）

802.11-2024 は、大きく次のような役割分担になっている。

Clause 1–3
用語・定義・言葉の使い方
→ 解釈に迷ったら Clause 1.4（Word usage） に戻る
特に Clause 3.1 や 3.4 なんかは略語も書いてあるので頻繁に使うことになる。
Clause 4
アーキテクチャと概念整理
→ BSS, ESS の整理をしたいときは Figure 4-3
→ 暗号化や認証に関わる RSNA や Association の思想を知りたい場合は
Clause 4.3.8（Robust security network association）
Clause 5
MAC サービス定義（やや抽象的）
レイヤ1物理層とレイヤ2データリンク層の間にも層があったのか！ってなる。
Clause 6
管理（MLME）と実際の動作
→ 多くの人類がここで初めて MLME という存在に出会う
→ Authentication / Association を理解する本丸（でも大事なことは大体9章参照しろって言われる）
Clause 9 以降
フレームフォーマットや詳細定義
→ 必要になったときだけ参照するが、ここが最頻出章かもしれない。鍵管理とかもここ。

この構造を知らずに読むと、
「今読んでいる章が何のための説明なのか」
分からなくなりがちだ。

7.2 認証・RSN・Association を調べたいとき

多くの人が最初に迷い込むのがこの領域。

概念を知りたいとき

Clause 4.3.8 — Robust security network association (RSNA)
→ RSN / RSNA の考え方と位置づけを把握する

実際の手順を知りたいとき

Clause 6.5.7 — Associate
- 6.5.7.2 MLME-ASSOCIATE.request
- 6.5.7.3 MLME-ASSOCIATE.confirm

Association の流れや条件はここに集約されているが、細かいところは Clause 9.x/12.x を見ろと書かれていることがほとんど。

RSN IE（RSNE）の扱いを確認したいとき

Clause 12.6.3 — RSNA policy selection in an infrastructure BSS

7.3 「この IE は入る？入らない？」を調べたいとき

IE の有無で悩んだら、
本文説明よりも フレーム定義テーブル / Frame Format を見るのが近道。

代表例：

Table 9-66 — Reassociation Request frame body
Table 9-67 — Reassociation Response frame body

ここには、

present if …
otherwise, not present

といった形で 条件が明示されている。

本文を読む前に
Table → Notes → 条件文
の順で確認すると、無駄に悩まなくて済む。

7.4 本文 → NOTE → 条件文の順で読む

802.11-2024 では、役割分担がかなり明確だ。

本文：基本ルール
NOTE：前提条件・例外・ポリシー
条件文（if / when）：実際の適用範囲

例えば RSNE についても、

本文では「shall insert」「shall not associate」
その後で
- when dot11RSNAActivated is true
- a matter of policy

といった条件が積み重なる。

本文だけで結論を出さないことが、
802.11 を読む上での精神安定剤になる。

7.5 おすすめしない読み方

Clause 1 から順番に読む
NOTE や Table を飛ばす
「shall だから必ずそう」と思い込む

この読み方をすると、
仕様書ではなく自分と戦うことになる。

7.6 おすすめの読み方（精神安定版）

調べたいテーマを決める（例：Association + RSN）
Clause 4 で概念を把握
Clause 6, 9, 12 で実動作を確認
Table 9.x で IE の有無や意味、取る値を確認
NOTE と条件文を最後に読む

802.11 は 一度で理解するものではない。
必要になったときに、必要な Clause に戻ればいい。

7.7 余談：全部読む必要は本当にあるのか

たぶん、全部読んだ人はいる。
でも、少なくとも僕はまだ会ったことがない。
僕も「ざっと全体に目を通した」ことしかない。でも Annex の MIB を全部一字一句読んだりしたことはない。

802.11 は、
「全部理解するための本」ではなく、
必要なときに参照するための地図であり、辞書のようなものだ。

今日も必要な章だけを開き、
静かに PDF を閉じる。

おわりに：来年の自分へ

来年の自分へ。

802.11を読むときは、
最初から全部理解しようとしないこと。

必要なところだけ拾い、
分からないところは一旦寝かせること。

そして
「仕様に書いてあるから動くはず」
という期待は、ほどほどに。

クリスマスに802.11を読む人は少ないと思うけど、
もし読んでしまったなら、
この記事が少しでも精神安定剤になれば幸いです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

802.11 を読む前に知っておくと精神が保たれること 〜IEEE 802.11 を開いたエンジニアの心境〜