こんばんは！
GMOコネクトの名もなきエンジニアです。
よろしくお願いします！
日刊IETFは、I-D AnnounceやIETF Announceに投稿されたメールをサマリーし続けるという修行的な活動です！！
今回は、2026-04-28（UTC基準）に公開されたInternet-DraftとRFCをまとめました。
- Internet-Draft: 26件
- RFC: 1件
参照先:
📌 その日のサマリー & Hot Topics
- 2026年4月28日付の更新は、合計で27件と多めの内容になりました。Part 1では20件のInternet-Draftを取り上げます。AIエージェントの権限委譲や発見、推論ルーティング、AIによるコンテンツ利用許諾といった話題が並び、合わせてSSHへのML-DSA組み込みやTCP-AO、RSVP、RADIUSのレビューといった暗号と認証まわりの動きも目立ちます。pNFSのFlexible Files v2やDNS、メールヘッダの更新も含まれており、IETFが扱う守備範囲の広さが伝わってきます。
- 注目したいのは、AIエージェントを支える基盤側の動きです。Reilly Model Routing Protocolは複数AIモデルへの推論振り分けをポリシー駆動で行う枠組み、Delegation Receipt ProtocolはAIエージェントへの権限委譲を利用者の鍵だけで成立させる暗号プリミティブで、どちらも自律エージェント時代の責任所在を技術で支える試みです。SSHにML-DSAとEd25519のComposite署名を導入する提案や、TCP-AOへの強い暗号アルゴリズム追加も、PQCと運用の現実をすり合わせる動きとして見逃せません。
投稿されたInternet-Draft
Reilly Model Routing Protocol (RMRP): A Framework for Policy-Governed, Auditable AI Model Routing
複数のAIモデルが混在する環境で、推論リクエストをどのモデルへ振り分けるかをポリシーで制御し、その判断を後から監査できるようにする枠組みを定義しています。ルーティング方針の宣言方法、実行時の意味論、監査証跡の要件、コスト按分の仕組みを揃えて規定し、誰がいつどの基準で振り分けたかを後追いできる構造です。特定のAIプロバイダや推論ランタイム、ベンダ実装、トランスポートに依存しないのが設計上の特徴で、組織規模のマルチモデル運用に必要なプロトコル層の空白を埋めることを狙っています。複数ベンダのモデルを束ねて使う流れに合わせた地盤づくりです。
Draft Link
Delegation Receipt Protocol for AI Agent Authorization
AIエージェントの権限委譲を、利用者の秘密鍵だけで成立させるための暗号プリミティブDRPです。エージェントが動き出す前に、利用者がスコープ範囲、有効期間、オペレータ指示のハッシュ、モデル状態のコミットメントを含む認可オブジェクトに署名します。署名済みのレシートは追記専用ログに公開されてからエージェントランタイムが制御を受け取る流れです。提案の狙いはオペレータを信頼すべき第三者の枠から外し、委譲記録への署名権限を利用者だけに集約することで、不正な権限拡大を構造的に塞ぐ点にあります。エージェント運用の責任所在をはっきりさせる方向の提案です。
Draft Link
Requirements for the Discovery of Agents, Workloads, and Named Entities (DAWN)
AIエージェントやクラウドワークロード、各種ネットワークサービスといった分散したエンティティを、組織やネットワークの境界を越えて見つけ合うための要件を整理しました。やり取りを始める前に必要となる識別、属性、信頼の手がかりは何か、分散環境ならではの制約をどう吸収するかを掘り下げます。具体的な発見プロトコルは規定せず、後続の方式選定や設計判断の土台として使えるよう要件側を切り出した位置づけです。AIエージェント時代の発見メカニズムをIETFがどう受け止めるかを示す、議論の起点として注目しています。後続標準化の方向性を左右する文書になりそうです。
Draft Link
Agentic Reasoning Protocol (ARP) Version 2.0
ブランドや組織、個人が自己表明するコンテキストや事実訂正、専門性、推奨範囲を、AIエージェントやRAG基盤に直接届けるためのプロトコルです。v2.0では静的ファイル中心だったv1系を拡張し、REST API、双方向フィードバック、複数当事者の暗号アテステーション、W3C DID、A2A信頼ハンドシェイク、Server-Sent Eventsによる鮮度配信、国際化対応を取り込んでいます。robots.txtやschema.orgを補完しつつ、推論挙動を直接対象にする発想で、コンテンツ側の意思表示をエージェント側に確実に届ける道筋を整えます。
Draft Link
Problems Statement and Requirements Analysis of DNS for Internet of Agents (IoA)
AI主導の時代に向け、Internet of AgentsすなわちIoAでのエージェント連携を支えるためにDNSが何を備えるべきかを論じます。エージェントが多数集まって協調する環境で生じる名前解決の課題、識別と発見の関係、信頼境界の置き方を取り上げ、現行DNSが直面する制約を切り分けました。具体的な技術仕様の手前で、要件として何が必要かを共有することで、後続の方式比較や設計議論の出発点にする狙いです。エージェント発見のために新しい階層を持ち込むのか、既存DNSで吸収するのかという根源的な論点も浮かび上がります。
Draft Link
A Vocabulary For Expressing AI Usage Preferences
ウェブ上のデジタル資産が自動処理システムによって使われる際の許諾や制限を、機械可読に表明するための語彙を定義します。コンテンツ提供者は、学習や推論など処理の種類ごとに条件を細かく宣言でき、AI側はそれを読み取って遵守判断につなげられる構造です。robots.txt系の既存慣習を補完しつつ、AI利用の前提でゼロから組み立てられた点が特徴で、出版社やクリエイタが意思表示する手段として活用が見込まれます。法的拘束ではなく技術慣行として動かす方向性が、現実的な落とし所を探る上で興味深い試みで、利害関係者の合意形成も手探りで進んでいる印象です。
Draft Link
ML-DSA 65/Ed255192 Composite Signatures in SSH
SSHプロトコルにML-DSA-65とEd25519を組み合わせたComposite署名方式MLDSA65-Ed25519-SHA512を組み込む手順を定めています。格子ベースの耐量子計算機署名と古典的な楕円曲線Ed25519を併用することで、量子時代と従来型の双方の脅威モデルに同時に備える狙いです。SSHのホスト鍵やユーザ鍵での識別子、署名フォーマット、検証手続きを規定し、移行期に既存の運用へ無理なく組み込めるようにしました。OpenSSHを開発するDamien Miller氏自身による提案で、実装側からの視点が強く出ている点も興味深いです。
Draft Link
Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants
OAuth 2.0クライアント表明認証と表明ベースの認可付与で扱うaudience値の取り扱いを見直す改訂です。RFC7521、RFC7522、RFC7523、RFC9126にまたがって既存の要件に存在した脆弱性を解消するため、aud値の検証手続きを統一して曖昧さを取り除きます。JWTアサーションを発行する側と検証する側の双方に影響するため、認可サーバや連携基盤を運用するチームは早めの確認をおすすめしたい改訂です。Bisドラフトとして仕様の本流に組み込まれる流れに乗っており、影響範囲の広さからも注目に値します。
Draft Link
RSVP Cryptographic Authentication with HMAC-SHA2
RSVPの暗号認証バージョン2において、NIST Secure Hash StandardをHMACモードで利用する方法を定めます。HMAC-SHA-256やSHA-384などを認証アルゴリズムとして使えるよう手続きと識別子を整理し、RSVP-TEを含むMPLS環境でホップごとの完全性と認証を強化することを意図しています。同伴文書のdraft-ietf-teas-rsvp-auth-v2と組み合わせて、RFC2747とRFC3097を置き換える位置づけで、長年使われてきたRSVPセキュリティの土台を現代の暗号要件に合わせて刷新します。
Draft Link
RSVP Cryptographic Authentication, Version 2
RSVPメッセージのホップごとの完全性と認証を担うINTEGRITYオブジェクトについて、特定の暗号アルゴリズムに依存しない形で形式と使用法を定め直します。RSVP-TEを使うMPLS展開で広く利用されてきた仕組みを土台にしつつ、最新の認証要件に合うよう手続きを整理しました。RFC2747とRFC3097の双方を置き換える位置づけで、HMAC系アルゴリズム拡張と組み合わせて運用品質を底上げする狙いです。長期運用されてきたMPLS基盤に対し、認証層を入れ替える地ならしという意味でも価値があります。
Draft Link
A Review of RADIUS Security and Privacy
RADIUSプロトコルに関するセキュリティ課題を網羅的に振り返るレビューです。古くから使われてきた認証認可の仕組みが抱える前提と弱点を整理し、後続のdraft-ietf-radext-deprecating-radiusで提案されるRADIUSセキュリティ強化の根拠を示します。共有鍵運用の脆さや、過去にCVEとして報告された攻撃パターン、UDPトランスポートの限界などの位置づけを再確認できる文書で、運用継続を判断する上での材料になります。BlastRADIUSなど近年の話題も含め、現実的な対処を考える上での出発点として目を通しておきたい内容です。
Draft Link
Integration of Remote Attestation with Key Negotiation and Key Distribution mechanisms
リモートアテステーションを鍵交換や鍵配送と組み合わせ、検証済みでポリシーに合致した環境にだけ暗号鍵を渡したり受け入れたりする仕組みを示します。既存のセキュアチャネルや鍵管理プロトコルの上に被せる構造で、公開クラウドのKMS、エンドユーザとAIデータセンタ間の通信、企業運用のKMSという代表的な3シナリオで使い方を例示しました。証明を行うデバイス（Attester）の環境、公開鍵、セッション識別子の結びつきをフォーマット非依存に表現し、Relying PartyがAttestation Resultsを判断材料に組み込めるようにします。
Draft Link
Safe and Reversible Sharing of Malicious URLs and Indicators
脅威インテリジェンスやセキュリティの現場で広く使われてきた、悪性URL、IP、メールアドレス、ドメインを安全かつ可逆に共有するための約束ごとを文書化しました。URIスキーム名を角括弧で囲んでURIパーサが直接解釈しないようにし、IPv6リテラル中のコロンや、Path、Query、Fragment内に隠れた指標も同じ流儀で難読化します。誤って実行されるリスクを抑えつつ、ツール間で復元できる相互運用性を担保する点が眼目です。CTIフィードを跨いだ運用慣行を成文化することで、解析者の事故防止と自動化の両立を狙えます。
Draft Link
Additional Security Algorithms For Use With TCP-AO
TCP Authentication OptionすなわちTCP-AOで使える暗号アルゴリズムをRFC5926から強化する更新です。これまではKDFとしてKDF_HMAC_SHA1とKDF_AES_128_CMAC、MACとしてHMAC-SHA-1-96とAES-128-CMAC-96を使う想定でしたが、本書はSHA-256以上を含むより強い候補を加えます。BGPなどTCP-AOで保護されている長期セッションを、現代的な暗号強度で運用し続けるための土台を整える位置づけです。SHA-1の使用が縮小されていく流れを踏まえ、運用継続のための置き換え経路を仕様側で先に整える内容です。
Draft Link
In-Band SCONE Reporting over QUIC
SCONEプロトコルでは、受信側が帯域推定を送信側へ返す経路がアプリケーション層に委ねられていました。本ドラフトはQUIC層でSCONEパケットを受信できる一方でアプリ側が未対応というケースを想定し、受信したSCONEパケットの内容をそのまま報告する新しいQUICフレームを追加します。SCONEネットワーク要素とのやり取りには変更を加えず、QUIC側だけで完結する報告経路を確保するのが狙いで、対応のばらつきを吸収できる実装現実的な提案です。アプリ実装の歩調が揃わなくてもSCONEを使い始められる利点があります。
Draft Link
DNS Root Server System Usage Considerations
DNSの拡張に使われるさまざまな技術が、DNSルートサーバシステムRSSとの通信にどう影響するかを整理した文書です。プロトコルごとの挙動を取り上げ、RSSへの問い合わせパターンや負荷の生まれ方、運用上の前提が揃っているかを評価していきます。ルートサーバ運用者と新しいDNS技術を提案する側の双方が、設計初期に意識すべき接点と注意点を共有するための土台になる位置づけです。Wes HardakerとWarren Kumariという長年DNS運用に関わってきた二人の手によるもので、実情への目配りが行き届いた内容に仕上がっています。
Draft Link
EDNS options for filtering information
DNS応答がフィルタリングや遮断、検閲を受けた事実を返すためのEDNSオプションと手続きを定めた覚え書きです。RFC8914のExtended DNS Errorオプションを補い、より細かな状況伝達を可能にします。検閲やマルウェア対策、コンテンツ規制で応答が改変されたことを利用者側のリゾルバや運用者が把握できるようになり、可観測性の確保や誤検知の切り分けに役立ちます。透明性向上を目的とした実用寄りの拡張で、利用者が見ている世界とリゾルバが返している世界の差を可視化する手段を提供します。原因の所在を切り分けやすくする実務的な工夫です。
Draft Link
Updated Use of the Expires Message Header Field
メール本文に付与されるExpiresヘッダの活用範囲を広げる更新です。送信者がメッセージの有効期限を明示できるようになり、受信側はその情報をもとに期限切れメッセージの扱いを変えられます。情報密度が高い通知や時間限定の連絡に向き、保管ポリシーや表示の優先順位制御と組み合わせて運用できる仕組みです。既存実装との互換性に配慮した範囲拡張で、メール基盤の運用品質を底上げする位置づけです。MUAやMTAが期限切れメッセージをどう扱うかの裁量を残しつつ、明示的なヒントを供給する形になっており、運用ポリシーの自由度を保ちます。
Draft Link
Parallel NFS (pNFS) Flexible File Layout Version 2
並列NFSであるpNFSのレイアウトタイプとしてFlexible File Layout Version 2を新たに定義します。メタデータサーバとデータが置かれるストレージ装置の連携を最小限に保ちつつ、既存プロトコルでデータアクセスできる柔軟性が特徴です。データ保護では、クライアント側ミラーリングと消失訂正符号を使った冗長化を組み合わせ、整合性確保のための仕組みも追加しています。スケールするpNFS環境での実装の幅を広げる更新で、ストレージ装置の選択肢を増やしながら可用性も底上げできる方向に踏み込んだ内容です。
Draft Link
Proxy-Driven Server for Flexible Files Version 2
Flexible Files v2のpNFS構成に、登録済みのプロキシサーバという役割を追加する拡張です。プロキシはメタデータサーバを定期的にポーリングして作業割り当てを取りに行き、レイアウト変換や消失したシャードからの全体再構築、NFSv3クライアント向けのコーデック変換などを担当します。コールバックを使わずフォアチャネルの応答だけで指示と完了報告をやり取りする設計のため、既存のNFSデプロイにも組み込みやすい構造になっています。クライアント能力の差を吸収しつつ、ストレージ運用の自動化を一段押し進めるための枠組みです。
Draft Link
発行されたRFC
この日に新規に発行されたRFCはありませんでした。
編集後記
- 4月末は連休前の駆け込みなのか、新規ドラフトと改訂が入り混じって賑やかになった印象で、AIエージェントを支える層がここまで具体的に提案として並ぶ景色は、ほんの数年前には想像していなかった姿だなと感慨にふけりながらまとめていました。暗号まわりではPQCへの段階的移行の地ならしが続いていて、現場で動いているSSHやTCP-AO、RSVPに新しい候補を埋め込む流れも見えており、今日も次のRFCに繋がる種をひとつでも丁寧に読み解いていきたい、そんな気持ちで一日のドラフトと向き合っていきたいなと改めて思いました。
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。