Zusammenfassung

  • Happy Eyeballs schützt Nutzer, indem es Alternativen versucht, ohne lange auf eine langsame oder defekte Familie zu warten. So kann die Gesamtquote grün bleiben, während IPv6 ausfällt.
  • Betreiber brauchen Nachweise je Familie: DNS-Antworten, Kandidaten, tatsächliche Versuche, Gewinnerfamilie, Fehler der Verlierer und erzwungene Tests in repräsentativen Zugangsnetzen.

Nehmen wir ein ausdrücklich hypothetisches Bild. Der Hauptmonitor ist grün, Transaktionen enden erfolgreich und der Support meldet keine Störung. Ein zweiter, auf IPv6 festgelegter Test aus einem bestimmten Zugangsnetz kann keine Verbindung herstellen. Beides kann stimmen. Der normale Client erhielt A und AAAA, begann mit IPv6 und stellte danach schnell genug IPv4 her, dass der Nutzer nur wenig Verzögerung bemerkte.

Das ist keine Behauptung über einen benannten Netzbetreiber. Es zeigt eine Messgrenze. Eine erfolgreiche Transaktion beweist, dass mindestens ein Pfad funktioniert hat, nicht die Gesundheit aller veröffentlichten Adressfamilien.

RFC 8305 definiert Happy Eyeballs v2, um sichtbare Verzögerungen zu reduzieren, wenn Adressen oder ganze Familien blockiert, defekt oder suboptimal sind. Der Client fragt A und AAAA asynchron ab, sortiert Ziele, staffelt Verbindungsversuche und behält die erfolgreiche Verbindung. Die übrigen Versuche werden abgebrochen. IPv6 wird grundsätzlich bevorzugt, doch das unmittelbare Ziel ist Kontinuität.

Die empfohlenen Zeitwerte erklären, warum der Fehler verborgen bleiben kann. RFC 8305 nennt 50 ms Auflösungsverzögerung und 250 ms zwischen Versuchen ohne historische RTT-Daten. Implementierungen dürfen diese Werte anpassen und frühere Leistung berücksichtigen. Sie sind kein allgemeines Clientversprechen. Entscheidend ist das Rennen: Ohne Telemetrie der verlorenen Versuche sagt die Gewinnerverbindung wenig über deren Zustand.

RFC 6724 ergänzt die Auswahl von Quell- und Zieladressen über IPv6 und IPv4 und erlaubt administrative Abweichungen. Zwei Geräte können für denselben Namen unterschiedliche Reihenfolgen und Pfade wählen, abhängig von Umfang, verfügbarer Quelle, Konfiguration oder bekannter Erreichbarkeit.

Eine zusammengefasste HTTP-Erfolgsquote presst alle Entscheidungen in ein Bit. Sie zeigt nicht, ob AAAA eintraf, welche IPv6-Adresse versucht wurde, wie lange sie wartete oder ob DNS, Neighbor Discovery, Routing, Filter, Path MTU oder der Dienst versagte. Ebenso bleibt offen, ob IPv4 beabsichtigt oder als Rettung gewann.

Der Mindestdatensatz enthält A/AAAA-Antworten und Zeiten, geordnete Kandidaten, Quell- und Zielfamilie, Start und Ende jedes Versuchs, Fehler oder Timeout, Gewinnerfamilie, Resolverpfad, Zugangs-ASN oder Kohorte, Ziel-Edge, Anwendungsergebnis, Clientimplementierung und Beobachtungszeit. Rückfall allein belegt keine Ursache.

Kombinieren Sie den normalen Dual-Stack-Test mit erzwungenen IPv6- und IPv4-Sonden. Der normale Test schützt die Nutzerreise; die festen Tests prüfen jede Oberfläche. Dual-Stack-Erfolg plus IPv6-Fehlschlag bedeutet „verfügbar, aber beeinträchtigt“, nicht „vollständig gesund“.

Quellen