こんばんは！
GMOコネクトの名もなきエンジニアです。
よろしくお願いします！
日刊IETFは、I-D AnnounceやIETF Announceに投稿されたメールをサマリーし続けるという修行的な活動です！！
「IPv6の拡張ヘッダー、実は使えない問題」に悩んでいませんか？
本日2025-12-26は、インターネット基盤技術の根幹を揺るがす提案が登場しました。IPv6拡張ヘッダーの原則廃止を求める draft と、IPv4アドレスを256倍に拡張する EzIP という、真逆のアプローチで現実の課題に挑む2大提案が同時投稿されています。
この記事でわかること：
- IPv6拡張ヘッダーがなぜ廃止されるべきなのか（セキュリティと廃棄率の実態）
- IPv4アドレス枯渇問題への現実的な解決策 EzIP の仕組み
- 分散コンピューティング時代のトラフィック制御の最前線（CATS & ARN）
今回は、2025-12-26（UTC基準）に公開されたInternet-DraftとRFCをまとめました。
- Internet-Draft: 6件
- RFC: 0件
参照先:
その日のサマリー & Hot Topics
年末を控えた本日は、ネットワークアーキテクチャの根幹に関わる提案が6件投稿されました。IPv6拡張ヘッダーの廃止提案やIPv4アドレス空間拡張という、インターネットの基盤技術を見直す大胆な提案が並びます。また、分散コンピューティング環境におけるトラフィック制御や、アプリケーション主導のネットワーク制御といった、次世代インフラの設計思想を示す文書も登場しました。L4Sサービスの監視やWebhook配信の標準化など、運用面を強化する提案も含まれ、理論と実践のバランスが取れた投稿内容となっています。
特に注目すべきは、IPv6拡張ヘッダーを原則廃止すべきとする draft-herbert-deprecate-eh と、IPv4アドレスを256倍に拡張する EzIP 提案の draft-chen-ati-adaptive-ipv4-address-space です。前者はセキュリティとパケット廃棄率の高さから ESP 以外の拡張ヘッダーを限定ドメイン内のみで使用すべきと主張し、後者は IPv4 Option を活用して既存インターネットに影響を与えずアドレス空間を拡張できると提案しています。どちらも現行プロトコルの課題に正面から向き合った内容で、今後の議論が楽しみです。
投稿されたInternet-Draft
Deprecating IPv6 Extension Headers on the Internet
ESP（Encapsulating Security Payload）を除くIPv6拡張ヘッダーをインターネット上で非推奨とする提案です。廃止の根拠は3点：インターネット経由の拡張ヘッダー付きパケットの高廃棄率、DoS攻撃への悪用可能性とセキュリティ脆弱性の多さ、そして高損失率が新しい拡張ヘッダー開発の阻害要因になっている点です。本ドラフトでは、ESP以外の拡張ヘッダーは限定ドメイン内のみで使用し、限定ドメインの境界ルーターで拡張ヘッダー付きパケットを廃棄すべきと推奨しています。実運用データに基づいた現実的なアプローチといえます。
Adaptive IPv4 Address Space
EzIP（Easy IPv4）と名付けられた、既存のIPv4 Optionメカニズムを用いたアドレス空間拡張ソリューションです。IPv4アドレスを最大256倍に拡張でき、既存のIPv4インターネットやプライベートネットワークに影響を与えません。IPv4プロトコルに完全準拠し、直接接続とプライベートネットワーク接続の両方をサポートします。ソフトウェアやファームウェア更新として導入可能で、キャッシュプロキシ技術を組み込めば1つのIPv4アドレスで広域をカバーできます。IPv4アドレス不足を即座に解決しつつ、IPv6の成熟を待つ時間的猶予を与える過渡的ソリューションです。
Export of L4S ECN in IP Flow Information Export (IPFIX)
L4S（Low Latency, Low Loss, and Scalable throughput）サービスを監視するための、IPFIX（IP Flow Information Export）情報要素のセットを定義します。これらの要素により、ネットワークオペレーターはL4S展開のECN（Explicit Congestion Notification）情報とトラフィックのパフォーマンスを監視できるようになります。低遅延・低損失を実現するL4Sの運用状況を可視化し、適切な品質管理を支援する仕組みです。L4Sは次世代の輻輳制御として注目されており、本提案はその実運用を支える重要な監視基盤となります。
Event and Webhook Delivery Semantics
イベントやWebhookベースの統合は、インターネットサービス間の相互運用でよく使われるアプリケーション層メカニズムですが、共有された配信セマンティクス契約が欠如しています。既存実装はリトライ動作、確認応答シグナリング、失敗分類、冪等性識別子、リプレイ処理で大きく異なり、脆弱な統合と曖昧な運用上の期待を生んでいます。本ドラフトは、既存トランスポート（主にHTTP）上でイベントとWebhook配信のための最小限のアプリケーション層配信セマンティクスプロファイルを定義します。統一的な配信保証の仕組みにより、システム間連携の信頼性向上を目指します。
Computing-Aware Traffic Steering (CATS) Problem Statement, Use Cases, and Requirements
分散コンピューティング環境において、サービス応答時間の改善とエネルギー消費の最適化を実現するための「Computing-Aware Traffic Steering（CATS）」の課題、ユースケース、要件を定義します。計算集約型で遅延に敏感なサービスは、様々なコンピューティング施設のリソースを活用することで改善できます。サーバーとネットワークリソースの選択では、単純な静的ディスパッチや接続性メトリクスだけでなく、コンピューティング能力とリソースを指向したメトリクスを考慮すべきです。本文書は、適切なコンピューティングリソースへトラフィックを誘導する際に、より多くの要因を考慮する必要性を示し、次世代インフラの方向性を提示しています。
Application-Responsive Network Framework
SRv6やネットワークスライシングといった先進技術の大規模展開に伴い、これらの新機能をアプリケーションに公開する必要性が高まっています。現在の実践では、ACLでパケットを分類し適切なネットワークリソースにマッピングしていますが、この方式ではアプリケーションがネットワークから受動的に認識されるのみで、能動的なインターフェースがありません。また、アプリケーション特性の変化がネットワーク設定調整を必要とするため、大規模展開が困難です。本ドラフトは、ARN ID により多くのネットワーク機能をカプセル化し、アプリケーションへのインターフェースを開放する Application Responsive Network（ARN）という新しいフレームワークを提案します。アプリケーションがOSにアクセスするようにネットワークリソースへアクセスできるようにすることを目指しています。
発行されたRFC
本日のRFC発行はありませんでした。
編集後記
年の瀬にふさわしい、インターネット基盤技術の大胆な見直し提案が集まった一日でした。IPv6拡張ヘッダーの廃止提案を見て、「理想の設計が現実の運用で通用しない瞬間」に立ち会っている感覚があります。仕様書では素晴らしい機能なのに、実際のインターネットでは高廃棄率とセキュリティ懸念で使えないという現実は、私たちエンジニアが日々直面する「仕様と実装のギャップ」そのものですね。一方、EzIP提案のようにIPv4 Optionという初期設計の柔軟性を活かした発想は目からウロコでした。
分散コンピューティングとネットワーク制御の融合を目指すCATSとARNの2件も、クラウドネイティブ時代のインフラ設計思想を体現しています。「アプリがOSにアクセスするようにネットワークを使う」というARNのビジョンは、まさに次世代インターネットの方向性です。個人的には、このアプローチが主流になるとネットワークエンジニアの役割も大きく変わりそうで、ワクワクしつつちょっと不安もあります。2025年も残りわずかですが、来年もこうした刺激的な提案に出会えることを楽しみにしています！
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。