Zusammenfassung

  • A und AAAA liefern Kandidaten, aber keinen Beweis dafür, dass der jeweilige Pfad vom aktuellen Client aus funktioniert.
  • RFC 6555 machte aus der IPv6-Präferenz einen begrenzten Vorsprung. RFC 8305 verfeinerte ihn durch asynchrone DNS-Abfragen, RFC-6724-Sortierung, Familienwechsel und zeitversetzte, überlappende Versuche.
  • Der erste abgeschlossene Aufbau gewinnt nur diese Verbindung. Der unauffällige Rückfall schützt Nutzer und kann zugleich einen dauerhaft kaputten Protokollpfad vor dem Betreiber verbergen.

DNS kannte das Ziel, nicht den Weg

Schon RFC 1671 beschrieb 1994 das Auswahlproblem des Dual Stack. Ein Name konnte IPv4- und IPv6-Adressen liefern, obwohl irgendwo ein Router IPv6 verwarf, ein Tunnel ausgefallen war oder der Dienst hinter dem AAAA-Eintrag nicht antwortete.

Der Datensatz musste nicht falsch sein. Er nannte eine Adresse, aber keine gegenwärtige Ende-zu-Ende-Erreichbarkeit. Ein serieller Client machte aus diesem Unterschied Wartezeit: IPv6-SYN senden, mehrere Wiederholungen abwarten, danach die funktionierende IPv4-Adresse probieren. Das leistungsfähigere System fühlte sich schlechter an als der alte IPv4-Client. Wer IPv6 abschaltete, beseitigte den Schmerz und schwächte damit gerade den Übergang, den die Präferenz fördern sollte.

Getrennte Hostnamen hätten den gemeinsamen Namensraum gespalten. Manuelle Positivlisten konnten wechselnde Fehler auf verschiedenen Zugangswegen nicht zuverlässig abbilden. Der fehlende Sachverhalt entstand erst beim tatsächlichen Aufbau.

Vorrang wurde zum Startvorsprung

RFC 6555 standardisierte Happy Eyeballs 2012. Es hob die Adresspolitik des Hosts nicht auf. IPv6 blieb gewöhnlich an erster Stelle. Wenn der bevorzugte Versuch jedoch nicht rechtzeitig vorankam, durfte ein Versuch über die andere Familie beginnen, während der erste noch lief.

Die Politik bestimmt damit das erste Experiment; beobachtbare Ausführung bestimmt den Träger dieser Sitzung. Vorrang ist kein unbefristetes Blockaderecht mehr.

Überlappung verbraucht Ressourcen. Jeder weitere Verbindungsversuch kann Serverzustand, Firewall-Einträge, NAT-Ports und Leitungskapazität beanspruchen. Deshalb verlangt das Verfahren Taktung und das Aufgeben der Verlierer. Ein völlig neutraler Schnellster-gewinnt-Wettbewerb hielte unnötige Last auf gemeinsamem IPv4; eine absolute IPv6-Regel ließe Nutzer für fremde Fehler zahlen.

Auch gelernter Misserfolg ist vorläufig. RFC 6555 erlaubt, eine gescheiterte Familie zeitweise zurückzustellen, fordert aber regelmäßige neue Versuche der bevorzugten Familie und nennt ungefähr zehn Minuten als Größenordnung. Beim Netzwechsel wird der Zustand verworfen. Das kaputte IPv6 eines Flughafens ist keine Evidenz für das Büro.

Version 2 begann schon bei der Auflösung

RFC 8305 ersetzte 2017 die erste Fassung. Das Verfahren besteht nun ausdrücklich aus asynchronen DNS-Abfragen, Sortierung der Ziele, asynchronen Verbindungsversuchen und der Wahl genau einer Verbindung mit Abbruch der übrigen.

AAAA und A werden fast unmittelbar nacheinander abgefragt, AAAA zuerst. Trifft A zuerst ein, erhält AAAA eine kurze Chance; empfohlen sind 50 Millisekunden Auflösungsverzögerung. So bewahrt IPv6 einen kleinen Vorsprung, ohne dass eine späte Antwort eine bereits bekannte IPv4-Adresse lange festhält.

Die bekannten Ziele werden zunächst nach RFC 6724 sortiert. Verwendbare Quelladresse, Geltungsbereich, Kennzeichnung und lokale Politik beeinflussen die Reihenfolge. Der Listenanfang ist trotzdem kein Erreichbarkeitszertifikat.

Danach werden die Familien verschränkt. Beginnt die Liste mit IPv6, rückt der beste IPv4-Kandidat normalerweise an die zweite Stelle. Eine lange Reihe defekter AAAA-Adressen darf nicht sämtliche Wartefenster verbrauchen, bevor das erste A getestet wird.

Die Versuche starten einzeln, dürfen anschließend aber parallel offen bleiben. RFC 8305 empfiehlt 250 Millisekunden als Standardabstand. Unter 10 Millisekunden ist verboten; 100 Millisekunden werden als Mindestwert und zwei Sekunden als Höchstwert empfohlen. Diese empirischen Werte sind konfigurierbar und sollen sich mit den Netzen verändern dürfen.

Historische Laufzeiten oder eine früher genutzte Adresse können die Ordnung verfeinern. Solcher Zustand darf nicht zwischen Netzschnittstellen wandern und soll beim Wechsel der Anbindung verschwinden. Sobald ein Aufbau gelingt, werden andere Versuche abgebrochen. Späte DNS-Antworten können noch den Cache füllen, entscheiden diese Verbindung aber nicht neu.

Ein gewonnener Handshake beweist wenig

Happy Eyeballs behandelt den anfänglichen Transportaufbau. Ein erfolgreicher TCP-Handshake garantiert weder TLS noch HTTP noch die Übertragung großer Pakete. RFC 8305 warnt ausdrücklich vor Path-MTU-Problemen, die erst nach dem Handshake sichtbar werden.

Die Siegeradresse authentisiert auch keinen Dienst. DNS-Antworten können wechseln, und zwei Verbindungen zu demselben Namen können verschiedene IP-Adressen benutzen. Identität braucht die dafür zuständige Sicherheitsschicht.

Der größte betriebliche Preis ist verlorene Sichtbarkeit. Scheitert IPv6 ständig und übernimmt IPv4 nach einer Viertelsekunde, bleibt die Anwendung benutzbar. Der Fehler bleibt bestehen, doch der Nutzer meldet ihn nicht. Deshalb verlangt das Dokument eine unabhängige Überwachung jeder Familie.

Quellen und Grenzen

Die geschlossene Grundlage bilden RFC 1671, RFC 6555, RFC 6724 und RFC 8305. Sie liefern weder aktuelle Implementierungsanteile noch eine weltweit optimale Verzögerung oder eine globale Qualitätsrangfolge der Protokollfamilien.