Happy Eyeballs Version 2 (RFC 8305)

   このエントリをはてなブックマークに登録    2017/12/22-1

Happy Eyeballs Version 2のRFC 8305が発行されました。 RFC 8305は、Happy Eyeballs (Version 1)を定義していたRFC 6555を上書き廃止するので、旧Happy Eyeballsが廃止されたうえで、Version 2の利用が推奨されることになります。

RFC 8305のAppendix AにRFC 6555との違いがまとめらています。RFC 8305とRFC 6555の違いは以下のようなものです。

  • how to perform DNS queries to obtain these addresses
  • how to handle multiple addresses from each address family
  • how to handle DNS updates while connections are being raced
  • how to leverage historical information
  • how to support IPv6-only networks with NAT64 and DNS64

(意訳等)
  • IPアドレスを得るためのDNSキュエリーを行う方法
  • 各アドレスファミリ毎に複数のIPアドレスがある場合の処理
  • DNSに関連するアップデートがコネクション確立試行中に発生した場合の処理(IETFで議論中のDNSプッシュ(draft-ietf-dnssd-push-13)やTTL切れに関して書かれています)
  • 過去の通信履歴を利用する方法(過去の通信時のRTT等を使うなど)
  • NAT64とDNS64によるIPv6-onlyネットワークをサポートする方法

Version 2は、Version 1で定義されているアルゴリズムに沿うものでありつつ、さらに品質を向上させたものであると書かれています。 Version 1は、DNSを利用した名前解決の結果が出た後で、どのようにTCP接続を行うかという内容でしたが、Version 2ではDNSサーバに対する問い合わせに関しても言及しています。

Version 2では、まず最初にIPv6のAAAAレコードの問い合わせを行ったのちに、ただちにIPv4のAレコードの問い合わせを行うべきであるとしています。

2015年の中旬に話題になったAppleがOS X El Captainで実装した手法は、IPv4とIPv6の両方に対する名前解決を行いつつ、最初に届いた結果がIPv4であれば、25ms待ってからTCP接続確立を試みるなど、IPv6を優先的に使うようというものでした。 RFC 8305(Version 2)では、同様の内容でIPv6のために50ms待つことを推奨しています。

getaddrinfo?

ソケットAPIを使う場合、Happy Eyeballs Version 2に対応するためには、同期APIであるgetaddrinfo()を使わずに、名前解決の非同期APIを使うことになります。 しかし、非同期APIであるgetaddrinfo_a()はGNU拡張です。 IPv6用の基本的なソケットAPIを定義したRFC 3493には、同期APIのgetaddrinfo()しかないのです。

ただ、そもそも、POSIXネットワーク処理を直接使わないことの方が今は多そうです。 たとえば、iOSでは、メインスレッドではgetaddrinfo()やgetnameinfo()などの同期型のPOISXネットワーク処理を使わないようにとあるので、特に問題なくHappy Eyeballs Version 2に対応できそうです。 (参考 iOS Developer Library : ネットワーク処理において犯しがちな誤りの回避

   このエントリをはてなブックマークに登録