IPv8 IETFドラフト——IPv4と完全後方互換な64ビットアドレス空間で「IPv6問題」を回避する新提案の中身

何が起きたか

2026年4月14日、ネットワークアーキテクトの Jamie Thain（One Limited）が IETF に個人インターネットドラフト draft-thain-ipv8-00 を提出した。名称は Internet Protocol Version 8（IPv8）。

提出情報:
  ドラフト名:   draft-thain-ipv8-00（2026年4月14日提出）
  提出者:       Jamie Thain（One Limited）
  IETF状態:    個人ドラフト（Individual Submission）
               ※ IETFワーキンググループ未採択
  有効期限:     2026年10月16日（通常の6ヶ月）
  話題化:       The Register 2026年5月12日記事で広く拡散
  ファンディング: オープンソーステストベッド用に$100,000クラウドファンディング開始

Thainは「既存プロトコルは当時の課題のために作られたが、状況は大きく変わった。IPv6の間違いから学んで、もっとうまくやれる」と述べている。

なぜIPv6で不十分なのか

IPv6は1998年に標準化されたが、28年後の今もIPv4が主流のままだ。

IPv6移行が進まない理由:

❌ デュアルスタック問題
  - ネットワーク機器・OS・アプリがIPv4/IPv6の両方を
    実装・管理する必要がある
  - 設定の複雑さが大幅に増加

❌ 後方互換なし
  - IPv4とIPv6は直接通信できない
  - NAT64/DNS64などのゲートウェイが必要

❌ アドレス空間の思想的転換
  - IPv4: 192.168.1.1（32ビット、親しみやすい）
  - IPv6: 2001:0db8:85a3:0000:0000:8a2e:0370:7334（128ビット）
  - 人間が読みにくい記法への移行コスト

❌ 管理分散の問題
  - DHCPv6・DNSv6・認証が別々のシステムのまま

IPv8の設計

64ビットアドレス: 親しみやすいIPv4記法を8オクテットに拡張

IPv4 アドレス（32ビット、4オクテット）:
  192.168.1.1

IPv8 アドレス（64ビット、8オクテット）:
  192.168.1.1.10.20.30.40
  └── 各オクテットは0〜255（IPv4と同じ範囲）

アドレス空間:
  IPv4: 2^32 = 約43億アドレス
  IPv6: 2^128 = 約340澗（undecillion）アドレス
  IPv8: 2^64 = 約1844京アドレス（十分な空間）

後方互換の仕組み

IPv8の最大の主張は「既存のIPv4デバイスを変更なしに共存させられる」点だ。

後方互換の概念モデル:

IPv4デバイス (192.168.1.1)
  ↓ そのまま接続
Zone Server（IPv8ゲートウェイ）
  ↓ IPv8ネットワークに中継
IPv8デバイス (192.168.1.1.10.20.30.40)

✅ IPv4デバイスはアップデート不要
✅ IPv8デバイスはIPv4とも通信可能
✅ NATなしで共存（設計上）

Zone Server: 管理の統合

IPv8は Zone Server という概念で、現在バラバラに動いているネットワークサービスを一元化する。

Zone Server が統合するサービス:
  ┌─────────────────────────────────────────┐
  │  Zone Server                            │
  │  ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐  │
  │  │ DHCP │ │ DNS  │ │ NTP  │ │ Auth │  │
  │  └──────┘ └──────┘ └──────┘ └──────┘  │
  └─────────────────────────────────────────┘

認証: OAuth2トークンベース
利点: 設定の一元管理・複数サービスの整合性
欠点: 単一障害点（SPOF）のリスク

IPv6との比較

観点	IPv4	IPv6	IPv8（提案）
アドレス長	32ビット	128ビット	64ビット
アドレス枯渇	枯渇済み	解決	解決
IPv4後方互換	✅	❌	✅（主張）
記法の親しみやすさ	✅	❌	✅
管理の統合	❌（分散）	❌（分散）	✅ Zone Server
IETF標準	✅	✅	❌（個人ドラフト）
実装	普及	普及中	未実装

技術的な批判点

コミュニティからの主な懸念:

1. Zone Server の単一障害点
   Zone Server が落ちると DNS・DHCP・認証が全停止する。
   現状のIPv4インフラは（不便でも）各サービスが独立して生存可能。

2. OAuth2のパフォーマンスオーバーヘッド
   高PPS（パケット/秒）ルーティングでOAuth2検証を
   ホップごとに行うのは現実的ではない。
   「管理は中央集権、ルーティングは分散」の設計が必要では？

3. 64ビットで本当に足りるか
   IPv4は43億で「足りる」と思われたが枯渇した。
   IoTデバイスの爆増を考えると128ビットのIPv6の方が安全マージンが大きい。

4. 「後方互換」の実装複雑さが未証明
   現在はドラフトのみ。Zone Serverの実装がどれほど複雑になるか不明。
   IPv6の失敗も「仕様は正しいが実装が難しすぎた」側面が大きい。

現在の状態と展望

現状（2026年5月時点）:
  ✅ IETFへの個人ドラフト提出（draft-thain-ipv8-00）
  ✅ The Registerをはじめ技術メディアで話題に
  ✅ Thainによるオープンソーステストベッド構築開始（$100,000クラウドファンディング）
  ❌ IETFワーキンググループの採択なし
  ❌ 既存コードベースへの実装なし
  ❌ RFC化の見込み：現時点では不明

期限: ドラフトは2026年10月16日に失効予定（延長or廃案）

参考: IPv6も1998年のRFC 2460から実質普及まで20年以上かかった

開発者・インフラエンジニアへの示唆

IPv8が実用化される可能性は現時点では低い。しかし、このドラフトは重要な問いを投げかけている。

IPv8ドラフトが示す設計哲学:

1. 「後方互換なき革新は採用されない」
   IPv6の教訓: 技術的に優れていても互換性がなければ28年経っても普及しない。
   IPv8の回答: 既存デバイスをそのままに、新機能を追加する。

2. 「管理の統合は移行コストを下げる」
   DNS・DHCP・認証のサイロを壊してZone Serverに統合する発想は
   ネットワーク管理の複雑さを本質的に下げる可能性がある。

3. 「記法の親しみやすさは採用率に直結する」
   128ビットIPv6アドレスを人間が覚えられないのは軽視できない問題だった。

落とし穴・注意点

個人ドラフトはほぼRFCにならない: IETFへの個人提出は年間数百件あるが、標準化まで進むのは一部のみ
「後方互換」は実装レベルで検証されていない: 仕様書上の主張であり、動作するテストベッドはこれから構築される
Zone Serverの仕様はまだ粗い: 認証フローの詳細・高可用性設計・他プロトコルとの相互作用が未定義
IPv6も「すぐに普及する」と言われ続けて28年: 新プロトコルは良い提案でも産業界の採用に数十年かかる

まとめ

IPv8は「IPv6よりも移行しやすいIPv4の後継」という明確な問いに対する一つの回答だ。技術的なアプローチは面白く、後方互換性重視の設計哲学は説得力がある。しかし現時点ではIETFワーキンググループの支持もなく、実装も存在しない。本番環境への影響はゼロに近いが、ネットワーキングのレイヤーをどう設計するかという思考実験として読む価値は大きい。テストベッドの構築が進めば、後方互換の実現可能性について具体的な議論が生まれるだろう。

参考リンク

未確認事項: 後方互換の動作は仕様上の主張であり、動作するテストベッドは2026年5月時点で構築中。Zone Serverの高可用性・フェイルオーバー設計は仕様に含まれていない。OAuth2の高PPS環境での実用性は未検証。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感