HAPPY WG — IETF 126 (Vienna, 2026-07-20 14:00-16:00 CEST)
Chairs: Tim Chown, Eric Kinnear / 出典: セッションスライドおよび録画の文字起こし
1. draft-ietf-happy-happyeyeballs-v3 (Tommy Pauly, Nidhi Jaju)
-04 での更新
- "address" → "endpoint"、"interface" → "PvD" への用語統一 (#134, #129)
- IPv6 の MTU 問題の説明追加 (#132)、abstract/intro のスコープ明確化 (#131)
- DNS 応答処理の具体例を追加 (#136) — 例: HTTPS + AAAA が来たら即 IPv6 を開始し、後から A が来たら interleave する / HTTPS + A のみなら Resolution Delay を起動する
Ben Schwartz より「IPv6 の問題を『ヘッダが大きいから』と説明しているが、実際はフラグメンテーション処理の違いではないか。フラグメンテーションに詳しい人にレビューさせるべき」との指摘。チェアが確認を約束。
PR #137: IPv6-only ネットワークのガイダンス刷新（最大の議題）
IETF 125 週のデザインチーム提案をテキスト化したもの。
- 4.1 節（クエリ送信）: 判断基準は「自分の PvD が持つ経路」。グローバル IPv4 接続性があれば A、IPv6 接続性があれば AAAA を MUST 送信。PREF64 を何らかの手段で認識していれば A も MUST 送信
- 7 節: 「IPv6-only / IPv6-mostly」というくくりをやめ NAT64 の扱いに整理。PREF64 は RA または ipv4only.arpa から発見。合成アドレス（DNS64 由来を含む）はソート段階で IPv4 として扱う
- 常に A を送るようになったため "Last Resort Local Synthesis Delay" は削除可能に
議論の焦点は split-tunnel VPN の扱い:
- Eric Nygren: PvD / VPN / ネットワーク接続性の話題は独立したトップレベル節に引き上げるべき（DNS キャッシュのフラッシュ等とも絡むため）
- Jen Linkova: 前回スライドと PR の内容が微妙に異なる。「合成 v6 と実 v4 があるとき、より具体的な経路があれば v4 で送る」形にすれば VPN ケースも解決する。→ Tommy は「de-synthesize → 処理 → re-synthesize は v4 として扱うのと道義的に等価で、実装詳細の問題」と回答
- Philipp Tiesel: VPN は暗黙の PvD にすぎず、PvD を正しく扱えば VPN もカバーされる。「leaky PvD」という概念の検討を提案
- Tommy Pauly: 純粋な PvD 主義では PvD をまたいだ回答の使い回しは禁止だが、実際の split-tunnel 配備はそれに依存しており厳格化すると壊れる懸念
- Lorenzo Colitti: PvD 仕様には「情報の不在」を宣言する仕組みも他 PvD から一部を継承する仕組みもなく、split tunnel を PvD で表現するのは非常に困難。PvD 側を直すべきかもしれないが、この文書では実務的なガイダンスを与えるのが正しい
→ split-tunnel の記述を PR に戻したうえでレビューを集め、早期マージを目指す方向。
PR #133: DNS サーバアドレスの選択
HEv2 から引き継いだ「DNS サーバも IPv6 を優先」というテキストの扱い。PR は 3901bis / RFC 6724 を参照しつつ、優先アドレスファミリを前に出すこと、無応答リゾルバをペナライズして次に切り替えることを追加。
- Lorenzo Colitti: 6724 はアドレスファミリ間のソートをしないわけではなく、アドレスペアの集合をソートするので事実上この提案の上位互換。「何も言わない」か「6724 を指す」かのどちらかにすべき
- Ben Schwartz: この領域には踏み込まないべき。DNS のコネクション最適化は別の問題空間で、DNS には 6 種類のトランスポートがある。Happy Eyeballs と DNS の間には抽象化の壁を置き、「DNS も Happy Eyeballs の利用者になれる」と書けば十分
- Andrew Yourtchenko: IPv4 のみのリゾルバ 2 台で片方が落ちたときの実運用経験があり、何らかの記述は必要
- Stuart Cheshire: この文書を初見で読む人のために、非規範的でよいので短い背景説明を残すのが好み
- Lorenzo Colitti: 暗号化トランスポートで得た応答かどうかをアルゴリズムが気にする可能性（ECH との関係）。スコープ外にするなら意識的にそうすべき
ルーム投票（テキストを残して改良する = Yes / 完全に削除 = No）:
| Yes（残す） | No（削除） | 意見なし | 投票終了時の参加者 |
|---|---|---|---|
| 5 | 14 | 6 | 70 |
削除寄りの結果。「6724 / 3901bis を指すに留め、無応答リゾルバのペナライズについての記述は残す」あたりへの着地見込み。
PR #138: Connection Attempt Delay の指数バックオフ
Firefox のテレメトリに基づく提案（固定 250ms → 50ms + 指数増加）。論点:
- RTT 推定と無関係な固定遅延に固有の問題なのか
- バックオフに上限を設けるべきか
- 「どの試行が勝ったか」だけでなく「何回試行を開始したか」も測るべき
Apple / Chromium ともに履歴 RTT ベースへの移行を進めており、250ms は HEv2 からの引き写しなので見直す価値があるとの認識で一致。
2. Optimistic DNS (Gautam Akiwate)
DNSOP での金曜の議論を前に、実装報告の前提としてタイムボックス付きで紹介。
- 定義: 期限切れキャッシュを即座に返しつつ、並行してネットワーククエリで更新するスタブリゾルバの機構
- 動機: TTL 61 秒目の「突然の遅延スパイク」。答えはほぼ変わっていないのに再解決コストを払っている
- 前提技術: 非同期 DNS が Optimistic DNS を可能にし、Happy Eyeballs がそれを安全にする。この 2 つがなければ期限切れ回答を使うべきではない
- 実装: mDNSResponder が 2018 年（macOS 10.14 / iOS 12）から出荷済み。Firefox は 2013 年から、Chromium も実装中
議論:
- Eric Nygren: 「TTL を数秒超える猶予期間」と「TTL を 7 日間無視する」は別物で、後者は運用・セキュリティ・プライバシー上の影響が大きい。2 つを分けて議論すべき
- 60 秒の例は非現実的（実際は接続が張られたままになる）との指摘。ドメイン側が HTTPS レコードの SvcParam で「2 時間までの延長を許可」のようにオプトインで宣言する形が望ましいとの提案
- 今後: ドラフトの居場所（DNSOP か HAPPY か）は dispatch 案件として週内に調整
3. 実装報告
3.1 Firefox (Max Inden, Mozilla)
Nightly でデフォルト有効化（約 15,000 ユーザ）。テレメトリはすべて公開。
- 再利用可能ライブラリ
mozilla/happy-eyeballs（sans-I/O・決定論的ステートマシン、時刻も引数として渡す、MIT/Apache-2.0）。ドラフトの性質がすべてユニットテストになっており、他言語への移植の参照に使える
ドラフトからの逸脱:
| 項目 | ドラフト | Firefox |
|---|---|---|
| Resolution Delay | 50ms | 25ms |
| Connection Attempt Delay | 固定 250ms | 50ms + ×2 バックオフ (50/150/350/750ms) |
| Interleave | アドレスファミリ | アドレスファミリ ＋プロトコル (QUIC-v6 → QUIC-v4 → TCP-v6 → TCP-v4) |
| Optimistic DNS | — | 使用（2013 年から） |
主なテレメトリ:
- 成功時 end-to-end: P50 74ms / P95 603ms。失敗は P75 50ms か 10s キャップの二極化
- 初回試行で勝つのが 84%、試行 1 回のみが 86.9%、キャンセルなしが 91.8%
- 初回試行までの時間 P50 3ms（Optimistic DNS の効果）
- h3 の発見経路: Alt-Svc のみ 35% / HTTPS レコードのみ 3% / 両方 4% / h3 なし 58%
- HTTPS RR の内容: h3 ALPN 79.5%、IPv4 hint 54.4%、IPv6 hint 51.2%、ECH 16.3%（DoH と OS リゾルバで差はほぼなし）
Alt-Svc 経由だと初回接続で 1 RTT を無駄にするため、alpn="h3" の HTTPS レコード公開を促す savearoundtrip.com を立ち上げ。
将来案: 優先ファミリを待たず HTTPS RR だけ待って race する (PR 116)、プロキシ対応、WebSocket/WebTransport 対応、Optimistic QUIC（シグナルがなくても H3 を H2 と race させる）
エッジケース: DNS ネガティブ応答の TTL、DNS coalescing、マルチ CDN での HTTPS-RR/CNAME 整合性チェック、dnsLookupEnd が Resource Timing 仕様とずれる問題（ブラウザ間で標準化すべき）
デバッグ: about:networking、Alt-Svc ページ、Firefox Profiler の Networking プリセットで各試行と勝者を可視化。qlog 出力への拡張にも前向き
質疑:
- Lorenzo Colitti: 「1 番目のアドレスを 1 番目のアドレスと race させたら数字はどう変わるのか」。2 回目の試行が成功する約 8% のうち、同じ IP への再送でも成功する分がどれだけあるのか知りたい。これは「この WG 全体の有用性の上限」を与える。単にパケットを多く送っているだけなら多く送ればいいだけの話になる。また RFC 6724 はユーザ空間実装が非常に困難で、ドラフトで何か言えないか
- Tommy Pauly: HTTPS レコードの取得率 3% は低すぎる。自分たちのブラウザ系ワークロードでは肯定応答が 17%、うち 30% が本来しなかった H3 アップグレードにつながっている。数値の突き合わせが必要
- ネットワーク負荷の増分とプロトコル間のフラッピング量を定量化すべき / 固定回線とセルラー (2G/3G/4G) で結果を分けて示すべき / 単一のタイマー値に固執すると 5 年後に HEv4 を議論することになる、との指摘
3.2 Chromium (Kenichi Ishibashi, Nidhi Jaju)
段階的出荷方針。
- 基盤: 非同期 DNS リゾルバが A / AAAA / HTTPS の到着ごとに部分結果を push
- Stage 1（出荷中）: TCP が逐次解決を消費。使えるアドレスが来次第接続、AAAA 未着なら IPv4 結果を Resolution Delay（RFC 8305、50ms）保持。自社サービスで測定可能な性能改善
- Stage 2（作業中）: QUIC。現状は全 DNS 応答を待って単一 IP のみ試行し、到達不能なら他ファミリで QUIC が通る場合でも TCP にフォールバックしてしまう。TCP と同じ挙動を付与する
- 並行: Optimistic DNS。リゾルバ側は
STALE_ALLOWED_WHILE_REFRESHINGモードを追加済み（stale を中間結果として返し、最終結果は常に fresh）。TCP はほぼ実装済みでフィールド実験へ、QUIC は逐次解決化の後 - Stage 3（予定）: クロスプロトコル協調（HEv3 モデル）。実は最初にここから着手したが、既存コードパスが年月をかけた最適化を抱えて進化し続けており書き換えが追いつかない、エッジケースで新パスの方が遅くなる、という理由で後回しに
質疑:
- Johannes Zirngibl: QUIC vs TCP か、QUIC vs TLS/TCP か（成功シグナルはどこか）→ 現状は完全に別コードパスで相互作用なし。Nidhi Jaju が「TLS 完了を成功とみなす」と補足
- Ben Schwartz: stale はどこまで許容するか → 永続化しないので再起動でクリア、ネットワーク変化時も stale 扱い。ただしデスクトップでは数週間前のレコードもあり得る。あわせて SVCB TargetName 対応への継続的な要望
- Ben Schwartz: QUIC 試行中に TCP+TLS が勝った場合 QUIC をキャンセルするか → しない（次のリクエストで使えるように）。「これは正しい挙動で、自分が connection escalation と呼んでいるもの。HEv3 のテキストがこれを許容することを確認すべき」
3.3 Apple (Tommy Pauly)
- HEv2 実装の発展形。固定タイマーではなく履歴 RTT 推定ベース。直近の数字で 97.2% が最初のアドレスで成功
- SVCB/HTTPS 対応は 2020 年から（ALPN 処理を含む）
- iOS 25: NAT64 プレフィックスがあるとき常に A を送信
- iOS 26.4: 同優先度の SVCB/HTTPS レコードのシャッフル
- iOS 27 / macOS 27 ベータ: Happy Eyeballs の並べ替えを SVCB 優先度グループ内に限定（従来は優先度をまたいで v4/v6 を並べ替えていた）、および解決タイミングのデータ収集
A と AAAA の到着時刻差: P50 0ms / P90 17ms / P95 34ms / P99 100ms。現行 50ms のタイマーは大半をカバーしている。各実装で同じカーブが見えるか突き合わせたい
今後: 「開始したが使われなかった接続試行の数」を計測したい（現状は勝者しか記録していない）
質疑: 失敗時の挙動をもっと掘り下げてほしい（再送で解決したのか、v6 失敗を v4 が救ったのか）/ バッテリー消費はどうか（無線が既に起きているタイミングに揃うなら影響は小さいはず、要検証）
4. Happy Eyeballs Webtester とハッカソン報告 (Johannes Zirngibl, Tim Betzer — TUM & MPI)
- ドメイン名にパラメータを埋め込み、サーバ側が挙動を変える方式。HTTP/3・2・1 対応、A / AAAA / HTTPS レコード（ALPN 設定可）
- QUIC vs TCP/TLS の遅延、IPv6 vs IPv4 の遅延を設定可能。遅延はネットワーク層（TCP ハンドシェイクにも影響）か TLS ハンドシェイクのみ（ServerHello を遅らせる）かを選択でき、ブラウザ検証には後者が公平
- 結果は遅延の組み合わせのマトリクスで表示。設定済みドメイン一覧をダウンロードして個別テストも可能
- ハッカソンでの拡張: Web サーバ側のパケットトレースに加え、権威サーバへの DNS クエリ到着順もトレースに追加
- 追加された個別機能テスト: HTTP/3 の可用性、ECH（stale config 時のリトライ、平文フォールバックの有無）、HTTPS の alias モード / port / TargetName の追随、hints が A/AAAA より優先されるか、A レコードを遅延させたときに後から来た AAAA が非同期にステートマシンへ反映されるか
- このツールで Firefox の hint 利用に関する未報告の挙動（レコードが使われたり使われなかったり）を前日に発見
happy-eyeballs.netが本番、新しいテストは staging (staging.he-test.net.in.tum.de) にあり。「ダッシュなしの happyeyeballs」サイトの運用者を探しているとのこと
5. HEv3 の qlog によるイベントログ (Mirja Kühlewind)
draft-kuehlewind-happy-qlog-00。WG チャーターの reporting の step 0 として、まず共通のログ形式を定める提案。
データ型:
HEAttemptTarget— ポート/アドレス/インタフェース/トランスポート、alpn、service_name、service_priority、ech_offeredHEPolicy— タイミング、優先度、成功/失敗条件、並列試行などの設定情報HEDNSResult=HEDNSAddressResult（アドレスとファミリ）/HEDNSServiceResult（サービスレコードの情報）
イベント: set_config / dns_query_started・dns_query_finished / nat64_prefix_discovered / candidate_discovered・candidates_sorted・candidate_removed / attempt_scheduled・attempt_started・attempt_pended・attempt_resumed・attempt_outcome / 各種タイマーイベント / connection_selected・connection_aborted / 集計メトリクスイベント
HEMetrics: he_session_id、outcome、total_duration_ms、tt_first_success_ms、first_success_family、first_success_transport、attempts_total / success / failure
議論:
- Lars Eggert: 「operator」とはネットワーク事業者かサイト運営者か。ログを取ることより、そのデータが必要な場所へどう届くかが難しい部分。→ Mirja は「まずオフラインでデータを取って分析したい。オンラインでの集約が必要ならアーキテクチャは別途必要だが、まずデータモデルから」と回答
- Ben Schwartz: デバッグ用途にはこの集計だけでは情報が足りない。qlog に DNS 関連イベントが欠けているのでは。最も欠けているのは細部を 1 本に束ねる手段で、
HESessionID は非常に有用。あわせて HEv3 の接続シーケンスのステートマシンを明示的に記述する PR #125 をレビューしてほしい（この粒度で観測するには仕様側の粒度が足りていない） - Lucas Pardue: -00 だが良い方向。DNS は独立した qlog スキーマにすべきかもしれない。セッション ID による threading はトランスポート / DNS / アプリケーションを串刺しにするうえで極めて重要
6. Happy Eyeballs エラーレポーティングの考察 (Philipp Tiesel, Jordi Palet Martínez)
draft-palet-happy-reporting-considerations。-01 で 5 つのペルソナに整理。
| # | ペルソナ | 特徴 | 報告手段の例 |
|---|---|---|---|
| 1 | 開発者・ユーザ | クライアント完全制御、集約要件なし | 開発者ツール、performance log、platform log (Windows events, systemd-journal 等) |
| 2 | 企業・管理ネットワーク運用者 | 端末への管理権限あり、集約・統合要件あり | platform log、anycast syslog |
| 3 | サービスプロバイダ | 第一層キャリア | anycast syslog、ICMP (happy-sad) |
| 4 | 中間トランジット事業者 | — | ICMP (happy-sad) |
| 5 | コンテンツプロバイダ・CDN | — | ICMP (happy-sad)、W3C NEL 拡張、ECMAScript オブジェクト |
議論:
- Lars Eggert: 1 と 2 に実質的な差はなく、両方とも支持する（ブラウザ／エンドポイント間で共通形式を作ることにも賛同）。それ以外は強い抵抗感。NEL はサーバ側なので余地はあるが懐疑的で、サービスプロバイダやトランジット事業者にブラウザが何かを晒す理由は思い当たらない
- Andrew Yourtchenko: 「こう動くはず」という期待・ポリシーを併せて示し、かつ「対処する意思がある」ことを示す手段はあり得るか
- Mike Blanche: リストの両端（ユーザとコンテンツ事業者/CDN）には関係性があるが、中間には既存の関係がない。「サービスプロバイダ」が何を指すのか（ローミング先か、自宅網か、private relay か）も曖昧
- Valentin Gosu (Mozilla): ほとんどのペルソナは既にこの情報を取得できる（qlog、プロファイル、PCAP、web tester など）。Happy Eyeballs で既に余分な作業をしているのに、なぜアプリがさらに報告作業をするのか。アクショナビリティを考えるべき。→ Philipp は「運用者は Happy Eyeballs が問題を隠すせいで IPv6 ブラックホールの有無すら分からない、念のため PCAP を取っておくことはできない」と反論
- Brian Trammell: happy-sad は約束ではなく、脅しと冗談の中間、実際には thought experiment。ドラフトは復活させるが、実装される事態になったらそれ自体がエラーメッセージだろう。とはいえ「どうすればこの情報を最小コストで露出できるか」は考える価値がある
- Jordi Palet: 9 年前からエラーレポーティングを求めてきた。顧客の ISP・企業網で IPv6 の不具合が Happy Eyeballs に隠されてしまう。「どのペルソナが最重要か」「各ペルソナへどう報告するか」の議論が WG に欠けている。メーリングリストで議論しないとまた 9 年経つ。→ Philipp は「重要度より、セキュリティ／プライバシー上どのペルソナなら現実的に対応できるかで考えるべき」と補足
7. Enhanced Dual Stack (Xipeng Xiao) — As Time Permits
draft-xiao-v6ops-eds-01。企業の IPv6 導入を加速するための提案。
- 問題意識: 現在のデュアルスタックは RFC 6724 のルールベース選択で性能を見ないため、IPv6 が劣化していても選ばれ得る。そのため導入前に重い事前検証が必要になり「一発勝負」のリスクが高い
- EDS の目標: 「IPv6 が動くなら IPv6、動かないなら IPv4」を保証し、なぜ IPv6 が選ばれなかったかの情報を提供して、低リスクで導入して問題は後から直せるようにする
- 3 つの強化:
- OS / プラットフォームレベルの HEv3 プロファイル（アプリがコード変更なしに HEv3 の恩恵を受ける）— HAPPY
- 従来型アプリ (
getaddrinfo()+socket()+connect()) 向けの互換パス — v6ops / 6man。RFC 6724 の「性能を考慮してよい」を「すべき」に変え方法も規定。リアルタイムのレースは行わない - 選択的診断 — どのアドレスファミリが試行・選択されたか、失敗/レース敗北/ポリシー/履歴による非優先化のいずれかを示す
- HAPPY WG への依頼: (1) HEv3 の OS/プラットフォーム実装プロファイルの定義（HEv3 ドラフト内か別ドキュメントかは WG が判断）、(2) IPv6 が使われなかった場合の選択的運用診断の意味論の定義（テレメトリプロトコルではない。プライバシー、認可、データ最小化を含める）
8. チェアのまとめ (Tim Chown, Eric Kinnear)
- 主要ドラフトはコンセンサスに近づいている。週内にさらに議論し、2〜3 週間で IPv6 関連部分を含めてドラフトに反映したい。その後 WG Last Call を検討
- 実装者には、Max が明示したような「ドラフトからの逸脱点」を各実装からも出してほしい。単なるデフォルト値の調整なのか、より本質的な差異なのかを見極めたい
- レポーティングのテーマも前進させる必要がある
- チャーター上のマイルストーンは 7 月末だが達成できない。AD からは期限延長で問題ないとの確認を得ている
主要なアクションアイテム
- PR #137（IPv6-only / NAT64 ガイダンス）に split-tunnel VPN の記述を戻し、レビューを経てマージ
- PR #133（DNS サーバ選択）は投票結果を踏まえ縮小方向で改訂
- PR #138（指数バックオフ）の検討、Resolution Delay / Connection Attempt Delay のデフォルト値を実測データに基づき再検討
- PR #125（接続シーケンスのステートマシン明示化）のレビュー
- IPv6 ヘッダ長 vs フラグメンテーションに関する MTU 記述の確認
- 各実装からドラフトとの逸脱点を報告
- Optimistic DNS の dispatch（HAPPY か DNSOP か）を調整
- エラーレポーティングのペルソナ優先順位をメーリングリストで議論