はじめに
2026 年 4 月、IETF のデータトラッカーに提出された draft-thain-ipv8-00 という Internet-Draft が、ネットワーク界隈で話題になっています。「IPv8」という名称と、「IPv4 は IPv8 の真部分集合」「100% 後方互換」「IPv6 の失敗を解決する」といった刺激的な主張により、一部のメディアや SNS では「新しいインターネットプロトコルが IETF で提案された」といった形で紹介されているケースも見られます。
しかし、Internet-Draft は誰でも提出できる作業文書であり、それ自体が「標準」や「IETF 公認の提案」を意味するわけではありません。内容を読み込むと、既存の RFC や実運用と矛盾する記述も複数確認できます。
本記事では、この IPv8 ドラフトの内容を整理した上で、既存 RFC と現場の実務知識に照らして技術的に成立するのかを検証します。
- IETF Internet-Draft というものの位置づけ
draft-thain-ipv8-00が主張する内容のサマリ- ドラフトの主要な技術仕様を既存 RFC と照合した検証結果（4 論点）
- ドラフトが提起している問題意識のうち、妥当な部分と成立しない部分
- 新しい技術仕様に触れる際にインフラエンジニアが持つべき視点
前提: Internet-Draft とは何か
IETF における位置づけ
IETF（Internet Engineering Task Force）における Internet-Draft（I-D）は、RFC として発行される可能性のある議論のたたき台として提出される作業文書です。重要な性質をまとめると以下のとおりです。
| 項目 | 内容 |
|---|---|
| 提出資格 | 誰でも提出可能（個人・企業・WG いずれも可） |
| 審査プロセス | 提出時点では技術的な審査は行われない |
| 有効期限 | 最大 6 ヶ月（更新がなければ自動失効） |
| 法的・規範的な位置づけ | 「作業中」以外の形で引用・参照することは不適切とされる |
| RFC 化までの道のり | WG での議論・合意・IESG レビュー・パブリックレビューを経て、ごく一部のみが RFC となる |
ドラフト自体にも、IETF の定型文として以下の明記があります。
参考: IETF（draft-thain-ipv8-00）
“Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ‘work in progress.'”
（Internet-Drafts は最長 6 ヶ月有効な草稿文書であり、他の文書によっていつでも更新・置換・廃止される可能性があります。Internet-Drafts を参考資料として利用したり、「作業中」以外の形で引用することは不適切です。）
https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
つまり、「IETF に提出された」という事実だけでは、その内容が技術的に妥当であることを一切保証しないという点は、記事化・情報発信の前提として強調しておくべきポイントです。
draft-thain-ipv8-00 の基本情報
今回対象とするドラフトの基本情報は以下のとおりです。
| 項目 | 内容 |
|---|---|
| ドラフト名 | draft-thain-ipv8-00 |
| タイトル | Internet Protocol Version 8 (IPv8) |
| 種別 | 個人提出（ファイル名のサフィックス -00 は初版を示す） |
| 有効期限 | 2026 年 10 月 16 日 |
| 関連ドラフト | BGP8・WHOIS8・Zone Server・WiFi8・Update8 等、合計 10 本以上のコンパニオン仕様が同時提出 |
一度に 10 本以上のコンパニオン仕様を提出し、全スタックを一新するという構成は、IETF における新規プロトコル提案としては非常に広範です。この広範さゆえに、個別仕様の検証は後続ドラフトに委ねられており、本体ドラフト（本記事で扱うもの）の段階ではハイレベルな主張の粒度にとどまっています。
IPv8 ドラフトの主な主張
ドラフトが掲げている主張を、インフラエンジニアが把握しやすい形で 4 つに整理します。
統合ネットワーク管理（Zone Server）
ドラフトの中核概念は Zone Server と呼ばれる、Active/Active ペアで動作する統合管理プラットフォームです。DHCP8・DNS8・NTP8・NetLog8（テレメトリ）・OAuth8（認証キャッシュ）・WHOIS8 リゾルバ・ACL8・XLATE8（IPv4/IPv8 変換）をすべて一つのプラットフォームで提供するとしています。
デバイスが接続時に DHCP8 Discover を 1 回送るだけで、必要な全サービスエンドポイントが 1 回の応答で返される、という運用モデルが示されています。
参考: IETF（draft-thain-ipv8-00）
“Every service a device requires is delivered in a single DHCP8 lease response.”
（デバイスが必要とするすべてのサービスは、単一の DHCP8 リース応答で提供される。）
https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
アドレス構造（64 ビット / r.r.r.r.n.n.n.n）
IPv8 アドレスは 64 ビットで、以下の 2 フィールドで構成されます。
| フィールド | サイズ | 意味 |
|---|---|---|
r.r.r.r | 32 ビット | ASN ルーティングプレフィックス |
n.n.n.n | 32 ビット | ホストアドレス（IPv4 と同じセマンティクス） |
ASN ホルダーごとに 2^32 = 約 43 億のホストアドレスが割り当てられ、グローバルルーティングテーブルは「ASN ごとに 1 エントリ」という構造的上限が設けられるとされています。
また、r.r.r.r = 0.0.0.0 のとき IPv4 アドレスとして扱うことで、「IPv4 は IPv8 の真部分集合であり、100% 後方互換」という位置づけが主張されています。この点は後の検証セクションで詳しく扱います。
BGP8 / WHOIS8 によるルート検証
BGP8 のルート広告は、インストール前に WHOIS8 レジストリで検証されるとしています。検証に失敗したルートはルーティングテーブルに投入されません。加えて、/16 より詳細なプレフィックスは AS 境界で広告禁止とすることで、以下の効果を狙っています。
- 手動の bogon フィルタリスト管理の不要化
- プレフィックスハイジャックの構造的困難化
- ルーティングテーブルの ASN 割り当て数に応じた有界化（約 17.5 万エントリで頭打ち）
Cost Factor（CF）による経路選択
OSPF8・IS-IS8・BGP8 を跨いで、Cost Factor（CF）という統一メトリックを導入するとされています。CF は以下 7 要素を TCP セッションテレメトリから算出する 32 ビット累積メトリックです。
- ラウンドトリップタイム
- パケットロス
- 輻輳ウィンドウ状態
- セッション安定性
- リンク容量
- 経済的ポリシー
- 地理的距離（物理限界としての光速フロア）
すべての BGP8 ホップにわたって CF が累積され、各ルーターが独立に最低 CF の経路を選択する、というモデルです。OSPF や EIGRP が AS 境界で止まるのに対し、CF は AS 境界を越えて End-to-End で動作する点が新規性として主張されてます。
技術的検証: 4 つの論点
ここからは、ドラフトの主張を既存 RFC と実運用の観点で検証していきます。まずはアドレス空間の再割り当てに関する 2 つの論点です。
論点 1: 127.0.0.0/8 を内部ゾーンに再利用できるか？
ドラフトの主張
ドラフトは、r.r.r.r フィールドの 127.0.0.0/8 範囲を内部ゾーンプレフィックス空間として恒久的に予約すると述べています。組織は 127.1.0.0・127.2.0.0 といった形で内部ゾーンプレフィックスを割り当て、RFC 1918 アドレスと同様に内部ルーティングで自由に利用できるとしています。
参考: IETF（draft-thain-ipv8-00）
“The 127.0.0.0/8 r.r.r.r range is permanently reserved as the IPv8 internal zone prefix space.”
（127.0.0.0/8のr.r.r.r範囲は、IPv8 の内部ゾーンプレフィックス空間として恒久的に予約される。）
https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
既存 RFC の定義
127.0.0.0/8 の扱いは、インターネット標準である RFC 1122（Requirements for Internet Hosts）で明確に定義されています。
参考: RFC 1122（Requirements for Internet Hosts — Communication Layers）
“(g) { 127,} Internal host loopback address. Addresses of this form MUST NOT appear outside a host.”
（{ 127, <any> }は内部ホストループバックアドレスである。この形式のアドレスは、ホストの外に出現してはならない。）
https://datatracker.ietf.org/doc/html/rfc1122
さらに、RFC 5735 および後継の RFC 6890 でも 127.0.0.0/8 全体がループバックとして分類されています。
参考: RFC 5735（Special Use IPv4 Addresses）
“127.0.0.0/8 – This block is assigned for use as the Internet host loopback address. A datagram sent by a higher-level protocol to an address anywhere within this block loops back inside the host.”
（127.0.0.0/8はインターネットホストのループバックアドレスとして割り当てられる。上位プロトコルがこのブロック内のアドレス宛にデータグラムを送ると、ホスト内でループバックする。）
https://datatracker.ietf.org/doc/html/rfc5735
この定義は 1989 年の RFC 1122 以来、30 年以上わたりインターネット標準（STD 3）として運用されている根本的なルールであり、世界中のすべての OS・ネットワーク機器・アプリケーションがこれに従って実装されています。
検証: 実装層でどう問題になるか
127.0.0.0/8 を「外部に出るアドレス」として再利用しようとすると、以下の層でそれぞれ独立に問題が発生します。
Linux・Windows・macOS・BSD 等、すべての主要 OS のネットワークスタックは、127.0.0.0/8 宛のパケットをループバックインターフェース（lo）に強制ルーティングします。
たとえば Linux では ip addr show で以下のように実装されています。
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo127.x.x.x 宛の通信は物理 NIC に渡らず、カーネル内部で完結します。これを「外部ルーティング可能」に変更するには全 OS のカーネル改修が必要であり、「既存デバイスに修正不要」というドラフトの主張と矛盾します。
企業向けのルーター・スイッチは、127.0.0.0/8 を bogon（不正ルート）として ASIC レベルでドロップする実装が一般的です。これはソフトウェアアップデートでは変更できず、ハードウェア交換を伴います。
localhost という名前は、世界中のシステムの hosts ファイルで 127.0.0.1 にマップされています。セキュリティソフト・データベース・Web サーバーは「127.0.0.1 宛の通信は自ホスト」という前提で動作しており、この前提を崩すとローカル通信と外部通信の境界が曖昧になり、セキュリティ上の重大な影響を及ぼす可能性があります。
既存の議論との比較
実は 127.0.0.0/8 の再利用は、過去にも別の形で議論されています。Linux カーネルに「localhost を 127.0.0.0/16 に縮小する」パッチが提案された際、コミュニティは RFC 1122 との矛盾を理由に強く反対しました。
また、IPv4 アドレス枯渇対策として 127.1.0.0 以降をユニキャスト化する別の Internet-Draft（draft-schoen-intarea-unicast-127）も存在しますが、こちらも「すべてのホストのネットワークスタック・すべてのネットワーク機器・すべてのネットワークソフトウェアの修正が必要」と自ら認めており、採択には至っていません。
結論： 127.0.0.0/8 を内部ゾーンに再利用するというアイデア自体は過去から繰り返し提案されていますが、30 年以上の実装資産との互換性を考えると、「既存デバイスの修正不要」と「127.0.0.0/8 の再利用」は両立しません。
論点 2: 100.0.0.0/8 を RINE に予約できるか？
ドラフトの主張
ドラフトは、r.r.r.r フィールドの 100.0.0.0/8 範囲を RINE（Regional Inter-Network Exchange）のピアリングファブリック専用として予約するとしています。AS 間のピアリングリンクアドレッシングに使用され、グローバル BGP8 ルーティングテーブルには広告されないとされています。
既存 RFC との矛盾
100.0.0.0/8 のうち、100.64.0.0/10 の範囲は RFC 6598（BCP 153）で既に CGNAT 用共有アドレス空間として割り当て済みです。
参考: RFC 6598（IANA-Reserved IPv4 Prefix for Shared Address Space）
“This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier-Grade NAT (CGN) devices.”
（本文書は、Carrier-Grade NAT（CGN）デバイスのニーズに対応する Shared Address Space として使用される IPv4 /10 アドレスブロックの割り当てを要求するものである。）
https://datatracker.ietf.org/doc/html/rfc6598
RFC 6598 は BCP（Best Current Practice）153 に指定されており、世界中の ISP が CGNAT 導入時に利用している運用中の予約です。IANA IPv4 Special-Purpose Address Regstry にも正式に登録されています。
検証: 実運用への影響
日本国内でも多くの ISP が CGNAT を導入しており、100.64.0.0/10 は顧客宅内機器（CPE）と ISP CGNAT 装置を接続するインターフェースに実際に割り当てられています。この範囲を「AS 間ピアリング専用」として上書き予約すると、世界中で既に稼働している CGNAT 基盤のアドレス計画と直接衝突します。
多くの組織は、セキュリティ対策として 100.64.0.0/10 をフィルタリストに登録しています。ドラフトの提案通りに 100.0.0.0/8 全体を RINE として使うと、既存のフィルタ設定を全世界規模で書き換える必要が生じます。
ドラフトは別セクションで「CGNAT デバイスは修正不要」「CGNAT デプロイメントは変更なし（R5 要件）」と明記しています。しかし 100.64.0.0/10 を RINE 用に再利用すれば、既存の CGNAT は当然影響を受けます。ドラフト自身の互換性要件（R5）と内部で矛盾しています。
論点 1・2 の検証まとめ
| 論点 | ドラフトの主張 | 既存 RFC / 実運用 | 評価 |
|---|---|---|---|
| 論点 1: 127.0.0.0/8 の再利用 | 内部ゾーンプレフィックスとして恒久予約 | RFC 1122（STD 3）でループバック専用 | 全 OS・全機器のスタック改修が必要で、ドラフト自身の「既存デバイス修正不要」と矛盾 |
| 論点 2: 100.0.0.0/8 の予約 | RINE ピアリング専用として予約 | RFC 6598（BCP 153）で CGNAT 共有空間に割当済み | 稼働中の CGNAT 基盤と衝突。ドラフト自身の「CGNAT 変更不要」とも矛盾 |
両論点とも、「既存の標準と運用を無視した上書き予約」という構造になっており、「100% 後方互換」という全体の主張と整合しません。新しいアドレス空間を確保したいのであれば、既存の RFC で明確に「Reserved for future use」とされている範囲（例：240.0.0.0/4 の Class E）を検討するほうが衝突が少ないはずですが、ドラフトはこれを選択していません。
論点 3: 「IPv4 は IPv8 の真部分集合」「100% 後方互換」は成立するか？
ドラフトの主張
ドラフトの最も大胆な主張の一つが、「IPv4 は IPv8 の真部分集合である」というものです。具体的には、r.r.r.r = 0.0.0.0 の IPv8 アドレスは IPv4 アドレスとして扱われ、既存のデバイス・アプリケーション・ネットワークに修正は一切不要であるとされています。
参考: IETF（draft-thain-ipv8-00）
“IPv4 is a proper subset of IPv8. An IPv8 address with the routing prefix field set to zero is an IPv4 address. No existing device, application, or network requires modification. The suite is 100% backward compatible. There is no flag day and no forced migration at any layer.”
（IPv4 は IPv8 の真部分集合である。ルーティングプレフィックスフィールドがゼロの IPv8 アドレスは IPv4 アドレスである。既存のデバイス・アプリケーション・ネットワークに修正は一切不要。このスイートは 100% 後方互換である。フラグデーも、いかなる層でも強制移行もない。）
https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
この主張が成立するなら、IPv6 の「デュアルスタック地獄」を回避しつつ、アドレス空間拡張を実現できることになります。極めて魅力的な主張です。
検証: パケットヘッダのバイナリ互換性
ドラフト自身が示すパケットヘッダ構造を見ると、この主張が技術的には成立しないことがわかります。
IPv4 ヘッダ vs IPv8 ヘッダの比較
| 項目 | IPv4 ヘッダ | IPv8 ヘッダ（ドラフト定義） |
|---|---|---|
| バージョン | 4 | 8 |
| 送信元アドレス | 32 ビット | 64 ビット（r.r.r.r + n.n.n.n） |
| 宛先アドレス | 32 ビット | 64 ビット（r.r.r.r + n.n.n.n） |
| ヘッダ長 | 20 バイト（オプション除く） | 28 バイト（8 バイト拡張） |
ドラフト自身も以下のように明記しています。
参考: IETF（draft-thain-ipv8-00, Section 5.1）
“The IPv8 header is 8 octets longer than the IPv4 header.”
（IPv8 ヘッダは IPv4 ヘッダより 8 オクテット長い。）
https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
ここに根本的な矛盾があります。IPv4 ヘッダと IPv8 ヘッダはバイナリレベルで異なる構造であり、以下のすべてが影響を受けます。
- IPv4 デバイスのパケットパーサー
-
Version フィールドが
8のパケットを受信すると、既存の IPv4 実装はこれを認識できず破棄するかエラーを返します。 - ルーター / スイッチの ASIC
-
ハードウェアパーサーはヘッダ長を 20 バイトとして固定実装しているケースが多く、28 バイトヘッダの解釈には FPGA / ASIC の改修が必要です。
- ミドルボックス（ファイアウォール・NAT・ロードバランサ）
-
送信元・宛先 IP アドレスを 32 ビットとして扱うコードパスが広範に存在します。
「r.r.r.r = 0.0.0.0 のとき IPv4 として処理する」ルールの論理的問題
ドラフトは「r.r.r.r = 0.0.0.0 の IPv8 アドレスは IPv4 として処理する」としていますが、そもそもパケットを受け取った側が「これは IPv8 パケットか、IPv4 パケットか」を判定するには、まず Version フィールドを読む必要があります。Version 8 のパケットをそのまま受信した既存の IPv4 機器は、r.r.r.r が 0 かどうかを判断する前に破棄します。
つまり、IPv8 パケットを IPv4 機器が透過的に処理することは、既存機器のソフトウェアスタックに手を入れずには原理的に不可能です。
8to4 トンネリングに関する示唆
ドラフト自身も、実際には「8to4 トンネリング」（HTTPS エンカプセレーション）を介して IPv4-only 網を跨ぐことを想定していると記述しています。これは IPv6 の「デュアルスタック地獄」と実質的に同じ構造です。トンネルエンドポイントとなる機器は IPv8 対応が必要になり、「既存デバイスに修正不要」という主張は維持できません。
結論： 「IPv4 は IPv8 の真部分集合」という主張は、意味論的には理解できる構想ですが、バイナリ層の互換性としては成立しません。IPv6 が直面したデュアルスタック問題を回避しているように見えるのは、ドラフトの記述レベルでの話であり、実装層では同種の課題が残ります。
論点 4：IPv6 批判の妥当性（25 年・マイノリティという表現）
ドラフトの主張
ドラフトは IPv8 の必要性を説明する文脈で、IPv6 を次のように評価しています。
参考: IETF（draft-thain-ipv8-00, Section 1.2）
“After 25 years of deployment effort IPv6 carries a minority of global internet traffic. The operational cost of the dual-stack transition model, combined with the absence of management improvement, proved commercially unacceptable.”
（25 年間の展開努力の後も、IPv6 はグローバルインターネットトラフィックの少数しか運んでいない。デュアルスタック移行モデルの運用コストと、管理改善の欠如は、商業的に受け入れがたいことが証明された。）
https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
検証: 最新の IPv6 普及統計
この批判を 2026 年時点の実測データと照合します。
Google の IPv6 統計（2026 年 3 月時点）
Google が公開している IPv6 到達率の統計によると、2026 年 3 月 28 日に IPv6 経由のアクセスが初めて 50.1% に達しました。これは 1 日限りのスパイクではありますが、長期トレンドとしては明確な増加基調にあります。
| 時点 | Google 経由の IPv6 到達率 |
|---|---|
| 2022 年 4 月 | 約 40%（初めて 40% 超え） |
| 2025 年初頭 | 約 43% |
| 2026 年 3 月 28 日 | 50.1%（単日ピーク） |
| 2026 年 3 月平均（前年比） | 46.33% → 約 50%（約 4 ポイント上昇） |
APNIC Labs の測定では 43.13%、Cloudflare Radar では 40.1% と、測定手法により数値は異なりますが、いずれも「マイノリティ」という表現は 2026 年時点では現状認識として正確とは言えません。
国別の普及率
国別に見ると、2026 年時点の普及率は以下のとおりです。
- フランス：約 86%
- インド：約 74%
- ドイツ：約 68%
- アメリカ：約 50%
- ブラジル・日本：約 50%
多くの主要国で IPv6 が既にメインのプロトコルとなっているか、それに近い水準にあることがわかります。
「25 年」という表現について
IPv6 の RFC 初版である RFC 1883 は 1995 年、現行仕様の RFC 2460 は 1998 年、最新版の RFC 8200 は 2017 年です。「25 年」という数値はどの起点を取るかで解釈が変わるため一概に誤りとは言えませんが、「長期間かけても定着していない」という含意を強調するためのレトリックとして用いられている印象があります。
実際の普及曲線を見ると、2014 年に 5%、2022 年に 40%、2026 年に約 50% と、近年は加速的に普及しているのが実態です。
結論： ドラフトの IPv6 批判は、2026 年時点のデータと整合しない部分があります。IPv6 の課題（デュアルスタックの運用コスト等）自体は実在しますが、「商業的に受け入れがたいことが証明された」という断定は、最新の普及状況と照らすと言い過ぎです。
ドラフトが提起している問題意識は的確か
ここまで技術仕様の多くが成立しないことを示しましたが、ドラフトが提起している問題意識そのものは、インフラエンジニアの視点で見ると共感できる部分も多く含まれています。公平を期すため、妥当な問題提起と成立しない解決策を切り分けて整理します。
ネットワーク管理の断片化
DHCP・DNS・NTP・syslog・SNMP・認証が独立したプロトコルとして発展してきた結果、共通の ID モデル・認証モデル・テレメトリフォーマットを持たないという指摘は、現場のインフラエンジニアの実感と一致します。
Zone Server による統合はコンセプトとしては理解できますが、既存の DHCP・DNS・NTP・syslog を全て新プロトコル（DHCP8・DNS8・NTP8・NetLog8）に置き換えるという実装規模の大きさから、現実的な移行パスを欠いています。
BGP ルート検証の欠如
「BGP4 には ASN が広告する権限を持つプレフィックスを検証する仕組みが存在しない」という指摘は、プレフィックスハイジャックの事例を考えると妥当です。
ただし、この問題に対しては既に RPKI（Resource Public Key Infrastructure） と ROA（Route Origin Authorization）という標準化された解決策が存在し、運用中です。ドラフトの WHOIS8 検証は、RPKI が既にカバーしている領域を別のアーキテクチャで再実装する提案となっており、既存の標準との関係性についてドラフト内では十分に整理されていません。
東西・南北トラフィックのセキュリティ
マルウェアが DNS 解決を介さずハードコードされた IP アドレスに C2 接続する問題や、ラテラルムーブメント防止の重要性は、実際のセキュリティインシデント対応でもよく扱われるテーマです。
ただし、これらは Zero Trust Network Access（ZTNA）・SASE・次世代ファイアウォールといった既存製品カテゴリで既に実装されている機能と重なる部分が大きく、プロトコル層で再定義する必要性は慎重に評価する必要があります。
インフラエンジニアが取るべき立場
話題性と技術的実現可能性を切り分ける
IPv8 ドラフトのように、「IPv6 の失敗を解決する」「100% 後方互換」といった魅力的な主張は、SNS やメディアで拡散されやすい性質を持ちます。一方で、魅力的な主張ほど、既存の制約との整合性を確認する必要性が高まります。
本記事で検証した 4 論点は、いずれも既存の RFC や実装資産との照合で矛盾が確認できました。これは「ドラフトの著者が不勉強である」という話ではなく、Internet-Draft という形式そのものが、査読を経ていない作業文書であることに起因するものです。
IETF プロセスの理解
RFC となる提案は、以下のような段階を経ます。
- Internet-Draft の提出（誰でも可能）
- Working Group での議論・合意形成
- IESG（Internet Engineering Steering Group）レビュー
- パブリックコメント
- IESG 承認
- RFC Editor による編集
- RFC として発行
個人提出の Internet-Draft は、この最初のステップにすら正式に入る前の段階です。IPv8 ドラフトは現時点で特定の WG に採択されておらず、「話題にはなっているが IETF の正規プロセスに乗っていない」状態とみるのが正確です。
情報発信時の責任
インフラエンジニアが技術ブログ・SNS・社内資料でこうした Internet-Draft を紹介する際は、「IETF で提案された新プロトコル」という表現を避け、「個人提出の Internet-Draft で提案されたアイデア」と正確に位置づけることが推奨されます。前者の表現は読者に誤った印象を与え、業界全体の情報品質を損なう可能性があります。
まとめ
draft-thain-ipv8-00は 2026 年 4 月に IETF に提出された個人提出の Internet-Draft であり、標準でも IETF 公認の提案でもない。127.0.0.0/8の内部ゾーン再利用は RFC 1122（STD 3）のループバック定義と正面衝突し、全 OS・全機器のスタック改修を伴うため「既存デバイス修正不要」とは両立しない。100.0.0.0/8の RINE 予約は RFC 6598（BCP 153）の CGNAT 共有空間と衝突し、ドラフト自身の「CGNAT 変更不要」要件とも内部矛盾を起こす。- IPv8 ヘッダは IPv4 より 8 バイト長いバイナリ非互換構造のため、「IPv4 は IPv8 の真部分集合」「100% 後方互換」の主張はパケット層で成立しない。
- IPv6 への「マイノリティ」批判は、2026 年 3 月 28 日に Google 統計で 50.1% に到達した現状と整合しない。
- ドラフトが提起する管理断片化・BGP 検証欠如・東西南北セキュリティの問題意識は妥当だが、RPKI・ZTNA・SASE 等の既存解との整理が不足している。
- インフラエンジニアが技術情報を発信する際は、「IETF で提案された新プロトコル」ではなく「個人提出の Internet-Draft」と正確に位置づけることが推奨される。
以上、最後までお読みいただきありがとうございました。
