IPv4は「在庫切れ」になった
IPv4アドレスは2011年に枯渇しました。世界のIPアドレスを管理する組織が「もう新しいIPv4アドレスの在庫はありません」と宣言したのです。
43億個あったはずのアドレスが、インターネットの爆発的な普及で使い切られました。そこで登場したのがIPv6。アドレス数は340澗（3.4×10³⁸）— 地球上のすべての砂粒に1つずつIPアドレスを振っても、まだ数百万倍余る数です。宇宙が終わるまでに使い切る方が難しいでしょう。
| 項目 | IPv4 | IPv6 |
|---|---|---|
| アドレス長 | 32ビット | 128ビット |
| アドレス数 | 約43億 | 約340澗 |
| 表記例 | 192.168.1.1 |
2001:0db8::1 |
| NAT | 必須 | 不要 |
| セキュリティ | IPsecオプション | IPsec標準搭載 |
| 自動設定 | DHCP（サーバーが配布） | SLAAC（ルータ広告で端末が自動取得） |
| ヘッダ | 可変長（毎回サイズ判定が必要） | 固定40byte（処理が速い） |
「じゃあIPv6に移行すればいいじゃないか」
話はそう簡単ではありません。
移行が15年経っても終わらない現実
IPv4が枯渇してから15年。2025年時点のIPv6普及率は 約43% です。フランス80%、ドイツ75%と進んでいる国がある一方、グローバルではまだ半分にも達していません。日本は約50%で、NTTのフレッツ光を中心に対応が進んでいます。
なぜ移行が進まないのか。理由は大きく3つあります。
理由1: NATで「なんとかなっている」
NAT（Network Address Translation）は、1つのグローバルIPアドレスを複数の端末で共有する仕組みです。家庭のルータはほぼすべてこの方式で動いています。
IPv4が枯渇しても、NATがあれば見かけ上は困りません。「困ってないのに、なぜ変える必要があるの？」というのが、多くの現場の本音です。
しかしNATは問題を 隠しているだけ です。
- P2P通信が困難: NATの内側同士は直接通信できない。WebRTCでビデオ通話する場合、NATを越えるための仕組み（STUN/TURN）が必要で、これが 接続失敗や遅延の原因 になる
- ポート枯渇: NATは1つのIPに対してポート番号（最大65,535）で端末を識別する。大規模ネットワークではポートが足りなくなる
- IoT時代の限界: 照明、エアコン、カメラ、スピーカー。1家庭のデバイス数が増え続ける中、NATの多段化は管理コストを増大させる
理由2: 移行方法が3つもあって、どれを選ぶか迷う
IPv6への移行は一夜にして完了するものではありません。主に3つの方式があり、それぞれ一長一短です。
① デュアルスタック（主流）
IPv4とIPv6を同時に動かします。
端末 → [IPv4 + IPv6] → ルータ → [IPv4 + IPv6] → インターネット
最も柔軟ですが、 2つのプロトコルを同時に管理する 必要があり、運用コストが単純に2倍になります。ファイアウォールもルーティングもDNSも、全部2系統。
ブラウザ側では「Happy Eyeballs」という仕組みがあり、IPv6で接続を試みて、ダメならIPv4に自動切替します。ユーザーは意識しなくて済みますが、 裏側の管理者は2倍大変 です。
② トンネリング
IPv4ネットワークの中にIPv6パケットを包んで通す方式です。
[IPv6パケット] → [IPv4ヘッダでラップ] → IPv4網 → [アンラップ] → [IPv6パケット]
既存インフラを活かせますが、カプセル化のオーバーヘッドが発生します。
③ トランスレーション（NAT64/DNS64/464XLAT）
IPv4とIPv6を途中で相互変換する方式です。モバイルネットワークでは464XLATが広く使われています。Ciscoはデュアルスタック完了後にNAT64/DNS64で段階的にIPv4を退役させるフローを推奨しています。
どの方式も 「完璧な移行方法」ではない というのが実情です。
理由3: セキュリティが2倍大変になる
ここが最も深刻な問題です。
攻撃面が2倍になる
デュアルスタック環境では、IPv4 と IPv6の両方にファイアウォールルールが必要です。IPv4だけ設定して、IPv6が フルオープンのまま放置 されているケースが実際に報告されています。
NATという「壁」がなくなる
IPv4ではNATが偶発的なファイアウォールとして機能していました。外部からNAT内部の端末に直接アクセスすることは基本的にできません。
IPv6ではすべての端末がグローバルIPアドレスを持ちます。つまり インターネットから直接見える 状態です。ファイアウォールを明示的に設定しなければ、端末が丸裸でインターネットに晒されます。
IPv6固有の攻撃も存在する
米国のNSAとCISAは共同で「IPv6 Security Guidance」を発行し、以下を警告しています。
- IPv6のセキュリティ設定をIPv4と同等以上にすること
- 不要なセグメントではIPv6を明示的に無効化すること
- Router Advertisement攻撃やNDP Spoofingなど、 IPv6にしか存在しない攻撃 への防御策を実装すること
「IPv6にすれば安全」ではなく、 「IPv6にすると守るべき面が増える」 が正確な表現です。
それでもIPv6に移行すべき理由
ここまで読むと「IPv6って面倒なだけでは？」と思うかもしれません。しかし、IPv4のNAT延命にも限界があります。
WebRTCの実務から見た現実
WebRTCでリアルタイム通信を開発していると、ICE候補にIPv6アドレスが含まれるケースが増えてきています。IPv6ではNATがないため、端末同士が直接接続できます。NATトラバーサルの失敗がなくなる分、 WebRTCの接続信頼性はIPv6環境の方が高い のです。
NATで延命を続けることは、P2P通信の品質を犠牲にし続けることでもあります。
日本のIPv6事情 — 意外と進んでいる
日本のIPv6環境は、世界的に見ても進んでいる方です。
NTTのフレッツ光では、IPv6 IPoE（ネイティブ方式）が利用できます。従来のPPPoE方式では、プロバイダとの接続ポイント（網終端装置）がボトルネックになり、夜間など混雑する時間帯に速度が落ちるという問題がありました。IPoEではこのボトルネックを迂回するため、混雑の影響を受けにくくなります。 「IPv6にしたら夜でも速い」という体験の正体がこれです。
- v6プラス: JPNE提供。IPv6 IPoE + IPv4 over IPv6（MAP-E）
- transix: インターネットマルチフィード提供。DS-Lite方式
- OCNバーチャルコネクト: NTTコミュニケーションズ提供
ユーザーにとっては「速くなった」という体感がIPv6移行の最大のモチベーションになっています。一方、サーバー側の対応はまだこれからです。Cloudflareを使っていれば自動でIPv6対応になりますが、自前運用のサーバーでは対応が漏れているケースも多いです。
エンジニアとして今やるべきこと
1. 自分のサービスのIPv6対応を確認する
# IPv6でアクセスできるか確認 curl -6 https://your-domain.com # AAAAレコードが設定されているか確認 dig AAAA your-domain.com
2. セキュリティ設定の棚卸し
IPv6を有効にしているなら、ファイアウォールルールがIPv6にも適用されているか確認してください。 ip6tables の設定を見落としているケースは珍しくありません。
# IPv6のファイアウォールルールを確認 sudo ip6tables -L -n
3. WebRTC開発者は特に注意
ICE候補にIPv6アドレスが含まれるケースが増えています。IPv6環境でのテストを行っていない場合、特定のネットワークで接続に失敗する可能性があります。
// ICE候補のログでIPv6アドレスを確認 peerConnection.onicecandidate = (event) => { if (event.candidate) { console.log('ICE candidate:', event.candidate.candidate); // IPv6アドレスが含まれているか確認 } };
まとめ
- IPv4は2011年に枯渇した。NATで延命しているだけ
- IPv6の普及率は43%。15年経っても移行は半分
- 移行が進まない理由は3つ。NATで困ってない・移行方法が複雑・セキュリティが2倍大変
- 「IPv6にすれば安全」は誤解。守るべき面が増える。NATという壁がなくなり端末が丸見えになる
- それでも移行は必要。NATの限界、P2P通信の品質、IoT時代のアドレス需要
- 日本はIPoEで進んでいる。でもサーバー側対応はまだこれから
IPv6への移行は「いつかやる」ではなく、「もうやっているか、知らないうちに使っている」フェーズに入っています。自分のサービスがどちら側にいるか、一度確認してみてください。
