Happy Eyeballs Version 2 (RFC 8305)
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 : ネットワーク処理において犯しがちな誤りの回避）
最近のエントリ
- 「ピアリング戦記」の英訳版EPUBを無料配布します！
- IPv4アドレス移転の売買価格推移および移転組織ランキング100
- 例示用IPv6アドレス 3fff::/20 が新たに追加
- ShowNet 2024のL2L3
- ShowNet 2024 ローカル5G
- ShowNetのローカル5G企画（2022年、2023年）
過去記事
