Happy Eyeballsとは
Happy Eyeballsは、IPv6とIPv4の接続候補を適切な間隔で並行して試し、その時点で先に利用可能になった経路を選ぶクライアント側の接続手順です。読み方はHappy Eyeballs（ハッピー・アイボールズ）です。現在の基本仕様はRFC 8305のHappy Eyeballs Version 2です。
IPv6を優先順の先頭に置くだけでは、IPv6経路が壊れていると接続完了まで長く待つことがあります。反対に最初からIPv4だけを使えば、正常なIPv6を活用できません。そこで、第一候補を尊重しつつ、待ち時間が長引く前に別のアドレスファミリーも試すという考え方を採ります。
名称に「目」が入っていますが、人を識別する機能ではありません。ネット利用者が接続方式を意識せず、素早く接続できる状態を表した名前です。
名前解決から接続確定までを一つの流れで扱う
- 1
- 2候補を並べ替える
端末のアドレス選択規則を適用し、IPv6とIPv4の候補を交互に試せる順へ整える
- 3時間差で接続を開始
先行候補を試し、未完了なら短い遅延後に次候補も開始する
- 4最初の成功を採用
利用できる接続を残し、不要になった他の試行を取り消す
IPv6とIPv4の候補を交互に並べる
名前解決で複数のアドレスが返ると、端末はRFC 6724などの規則で候補を選びます。Happy Eyeballs v2は、一方のファミリーだけをすべて試してから他方へ進むのではなく、IPv6とIPv4が交互に現れる候補列を作ります。これにより、先頭のIPv6アドレスだけが不調でも次のIPv4候補へ早く進めます。
次の試行を開始しても、先の試行を直ちに中止するわけではありません。複数の試行を短時間だけ重ね、接続が先に完成したものを勝者にします。DNS応答が片方だけ先に届いた場合も、もう片方を無期限には待ちません。
過去の速さは参考にするが、ネットワーク変更後は引き継がない
実装は、宛先ごとの往復時間や以前に成功したファミリーを記憶し、次の候補順や遅延の調整に利用できます。ただしWi-Fiから携帯回線へ切り替われば、到達経路も品質も変わります。RFC 8305は、ネットワーク変更時にこのような履歴を消すことを求めています。
この手順は「常にIPv6が速い」「常にIPv4へ逃がす」という判定ではありません。接続ごとに利用可能性を確認し、端末の優先方針と現実の到達結果を両立させます。
便利だからこそ、壊れたIPv6を見逃すこともある
IPv6経路が壊れていてもIPv4がすぐ成功すれば、利用者は問題に気づかないことがあります。Happy Eyeballsは体感を改善しますが、ネットワーク障害そのものを修復する機能ではありません。運用者はIPv4とIPv6を個別にも監視する必要があります。
DNS64とNAT64を使うIPv6ネットワークでも、合成AAAAをIPv6候補として扱えます。ただしIPv4アドレスをアプリケーションへ直接書いた場合などは、名前解決を前提とした処理が使えず、別の互換機構が必要になることがあります。
仕様の確認資料：RFC 8305「Happy Eyeballs Version 2」、RFC 6724「Default Address Selection for IPv6」