Chapter 03
IPv6 の基礎 — Matter は IPv6 の上にしか存在しない
この章がなぜ必要なのか——「機器が見つからない」の原因の多くはここにある.
Matter は IPv6 必須である。IPv4 は一切使わない。 これは設計上の妥協ではなく、明確な選択である。
そして開発現場で最も多いトラブルの 1 つが 「コミッショニングはできたのに、その後つながらない」—— その原因の大半は IPv6 のアドレス・ルーティング・マルチキャストにある。
この章では、Matter に必要な範囲に絞って IPv6 を整理する。 IPv6 に詳しい人も、マルチキャストと ULA の節だけは目を通してほしい。
この章で使う既出の用語（定義は各リンク先）. Matter（01 章 3 節）、コミッショニング（01 章 3 節）、ネットワーク（01 章 3 節）、ローカル制御（01 章 2 節）、ACL（02 章 4 節）、IPv6（02 章 1 節）、リンク（02 章 1 節）
1. なぜ IPv6 なのか
| 理由 | 内容 |
|---|---|
| アドレスが枯渇しない | 家庭内に数百のセンサーがあっても NAT が要らない |
| NAT がない | 端末どうしが直接通信できる。ローカル制御の前提 |
| リンクローカルが標準 | 設定なしで同一リンク内の通信ができる |
| マルチキャストが標準機能 | mDNS による探索が素直に書ける（IPv4 のブロードキャストと違い階層化されている） |
| 6LoWPAN との親和性 | Thread が IPv6 前提で設計されている |
| アドレス自動設定 (SLAAC) | DHCP サーバなしでアドレスが決まる |
決定的なのは NAT がないことである. IPv4 + NAT の世界では、家庭内の機器どうしが直接通信するのに UPnP や STUN のような回避策が必要だった。 IPv6 ではすべての機器がグローバルに一意なアドレスを持てるので、 「スマホから電球へ直接パケットを送る」が素直に書ける。 Matter のローカル制御は、この性質の上に成り立っている。
2. アドレスの形
2001:0db8:0000:0000:0000:8a2e:0370:7334
└──────────┬──────────┘└──────────┬─────┘
ネットワーク部 インタフェース ID
（通常 64 bit） （通常 64 bit）128 bit を 16 bit ずつ 8 グループに区切り、16 進で書く。省略規則:
| 規則 | 例 |
|---|---|
| 各グループの先頭 0 は省略 | 0db8 → db8 |
連続する 0 グループを :: に（1 回だけ） | 2001:db8:0:0:0:0:0:1 → 2001:db8::1 |
3. アドレスの種類 — ここを取り違えると詰まる
Matter の開発では、同じ機器が複数の IPv6 アドレスを同時に持つのが普通である。 どれを使うべきかを知らないと、通信できない。
| 種類 | プレフィックス | 到達範囲 | Matter での用途 |
|---|---|---|---|
| リンクローカル (LLA) | fe80::/10 | 同一リンク内のみ | 近隣探索、同一リンク内の通信 |
| ユニークローカル (ULA) | fc00::/7（実質 fd00::/8） | サイト内（家庭内） | Matter の主戦場 |
| グローバル (GUA) | 2000::/3 | インターネット全体 | ISP から配られていれば使える |
| マルチキャスト | ff00::/8 | 指定スコープ | mDNS、グループ制御 |
| ループバック | ::1 | 自ノード | — |
リンクローカルアドレス (LLA)
すべての IPv6 インタフェースが必ず持つ。fe80:: + インタフェース ID。
重要な性質: LLA はルータを越えない. だから「Wi-Fi の機器と Thread の機器」のように別リンクにいる相手には LLA では届かない。
また LLA を使うときはスコープ ID（インタフェース指定）が必須である。
ping6 fe80::1は失敗し、ping6 fe80::1%eth0が必要になる。 複数インタフェースがあると、どこへ送るか決まらないからだ。
ユニークローカルアドレス (ULA)
fd + 40 bit のランダムなグローバル ID + 16 bit のサブネット ID + 64 bit のインタフェース ID。
fd11:2233:4455:0001:0011:2233:4455:6677
└┬┘└──────┬─────┘└─┬┘└──────────┬───────┘
fd グローバルID サブネット インタフェースID
（ランダム）家庭内で閉じた、しかしリンクを越えられるアドレス。 Matter が最も頼りにする種類である。
Thread の Mesh-Local プレフィックスは ULA である（
fd<random>/64）。 Thread ネットワークの内部通信に使われる。さらに Border Router は OMR プレフィックス（Off-Mesh-Routable、これも通常 ULA）を Thread ネットワークに配布し、Wi-Fi 側からも到達できるアドレスを機器に持たせる。 「Thread の電球にスマホから届く」のは、この OMR アドレスのおかげである（04 章）。
グローバルユニキャストアドレス (GUA)
ISP から IPv6 プレフィックスが配られていれば、機器はこれも持つ。 Matter の動作に必須ではないが、あれば使われる。
GUA があると外から直接届いてしまうのでは？ 到達可能性とアクセス許可は別である。 Matter の通信は必ず暗号化・認証されている（11 章）ので、 鍵を持たない相手はセッションを張れない。 とはいえ、家庭用ルータは通常デフォルトで外部からの着信を遮断する設定になっている。
4. マルチキャスト — 探索の要
IPv6 にはブロードキャストがなく、マルチキャストで代替する。
ff 0 2 ... :fb
│ │ │
│ │ └─ スコープ（2 = リンクローカル、5 = サイト）
│ └──── フラグ
└──────── マルチキャスト識別Matter に関係する主なアドレス:
| アドレス | 用途 |
|---|---|
ff02::1 | リンク内の全ノード |
ff02::2 | リンク内の全ルータ |
ff02::fb | mDNS（リンクローカルスコープ） |
ff03::fb | mDNS（サイトローカルスコープ、Thread で使う） |
ff02::1:ffXX:XXXX | Solicited-node（近隣探索用） |
mDNS のスコープが実務で最大の落とし穴である.
Wi-Fi 側の機器は
ff02::fb（リンクローカル）で mDNS を出す。 Thread 側の機器はメッシュ全体に届く必要があるのでff03::fb（サイトローカル）を使う。この 2 つは自動では繋がらない。 Thread Border Router が両者を中継することで、初めて 「スマホ（Wi-Fi）が Thread の電球を見つけられる」状態になる。
「Thread の機器がスマホから見えない」というトラブルの多くは、 Border Router の mDNS 中継（あるいは SRP サーバ）が正しく動いていないことに起因する。
マルチキャストが届かない環境
| 環境 | 問題 |
|---|---|
| 企業ネットワーク | マルチキャストが遮断されていることが多い |
| ゲスト用 Wi-Fi | 端末間通信（クライアント分離）が禁止されている |
| メッシュ Wi-Fi | 中継機を跨ぐとマルチキャストが落ちることがある |
| VLAN 分割 | IoT 用 VLAN を分けると mDNS が越えられない |
開発中は必ず、素直なフラットなネットワークで検証すること。 高機能なルータほど、IoT の探索を妨げる機能が有効になっている。
5. 近隣探索 (NDP) とアドレス自動設定
IPv6 では ARP の代わりに NDP（Neighbor Discovery Protocol、ICMPv6 ベース）を使う。
| メッセージ | 役割 |
|---|---|
| Router Solicitation (RS) | 「ルータはいますか」 |
| Router Advertisement (RA) | 「私がルータです。プレフィックスはこれです」 |
| Neighbor Solicitation (NS) | 「このアドレスの人、MAC は？」（ARP 相当） |
| Neighbor Advertisement (NA) | 「私です」 |
SLAAC（ステートレスアドレス自動設定）
- 機器が LLA を自分で作る（インタフェース ID から）
- DAD（重複検出）で NS を送り、誰も応答しなければ確定
- RS を送る → ルータが RA でプレフィックスを教える
- プレフィックス + インタフェース ID で GUA / ULA を生成
DHCP サーバが要らないのが IPv6 の大きな利点である。
DAD の遅延に注意. アドレスが使えるようになるまで、DAD の待ち時間（通常 1 秒程度）がかかる。 起動直後にすぐ通信しようとして失敗する実装バグは実際に存在する。 「アドレスが確定してから通信を開始する」を守ること。
6. MTU とフラグメンテーション
| ネットワーク | 実効ペイロード |
|---|---|
| Ethernet / Wi-Fi | 1500 bytes（IPv6 の最小 MTU は 1280） |
| Thread (802.15.4) | 物理フレーム 127 bytes。ヘッダ圧縮後の実効ペイロードは 数十バイト |
これが Matter の設計を大きく規定している.
フラグメントは高価である。 802.15.4 上で 1 パケットが 5 フラグメントに割れると、 1 つ落ちるだけで全部再送になり、電池も食う。
実装上の含意: 属性を一度に大量に読まない。 ワイルドカード読み出し（09 章）で数百の属性を一気に取ると、 Thread デバイスでは応答が巨大になり、失敗率が跳ね上がる。
7. 開発でよく使う確認コマンド
# インタフェースの IPv6 アドレスを全部見る
ip -6 addr show # Linux
ifconfig | grep inet6 # macOS
# リンクローカルへの ping（スコープ必須）
ping6 fe80::1234:5678:9abc:def0%en0
# 全ノードマルチキャストで生存確認（同一リンクの IPv6 機器が一覧できる）
ping6 -I en0 ff02::1
# 近隣キャッシュ
ip -6 neigh # Linux
ndp -an # macOS
# 経路
ip -6 route # Linux
netstat -rn -f inet6 # macOS
# mDNS で Matter の機器を探す
dns-sd -B _matter._tcp # macOS（運用中の機器）
dns-sd -B _matterc._udp # macOS（コミッショニング待ちの機器）
avahi-browse -r _matter._tcp # Linux
ping6 ff02::1は最初にやるべき確認である. 同一リンクにいる IPv6 対応機器が全部応答する。 ここに目的の機器が出てこなければ、Matter 以前にネットワークの問題である。
8. よくあるトラブルと切り分け
| 症状 | 疑うべきこと |
|---|---|
| 機器が発見できない | mDNS がブロックされている。マルチキャストが通っていない |
| Thread 機器だけ見えない | Border Router の中継。OMR プレフィックスが配られているか |
| コミッショニング後に繋がらない | 運用アドレスが変わった。DNS-SD の再登録（SRP）が失敗している |
| 一部の機器だけ不安定 | Wi-Fi の省電力設定でマルチキャストが取りこぼされている |
| 大きな読み出しだけ失敗 | MTU / フラグメント（Thread で顕著） |
| ルータ再起動後につながらない | プレフィックスが変わり、機器が古いアドレスのまま |
切り分けの順序
1. ping6 ff02::1 で相手が見えるか
↓ 見えない → リンク層・IPv6 の問題（Matter 以前）
2. dns-sd / avahi でサービスが見えるか
↓ 見えない → mDNS・マルチキャスト・SRP の問題
3. アドレスへ直接 ping6 が通るか
↓ 通らない → ルーティング・プレフィックスの問題
4. Matter のログでセッション確立を確認
↓ 失敗 → 証明書・鍵・ACL の問題（[12 章](12_デバイス認証と証明書.md)〜[14 章](14_運用時のセキュリティ.md)）この順序を守ると、原因の特定が劇的に速くなる. 逆に、いきなり Matter のログを読み始めると、 実はネットワークの問題だったというケースで大量の時間を失う。
9. まとめ
- Matter は IPv6 専用。IPv4 は使わない。NAT がないことがローカル制御の前提。
- 機器は LLA・ULA・GUA を同時に持つ。用途が違う。LLA はリンクを越えない。
- Thread では Mesh-Local（内部用）と OMR（外部から到達可能）を区別する。
- mDNS のスコープ（
ff02::fbとff03::fb）の橋渡しは Border Router の仕事。 - 802.15.4 の 127 バイトフレームが、TLV の採用と「一度に読みすぎない」設計を強いている。
- トラブルは必ず 下の層から順に切り分ける。
ping6 ff02::1が最初の一手。