64ビットアドレスでIPv4を内包するIPv8の個人ドラフト（draft-thain-ipv8-00）がIETFに提出された

2026年4月14日付でIETFに draft-thain-ipv8-00 が提出された。
著者はバミューダのOne Limited所属Jamie Thain氏で、タイトルはそのまま「Internet Protocol Version 8 (IPv8)」。

期限は2026年10月16日の通常のInternet-Draftで、個人ドラフト（individual submission）扱い。
つまりIETFのワーキンググループを経由した合意文書ではなく、1人（1社）が出した提案書という位置付けになる。

中身は「IPv6をやり直す」色が強くて面白いので読んでみた。
IPv6が25年かけても世界の流量の過半を取れなかったという現状認識から出発して、アドレス枯渇だけでなく「管理系の分断」と「BGP経路表の無制限肥大」までまとめて直そう、というかなり野心的な提案になっている。

IPv6はどうやって決まったのか

先に対比として、IPv6がどう標準化されたかを振り返っておく。
IPv8のドラフトが「1人の提案」なのに対し、IPv6は完全に集団合意プロセスを経ている。

1990年前後: IPv4アドレス枯渇がRFC 1287などで具体的に警告される
1992年: IETFが IPng（Internet Protocol next generation）という上位概念の議論を開始し、候補案の募集をかける
1992〜1993年: 複数の候補案が競合。代表的なものが3つ
- CATNIP（Common Architecture for the Internet）: TCP/IP・OSI・IPXを統合する野心的な提案
- TUBA（TCP and UDP with Bigger Addresses）: ISO CLNPの20バイトアドレスをIPv4の代わりに使う
- SIPP（Simple Internet Protocol Plus）: IPv4の拡張方向。64ビット案から始まり最終的に128ビットへ
1994年7月: IPng Area Directorate（IPngディレクトリ）が提言を出し、SIPPをベースに128ビットアドレスへ拡張したものを採用
1995年: RFC 1883としてIPv6（Internet Protocol, Version 6）が初公開
1998年: RFC 2460で現代的なIPv6仕様に改訂（Draft Standard）
2017年: RFC 8200でInternet Standard（STD 86）に昇格

なぜ「6」で「8」が空いていたか

IPv5が欠番なのは、実験的ストリームプロトコル ST / ST-II（RFC 1190, RFC 1819）に既に「バージョン5」が割り当てられていたため。
IPngの候補選定時点で5は使えなかったので、次の空き番号として6が採用された。

7・8・9はその後、各候補案の名残りとして一時的にIANAに予約された時期がある。

TUBA → IPv7
CATNIP → IPv7（途中でCATNIPに統合）
PIP（別案）→ IPv8
TP/IX（別案）→ IPv9

いずれもIPv6採用で用済みになり、予約解除の方向で整理された。
今回のdraft-thain-ipv8-00は、この「空いていたバージョン番号8」に改めてIANA申請をかけている格好になる。

IPv6とのプロセス面での違い

IPv6は3本以上の競合提案をIETFのディレクトリで比較検討した上で、SIPP派生をベースに合意形成した設計だった。
一方のdraft-thain-ipv8-00は、個人ドラフトとしてぽんと1本投げ込まれた状態で、WGの設立も合意も経ていない。

この違いは後述のBGP8やZone Server必須化のような踏み込んだ要求が「どれだけ通りそうか」を読むうえで重要になる。

IPv8が解決したい問題

ドラフト冒頭で挙げられている動機はこう。

動機	内容
管理系の分断	DHCP・DNS・NTP・認証・ログが別々のシステムに分かれていて相互に協調していない。IPv8はこれをZone Serverという1プラットフォームに束ねる
アドレス枯渇とCGNAT	IPv4は2011年2月に割り当てが完了済み。CGNATでしのいでいるがレイテンシとプロトコル破壊を招く。IPv6はdual-stack運用コストが高すぎて普及が進まなかった
BGP経路表の無制限な肥大	BGP4は2024年時点で90万プレフィックスを超え、アーキテクチャ上の上限がない。deaggregationとオーナーシップ検証欠如がハイジャックとリークを招いている

IPv6が「アドレス空間」だけを解こうとしたのに対し、IPv8は「アドレス＋管理面＋経路表サイズ＋セキュリティ」を1枚絵で解こうとしている点が違う。

64ビットアドレスの構造

IPv8のアドレスは64ビットで、こう書く。

r.r.r.r.n.n.n.n

r.r.r.r（32ビット）はASN相当のルーティングプレフィックスで、AS番号にひもづく
n.n.n.n（32ビット）はホストアドレス部分で、IPv4と同じセマンティクスをそのまま使う

総アドレス空間は2^64 ≒ 約1,844京個。
1つのASNごとに2^32（約43億）のホストアドレスが割り当てられる構造で、CGNATはそもそも不要になる。

IPv6の128ビット＋コロン区切りの16進表記に比べると、見た目が完全に「IPv4を2段重ねにしたもの」になっていて、運用者の認知負荷をかなり下げに行っている。

IPv4を真部分集合として含む

ここが一番攻めた設計ポイントで、r.r.r.r = 0.0.0.0 のアドレスは素のIPv4として処理される、と明記されている。
つまり、

既存デバイスの改修ゼロ
dual-stack強制なし
移行期限なし
100%後方互換

という整理になっている。
IPv6が「別プロトコルを並走させる」方向でつまずいたのを、IPv8は「IPv4を包含する拡張」として逆側から攻めている。

予約アドレス帯

範囲	用途	ルーティング
`127.x.x.x`	組織内ゾーン用プレフィックス	外部には絶対流さない
`127.127.0.0`	組織間相互接続DMZ	プライベートのみ
`100.x.x.x`	RINEピアリングファブリック	グローバルには流さない
`*.222.x.x.x`	内部ルータ間リンク	慣習のみ
`0.0.255.254`	プライベートBGP8ピアリング（ASN 65534）	プライベート
`ff.ff.ff.ff`	ブロードキャスト	L2のみ

クラウドのVPC間でRFC1918空間がぶつかる問題を、顧客VPCごとにユニークな 127.x.x.x ゾーンプレフィックスを振ることで回避する、という書き方になっている。
クラウドプロバイダ側の需要にもかなり寄せてきている。

パケットヘッダの構造

ヘッダはIPv4をベースに、送信元/宛先アドレスフィールドを32ビットから64ビット（ASN+ホスト）に差し替えた素直な拡張になっている。

Version (4ビット) = 8
IHL, Type of Service, Total Length (IPv4と同一)
Source/Destination ASN Prefix (各32ビット、新規)
Source/Destination Host Address (各32ビット、新規)

IPv4と比べてヘッダ長は8オクテット増える、という控えめな差分。
IPv6の「ヘッダを作り直した」世界観と比べると、スタックの実装コストを相当低く見積もっている。

管理系を束ねるZone Server

IPv8の特徴としてアドレスよりむしろ語られるべきなのが、Zone Serverという「active/active構成で動く1つのプラットフォーム」に管理系サービスを集約する思想。

サービス	役割
DHCP8	1回のレスポンスで必要な全サービスエンドポイントを返す
DNS8	`A8` レコードによる名前解決（64ビット値を運ぶ、IANA申請中）
OAuth8	JWT検証
NetLog8	テレメトリ集約
WHOIS8	経路検証
ACL8	アクセス制御
XLATE8	IPv4/IPv8変換

ドラフトには「IPv8ネットワークに繋がる端末は、DHCP8 Discoverを1発投げるだけで必要な全サービスエンドポイントを受け取る」とある。
現代のNWが「それぞれ別の箱・別のチームで動いているサービスの寄せ集め」になっているのを、プロトコル層から強制的に束ねに来ているのがすごいところ。

BGP8とCost Factorによるルーティング

IPv8が要求するルーティングプロトコルはこう整理されている。

プロトコル	役割	備考
eBGP8	AS間	注入可能な最小プレフィックスは `/16`
IBGP8	ゾーン間	Cost Factor付き
OSPF8	ゾーン内	OSPFv2拡張
IS-IS8	任意の内部GP	—

BGP経路表は「ASNあたり1経路」で上限化

ここが面白い。
eBGP8には /16 未満の注入が境界で拒否されることで、BGP8の経路表は構造的にASNあたり1経路に上限化される、と明言されている。

現在のBGP4が90万超に膨らんでいるのに対し、BGP8の想定経路表は約17.5万（ASN割当数相当）。
これは「Deaggregationでトラフィックを引っ張るBGPの慣習そのもの」を禁止しに行っている設計で、賛否は確実に割れるはず。

Cost FactorはAS境界をまたぐ統一メトリック

Cost Factor (CF) は32ビットの統一メトリックで、以下を合成する。

RTT
パケットロス
輻輳ウィンドウ状態
セッション安定性
リンク容量
経済的ポリシー
地理的距離（物理フロア検証付き）

OSPF/EIGRPがAS境界で止まるのに対し、CFはend-to-endでAS間をまたぐ。
経路選択に「経済ポリシー」と「物理距離フロア」が明示的に入っているのも今っぽい。

East-WestとNorth-Southで分けたセキュリティ

IPv8のセキュリティモデルは「East-West（内部横移動）」と「North-South（インターネット出口）」を分けて考える。

East-West側はACL8でゾーン分離

内部横移動を、3層のACL8で止める。

NICファームウェアレベルのACL8
Zone ServerゲートウェイのACL8
スイッチポートでのOAuth2 VLAN強制

NICが10/秒（認証なし）、100/秒（認証あり）のレート制限をハードウェアで強制する、という記述もある。
ブロードキャストは10/秒まで。
このあたり、「普通のエンドポイント保護では手が出せないレイヤに制限を持たせる」方向で、ランサムウェアの横展開対策を意識している。

North-South側ではDNS8とWHOIS8検証が必須

出口側は、次の2つの検証が必須になる。

flowchart TD
    A[アプリが外部接続] --> B[DNS8による名前解決]
    B -->|失敗| X[接続ブロック]
    B -->|成功| C[宛先ASNの特定]
    C --> D[WHOIS8で宛先ASNを検証]
    D -->|未登録/失敗| X
    D -->|成功| E[通信許可]

これで、「ハードコードされたIPに直接繋ぐマルウェアC2」をプロトコル層で潰せる、という整理になっている。
BGP8の経路広告もWHOIS8検証を通らないとインストールされないので、従来のbogonフィルタ手動メンテが不要になる、という主張もある。

デバイス準拠ティア

ドラフトでは機器が3段階に整理されている。

ティア	機器	要求機能
Tier 1	エンドデバイス	DHCP8、静的経路、VRF管理、NetLog8、ACL8
Tier 2	L2スイッチ	802.1Qトランク、VLAN自動生成、PVRST、OAuth2ポートバインド、NetLog8
Tier 3	L3ルータ	Tier 1 + eBGP8、IBGP8、OSPF8、IS-IS8、XLATE8、WHOIS8リゾルバ

スパニングツリーはPVRST必須、Zone Serverがルート、という踏み込んだ指定になっている。
Tier 1にすらNetLog8クライアントが入っているのも、「NW全体で一貫したテレメトリを取ること」を標準仕様に格上げしている例。

フラグデーなしで段階的に乗る移行戦略

IPv8の移行は段階的で、「全員で同じ日に切り替える」必要がない。

Tier 1/2 ISPがソフトウェア更新
クラウドプロバイダが内部採用
企業が任意でASNプレフィックス採用
コンシューマISPが移行

IPv4だけの中継網でIPv8アイランドが分断されるケースは、HTTPS上にカプセル化する8to4トンネルで接続する（暗号化とFW越えを優先）。
BGP8の 8TO4-ENDPOINT 属性がトンネルのエンドポイントを自動で配るので、手動設定ゼロで穴を掘れる、という主張がある。

CGNAT装置側は改修不要で、IPv8対応CGNATは r.r.r.r を保ったまま n.n.n.n のみを変換する設計。

アプリケーション互換性

既存IPv4アプリは無改修で動く、と明記されている。
IPv8のソケット互換層が透過的にシステムコールをインターセプトする。

新しいアプリは AF_INET8 と sockaddr_in8 を使ってASNとホストを分離して扱える。
IPv6で散々引っかかった「アプリ側のAF対応と文字列パース」を、最初からIPv4形式の拡張として逃がしている。

IPv6への当てこすり

ドラフト本文から読み取れるIPv6への評価は辛口で、要約するとこうなる。

dual-stack強制が普及の最大の壁だった
25年経っても「世界のトラフィックのマイノリティ」しか運んでいない
アドレス枯渇だけを解いた結果、管理分断や経路表肥大は手つかずのまま残った
IPv8はsingle-stackと統合管理を同時に取りに行く

「IPv6が実現した技術的な美しさ」に対する反論ではなく、「社会実装として負けた理由を制度設計側から直す」という切り口になっている。

IANAへの要求

IPv8は以下の割当をIANAに要求している。

IPバージョン番号「8」
r.r.r.r レンジとして 127.0.0.0/8（内部ゾーン）、100.0.0.0/8（RINE）
n.n.n.n 側の 222.0.0.0/8 を内部リンク慣習として文書化
DNS A8 レコードタイプ
ASN 65534（プライベートピアリング）、65533（ドキュメント用）

前述のとおり、IPv8のバージョン番号枠はIPng検討時に PIP 用として一度予約され、採用見送りで空いていた枠にあたる。