こんばんは！
GMOコネクトの名もなきエンジニアです。
よろしくお願いします！
日刊IETFは、I-D AnnounceやIETF Announceに投稿されたメールをサマリーし続けるという修行的な活動です！！
今回は、2026-05-25（UTC基準）に公開されたInternet-DraftとRFCをまとめました（後編）。
- Internet-Draft: 13件（当日合計 33件）
- RFC: 0件（当日合計 0件）
参照先:
📌この記事でわかること
- Context Relay Protocolが、AIのコンテキスト品質やハルシネーションのリスクをHTTPヘッダでどう運ぶか
- RPAに基づくBGPのAS_PATH検証や、フィルタリングされたDNSの構造化エラーといった正当性の底上げ
- HPKEのJWE併用やTLS1.3でのFN-DSA交渉など、耐量子を見据えた暗号の動き
その日のサマリー & Hot Topics
- 後半もInternet-Draft中心で、AIとネットワークが交わる提案が目立ちました。Context Relay ProtocolはAIのコンテキスト品質やハルシネーションのリスクをHTTPヘッダに載せる語彙と中核仕様の二本立てで登場し、VICDMは検証可能なアイデンティティと委任のモデルを示しています。経路の安全性ではRPAに基づくAS_PATH検証が出てきました。トランスポートではNETCONF over QUICやRoCEv2の輻輳通知・負荷分散、暗号ではHPKEのJWE併用やTLS1.3でのFN-DSA交渉といった、移行を見据えた話題が並びました。
- 後半で気になったのは耐量子まわりの動きです。TLS1.3でFN-DSAを認証に使う交渉方法を定めるdraft-song-tls-fndsaが出て、格子系の署名を既存の拡張の枠組みにそのまま載せていく流れが見えました。あわせてJOSEのHPKEをJWEと組み合わせるdraft-ietf-jose-hpke-encryptもあり、暗号の移行を意識した設計が複数のレイヤで同時に進んでいます。RPAによるAS_PATH検証やフィルタDNSの構造化エラーなど、経路と名前解決の正当性を底上げする提案も光っていました。
投稿されたInternet-Draft
Categorical Settlement Attestation Format for Agentic-Payment Flows
エージェント決済フロー向けに、カテゴリ型の決済アテステーションフォーマットを定めるドラフトです。ある支払いが、特定のチェーン上で特定の時点に、アテストする側のリスクモデルのもとでどの決済状態に達したかを記録します。結果はSETTLED・PENDING_FINALITY・REVERSEDという閉じた列挙を使います。このカテゴリ型の結果は下流の規制義務にとって意味を持ち、SETTLEDはEUのMiCA第80条やアンチマネーロンダリング規制のもとでの決済ファイナリティの記録保持義務を引き起こすと説明されています。
Draft Link
NETCONF over QUIC
NETCONFのメッセージを交換する安全なトランスポートとしてQUICを使う方法を定めるドラフトです。NETCONF over QUICはQUICのストリームを活かして、例えばTCPのヘッドオブラインブロッキングの一部を解消できます。提供されるセキュリティ特性はNETCONF over TLSと同等です。あわせて、ietf-netconf-clientとietf-netconf-serverのYANGモジュールを拡張するYANGモジュールも定義しています。現時点ではプレースホルダの値を含んでおり、RFC化の際に確定値へ差し替える旨が編集上の注記として添えられた提案です。
Draft Link
BGP based SRv6 Routing Planes for DC network
現代のデータセンターネットワーク向けに、BGPに基づくマルチプレーンのルーティングアーキテクチャを紹介するドラフトです。トラフィックの分離が求められるAI/MLワークロードを動かす環境を特に念頭に置いています。集団通信やマルチテナンシといった特性を持つワークロードに決定的なルーティングを与え、共有された物理インフラの上に複数の論理ルーティングプレーンを作れるようにします。プレーンは、ファブリックカラーの包含・除外といった制約、最短経路などの計算種別、メトリック種別という3つの要素を組み合わせて定義される仕組みです。
Draft Link
Context Relay Protocol (CRP) -- HTTP Header Field Vocabulary
Context Relay Protocol（CRP）のHTTPヘッダフィールドの語彙をすべて定義するドラフトです。CRPのヘッダフィールドは、コンテキストの品質、安全性のリスク、来歴の完全性、規制上の分類、エージェントの状態、メモリ層の情報といったAI特有のメタデータを、AIのリクエスト・レスポンスのやり取りに標準のHTTPヘッダとして載せます。本仕様は6つの名前空間にまたがる58個のヘッダフィールドについて規範的な定義を与え、IANAのHTTP Field Name Registryへの暫定登録に適した形で示しています。AIトラフィックの可視化に向けた語彙集です。
Draft Link
Benchmarking Methodology for Computing-aware Traffic Steering
Computing-aware Traffic Steering（CATS）のベンチマーキング手法を提案するドラフトです。CATSは、コンピューティングとネットワークの両方の情報を踏まえてサービスリクエストを適切なサービスインスタンスへ誘導するトラフィックエンジニアリングの手法です。本ドラフトはそのCATSを対象としたベンチマーキングの方法論を示します。abstract自体は簡潔ですが、計算資源を考慮した経路誘導の性能をどう測るかという観点を扱い、評価のための共通の物差しを整える位置づけだと読み取れます。
Draft Link
Fast Congestion Notification Packet (CNP) in RoCEv2 Networks
RoCEv2ネットワーク向けの輻輳制御の仕組みを説明するドラフトで、RFC7514に記されたReally Explicit Congestion Notification（RECN）から着想を得たFast Congestion Notification Packet（Fast CNP）を扱います。RoCEv2のCNPを拡張することで、スイッチが送信元へ直接Fast CNPを送り、そのRoCEv2データトラフィックのフローを送り出す送信レートを下げるよう助言できるようにします。輻輳の合図をより速く送信元に届けることで、転送レートの調整を素早く促す狙いがあると読み取れます。
Draft Link
Verifiable Identity Claims and Delegation Model (VICDM)
アプリケーション層プロトコルでアイデンティティの主張を扱うための概念的な枠組みを定めるドラフトです。インターネット上ではアイデンティティを名乗ること自体は任意だが、いったん主張されたアイデンティティは必ず検証可能でなければならない、というモデルを導入します。さらに、第三者のインフラに検証可能で透明な形で自分の代わりに振る舞う権限を与える委任の仕組みも定めます。匿名や仮名でのやり取りの余地を完全に保ちつつ、なりすましを減らすことを目標とし、プロトコルそのものではなく原則を定義する文書だと述べています。
Draft Link
Context Relay Protocol (CRP) -- Core Specification
Context Relay Protocol（CRP）の中核仕様を定めるドラフトです。CRPは、運用中の大規模言語モデルシステムにおいて、AIのコンテキスト、安全性のガバナンス、コンプライアンスのエビデンスを管理する、言語に依存しない構造化されたプロトコルです。HTTP互換のサイドカープロトコルとして動き、AIのリクエスト・レスポンスのやり取りごとに、コンテキスト品質、ハルシネーションのリスク、来歴の完全性、規制上の分類といったメタデータを標準化されたヘッダで付加します。基盤となる公理、リクエスト・レスポンスモデル、サイドカー構成などを定義しています。
Draft Link
Use of Hybrid Public Key Encryption (HPKE) with JSON Web Encryption (JWE)
Hybrid Public Key Encryption（HPKE）をJSON Web Encryption（JWE）と組み合わせて使う方法を定義するドラフトです。HPKEは任意の長さの平文を受信者の公開鍵で公開鍵暗号化でき、適応的選択暗号文攻撃に対する安全性を備えています。本仕様はHPKEの機能のうち特定の部分集合を選んでJWEと併用します。あわせて、Integrated Encryptionを鍵管理モードとして使えるようにするためRFC7516（JWE）を更新します。JWEの枠組みにHPKEを取り込むための具体的な対応関係を整理する内容です。
Draft Link
Structured Error Data for Filtered DNS
フィルタリングされたDNS向けに構造化されたエラーデータを定めるドラフトです。DNSフィルタリングはネットワークセキュリティやポリシー適用などの理由で広く使われていますが、フィルタされた応答にはエンドユーザーが理由を理解するための構造化された情報がありません。説明を伝える既存の仕組みは、特にHTTPSリソースに対する応答がブロックされた場合に害を及ぼします。本ドラフトはRFC8914を更新し、Extended DNS ErrorのEXTRA-TEXTフィールドを構造化する対応をクライアントが合図できるようにして、表示やログ、利用に役立てます。
Draft Link
BGP AS_PATH Verification Based on Route Path Authorizations (RPA) Objects
Route Path Authorizations（RPA）オブジェクトに基づくBGPのAS_PATH検証手法を定めるドラフトです。RPAは、ある自律システムがBGPの経路伝播で従う経路の記述を証明するRPKIオブジェクトです。本ドラフトはRPAに基づくAS Path検証の方法論を示し、AS Pathの偽造や経路リークを緩和し、場合によっては解消することを狙います。あわせて、RPAが対処を助けるさまざまなBGPのセキュリティ脅威を説明し、RPAの導入に伴う運用上の考慮事項も提供しています。経路の正当性を経路情報から確かめる枠組みです。
Draft Link
A RoCEv2 Flow-Level Load Balancing Method Based on the IPv6 Flow Label
RoCEv2ネットワークでフロー単位の負荷分散を実現する方法を提案するドラフトです。5タプルに基づく従来のフロー単位の負荷分散では、同じ5タプルを共有する別々のRDMAセッションを区別できず、いわゆるエレファントフローが同じ経路にハッシュされて輻輳を招きます。本手法はRoCEv2パケットのIB BTHやIB DETHヘッダからキューペア（QP）の情報を解析し、それをIPv6のフローラベルの一部と組み合わせることで、この問題を解決します。同じ5タプルでも異なるRDMAセッションを見分け、経路を散らすための仕組みです。
Draft Link
Use of FN-DSA in TLS 1.3
TLS1.3でFN-DSAを認証に使うための交渉方法を定めるドラフトです。signature_algorithmsおよびsignature_algorithms_certの拡張を通じて、TLS1.3の認証にFN-DSAを選べるようにする方法を規定しています。abstract自体は簡潔ですが、格子に基づく署名方式であるFN-DSAをTLSのハンドシェイクで扱えるようにすることを目的としており、耐量子の署名を既存のTLS1.3の交渉の枠組みに自然に組み込むための具体的な手順を示す内容だと読み取れます。
Draft Link
発行されたRFC
この日に発行されたRFCはありませんでした。
編集後記
- 後半はAIのトラフィックを正面から扱う提案が増えていて、Context Relay Protocolがハルシネーションのリスクや来歴の完全性をHTTPヘッダにそのまま書き込んでしまうという発想には、思わず唸ってしまいました。AIの振る舞いをネットワークの可視化の対象として捉え直していく動きと、TLSへ格子系の署名を持ち込む耐量子の流れが同じ一日のうちに並んでいるのを見ると、私たちの足元を支えているインフラが静かに、でも確実に作り替えられている最中なんだなと、なんだか一人で胸が高鳴ってしまいました。
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。