TL;DR（30秒で分かる要約）
- 何が起きた？ → 2026年4月、J. Thain氏がIETFに「Internet Protocol Version 8（IPv8）」のInternet-Draftを提出
- なぜ重要？ → IPv4アドレス枯渇・IPv6移行の長期停滞という2つの課題を同時に解こうとする設計提案で、技術的なアイデアとして注目に値する
- 注意点 → 現時点は「提案段階（Internet-Draft）」であり、標準化されたプロトコルではない。「IPv8が来た」という見出しには注意が必要
はじめに
「IPv8が登場した」という情報を目にしたことはあるでしょうか。
まず最初に押さえておきたいのは、IPv8は現時点でIETFのInternet-Draft（提案文書） であり、正式なRFCや標準プロトコルではないという点です。Internet-Draftとは「標準化のための議論のたたき台」であり、有効期限は6ヶ月です。今回のdraft-thain-ipv8-00は2026年10月に期限を迎えます。
ただし、技術的な設計思想は読み応えがあります。IPv4アドレス枯渇という30年来の課題と、IPv6移行が世界的に遅々として進まない現状（Googleの統計でグローバルユーザーのIPv6可用性は約45〜50%）に対して、別のアプローチを提示しているからです。
今回の提案概要
| 項目 | 内容 |
|---|---|
| 提案者 | J. Thain（One Limited） |
| 提出日 | 2026年4月（IETF Internet-Draft） |
| ドラフト番号 | draft-thain-ipv8-00 |
| ステータス | Internet-Draft（提案段階） |
| ドラフト有効期限 | 2026年10月16日 |
| 関連仕様 | ARP8, ICMPv8, Route8, Zone Server Architecture, Update8 |
IPv4・IPv6・IPv8の違い（Before / After）
Before：IPv4とIPv6が抱える課題
IPv4の問題（32ビット = 約43億アドレス）：
インターネット黎明期に設計されたIPv4は、アドレス空間が32ビット（約43億個）しかありません。IoTデバイスや新興国のインターネット普及により、グローバルアドレスは実質的に枯渇しています。現在はNAT（ネットワークアドレス変換）で延命していますが、根本的な解決策ではありません。
IPv6の問題（128ビット = 340澗個）：
IPv6はアドレス空間を128ビットに拡張し、理論上は問題を解決します。しかし「デュアルスタック移行」が必要で、ルーター・OS・アプリケーションすべてがIPv4とIPv6の両方に対応する期間が続きます。世界的な普及率は約50%に留まっており、完全移行の見通しは立っていません。
After：IPv8が提案する設計
IPv8の核心は「アドレス体系を変えるだけでなく、ネットワーク管理の仕組みごと置き換える」というアプローチです。
【IPv4】
アドレス: 32ビット（例: 192.168.1.1）
管理: DHCP・DNS・NTP・認証がそれぞれ独立したシステム
移行: NAT で延命中
【IPv6】
アドレス: 128ビット（例: 2001:db8::1）
管理: 従来のサービスをIPv6対応に更新が必要
移行: デュアルスタックで長期並存中（〜50%普及）
【IPv8（提案）】
アドレス: 64ビット（32bit ASN + 32bit ホスト）
管理: Zone Server が DHCP8・DNS8・NTP8・認証を統合提供
移行: IPv4を「IPv8の一形態」として内包（デュアルスタック不要）
技術的な詳細
アドレス構造
IPv8のアドレスは64ビットで、2つのフィールドに分かれます。
IPv8 アドレス（64ビット）
┌─────────────────────────┬─────────────────────────┐
│ ASNプレフィックス（32bit） │ ホストアドレス（32bit） │
│ AS番号保有者を識別 │ 各ホストを識別（約43億個） │
└─────────────────────────┴─────────────────────────┘
例：ASN保有者（ISPや大企業）1社あたり約43億ホストアドレスを取得可能
IPv4との後方互換性の仕組み：
IPv4 アドレス → IPv8 で表現する場合
0.0.0.0（ASNプレフィックス） + [IPv4アドレス32bit]
つまり「192.168.1.1」は IPv8 では「0.0.0.0:192.168.1.1」として扱われる
→ 既存デバイスを変更せずにIPv8ネットワークに参加できる（理論上）
Zone Server アーキテクチャ
IPv8の特徴的な設計が「Zone Server」です。従来バラバラに存在していたネットワークサービスを一元化します。
【従来のネットワーク管理】
DHCP サーバー（IPアドレス割り当て）
DNS サーバー（名前解決）
NTP サーバー（時刻同期）
認証サーバー（RADIUS等）
ログ収集（別途構築）
↑ それぞれ独立して設計・運用
【IPv8 Zone Server】
Zone Server
├── DHCP8（アドレス割り当て）
├── DNS8（名前解決）
├── NTP8（時刻同期）
├── 認証（OAuth2 JWT トークン）
├── WHOIS8（経路検証）
├── ACL8（アクセス制御・隔離）
└── ログ記録（統合監査）
↑ 単一プラットフォームで統合提供
セキュリティ設計
IPv8の提案で注目できるのはセキュリティの組み込み方です。
| セキュリティ機能 | 説明 |
|---|---|
| OAuth2 JWT 認証 | ホストの通信に認証トークンを要求。なりすましを防止 |
| WHOIS8 | BGP経路の検証機構。ルーティングハイジャック対策 |
| ACL8 | アクセス制御リストによるゾーン隔離（東西・南北方向） |
従来のIP設計では「ネットワーク層はベストエフォートで届ける」という思想でした。IPv8は設計段階から認証・検証を組み込む点で異なるアプローチを取っています。
この提案が面白い理由（ユースケース視点）
ユースケース 1：大規模IoT環境での管理統合
現状の課題： IoTデバイスを数千台管理する場合、DHCPサーバー・DNSサーバー・認証基盤・ログ収集を個別に構築・運用する必要があり、管理コストが高い。
IPv8の提案が示すもの： Zone Serverによる統合管理が実現すれば、1つのプラットフォームでデバイスの参加・認証・通信制御・ログ記録が完結します。設計思想としてはゼロトラストネットワークと相性がよい構造です。
ユースケース 2：マルチテナントのデータセンター
現状の課題： 複数テナントを収容するデータセンターでは、テナント間のネットワーク隔離・認証・ログ管理を複数ツールで組み合わせるのが一般的です。
IPv8の提案が示すもの： ASNプレフィックスでテナントを識別し、ACL8でゾーン隔離、WHOIS8で通信元検証をLayer 3レベルで統合できる設計思想です。実装が進めば、現在のVLANやVXLANに依存した隔離より設定がシンプルになる可能性があります。
IPv4 / IPv6 / IPv8（提案）の比較
| IPv4 | IPv6 | IPv8（Draft） | |
|---|---|---|---|
| アドレス長 | 32ビット | 128ビット | 64ビット |
| アドレス数 | 約43億 | 340澗 | ASN×約43億 |
| 普及状況 | 現役（NAT延命中） | 約50%（デュアルスタック） | 提案段階（未実装） |
| 移行コスト | — | デュアルスタック必要 | IPv4後方互換（設計上） |
| 管理統合 | なし | なし | Zone Serverで統合 |
| セキュリティ | 追加実装が必要 | 追加実装が必要 | 設計組み込み（OAuth2 JWT等） |
| 標準化 | RFC 791（1981） | RFC 8200（2017） | Internet-Draft（2026） |
まとめ
- ✅ IPv8はIETFに提出されたInternet-Draftで、64ビットアドレス＋Zone Server統合管理を提案
- ✅ IPv4の後方互換設計によりデュアルスタック不要という点が設計上の差別化
- ✅ セキュリティ（OAuth2 JWT、WHOIS8、ACL8）をアドレス設計と統合している点が興味深い
- ⚠️ 現時点は「提案段階」。RFCになるかどうか、実装・普及するかどうかは未知数
- ⚠️ IPv6がRFC化（1998年）から普及まで20年以上かかっている現実を踏まえると、IPv8の行方は長期視点で追う必要がある
次のアクション： ドラフト本文に興味がある方は draft-thain-ipv8-00 を直接確認してみてください。関連仕様（ARP8, Route8, Zone Server Architecture）も同時提出されており、全体設計が読み取れます。
最後まで読んでいただき、ありがとうございました！