こんにちは！！
GMOコネクトの名もなきエンジニアです。
よろしくお願いします！

日刊IETFは、I-D AnnounceやIETF Announceに投稿されたメールをサマリーし続けるという修行的な活動です！！
今回は、2026-06-19（UTC基準）に公開されたInternet-DraftとRFCをまとめました。

Internet-Draft: 27件
RFC: 3件

件数が多いため2本に分けてお届けしており、この後編ではInternet-Draftの21件目から27件目と、発行されたRFC 3件を紹介します。1件目から20件目は前編をご覧ください。

参照先:

その日のサマリー & Hot Topics

後編で扱う10件は、ルーティングのセキュリティと運用管理、そしてBFD認証まわりが中心です。前編のSource-Selective BGPフレームワークと対になるASPAプロファイルがWG文書として熟成を進め、DNSエラーのTTL付与やGRASPの課題整理、IPFIXへのGTP-U情報の追加といった運用寄りの提案も並びました。RFCは3本発行され、うち2本がBFD認証の負荷を下げる工夫、1本が帯域外STIRをサービスプロバイダ向けに広げる内容です。
この日のRFCの主役はBFD認証の軽量化です。すべての制御パケットに同じ認証をかけると性能に響くという現実に対し、RFC 9985は計算量の重い認証と軽い認証を状況に応じて使い分ける最適化を、RFC 9986はISAACを使ってCPU時間を抑える認証モードを定めました。トレードオフを正直に示しながら、認証を現実的に回すための選択肢を増やしています。ルーティング基盤の地味だけれど大切な足回りが整った一日です。

投稿されたInternet-Draft

A Profile for Autonomous System Provider Authorization

RPKIで使うASPAオブジェクトの、CMSで保護されたコンテンツタイプを定義するWG文書です。ASPAは、AS識別子の保持者である発行者が、ほかの一つ以上のASを自分のトランジットプロバイダとして認可するデジタル署名付きのオブジェクトです。検証されたASPAのeContentは、経路リークの検出と緩和に使えます。前編で紹介したSource-Selective BGPが送信元の認可を扱うのに対し、こちらはASの上下関係を認可することで経路リークに立ち向かう、RPKI応用の主力の一つです。著名な著者陣が名を連ね、-27版まで議論が積み重なっています。
Draft Link

Add TTLs to DNS errors

DNSサーバがNXDOMAIN以外のエラーを返すとき、そのエラーを受信側がどれだけキャッシュしてよいかを指定する仕組みが今は無い、という課題に向き合う初版ドラフトです。この提案では、サーバが応答の追加セクションにSOAレコードを加えることで、エラーのTTLを指定できるようにします。クライアントはこのTTLを裁量で使え、最大値で頭打ちにする、最小値を課す、あるいは無視する、といった扱いができます。エラー応答の再問い合わせが無用に増えるのを抑えられる、実務感覚に根ざした素朴で効きそうな提案です。
Draft Link

GRASP through routers: a Problem Statement

自律的なシグナリングを担うGRASPを、ルータなどのネットワーク要素自身にGRASPの対応を求めずに、サーバや仮想マシンといった機器の上でサービスを展開する文脈で使うときの課題を分析する初版ドラフトです。サブネットをまたいだ発見や、管理境界をまたいだ動作など、発見の仕組みにまつわる論点を洗い出し、今後の拡張やプロファイル、アーキテクチャの精緻化に向けた用語と一般的な考慮事項を提供します。まず問題を丁寧に定義してから解決に進むという、IETFらしい段取りのProblem Statementです。
Draft Link

Export of GTP-U Information in IP Flow Information Export (IPFIX)

GTPのユーザープレーンヘッダに含まれる情報を、IPFIXで報告するための情報要素を導入するWG文書です。トンネルエンドポイント識別子や、そのセッションコンテナ拡張ヘッダに含まれるデータなどを対象にします。モバイル網ではGTP-Uでユーザートラフィックが運ばれるため、フローの計測や分析でトンネルの識別子まで見えるようになると、加入者単位やセッション単位の可視化がぐっとやりやすくなります。5Gや4Gのコア網を運用する現場にとって、トラフィック分析の解像度を上げる実用的な整備で、-13版まで進んでいます。
Draft Link

Guidelines for Writing an IANA Considerations Section in RFCs

プロトコルが使う各種のパラメータを、衝突なく相互運用できるように割り当てるための、IANA Considerationsセクションの書き方の枠組みを定義する文書です。IETFのプロトコルでは、この記録係の役割をIANAが担います。あるレジストリで賢く割り当てを行うには、どんな条件で新しい値を割り当てるべきか、既存の値の変更をいつどう行えるかといった指針が必要です。この文書は仕様の著者がそうした指針を書くための枠組みを定め、レジストリ運用で起きがちな論点に漏れなく答えられるようにします。RFC 8126を置き換える第4版で、-02版です。
Draft Link

Agent Attribution Header Fields

人間の利用者が自律的なコンピュータエージェントとやり取りするとき、その通信がエージェント由来であることを見分け、どの人間がそのエージェントに責任を持つのかを知れるようにするための、メールヘッダフィールドを定義する初版ドラフトです。一つ目のヘッダは人間が読める形で、エージェントに責任を持つ人間のメールアドレスを示します。二つ目のヘッダは機械可読で、帰属情報をJSONで表します。メールの世界にもエージェントの送信主体をどう明示するかという問いが届き始めており、責任の所在をたどれるようにする発想が印象的です。
Draft Link

New Pure Post-Quantum Protocol Specification

純粋なPQCのメカニズムでシステムを保護し、将来的な完全なPQC移行につなげることを目的とした、Abdelaziz Pure Key ProtocolことAPKPの仕様を提案する初版ドラフトです。量子攻撃から守りたい高セキュリティ環境での利用を想定しています。注目すべきは、この文書がdraft-muhammad-apkp-pqcprotocolとdraft-muhammad-ahkp-pqcprotocolを置き換えて統合すると明記している点で、前日に紹介したAPKPの後継にあたります。提案をpquipの文脈に整理し直した格好で、ピュアなPQCを掲げる構想が版を追って形を変えながら続いている様子がうかがえます。
Draft Link

発行されたRFC

Meticulous Keyed ISAAC for Bidirectional Forwarding Detection (BFD) Optimized Authentication

BFDの最適化認証モードのひとつ、Meticulous Keyed ISAAC認証を記述するRFCです。このモードは、MD5やSHA-1を使うよりも少ないCPU時間で一部のBFDパケットを認証できますが、その代わりに安全性は下がるというトレードオフがあります。状態変化を伝えることには使えませんが、セッションをUpの状態に保つのには使えます。すべてのパケットに強い認証をかけるのは重い、という現場の悩みに対して、守りたいところと軽くしたいところを切り分ける現実解を用意した一本で、次に紹介する最適化認証のRFCと合わせて読むと狙いがよく分かります。
Draft Link

Optimizing Bidirectional Forwarding Detection (BFD) Authentication

BFD認証に対する実験的な最適化を記述するRFCです。すべてのBFD制御パケットに同じ認証をかけると性能に悪影響が出かねない場面でも、認証を使いたいという要望に応え、BFDがうまくスケールするようにします。具体的には、BFDの重要な変化に適用する計算量の重い仕組みと、大多数の制御パケットに適用する計算量の軽い仕組みに、認証を分割します。重要な瞬間だけしっかり守り、平常時は軽く回すという発想で、先ほどのISAAC認証とともに、BFD認証を実運用で無理なく使うための選択肢を広げる内容です。
Draft Link

Out-of-Band Secure Telephone Identity Revisited (STIR) for Service Providers

STIRの枠組みは、そのPASSporTを、SIPリクエストのヘッダに入れて運ぶインバンドの方法と、PASSporTを保管して依拠当事者が取り出せるようにするサービスを通じたアウトオブバンドの方法の、両方を定めています。このRFCは、インバンドのSTIRが必ずしも普及していない場面で、大規模なサービスプロバイダを支えるために、アウトオブバンドでのPASSporTの運搬をどう使えるようにするかを定義します。なりすまし電話対策として広がるSTIRを、現実の相互接続環境でも機能させるための一本で、通信事業者にとって実務的な意味の大きいRFCです。
Draft Link

編集後記

BFD認証の2本を読みながら、強い認証をどこにかけ、どこで軽くするかという線引きの話に、運用の知恵が詰まっているなとしみじみ感じました。安全性を落とすというトレードオフを隠さずに書ききる姿勢も、いかにもIETFらしくて好きです。2日続けてエージェント関連の提案を追ってきましたが、みなさんの現場ではエージェントの認証や証跡の話はもう出てきていますか、よければコメントで教えてください。前編ともども、お付き合いありがとうございました。

最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。

お問合せ: https://gmo-connect.jp/contactus/