TCP/IPへの疑問 その3
1. IPv4 アドレス枯渇と現在の割当事情
Q. IPv4 はもう新規に発行されない？どうやって運用している？
A. RIR（APNIC など）の在庫は既に枯渇し、通常の "/24 を新規でもらう" という手続きは終了しました。現在は 再利用・売買マーケット や NAT でしのぎつつ、根本解決として IPv6 へ移行しています。
-
再割当の実例：Cloudflare は 2024 年に中古 IPv4 ブロック
/17を約 1000 万 USD で購入（公式ブログより）。 - NAT の多段化：家庭 ⇒ ISP ⇒ IX の 3 段目 NAT で CGNAT が一般化。
- 対策の潮流：大規模サービスは "デュアルスタック (IPv4+IPv6)" を標準構成に。
2. 経路 MTU 探索 (PMTUD) と断片化
Q. DF フラグを付けて送ると何が起きる？
A. DF=1 で送ったパケットが途中リンクの MTU を超えると、ルータは ICMP Type3/Code4 (Fragmentation Needed) を返して破棄します。送信元は ICMP の Next‑Hop MTU フィールドを読んで 再送時にセグメントを小さく し、最終的に "経路上で最小の MTU" を学習します。
| ステップ | 送信元 | ルータ | 宛先 |
|---|---|---|---|
| ① 初回送信 | DF=1, 1500B | -- | -- |
| ② MTU超過 | ICMP 3/4 返送 (ex. MTU=1400) | -- | |
| ③ 調整再送 | DF=1, 1400B | 転送 | 受信 |
IPv6 ではルータ断片化が禁止 ⇒ 送信元が必ずフラグメント処理 or PLPMTUD を行う。
ブラックホール対策：ICMP がフィルタされる企業網では、アプリ側で 1280B など小さめ MSS を設定する。
3. IPv4 と IPv6 ― ヘッダ・性能・セキュリティの違い
| 観点 | IPv4 | IPv6 | 実務的 Tip |
|---|---|---|---|
| ヘッダ長 | 20〜60B 可変 | 40B 固定 | ルータの ASIC が扱いやすい → スループット向上例あり |
| チェックサム | あり | なし | L4(TCP/UDP) の CRC で十分との設計判断 |
| NAT | 当たり前 | 原則不要 | "隠れる安心感" → FW できっちり閉める文化へ転換 |
| 最小 MTU | 68B | 1280B | 小さすぎるパケットは IPv6 ではそもそも送らない |
| 接続確立 | 3‑way HS | 同じ | Happy Eyeballs で "IPv6→IPv4" 同時試行 ⇒ 最速パス選択 |
速度は IPv6 が必ず速いわけではない。例として、同一 ISP でも "IPv6 経路が遠回り経由で逆に遅い" ケースがある。speedtest --source <IPv4/6> で自宅実測して比較しよう。
4. IPv6 の割当階層と国内キャリア状況
-
IANA → APNIC → ISP → エンドユーザ (/64 or /56) の流れ。
-
国内 4 大キャリアは光回線もモバイルも IPv6 に概ね対応 だが、
- ドコモ光: プロバイダ側で IPoE 申し込み必須。
- ソフトバンク光: 光BBユニット必須。
- MVNO では未対応例（日本通信 SIM など）あり。
確認コマンド
curl https://api64.ipify.org # 自分のIPv6 dig AAAA example.com @8.8.8.8 # サイトがIPv6持つか
5. IP アドレスと位置情報・プライバシ
Q. IPv6 で端末がグローバル IP を持つと個人特定される？
A. 一般公開 DB から得られる位置は市区町村レベル。契約者情報は ISP の内部データなので 裁判所の開示請求 が無い限り判明しない。ただし長期に同じアドレスを使えばサイト横断追跡は容易になる → OS の Temporary Address (RFC4941) がデフォルトでオン。
6. クライアント×サーバ 9 通りの接続パターン
| C\S | IPv4 Only | IPv6 Only | Dual |
|---|---|---|---|
| IPv4 Only | IPv4 OK | ✗失敗 | IPv4 OK |
| IPv6 Only | ✗失敗 | IPv6 OK | IPv6 OK |
| Dual | IPv4 OK | IPv6 OK | 通常 IPv6 (優先) |
NAT64/DNS64 が入る特殊網では "IPv6 Only クライアント ↔ IPv4 Only サーバ" も通信可能。
7. DNS・Happy Eyeballs ― どちらの IP で繋ぐ？
- DNS は A と AAAA を両方返すだけ。選択は OS が実装する アドレス選択ポリシ (RFC6724) と Happy Eyeballs (RFC8305)。
- ブラウザは AAAA→数 ms→A の順にソケットを開き 速い方のみ維持。したがって "両方で 2 倍データ転送" にはならない。
8. ネットワーク診断ツール活用例
| ツール | 目的 | 例コマンド／フィルタ | ||
|---|---|---|---|---|
| Wireshark | MTU/フラグメント確認 | `ip.flags.mf==1 | ip.frag_offset>0` | |
| DF ビット確認 | 展開 → IP → Flags → DF=1 | |||
| ping | 手動 PMTU テスト | ping -c4 -s1472 -M do example.com |
||
| dig/nslookup | DNS A/AAAA | dig +short A google.com |
||
| DevTools(Network) | HTTP サイズ/Timing | 大遅延→背後で PMTU? を推測 |
9. クラスフル (A‑D) と CIDR
-
クラスA
/8(0xxxxxxx) 〜 クラスC/24(110xxxxx) は歴史的区分。 - 192.168.0.0/16 や 10.0.0.0/8 は "私用アドレス" (RFC1918) で、クラス概念とは切り離して運用。
-
先頭ビット
10⇒ クラスB であっても、172.16.0.0/12はその一部を私用に再定義しただけ。混同注意。
10. IP マルチキャストとは？
一言でいうと: 送信者が 1 回だけパケットを投げる だけで、参加を表明した複数の受信者 が同時にデータを受け取れる仕組みです。ユニキャスト(1対1)でもブロードキャスト(1対全員)でもなく、“1対多 (必要な人だけ)” の効率的な通信方式。
10‑1 なぜ必要？
| 方式 | 帯域消費 | サーバ負荷 | 具体例 |
|---|---|---|---|
| ユニキャスト | 受信者数 × 同じデータ | 受信者数分ソケットが必要 | Webページ閲覧 |
| ブロードキャスト | 1 回 (L2 全員が処理) | 小 | ARP, DHCP DISCOVER |
| マルチキャスト | 1 回 (必要な端末のみに配布) | 小 | IPTV, 株価ティッカー, 社内ライブ中継 |
10‑2 アドレスとグループ
-
IPv4 :
224.0.0.0 – 239.255.255.255(クラス D) → 2²⁸ ≒ 2.68 億 グループ -
IPv6 :
ff00::/8→ 送信範囲 (スコープ) を 4 bit で指定 - 代表例
224.0.0.1= LAN 内の全ホスト,239.0.0.0/8= 組織内プライベート,ff02::1= IPv6 全ノード
10‑3 参加 (所属) と脱退の手順
| フェーズ | プロトコル | どんなパケット？ | 説明 |
|---|---|---|---|
| 参加宣言 | IGMP Membership Report (IPv4) / MLD Report (IPv6) | 端末 → ルータ | "このグループに入りたい" を通知 |
| 定期照会 | IGMP/MLD Query | ルータ → 端末 | まだ参加してる？ と確認 |
| 離脱 | IGMP Leave Group / MLD Done | 端末 → ルータ | アプリ終了などでグループを抜ける |
ポイント: 仕組みは OS が自動処理。ユーザは URL
udp://@239.1.1.1:5000を再生するだけで、裏で IGMP が飛ぶ。
10‑4 1 グループに参加できる台数は？
- プロトコル上の上限 なし。コピー処理はネットワーク機器が行うため、送信者の負荷は変わりません。
- 実質上限は スイッチ/ルータのテーブル容量 と 物理帯域。企業 LAN なら数千台でも運用例あり。
10‑5 設計・運用 Tips
- IGMP スヌーピング を有効にすると、無関係ポートにフラッディングされない。
- WAN 越しに配信したいときは Source‑Specific Multicast (SSM, 232.0.0.0/8) が推奨。
- Wi‑Fi では再送が無い UDP マルチキャストが弱い → QoS/信頼性に注意。
11. 用語早見表
| 用語 | 意味 | 一言メモ |
|---|---|---|
| DF/MF | 断片化禁止/続片フラグ | DF=1 で PMTUD 使用 |
| Happy Eyeballs | IPv4/6 並列接続 | RFC8305: レイテンシ改善 |
| Temporary Addr | IPv6 一時アドレス | RFC4941: プライバシ確保 |
| CGNAT | Carrier‑Grade NAT | ISP での大規模 NAT |
| NAT64 | IPv6↔IPv4 変換 | DNS64 で AAAA 合成 |
12. Happy Eyeballs は "いつ" 行われるのか？
Q. DNS を引いてから 3WAY ハンドシェイクのどの段階で動く？
A. Happy Eyeballs は DNS で A / AAAA がそろった直後に発動し、TCP 3WAY ハンドシェイクより“前”に並列で SYN を送る仕組み です。
- ブラウザが DNS へ問い合わせ → A と AAAA を同時取得
- OS/ブラウザがまず IPv6 に SYN を送信
- 200〜300 ms 待機後、まだ応答がなければ IPv4 にも SYN
- 先に SYN‑ACK が返ったほうで 3WAY を完了、もう片方は RST／タイムアウトで破棄
🔧 ポイント：Happy Eyeballs は "どちらで 3WAY を完了するか" を“試走”して決める予選レース。UDP のようにハンドシェイクが無いプロトコルでは同様の処理は自前実装が必要。
13. マルチキャストとブロードキャストの違い
| 観点 | ブロードキャスト | マルチキャスト |
|---|---|---|
| 通信範囲 | 同一 L2 セグメント内 全端末 | グループ参加端末のみ |
| 代表アドレス (IPv4) |
255.255.255.255 / 192.168.1.255 など |
239.1.1.1 など (224.0.0.0/4) |
| 代表アドレス (IPv6) | なし（IPv6 では廃止） |
ff02::1（全ノード）ほか ff00::/8
|
| 転送の仕組み | ルータを越えない（L2限定） | IGMP (IPv4) / MLD (IPv6) で参加を管理し、ルータが中継 |
| 主な用途 | ARP, DHCP Discover 等の 初期ブロードキャスト | IPTV, 株価速報, 大学講義配信など帯域節約型同報 |
| 長所 | 実装が単純 | 送信一回で多端末へ → 帯域・サーバ負荷節約 |
| 短所 | トラフィック増大・ストームリスク | ルータ/NAT対応が必要、インターネット越えは困難 |
💡 IPv6 ではブロードキャストが廃止され、全ノード/全ルータ宛ての通信もすべてマルチキャストに集約されました。これにより不要なトラフィックが削減され、L2 の負荷を抑えています。