「IPv4 の次は IPv6、その次は IPv8 か」という話を耳にすることがある。ただ、IPv8 という正式な規格は存在しない。IPv4 のバージョンフィールドは 4bit で、0〜15 まで使える。IPv5 は 1979 年に Internet Stream Protocol（ST）が使用済みで、IPv6 は意図的に IPv4 との非互換を選んだ設計になっている。IPv7 以降も断片的な提案はあるが、IETF で標準化されたものはない。
では「次世代プロトコル」として実際に研究・標準化が進んでいるのは何か。IPv4 が抱えた課題をどう解決しようとしているのか。この記事ではその実態を整理したい。
IPv4 は今も現役だが、課題は積み上がっている
まず現状を確認しておく。IANA の未割り当て IPv4 は 2011 年に枯渇した。ただ現場では、NAT、CGNAT、CDN、プロキシ、アドレス移転市場のおかげでまだ十分に機能している。
主要国の IPv6 普及率を見ると、国ごとに大きな差がある。
フランスやインドは 70〜90% に達している一方で、日本や韓国は 50% を下回る水準だ。IPv6 の普及が遅い理由は規格の問題ではなく、「NAT で当面しのげる」から移行の優先度が上がらないことにある。
一方で、固定回線速度を見ると国によってかなりの差がある。
速度の主因は回線インフラの投資差だが、余計な NAT やプロキシの層が遅延を積み上げていることも無視できない。IPv4 の延命策が増えるほど、経路のシンプルさは失われていく。
IPv6 が「クリーンブレーク」を選んだ理由と、その代償
IPv6 は IPv4 との後方互換を捨てた。これは意図的な判断だ。アドレス長を 32bit から 128bit へ拡張するだけでなく、ヘッダ構造を見直し、NAT を前提としないエンドツーエンド設計に戻すことを目指した。
ただ、この「クリーンブレーク」が移行の摩擦を生んだ。IPv4 と IPv6 を並行運用する dual stack 期間が長引き、監視、FW、ログ解析、許可リストを二重管理する必要が出た。コストが増えるわりに、エンドユーザーへの目に見えるメリットが薄く、「今やる理由が弱い」で止まりやすい。
この反省から、「IPv4 との互換性を保ちながら拡張できないのか」という発想が生まれた。それが SRv6 や各種トランジション技術につながっている。
SRv6：IPv6 を拡張し、IPv4 もカプセル化する
SRv6（Segment Routing over IPv6）は、IPv6 の拡張ヘッダを使ってパケットの経路を明示的に指定する仕組みだ。RFC 8986 として標準化されている。
ポイントは、IPv4 パケットを SRv6 の中にカプセル化して転送できること。つまり、IPv4 のトラフィックを IPv6 の経路制御の上で動かせる。IPv4 の「上位互換」に近い発想を、IPv6 の拡張として実現しようとしている。
SRv6 が解決しようとしている課題はいくつかある。
- MPLS ラベルなしで経路制御できる（ラベルスタックの複雑さを減らせる）
- 経路ごとにトラフィックエンジニアリングを細かく設定できる
- クラウドとキャリア網の境界を越えた経路制御が統一的にできる
- IPv4 と IPv6 の混在環境を一つの転送プレーンで扱える
NTT、中国電信、Alibaba などが商用導入を進めており、特に大規模データセンター間の接続や 5G コアネットワークでの採用が増えている。
SCION：経路そのものを再設計する
SRv6 が IPv6 の拡張であるのに対し、SCION（Scalability, Control, and Isolation On Next-generation networks）はより根本的な再設計を目指している。スイス連邦工科大学（ETH Zürich）が主導する研究で、IEEE Security & Privacy 2011 で発表された。
SCION の核心は「経路の選択権を送信側に渡す」ことだ。現在のインターネットは BGP（Border Gateway Protocol）によって経路が決まり、送信側はどの経路を通るか制御できない。SCION ではパケットを送る側が経路を明示的に指定できる。
これにより次のことが実現する。
- ISP や国家の恣意的な経路変更を防げる（経路ハイジャック対策）
- 遅延・帯域・信頼性に基づいて送信者が経路を選べる
- 障害が一部の AS（自律システム）に局所化されやすくなる
- 認証がアーキテクチャに組み込まれているため、なりすましが難しい
スイスの政府・金融機関向けネットワーク「SSFN」（Swiss Secure Finance Network）では実際に本番運用されている。IPv4/IPv6 の上でオーバーレイとして動かす構成も可能なため、既存インフラとの共存ができる。
NDN：IP アドレスではなく「コンテンツ名」でルーティング
NDN（Named Data Networking）は、アドレスではなくコンテンツの名前でパケットをルーティングする発想だ。NSF（米国国立科学財団）が支援する Future Internet Architecture プロジェクトの一つとして研究されている。
現在のインターネットは「どのホストに送るか」を軸に設計されている。NDN は「何を取得したいか」を軸にする。コンテンツに名前を付け、その名前でルーティングする。
これで解決できることがある。
- 同じコンテンツをネットワーク内でキャッシュできるため、CDN に近いことがインフラ層で実現できる
- コンテンツの完全性を名前に含めることで、改ざんが検出しやすくなる
- 送信元アドレスに依存しないため、モバイル環境でのハンドオーバーが自然になる
ただし、既存の IP インフラとの互換性が低く、普及の見通しは現時点では不透明だ。IoT やエッジコンピューティングの分野で部分的な採用が進んでいる。
QUIC/HTTP3：IP バージョン差を上のレイヤーで吸収する
アーキテクチャを変えるのではなく、上のレイヤーで IP バージョン差を吸収する方向もある。QUIC（RFC 9000）はその代表だ。
QUIC は UDP の上で動き、IP アドレスとポートの組み合わせをコネクションの識別子として直接使わない。接続 ID というコネクション固有の識別子を使うため、IP アドレスが変わっても接続が継続できる。
これにより、IPv4 でも IPv6 でも同じ品質で通信できる構造が上位レイヤーで実現している。HTTP/3 は QUIC の上で動く。現在、主要ブラウザとサーバーのほとんどが対応済みだ。
「IPv4 上位互換」はどこまで実現しているか
「IPv4 の上位互換」に最も近い方向で実用化が進んでいるのは、SRv6 と MAP-T などのトランジション技術の組み合わせだ。
MAP-T（Mapping of Address and Port using Translation, RFC 7599）は、IPv4 パケットを IPv6 ネットワーク内で転送し、出口で IPv4 に戻す仕組みだ。エンドポイントが IPv4 のまま、バックボーンを IPv6 に移行できる。
これらを組み合わせると、
- エンドユーザーは IPv4 のまま使い続けられる
- コアネットワークは IPv6 で設計できる
- 経路制御は SRv6 で統一できる
という構成が実用レベルで動く。「IPv8」という新しいバージョン番号は必要なく、既存の規格の組み合わせで近い目標に到達できる。
実際に進んでいること
研究や規格の話だけでなく、現時点で実際に動いていることも整理しておく。
- 5G SA（スタンドアローン）：コアネットワーク設計が IPv6 前提。3GPP 標準に組み込まれている
- SRv6 商用運用：中国電信、NTT、Softbank などが国内バックボーンに採用
- SCION 本番運用：スイスの金融ネットワーク（SSFN）で稼働中
- Apple App Store 審査：IPv6-only 環境での動作確認を要求。アプリ側の対応を強制
- Cloudflare / Google：IPv6 トラフィックの比率が年々上昇。エッジで IPv4/IPv6 を吸収する構成が標準化
IP プロトコルの「次のバージョン」は単一の規格として登場するのではなく、こうした技術が層ごとに置き換わっていく形で進む。
今できることは、IP アドレスへの依存を少しずつ減らすことだ。固定 IP 許可リストをやめ、証明書と ID ベースの認証に移行し、DNS を正しく使い、CDN とエッジを活用する。それが、どの次世代プロトコルが来ても対応できる設計の準備になる。
私見：IPv4 を 8 オクテットに拡張すれば良かったのでは
最後に私見を書いておきたい。
IPv6 が「クリーンブレーク」を選んだことで 30 年近く移行が進まなかったのを見ると、そもそも設計の方向が違ったのではないかと思う。
私が理想的だと思うのは、IPv4 のアドレス記法をそのまま 8 オクテットに拡張した形だ。
255.255.255.255.255.255.255.255
つまり、今の x.x.x.x（32bit）を x.x.x.x.x.x.x.x（64bit）に伸ばす。
これだけで何が変わるか。
アドレス空間は劇的に広がる
32bit の IPv4 は約 43 億アドレス。64bit にすると約 1844 京アドレス（2 の 64 乗）。IoT 機器が 350 億台になっても、地球上の砂粒より多い数のアドレスが確保できる。NAT で延命する必要がなくなる。
IPv4 との後方互換を保ちやすい
既存の IPv4 アドレスを 0.0.0.0.x.x.x.x として扱えば、現行の IPv4 パケットは新しいプロトコルのサブセットとして機能する。ルーターは上位 4 オクテットが 0.0.0.0 のアドレスを IPv4 互換として転送できる。dual stack の混乱期を大幅に短縮できた可能性がある。
人間が読める表記を維持できる
IPv6 の 2001:0db8:85a3:0000:0000:8a2e:0370:7334 は、現場での障害対応、ログ確認、FW ルール設定で扱いにくい。8 オクテット表記なら、IPv4 の知識がある人間がそのまま読める。
# 現行 IPv4
192.168.1.100
# 拡張 8 オクテット案
0.0.0.0.192.168.1.100 （IPv4 互換空間）
10.48.0.0.192.168.1.100 （新しいグローバルアドレス空間の例）
現実的な課題はある
もちろん、これが完璧な設計というわけではない。
- 64bit でも将来の超大規模 IoT や AI エージェント網に足りないかもしれない（IPv6 の 128bit はここを見越している）
- ルーターのアドレス処理ロジックを変える必要があり、当時の 1990 年代のハードウェアには重い変更だった
- セキュリティ機能（認証、暗号化）はアドレス拡張だけでは解決しない
それでも、「表記を変えずにオクテット数だけ増やす」という発想は、30 年かけて普及しなかった IPv6 の移行コストを考えると、現実解として十分あり得た選択肢だったと思う。
IPv6 の設計者たちもこのジレンマは分かっていたはずで、それでもクリーンブレークを選んだのには理由がある。ただ結果として、今も世界の半分は IPv4 で動いている。その事実は重い。
私見：NAT のボトルネックは銅線の問題でもある
もう一つ付け加えたい視点がある。
NAT がボトルネックになる理由は、アドレス変換の処理コストだけではない。そもそも現在のネットワーク機器は、光ファイバーで届いた信号を受け取るたびに、いったん電気信号に変換してから処理している。電気信号は熱を持ち、干渉が起き、信号劣化が起きる。NAT の変換処理もこの電気回路上で行われるため、大量のセッションを捌くほどその限界が見えてくる。
NTT が推進する IOWN（Innovative Optical and Wireless Network） 構想、その中核にある APN（All-Photonics Network） は、この構造を根本から見直そうとしている。
従来のアーキテクチャはこうなっている。
光ファイバー → [電気変換] → ルーター（電気処理）→ [光変換] → 光ファイバー
APN の目指すものはこうだ。
光ファイバー → ルーター（光のまま処理）→ 光ファイバー
「光波長パス」を end-to-end で張り、電気変換を挟まずにパケットを転送・制御する。さらに IOWN はネットワーク層だけでなく、デバイスや半導体レベルまで光技術を広げることを視野に入れている。NTT はこれにより、従来比で消費電力を 1/100、伝送容量を 125 倍、端末間遅延を 1/200 にすることを目標として掲げている。
これが実用化されると、何が変わるか。
NAT の処理コストが根本から下がる
電気変換が不要になれば、変換に伴う遅延と発熱が消える。CGNAT が抱えるセッション数の壁が大幅に緩和される可能性がある。現在「NAT は遅い」と言われる根本原因が、プロトコルではなく物理層にあることが改めてわかる。
IPv4 の延命がさらに延びる可能性
逆説的だが、APN が普及すると「NAT でもまだいける」という状況がさらに続くかもしれない。ただ、処理能力のボトルネックが消えることで、より多くのデバイスを少ない装置で捌けるようになる。消費電力も劇的に下がるため、インフラのランニングコスト構造が変わる。
アドレス設計とは別の軸でブレイクスルーが起きる
IPv4 か IPv6 か、8 オクテットか 128bit かという議論は、アドレス空間と経路制御の話だ。IOWN/APN はその議論とは別の軸——物理的な転送速度・消費電力・遅延——でブレイクスルーをもたらす。
プロトコルの設計と物理インフラの進化は別々に進む。APN が「どのプロトコルが来ても高速・低遅延に捌ける基盤」を作れば、IPv4 であれ IPv6 であれ、新しいアドレス体系であれ、その上で動かせる選択肢が広がる。
NTT は 2030 年代の実用化を目指しているとしており、現時点では研究・実証段階だ。ただ、「光ファイバーで来た信号を電気に戻さず、光のまま処理する」という発想がインターネットの物理基盤を根本から変える可能性を持っていることは確かだ。アドレス設計の議論と並行して、こちらも注目しておく価値がある。
