要約

  • Happy Eyeballs は候補接続を重ねて待ち時間を減らすが、勝者が証明するのはその候補の到達性だけだ。
  • DNS 到着時刻、候補順序、開始時刻、失敗、取消理由をファミリー別に残す必要がある。
  • アプリの成功とデュアルスタックの健全性は別の運用上の主張である。

一つの例を考えよう。AAAA と A が得られ、IPv6 の後に IPv4 が開始され、IPv4 が先に完了してページは平穏に表示される。利用者には停止がなく、成功セッションだけを見る画面も緑のままだ。しかし IPv6 は経路やサービスの問題を抱えているかもしれず、応答前に取り消されただけかもしれない。確立された接続だけでは区別できない。

RFC 8305 は、この観測上の曖昧さが生じ得る接続レースの挙動を定めている。A と AAAA を非同期に解決し、RFC 6724 で宛先を並べ、ファミリーを交互にし、時間差で試行する。一つが成功すれば残りを取り消す。本稿の編集上の評価では、壊れた候補の全タイムアウトを利用者に負わせず、可用性を守り得る仕組みである。

ただし IPv4 勝利後の IPv6 の「取消」は成功でも必ずしも失敗でもない。競争によって打ち切られた観測だ。IPv4 勝利も IPv4 優先を意味しない。DNS の順序、RFC 6724 の方針、過去の RTT が結果を変える。

よく引用される 250 ミリ秒は普遍的な目標ではない。RFC 8305 が接続試行間隔の既定値として推奨する一例であり、適応と安全境界がある。A が AAAA より先に届くときの解決待ちとも別である。したがって証跡には「有効」という印ではなく、実際の設定値と時刻が必要だ。

RFC 8305 自身が運用問題を隠す限界を挙げている。レースを止めるのではなく、利用者を待たせず敗者側を測るべきだ。ネットワーク状況、リゾルバ経路、A/AAAA 到着、候補順、ファミリー、設定された Resolution Delay、設定値または適応後の Connection Attempt Delay、実際の開始差、ハンドシェイク段階、各試行の結果、アプリケーションの結果、取消理由、勝者に加え、利用した接続履歴キャッシュのネットワーク適用範囲と有効期間を一つの接続単位で残す。編集上の運用提案として、プライバシーへの露出を抑えるため保存期間と集計粒度を制限する。

RFC 6555 は壊れた IPv6 による遅延を減らす発想から始まった。RFC 8305 はその救済を改善したが、救済されたセッションを敗者側の健全性証明にはしていない。RFC 6724 も選択方針であり、到達性測定ではない。