IETF 126 QUIC WG セッションまとめ
日時: 2026年7月22日（水）16:00–18:00 Session IV / ウィーン
情報源: 録画の文字起こし（recording-126-quic-1）、各発表スライド
全体状況
- draft-ietf-quic-reliable-stream-reset-09 が WGLC 中（8/3 締切）。他の WG 文書は大きな更新なし、または本セッションでカバー
- 人間のスクライブ立候補がなく、議事録は AI ノートテイカーに依存する形で進行
- アジェンダは採択済み4件＋As Time Permits 7件と項目数の多い構成
WG 採択済みアイテム
QMux（draft-ietf-quic-qmux-02）— Lucas Pardue 代理発表、Eric Kinnear
IETF 125 以降 01・02 を発行。00→01 はワイヤ非互換、01→02 はワイヤ互換（振る舞い・記述の厳密化のみ）。主な変更は QMux records（§3.2）、QMux over TLS での ALPN 必須化（§8.1）、RESET_STREAM_AT の許可、全般的なハードニング。
実装は quicly / HAProxy / mvfst / picoquic / msquic fork / Cloudflare quiche fork（curl バックエンドで HTTP/3 over QMux）/ quic-go fork / moq-dev 系ライブラリ / Wireshark dissector MR と幅広い。dissector は既存 QUIC 処理を再利用できたため想定より容易で、QMux の価値提案の裏付けとして紹介された。
Interop ドライバとしては draft-kazuho-httpbis-http3-over-qmux-00（ALPN h3qx-01）を更新。02 はワイヤ互換なので新 ALPN は不要。MoQ over QMux も人気の標的。Marco Munizaga が QUIC interop runner の PR を作業中。結果の記録が不十分だった点は反省として挙げられた。
未解決 issue は4件のみ:
| Issue | 論点 | 議論の方向 |
|---|---|---|
| #17 | QUIC の TLS ネゴシエーション（CRYPTO フレーム）を QMux で流用可能にするか | 「QUIC 実装は既に TLS 機構を内蔵しているので楽」という提案に対し、モードを増やす複雑さを嫌う声が優勢。Lucas・Alan Frindell・Marco とも現状維持支持。将来別ドキュメントの拡張として書ける、と整理 |
| #41 | TCP 必須か（editorial） | Kazuho Oku: 基板ごとにクローズ方法が違う（TCP の FIN は単方向、RST は双方向）ので、TCP 使用時を規定し他は「自分で決めろ」節を置くのが現実的。Eric も同意 |
| #60 | 非 TLS 基板での ALPN 相当 | 選択肢は (a) you problem (b) ポート番号 (c) QMux TP で ALPN。Christian Huitema は (a) 支持（Unix socket をやりたい人が draft を書けばよい）、Alan Frindell は ALPN/ポートの組み合わせ爆発を指摘。Lucas は当面 punt を主張 |
| #67 | graceful close の再検討 | バッテリー駆動端末が「アイドル接続が消えた」通知で起こされる問題。「寝ろと言うためにドアをノックするようなもの」。silent close を可能にする案は好意的 |
Extended Key Update（draft-ietf-quic-extended-key-update-03）— Yaroslav Rosomakho
QUIC に post-compromise security を導入する提案。通常の Key Update はハンドシェイクと同じ shared secret 由来なので鍵漏洩に無力だが、EKU は新規の鍵交換を含むため blast radius を「EKU と EKU の間」に限定できる。
QUIC EKU は TLS EKU に依存。TLS 側は形式的解析中でまもなく WGLC 見込みで、解析結果次第で変更があり得るため待ちの状態。
TLS EKU 側の最近の変更で QUIC にも効くもの:
- 3つの独立ハンドシェイクメッセージ → 単一の
ExtendedKeyUpdate+ uint8 サブタイプ（key_update_request / key_update_response / new_key_update）。TLS メッセージ型は1バイトの希少資源のため。new_key_updateは QUIC では使用不可（QUIC は Key Phase bit を回すため）。IANA レジストリを要求予定 - エラーコード廃止。必ず（最終的には）成功する設計。応答側は多忙なら遅延可、要求側は待ちきれなければ接続終了
- 形式解析（FATT）の助言で、ハンドシェイクメッセージの継続的な transcript を保持（従来は毎回新規）。実装への影響は小さかった
実装は TLS EKU が mbedTLS と rustls、QUIC は rustls/quinn ベースを作業中。Magnus Westerlund から「ハンドシェイク完了後の CRYPTO フレーム禁止を上書きするのでは」との指摘があり、NewSessionTicket と同じ仕組みを利用する旨が回答された。動機となるユースケースは VPN・IoT・BGP over QUIC といった長寿命接続。interop 参加者とレビュアを募集中。
ACK Receive Timestamps（draft-ietf-quic-receive-ts-03）— Joseph Beshay (Meta), Ian Swett (Google)
02→03 は editorial のみ（max_receive_timestamps_per_ack のデフォルト 0 = フレーム禁止の明確化、タイムスタンプ操作とリソース枯渇に関する Security Considerations 追加）。
議論の中心は open issue #43「実現不可能なタイムスタンプの棄却ガイダンスは要るか」。タイムスタンプは peer 制御（完全性保護はあるが信頼はできない）で、実時間 1ms を 2ms として報告し続けると BBR の帯域推定が持続的に2倍になる、という Victor の指摘が具体例。現 draft は「SHOULD 妥当性チェック / MAY 無視」と書くのみで具体的ヒューリスティックがなく、Ian と Victor が2案を提示:
- 大きすぎる: 最初のタイムスタンプからの差分がローカル経過時間より大幅に大
- 小さすぎる: 差分がローカル経過時間 − SRTT や PTO タイマより大幅に小
主なコメント:
- Alessandro Ghedini (Cloudflare): ヒューリスティックの中身はさておき、デフォルトの推奨を書けば実装が毎回考えずに済む
- Gorry: きちんとしたルールを書き、変わった経路での挙動をサニティチェックすべき
- Jonathan Lennox: 昔は peer のクロック精度が20%もずれた。悪意がなくても時計が速い/遅いことは正当にあり得る（TIPTOP の火星‐地球の例にも言及）。タイムスタンプベース輻輳制御の一般的ガイダンスはむしろ CCWG 向きでは
- Ian 自身「この棄却基準は10分考えた程度のもの」と認め、Joseph と PR を出して議論継続へ
実装は mvfst が最新 draft 対応（インターネット未有効、interop endpoint には出せる）、Google Quiche も最新フォーマット対応（TP ネゴシエーションは今後）。
qlog（main-schema-14 / quic-events-13 / h3-events-13）— Lucas Pardue
個別イベントの多数の設計変更と editorial 改善。基盤設計は変更予定なし、拡張性モデルは決着、長期懸案だった JSON-SEQ vs JSON は「no action」でクローズ（JSON-SEQ 維持）。実装間で qlog バージョンがまちまちなので「今が最新に更新する良い時期」、構造化定義の取り込みは LLM が得意なので移行コストは低いかも、との案内。
新パーサツールとして Pat Meenan の Waterfall Tools（webperf 由来、HAR や Chrome NetLog を解析）を紹介。リソースごとのウォーターフォールで開始/終了だけでなくバイト到達のバンディングが見え、優先度・HOL ブロッキング・ロス再送の示唆が得られる。さらに qvis のシーケンス図と Chrome NetLog Viewer 風のイベントビューまで統合されている。
open issue 4件（#27 0-RTT の曖昧さ、#121 Session Ticket 内容と保存 TP/SETTINGS のログ、#501 tuple 情報の移動、#517 frames_processed の一貫性）のうち #517 のみ議論。QMux にはパケットがなくフレームの可視性が問題になったことから frames_created / frames_parsed を追加した結果、HTTP/3 側（frame_created / frame_parsed）と不整合になったもの。3案（QUIC の frames_processed 削除／HTTP/3 に追加／何もしない）に対し:
- Kazuho Oku: 削除支持。QMux はフレームのストリーミング処理を許すなど同種の問題が続出するので単純に保ち、必要になったら足せばよい
- Christian Huitema: 同意。フロー制御拡張の受信のような正当なイベントは独立イベントにできる
- Lucas: 「後から足す方が非推奨化・削除より容易」という方針で明確なシグナルを得た
残る 0-RTT / Session Ticket 系 issue を閉じれば WGLC の準備はほぼ整ったとの認識。careful-resume-qlog、happy-qlog、roq-events、moq-qlog、h2-events といった後続 draft の基盤として、ここを固めることが重要と強調された。
As Time Permits
Reverso for QUIC（draft-frochet-quicwg-reverso-for-quic-01）— Florentin Rochet (UNamur)
QUIC v1 では受信側の contiguous zero-copy が原理的に不可能（暗号化データが暗号化された制御情報に挟まれるため）という問題提起。SIGCOMM CCR 2026年1月号の論文がベース。必要な変更は3つ:
- short header に stream ID と offset を追加（最悪ケースで 5→13 バイト、ヘッダ保護アルゴリズムは不変）
- STREAM フレームがあればパケット内の最初に置く
- 全フレームの要素順序をワイヤ上で反転
仕組みは out-of-place 復号の「隠れたコピー」を再組立に流用するもので、復号先をストリームバッファ上の適切な位置に指定し、前パケットの制御フレームを上書きしながら連続したストリームデータを得る。順序反転の理由は short header への追加情報を最小化でき、双方向に読み書きできるバッファ抽象さえあれば v1 と vReverso で同一のパース/シリアライズコードが使えるため。
主なコメント:
- Kazuho Oku: エンコード時にフレームヘッダ長が事前に分からずデータ開始位置が変わる v1 の複雑さが解消されるのは良い。v1 の開発期ならこちらを好んだが、既に広く出荷済みの今やるべきかは疑問 →（発表者）QMux のような新設計には継承できる
- Brian Trammell: これは事実上 QUIC v3 でワイヤ非互換、両端のネゴシエーションが前提 → その通り
- Lars Eggert: 巧妙なハックで性能は出るが、メモリコピーが残るボトルネックになっている deployment がどれだけあるか。Christian Huitema もチャットで「picoquic の主ボトルネックはメモリコピーではなく複雑さ」「この種の要求は今日 RDMA が担っているのでは。RDMA との比較は？」と指摘
- Ian Swett: 面白い実験。ワイヤフォーマットを壊すならもっと大胆に。RDMA がやっていることを参考に、そもそもデータパケットに制御メッセージを同居させる必要があるのかまで考えては
CTaps / TAPS over QUIC — Ingebrigt Hovind
TAPS の C 実装で、QUIC をサポートする初のオープンソース TAPS 実装（修士論文＋ANRW 投稿論文ベース）。報告されたギャップ:
- クローズ意味論: QUIC connection → TAPS connection group、QUIC stream → TAPS connection にマップされるが TCP には等価物がない。
close()時に TCP は graceful teardown を始めたいが QUIC は FIN を送りつつ受信は開けておきたい。汎用 API のはずが下位プロトコルがアプリに漏れる - 粒度の喪失: QUIC の STOP_SENDING / RESET_STREAM に対し TAPS は単一の
Abort()で方向性が失われる。また TAPS は接続確立時にしか方向性を指定できず、後から clone で作るストリームの方向性を設定する手段がない - 緩和策: TAPS API 側に optional flag / 新パラメータを足す（spec から乖離）、クローズは「常に QUIC を使っていると仮定して connection group だけ操作する」と一貫するが、これはライブラリがアプリの書き方を強制していることになる
議論:
- Jonathan Lennox: TAPS は Apple の Network framework の一般化なので Apple がやったとおりにすれば、とやや皮肉りつつ、TAPS WG が閉じているのでどこで扱うか AD のガイダンスが要る（TSVWG?）
- Brian Trammell: TAPS 策定時、QUIC はまだ IETF プロトコルではなかったので意図的に対象外にした。QUIC の上に標準的な API がないことが採用の障壁というギャップがある
- Eric Kinnear (Apple): Apple と同じことをしない方がよい。多様なアイデアの実験から良いものを選ぶべき
チェアは「ここは TAPS WG ではない」としつつ、QUIC ストリームの強力な機能に API が追いついていない点は QUIC 的にも興味深いと評し、継続議論は TSV へ誘導した。
GCM-SST in QUIC（draft-westerlund-tls-gcm-sst-00）— Magnus Westerlund（+ John Preuß Mattsson）
GCM-SST は AES-GCM と同じ暗号構成ながら AEAD 呼び出し（QUIC ではパケット）ごとに認証鍵を導出する AEAD アルゴリズム。CFRG の個人 draft で、ETSI/3GPP で標準化済み、独立した安全性証明が2つ。
AES-GCM は全呼び出しで同一の認証鍵 H を使うため、一度偽造に成功すると鍵が判明し以後の偽造が容易になる（rekey まで）。これがタグ切り詰めを困難にしている根本原因で、GCM-SST は「崩壊」しないため truncation が可能。
| 名前 | タグ長 | 初回偽造確率 | 初回偽造後 |
|---|---|---|---|
| GCM_SST_14 | 14 B | 1/2^112 | 1/2^112 |
| GCM_SST_12 | 12 B | 1/2^96 | 1/2^96 |
| POLY1305 | 16 B | 1/2^91 | 1/2^91 |
| GCM | 16 B | 1/2^116 | 1 |
つまり 12 バイトの GCM_SST_12 が 16 バイトの POLY1305 より 5 bit 強い。ヘッダ保護は AES-GCM 同様 AES-ECB を使い、Rijndael（256bit ブロック）では nonce 用に sample をゼロパディングで拡張（mask = Stream(40, hp_key, ZeroPad(sample,28))[0..4]）して短いパケットでも成立させる。
Multipath / Multicast での意義が強調された。AES-GCM は全パスで同じ認証鍵 H（nonce のみ違う）なので攻撃を複数パスに分散できるが、GCM-SST は特定 nonce を狙う必要があり multipath でも ideal を維持。Multicast では受信者が独立に鍵付けされないため、AES-GCM だと受信者数 R にスケールして偽造試行を分散でき、1回成功すると各受信者向けにパケットを仕立てられてしまう。
議論:
- Lars Eggert: これは TLS でやるべきでは、TLS が良しとしたら QUIC は従うだけ？ → draft は TLS 向けで cipher 識別子を登録し QUIC のヘッダ保護も定義する。ただし TLS と QUIC でトレードオフが違う部分があるのでここでも提起した。AVTCore ではさらに短いタグを議論予定
- Martin Duke: TLS 実装が突然これをネゴシエートし始めたら QUIC 実装がタグ長で壊れるのでは、sample や最小パケットサイズは？ → ゼロパディングで変わらないよう設計済み → 「思ったより簡単だった」（RFC 9001 に cipher を認可する軽微な editorial 変更は必要）
- Christian Huitema: 暗号アジリティは歓迎。理論上は全コードパスがタグ長をアルゴリズムの関数として扱っているはずだが、実際には常に16なのでバグが数個出るだろう
- David Schinazi (Google): TLS の code point をそのまま QUIC に持ち込むことはできない（AES-CBC を入れるとワイヤ上は動くが安全でない）。QUIC 実装は許可 cipher の allow list と最小パケットサイズ等のパラメータを明示的に持ち、1つずつ追加していくのが QUIC のアジリティのやり方。暗号学者の意見を聞きたいが、彼らには QUIC 側からの入力が必要で、特に multicast が新しい点（TLS では multicast TCP はできない）
HTTPS RR と QUIC v2 の採用状況 — Max Inden (Mozilla)
Firefox の公開テレメトリ（GLAM）に基づくクライアント側の測定報告。
HTTPS RR: Firefox 接続の 35% は Alt-Svc 経由でのみ h3 を学習＝最初の接続では HTTP/3 にならない。HTTPS レコードで h3 が広告されている接続は約7%のみ。原因は公開サイトの少なさ（上位100万サイトの20%強、しかもその70%超が単一 CDN のデフォルト、Dong et al. IMC 2024）と、オンパス機器が SNI を見えるようにするためレコードや ECH パラメータを剥がし h3 のヒントごと失われること（FortiGate, Cisco）。論点として「Alt-Svc を deprecate するか、SVCB に移すか（draft-thomson-httpbis-alt-svcb）」が提起された。
QUIC v2: RFC 9369 は v1 と機能的に同一で salt / label / codepoint のみ異なる anti-ossification 版。Firefox Nightly では v1 ≈ 100%、v2 ≈ 0%。IMC 2024 でも QUICv1 ドメインの 0.003% 未満。14 スタック中10が実装しているのに本番デプロイは稀（Google/YouTube・Meta・Cloudflare・Bing は v1、Outlook・Caddy・LiteSpeed・HAProxy は v2）。ドメインの HTTPS RR と v1/v2 対応をチェックできる savearoundtrip.com を公開。
David Schinazi (Google) の反論が重要:「Google は v2 を実装したがデプロイしていない。理由は v2 が ossification に効かないから。HTTPS レコードや Alt-Svc でサーバの v2 対応を事前に知る手段がないので、ハンドシェイクは結局 v1 で始まる。compatible version negotiation で v2 に移っても最初に送るのは QUIC v1 Initial。ossification が問題なのは SNI や ClientHello が JA3 等でハッシュされる上り方向であり、下り方向を見ている者はいない。v2 を有用にするには HTTPS レコードでの対応発見手段が必要」。Max は「Firefox は v1 と v2 を offer して下り方向を grease している」「サーバの v2 対応は現状記憶していない」と応答。
Mutable Idle Timeout?（draft-pardue-quic-idle-timeout-update-00）— Lucas Pardue（個人）
「モントリオールの昼食での雑談から生まれた draft で、考えるほど自分は反対に傾いているが賛成する人もいるので『?』付き。むしろ他のトランスポートパラメータを可変にする話が今後出たときのために議論を記録に残したい」という趣旨。
RFC 9000 §10.1 の整理: 実効 idle timeout は両端の広告値の最小（ただし 0 は特別扱いで、TP を送らないのと同じ）。silent close されるのが良い特性（無線を起こさずに済む）。一方「実効値より前に接続を放棄するなら immediate close を開始することにコミットする」という文言は意外。
実装デフォルトの調査:
| 値 (ms) | 実装 |
|---|---|
| 30,000 | Chromium, quic-go, MsQuic, quinn, picoquic, lsquic, neqo, haproxy, h2o |
| 60,000 | aioquic, mvfst |
| 240,000 | GFE |
| 300,000 | envoy |
| 0 | ngtcp2 |
| なし | s2n-quic, quicly, Cloudflare quiche |
30秒が多いのは NAT タイムアウトが約30秒であることの影響がありそう（ただし idle timeout で NAT 問題を回避すべきでないという指摘も）。quiche が none なのは「ライブラリが意見を持つべきでなく、どの値も Goldilocks 問題になる」ため。
動機の中心は HTTP/3 GOAWAY。GOAWAY 後はサーバのレスポンス送信だけが接続を駆動するため、immediate close するかクライアントの30秒 idle timeout を待つかの二択になる。GOAWAY 送信時に idle timeout を短く（例: 5秒）再交渉できれば、アプリ層のタイムアウト管理をトランスポートに押し込めて追加トラフィックなしに片付けられるという発想。提案は IDLE_TIMEOUT_UPDATE_REQUEST / _ACCEPT / _REJECT の3フレームで、どちらの端点も要求可能、0 で無効化。ただしシーケンス番号でのロックや DoS 考慮が必要で「単純化のはずが結局かなり複雑」と自己評価。
議論:
- Brian Trammell: 反対するために列に並んだが、有用そうなのは reset せずに長時間接続を維持したいときに別経路へ再 NAT され、それに気づいた場合。メカニズム自体は好き
- Ian Swett (Google): 最重要なのは早期に idle timeout する側が peer に伝えること（伝えないと tail latency 問題になる、自分たちもバグを踏んだ）。実装を直すのが step 0。Chrome は 300秒の idle timeout を実験中で数ヶ月内にあり得る＝インターネットは思ったほど ossified ではないかもしれない。HTTP/2 の SETTINGS のトラウマがあるので更新可能なものは不安。拡張をネゴシエートしたなら reject は必要か（去るか閉じればよい）
- 別の参加者: 最初は嫌いだったが読むほど好きになった。hole punching や connection migration が好きで、パスごとに異なるタイムアウトを持てるのは有用そう。MASQUE 系は H3 と性質が大きく違うのでそれに応じて動けるのも有用。ただし他の TP まで更新可能にするのは怖い
QUIC and Multicast — Max Franke (TU Berlin), Louis Navarre, Kyle Rose, Olivier Bonaventure
技術詳細・draft の優劣・privacy/security トレードオフにはあえて踏み込まず、実ユースケース・動くコード・「なぜ今か」に絞った発表。
multicast は今日のインターネットで実際に使われている（Broadpeak の Multicast ABR がワールドカップ配信に使用）が、配信経路が複雑で専用ハードを要し、独自仕様で安全でもない。QUIC は UDP 上で動くので自然に載り、WebTransport 経由でブラウザへの道があり、セキュリティと信頼性が得られ、middlebox なしに end-to-end で完結し、拡張が綺麗に収まる、という位置づけ。
PoC は3種:
- Minimal Multicast QUIC（今回のハッカソン成果）: サーバ側 600行程度。multicast ツリーと復号鍵を告知する1フレーム、サーバは multicast アドレスの新接続で DATAGRAM を送信、クライアントは新ソケットを開いて元の接続に流し込む（別パケット番号空間）。1日で6つの QUIC スタックを改造し、RTP ストリームがラップトップと iPhone で動作
- Flexicast（draft-navarre-quic-flexicast）: Multipath QUIC の意味論を再利用（信頼性・ACK・パス管理とフォールバック・輻輳制御）。quiche 実装で 100 Gbps までスケール。より重い
- MoQ over Multicast QUIC（draft-jholland-quic-multicast）: MoQ リレーがユニキャストに加えて multicast チャネルを emit。改造 Firefox が通常どおりユニキャスト接続しつつ拡張をネゴシエート、multicast に join 成功するとユニキャスト送信が停止。reliable STREAM フレームを使用し、integrity フレームで注入を防止。未最適化の実装で egress を80%超削減、multicast 経路の追加遅延は integrity 込みで約60ms。multicast が動かない場合の追加コストは接続開始時の数フレームのみ。デモは live.quicast.de で公開
質疑:
- 輻輳制御は？ → 2 IETF 前に CCWG で議論しようとしたが multicast のアプリケーションがないので誰も関心を持たなかった（鶏と卵）。解はある、フロー制御も含め検討済み
- François Michel: ハッカソンで最小実装をやった側として、最小解の設計に合意できたことが大きい。その路線で interop に必要な部分の合意を進めてほしい。2つの draft の差は主に multipath の使用と authentication/integrity の扱いで、共通の土台はある
- Magnus Westerlund (Ericsson): multicast 拡張はツールボックスに持つ価値がある。輻輳制御や適切なセキュリティ特性など解くべき問題は明らかにあるが、WG が着手する時期では
- end-to-end セキュリティ（リレーが multicast の起点なら end-to-end 性はソース〜リレー間では？）→ ユニキャスト接続をセキュアなアンカーとして鍵材料を交換する。トレードオフは全受信者が鍵を共有すること（受信者の1人がパケットを注入し得る）で、それを integrity フレーム（パケットのハッシュ）でソース由来と検証可能にする。それ以上に強い認証性は鍵共有方式ではカバーされない
- QUIC を制御チャネルとして使い、multicast で落としたパケットだけ再送要求できるか → できる。多数が落とせば別 multicast チャネルで、個別ならユニキャストで再送も可能
発表者からは今後1年の公的資金を確保しフルタイムで取り組める旨の表明。チェアのまとめは「関心はあり、MoQ 空間に牽引ユースケースがありそうだが MoQ WG は多忙。チャットでは BoF 的なものの提案もあった。チェア陣と AD で今週話す必要がある。過去にも提示され関心が高かったので、何もせず1年待たせて資金が尽きるのは残念」。
n0 QUIC NAT Traversal（draft-bruynooghe-n0-quic-nat-traversal-00）— Floris Bruynooghe, Diva Martinez
Quinn のフォークで Multipath と NAT traversal を組み合わせた実装報告（github.com/n0-computer/noq）。
接続はリレー経路（HTTPS/WebSocket）で確立し、QUIC スタックからは IPv6 ULA の普通のパスに見えるので path 0 として扱い、NAT traversal をその上で調整。probe は RFC 9000 の PATH_CHALLENGE / PATH_RESPONSE を使い、成功したら path 1..n として開く。
draft-seemann-quic-nat-traversal がベースで、サーバは ADD_ADDRESS / REMOVE_ADDRESS で候補を広告・撤回。本家と異なるのはクライアントが REACH_OUT フレーム（round + アドレス）で開始する点で、ICE のようなアドレスペアリングをせず候補を総当たりで flood する off-path probing。
捨てた設計として「新パスの path ID を使って probing する方式」を挙げ、サーバ側が1つの path ID しか使っていないのにパス churn が大きすぎ CID を大量消費し、peer が max path ID を上げて新 CID を発行するまで待つ必要があったと説明。代わりに probing フレームの概念を戻した（multipath では全パケットが migration 扱いになり off-path probing ができないため）結果、multipath 非依存になったのが綺麗な副産物。
残る課題:
- CID 発行が最大の問題。現状 NAT probe が使用中の active CID を使っている、probing が1パスで大量の CID を消費、各パスが全 CID を受け入れる必要
- PATH_NEW_CONNECTION_ID を REACH_OUT に interleave する案、駄目なら共有鍵をネゴシエートして peer 側で CID を生成する拡張（望ましくないと自認）
- multipath での probing packet、リレー接続が不要/不可能な場合の複数パス同時接続確立（別々の接続試行にして片方を捨てる方が良いかも）
初 IETF 参加とのことで、チェアは「P2P ユースケース自体が charter 内かは微妙だが、それを可能にする QUIC の拡張・部品は範囲内」としてメーリングリストでの議論を促した。
発言者名は録画の自動文字起こしから拾っているため、一部に表記ゆれや誤りが含まれる可能性があります（スライドに記載のある著者名は正しい綴りに修正）。