こんばんは！！！
GMOコネクトの名もなきエンジニアです。
よろしくお願いします！
日刊IETFは、I-D AnnounceやIETF Announceに投稿されたメールをサマリーし続けるという修行的な活動です！！
今回は、2026-06-24（UTC基準）に公開されたInternet-DraftとRFCをまとめました。
- Internet-Draft: 本Part19件（本日のInternet-Draft合計59件）
- RFC: 本Part0件（本日のRFC合計0件）
参照先:
その日のサマリー & Hot Topics
- 2026年6月24日分の終盤は、オーバーレイとトランスポートの入れ替えが目立ちました。VXLANがRFC 7348を廃止してIETFの文書ストリームへ移り、ヘッダーへの追加を伴う拡張とIANA登録の道が開かれます。EPPとIPFIXがそれぞれQUICの上へ載る提案も並びました。イーサネットをIPv6のバックボーンへ重ねるME6E系のシリーズ、分散型の名前付けと所有権を目指すKineticの二本、GAAPによる軽量なマルチキャストのグループアドレス割り当てなど、足元を支える基盤寄りの提案が幅広く揃っています。
- 注目はVXLANの扱いが変わる点です。RFC 7348はすでに広く配備されていたVXLANを、インターネットコミュニティのために記録として残した文書でしたが、今回の改訂はそれを廃止し、仕様そのものをIETFの文書ストリームへ移します。狙いはVXLANヘッダーへの追加を伴う拡張を作れるようにし、あわせてIANAへ登録できる道を用意することです。形式と処理はRFC 7348と完全に互換のまま、拡張の受け皿だけを静かに整えるという進め方になっており、既存の実装を一切壊さないための配慮がよく効いています。
投稿されたInternet-Draft
Multi-Stage Transparent Server Load Balancing
クライアントとサーバーの間でパケットヘッダーを変えずに、レイヤー3ネットワークを越えてサーバーの負荷分散を行う手法として、Multi-Stage Transparent Server Load Balancing、略称MSLBの仕様を定める文書です。対象とするプロトコルを選ばない汎用性が特徴で、IPsec ESPやSSL/TLSのように通信そのものを暗号化するプロトコルであっても、ヘッダーを書き換えずに負荷分散の仕組みへ乗せられます。暗号化された通信経路を保ったまま負荷分散の層を挟み込める点が、実装上の利点になりそうです。
Draft Link
Multiple Ethernet - IPv6 address mapping encapsulation - prefix resolution
IPv6のバックボーン網の上にイーサネット網を拡張して重ね、複数のイーサネット網を積み上げて運べるようにする仕組みが、Multiple Ethernet - IPv6 address mapping encapsulation - Prefix Resolution、通称ME6E-PRです。カプセル化によってイーサネットフレームをIPv6の中へ収め、宛先を解決する仕組みを備える点が核であり、自分の管理下にないルーティングドメインの上でも動作できるよう設計されています。管理者が経路を掌握していない環境まで対象に含めた点が、次に挙げる姉妹仕様との分かれ目になります。
Draft Link
Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix
同じ著者による前項の仕様と対をなす文書で、Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix、略称ME6E-FPの基本仕様をまとめています。IPv6のバックボーン網の上にイーサネット網を拡張し、複数のイーサネット網を積み重ねて扱える点はPrefix Resolution版と共通ですが、こちらは自分の管理下にあるルーティングドメインの上で動くことを前提に据え、経路解決の手間を省いた固定プレフィックスの構成を採ります。運用者が経路全体を掌握できる環境向けに割り切った設計になっています。
Draft Link
Multiple Ethernet - IPv6 mapped IPv6 address (ME6A)
プレーンIDという値を持つ、イーサネットをIPv6空間へ射影したアドレスの仕様がMultiple Ethernet - IPv6 mapped IPv6 address、略称ME6Aです。前の二つの文書がカプセル化そのものの手順を定めるのに対し、こちらはその通信で使うアドレス形式自体を定義する立場にあります。プレーンIDの値を一意に割り当てることで、本来重複しうるMACアドレスをIPv6アドレス空間の中で一意なものに変換でき、Ethernet over IPv6のカプセル化に利用できます。アドレス設計を担う土台の文書に当たります。
Draft Link
Group Address Allocation Protocol (GAAP)
マルチキャストで使うグループアドレスを、軽量かつ分散的な形で割り当てるプロトコル、Group Address Allocation Protocol、略称GAAPの設計を記した文書です。基本の割り当て手順は中央集権的なサービスを必要とせず、設定も最小限で足りるよう組まれていますが、暗号化や管理上のスコープを伴う配備では追加の設定が要る場合があります。マルチキャストパケットの送受信に一意なグループアドレスを必要とする参加者同士の間で動作し、IPv4とIPv6の双方のネットワーク向けに調整された、既存プロトコルを拡張しない単純な選択肢として設計されています。
Draft Link
Provider Independent Addresses Aggregation
プロバイダに依存しないアドレス、いわゆるPIアドレスについて、それをまとめて集約できるかどうかという論点そのものを提起する短い文書です。集約する際の具体的な手法や結論はこの版では示されておらず、答えを急がず開いたままにしてある点が特徴といえます。あくまで検討の出発点として書かれており、今後さらに研究とレビュー、そして議論が積み重ねられていく予定であることが明記されています。PIアドレスをまとめて扱えるかどうかという問いかけそのものが主眼に据えられており、続報でどのような具体案が示されるのかが気になる一本です。
Draft Link
Outer Header Translator
ネットワークアドレス変換には便利さがある一方で、通信の端から端までを直接つなぐ透過性を損なうという副作用が付きまといます。この文書はOuter Header Translatorという技術を通じて、アドレス変換と端から端までの透過性という両立しにくい要件を同時に成り立たせる方法を提案しています。移動性への対応や、ネットワークが移行の途上にある状況、マルチホーミング、ポリシールーティングといった課題に対しても解を与えうるとされ、変換を挟みながらも透過性を保つという一見矛盾した要求への答えを探ろうとする提案になります。
Draft Link
Multi-segment SD-WAN via Cloud DCs
地理的に離れたSD-WANのセグメント同士を、クラウドのバックボーンを経由してつなぐ方法を記した文書です。クラウド側のゲートウェイがトラフィックをいったん復号してから再暗号化する必要がない点が肝で、IPsecで暗号化したペイロードをGENEVEヘッダー、つまりRFC 8926で定義されたものの中へカプセル化することで、離れた顧客構内装置同士の間を暗号化されたまま直接転送できるようにします。処理の負荷を抑えつつ拡張性を高め、企業データの機密性も保ったままの多セグメント接続を確保しようという狙いが示されています。
Draft Link
BRSKI discovery and variations
BRSKI、すなわちBootstrapping Remote Secure Key Infrastructure系のプロトコルには複数の変種があり、互いに相互運用できないため、開始側は自分が対応する変種を支える応答者を見つけられる必要があります。この文書はDNS-SD、GRASP、CORE-LFといった異なる発見の仕組みを使い、応答者を自動的に告知し発見し選択する手順を変種ごとに規定します。あわせて、あらゆる変種のトラフィックを中継できるBRSKIプロキシの手順や、Pledgeを識別子で発見する手順も定め、IANAが定義する表に頼る形で組み立てています。
Draft Link
Enhanced Topology Independent Loop-free Alternate Fast Re-route
Segment Routingの枠組みでノードセグメントと隣接セグメントを保護するTI-LFAは、局所修復点から見た収束後の予想経路に沿って保護を確立する高速再経路の手法を核に据えています。ところがこの経路は、SIDリストで通過が指定されているノードであっても、そのノードを飛ばしてしまうことがあります。この文書はEnhanced TI-LFA、通称TI-LFA+を定義し、セグメントにNo-bypass指示子を加えることで、ファイアウォールのような特定のノードを迂回しないようにします。あわせてSRHにNo-bypassフラグとNo-FRRフラグを新たに定めます。
Draft Link
Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space
経路計算要素PCEがPCCの要求に応じて経路を計算する土台の上に、Stateful PCE拡張という仕組みがあります。これはPCEPを使ってMPLSのトラフィックエンジニアリングLSPをステートフルに制御し、SRネットワークでの経路計算にも用いられます。PCCが自分のローカルに設定したLSPの制御をPCEへ委譲するこのモデルで能動的な制御を実現し、PCE自らが起点となるLSPの作成や削除もできます。PCEに基づく中央コントローラPCECCは、SDNの要素との統合で分散した制御プレーンの処理を簡素化します。本文書は、PCEが制御する識別子空間を広告するためのPCEP拡張を規定します。
Draft Link
Compressed SID (CSID) for SRv6 SFC
SRv6ではSIDが128ビットという長さの値で表され、経路の情報を運ぶSRHの中にこの128ビットのSIDが数多く含まれると、生じるオーバーヘッドがペイロードの伝送効率へ大きく影響してしまいます。この問題に対処するために、識別子を短く圧縮するCompressed SID、略してCSIDという仕組みが提案されてきました。本文書は、この考え方を踏まえて圧縮されたSRv6のサービスプログラミングを可能にするために、REPLACE-CSIDとNEXT-CSIDという二つのフレーバーを持つサービスセグメントの新しい振る舞いを定義するものです。
Draft Link
Extensible Provisioning Protocol (EPP) Transport over QUIC
Extensible Provisioning Protocolの略称であるEPPが持つセッションを、QUICのコネクションへどのように対応付けるかを本文書は規定します。EPPのやり取りをQUICの上で運ぶこの方式はEPP over QUIC、頭文字を取ってEoQと呼ばれています。EoQは、QUICプロトコルが持つ機能を活用する設計であり、EPPのセッションという単位をQUICのコネクションという単位へ落とし込む対応関係を定めます。ドメイン名の登録手続きなどプロビジョニングを担うEPPが、QUICという新しいトランスポートの上でセッションをどう成立させるかを扱っています。
Draft Link
YANG Model for Border Gateway Protocol (BGP-4)
BGP、いわゆるBorder Gateway Protocolの設定と管理のために使うYANGデータモデルを定義するのがこの文書です。扱う範囲はプロトコルの動作そのものだけでなく、経路選択に関わるポリシーや、経路の集合であるRIBのような運用上の側面にも及びます。モデルの中身は、データセンターを運営する事業者や通信事業者、そしてコンテンツを提供する事業者といった、実際にBGPを運用する現場の要件を踏まえて組み立てられています。設定と運用の両面を一つのYANGモデルとして扱えるよう体系立ててまとめた内容になります。
Draft Link
The Kinetic Network Protocol
人が読める名前を暗号鍵に結び付ける名前付けと所有権の仕組みを、中央のレジストリやブロックチェーン、金銭を伴う更新なしに成り立たせるのがKinetic Network Protocolです。名前の取得はコミットしてから明かすコミットとリビールの流れと、検証可能遅延関数を用いた手順に沿って逐次的に進みます。署名付きのハートビート記録を残しながら冗長な分散ハッシュテーブルへ状態を保存することで、先回りの登録や大量の一括登録、古い状態を乗っ取る攻撃への耐性を持たせています。プロトコルのモデルや必要な記録、検証の規則、セキュリティ上の考慮事項を定めた文書です。
Draft Link
Kinetic Identity Documents and Service Manifests
Kineticという名前は譲渡できる人が読める別名であるのに対し、KID、Kinetic Identity Documentは変わらない暗号的なアイデンティティを指します。本文書は、このKIDと、KIDが署名するCapability Manifestを組み合わせたモデルを規定します。Capability Manifestには、そのアイデンティティが今提供しているサービスが記されます。名前とアイデンティティを切り離す設計により両者の取り違えを避けつつ、Webサイトやメッセージングの窓口など様々な宛先へ、下層のプロトコルを変えずに名前を解決できるようにします。
Draft Link
IPFIX Protocol over QUIC
IPFIXプロトコルは、トラフィックフローの情報をネットワーク越しに伝える手段を提供し、Flow RecordやTemplate RecordをExporterからCollectorへ、SCTP、UDP、TCPなど複数のトランスポート上で運びます。QUICは本質的に安全で信頼性あるコネクションを提供し、一つのコネクションで複数の独立したストリームを多重化できるため、ExporterとCollectorの間の管理を広げやすくします。本文書は、IPFIXをQUICトランスポートの上で使う方法を記し、IPFIXoQUICと名付けています。
Draft Link
OAuth 2.0 Token Exchange Target Service Discovery
OAuth 2.0のクライアントは、Token Exchangeを行う際にある主体トークンについてどのような交換先を使えるかをあらかじめ確かめたい場面があります。本文書は、audienceやresource、scope、トークンの型といった選べる範囲を発見するための方法を定めます。発見用のエンドポイントは、認可サーバーが対応する任意の型の主体トークンをトークン型URIで受け取り、その後のToken Exchangeリクエストで使える値を返します。アイデンティティチェーンやドメインをまたぐ委任といった、より踏み込んだ利用場面を支える方法を示す内容です。
Draft Link
Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks
複数のテナントを収容する仮想化データセンターでオーバーレイネットワークが求められる場面に応えるのがVXLAN、Virtual eXtensible Local Area Networkです。この方式と関連プロトコルはクラウドや企業のデータセンターで使われます。本文書はRFC 7348を廃止します。RFC 7348はインターネットコミュニティ向けに、既存のVXLANを文書化したものでしたが、本文書はVXLANの仕様をIETFの文書ストリームへ移し、VXLANヘッダーへの追加やIANA登録を要する拡張を作れるようにします。この形式と処理はRFC 7348と互換します。
Draft Link
発行されたRFC
本日発行されたRFCはありません
編集後記
- 終盤でいちばん目を引いたのはVXLANの改訂で、すでに世界中で広く動いている技術の記録をIETFの文書ストリームへあらためて移し、ヘッダーへの追加を伴う拡張とIANA登録の道を開いていくという進め方に、標準化という手順そのものの意味をじっくり考えさせられました。形式と処理はこれまでと完全に互換のままなので既存の実装は壊れず、それでいて拡張の受け皿だけがきちんと整うという設計になっていて、EPPやIPFIXがQUICへ載る提案ともあわせ、足元の土台が静かに更新されていく気配をたしかに感じた終盤でした。
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。