要約

  • 2012年のRFC 6555はアドレスファミリー間の短い競争を示し、2017年のRFC 8305はDNS、宛先の並べ替え、時間差接続、取り消しを一体化したスケジューラーへ発展させた。
  • 推奨値250ミリ秒は単なる高速化の定数ではなく、利用者の待ち時間と投機的な接続負荷を交換する制御値である。
  • 最初のTCP/IP接続障害は隠せても、アプリケーション層の障害は直せず、負け続ける経路を運用者が修復する動機まで弱めかねない。

デュアルスタック移行では、正しい優先順位が必ずしも正しい体験を生まない。ホストがIPv6とIPv4の宛先を受け取り、設計どおりIPv6を先に選んでも、その経路が遅い、あるいは壊れていれば、利用者は利用可能なIPv4が後ろに控えているのに待たされる。2012年4月にProposed Standardとして公開されたRFC 6555は、この不一致をクライアント内部で吸収しようとした。

例示アルゴリズムは、ホストのアドレス優先順を維持したまま最初の接続を開始する。短い時間を置いて別のアドレスファミリーの先頭候補も開始し、最初に確立した接続を採用して他方を捨てる。当時のFirefoxとChromeは300ミリ秒を使っていた。履歴がなければIPv6を優先し、長い移行期間に不必要なIPv4負荷を生まないことも求められた。

ここで時間は資源になる。間隔が長すぎれば、利用者は優先経路の故障コストを負担する。短すぎれば、本来は一回で成功した接続まで二本目を走らせ、パケット、ソケット、サーバー処理を余計に消費する。待ち時間を減らすほど、クライアントは冗長な作業を保険料として払う。

大規模な配備と測定を経て、問題は二つのアドレスと一つのタイマーでは表せないことが明らかになった。2017年12月にProposed Standardとして公開されたRFC 8305はRFC 6555を廃止し、処理を四段階に整理した。DNS問い合わせを非同期で送り、得られた全宛先を並べ、非同期の接続試行を時間差で開始し、一つの成功を残して他を取り消す。

競争はDNSから始まる。RFC 8305はAAAAを先に送り、その結果を待たず直後にAを送ることを推奨する。Aが先に返った場合は、推奨50ミリ秒のResolution DelayでAAAAに短い猶予を与える。両方を常に待つのでも、最初のDNS応答にアドレスファミリーを決めさせるのでもない。接続処理中に新しい回答が届けば、候補へ追加できる。

次の制御面は宛先順である。宛先アドレス選択が基本順を与え、実装は同じネットワークでの過去のRTTや以前の利用実績を考慮できる。アドレスファミリーを交互に混ぜることで、一方に不調なアドレスが複数あっても、そのすべてが他方の試行を塞がない。履歴はネットワーク文脈に結び付ける必要があり、あるWi-Fiの勝者を別の回線へ無条件に持ち込めない。

RFC 8305のConnection Attempt Delayは既定で250ミリ秒が推奨される。推奨最小値は100ミリ秒で、10ミリ秒未満にはしてはならず、推奨最大値は2秒である。First Address Family Countの推奨値は1だ。いずれも実測に基づく調整可能な値であり、ネットワークの変化に応じた見直しが想定される。短くすれば裾の待ち時間を削れるが並行処理が増え、長くすれば負荷を抑える代わりに誤った優先順が利用者へ露出する。

RFC 8305は複数アドレス、途中で変わるDNS回答、履歴情報、NAT64/DNS64を使うIPv6-onlyネットワークまで扱う。ただし境界は明確だ。対象は最初のTCP/IP接続失敗であり、転送路が確立しても上位アプリケーションが正常とは限らない。競争に負けた経路そのものも修理しない。

その結果、利用者の成功とネットワークの健康が分離する。RFC 6555は、ファミリー別の障害診断が難しくなると既に認めていた。RFC 8305でも、経路MTUなどの運用障害が別経路の成功で隠れる可能性が示される。画面が開けば利用者は満足するが、故障を所有する運用者には十分な苦情が届かないかもしれない。

Happy Eyeballsは、IPv6優先を維持しながら利用者を移行期の試験員にしない互換性契約である。同時に、IPv4を保険として残す。保険がよく機能するほど、IPv4の希少な資源を保持し、負けるIPv6経路の修復を遅らせる誘因も生じる。スケジューラーが決められるのは各接続の順序と時刻であり、移行の終わりではない。