Zusammenfassung

  • RFC 6555 beschrieb 2012 ein kurzes Rennen zwischen Adressfamilien; RFC 8305 ersetzte dieses Modell 2017 durch einen Scheduler für DNS, Zielsortierung, versetzte Verbindungsversuche und Abbruch.
  • Die empfohlenen 250 ms sind ein Verteilungsschlüssel zwischen wahrgenommener Wartezeit und spekulativer Netzlast, kein zeitloser Beschleunigungswert.
  • Das Verfahren überbrückt anfängliche TCP/IP-Fehler, kann aber defekte Pfade verdecken, IPv4-Abhängigkeiten verlängern und behebt keine Fehler der Anwendungsschicht.

Happy Eyeballs entstand aus einem Widerspruch der Dual-Stack-Migration. Ein Host erhält IPv6- und IPv4-Ziele, bevorzugt wie vorgesehen IPv6 und lässt den Nutzer dennoch warten, wenn dieser Pfad langsam oder defekt ist. Eine funktionierende IPv4-Alternative liegt bereit, kommt aber zu spät an die Reihe. RFC 6555 wurde im April 2012 als Proposed Standard veröffentlicht und verlagerte diese Wartezeit in eine Entscheidung des Clients.

Der Beispielalgorithmus behielt die Adresspräferenz des Hosts bei. Er startete den ersten Verbindungsversuch und nach einer kurzen Frist die erste Adresse der anderen Familie. Firefox und Chrome verwendeten damals 300 ms. Die zuerst aufgebaute Verbindung blieb bestehen, die andere wurde verworfen. Ohne Verlaufsdaten blieb IPv6 bevorzugt; zugleich warnte der Text vor unnötiger IPv4-Last während einer langen Übergangsphase.

Der Timer war damit von Anfang an ein ökonomischer Regler. Ist er zu lang, trägt der Nutzer die Kosten eines schlechten bevorzugten Pfads. Ist er zu kurz, lösen selbst gesunde Verbindungen regelmäßig einen zweiten Versuch aus und verbrauchen Pakete, Sockets und Serverarbeit. Der Client kauft weniger Wartezeit mit redundanter Kapazität.

Nach breiter Einführung und Messung zeigte sich, dass zwei Adressen und eine Uhr die Wirklichkeit nicht abbilden. RFC 8305 erschien im Dezember 2017 ebenfalls als Proposed Standard und setzte RFC 6555 außer Kraft. Er beschreibt vier verbundene Phasen: asynchrone DNS-Anfragen, Sortierung aller aufgelösten Ziele, zeitlich versetzte asynchrone Verbindungsversuche sowie das Behalten eines Erfolgs und Abbrechen der übrigen Versuche.

Das Rennen beginnt bereits im DNS. RFC 8305 empfiehlt, AAAA zuerst und A unmittelbar danach abzufragen, ohne die erste Antwort abzuwarten. Trifft A zuerst ein, gibt ein empfohlener Resolution Delay von 50 ms AAAA eine kurze Chance. Weder müssen beide Antworten grundsätzlich abgewartet werden, noch darf die schnellste DNS-Antwort automatisch die Adressfamilie festlegen. Später eintreffende Antworten können während des Verbindungsaufbaus ergänzt werden.

Die Sortierung bildet die nächste Kontrollfläche. Die Zieladressauswahl liefert die Grundordnung. Eine Implementierung darf historische RTT-Werte oder frühere Nutzung im selben Netz berücksichtigen. Die Familien werden ineinander verschachtelt, damit mehrere unbrauchbare Ziele einer Familie nicht die ganze Liste blockieren. Historie ist an den Netzkontext gebunden: Was in einem Netz gewann, ist im nächsten nicht zwingend die beste Wahl.

RFC 8305 empfiehlt 250 ms als voreingestellten Connection Attempt Delay. Als Minimum werden 100 ms empfohlen; niemals darf der Wert unter 10 ms liegen. Das empfohlene Maximum beträgt zwei Sekunden, der empfohlene First Address Family Count eins. Diese Werte beruhen auf empirischen Messungen und dürfen sich mit den Netzen verändern. Kürzere Abstände reduzieren die sichtbare Ausfalllatenz und erhöhen parallele Arbeit. Längere Abstände sparen Last und machen eine falsche Präferenz länger spürbar.

Der Scheduler berücksichtigt mehrere Adressen, während des Aufbaus wechselnde DNS-Antworten, historische Informationen und IPv6-only-Netze mit NAT64/DNS64. Seine Grenze bleibt klar: Er behandelt den anfänglichen TCP/IP-Verbindungsfehler. Eine erfolgreiche Transportverbindung garantiert keine funktionierende Anwendung, und der unterlegene Pfad wird nicht repariert.

Daraus entsteht ein Beobachtungsproblem. RFC 6555 erkannte bereits, dass Rennen Fehler einzelner Adressfamilien schwerer diagnostizierbar machen. RFC 8305 hält an dieser Warnung fest; Betriebsfehler wie Path-MTU-Probleme können hinter einem erfolgreichen Alternativpfad verschwinden. Der Nutzer bekommt den Dienst, während dem verantwortlichen Betreiber womöglich die Beschwerde fehlt, die eine Untersuchung ausgelöst hätte.

Happy Eyeballs ist deshalb ein Kompatibilitätsvertrag. Der Client übernimmt etwas spekulative Arbeit, um IPv6-Präferenz und gute Nutzererfahrung zu verbinden. IPv4 bleibt eine Versicherung samt knappen Adressen und Betriebskosten. Eine wirksame Versicherung verändert Anreize: Schneller Fallback reduziert den Druck, schwaches IPv6 zu reparieren, und verfestigt Gründe, IPv4 vorzuhalten. Der Scheduler verwaltet den Übergang, kann aber dessen Ende nicht bestimmen.