Happy Eyeballs Version 2 の仕様

IPv4IPv6両方が利用可能なデュアルスタック環境において、通信する際にIPv6IPv4を並列的に試してより早く通信の確立が出来た方を試す Happy Eyeballs という仕組みがあります。

より環境の良い方を使うだけでなく、IPv6で通信を試みてからうまくいかない場合にIPv4にフォールバックするのでは無いためより早く通信通信の確立ができます。

Happy EyeballsはRFC 6555で標準化されておりますが、Appleの人によって提案されているHappy Eyeballs Version 2の仕様がIETFで議論されているので簡単に読みます。

Happy Eyeballs Version 2

Happy Eyeballs Version 2は、RFC 6555の頃より何点か変更があります。

まず、大きなところで、名前解決について非同期名前解決の方式が追加されました。今まで名前解決についての規定はありませんでした。AとAAAAを同期的に名前解決する実装もありましたが、早く名前解決出来た方から通信を開始すべき(SHOULD)ということになりました。

従来実装

提案方式

(3月に行われたIETF98の資料(pdf)より)

この非同期式名前解決が実施できない場合は(APIがない場合)、IPアドレスファミリごとに別スレッドを使って同等の事ができる。

その他

  • Happy Eyeballs中に、名前解決の結果が変わった場合の対応について。削除された場合は施行を継続、アドレスが増えた場合は適宜施行リストに追加
  • 以前の通信結果(IPアドレス毎のRTTや、以前TCP Fast Openを使った)などにより、通信施行順番の変更が可能に
  • NAT64 と DNS64を持つIPv6 only環境について

今後

3月に行われたIETF98では、議事録を読む限り興味を持ってる人も多く、またその後にWG Draftに昇格していることからも引き続きホットな議論になるものと思われる。

今月7月に行われるIETF99のv6ops WGのAgendaにもHappy Eyeballs Version 2の議論が行われる予定と鳴っている。