Zusammenfassung

  • Happy Eyeballs verkürzt sichtbare Wartezeit durch überlappende Versuche; der Sieger belegt nur seine eigene Erreichbarkeit.
  • DNS-Ankunft, Reihenfolge, Start, Fehler und Abbruch müssen je Adressfamilie erhalten bleiben.
  • Anwendungserfolg und störungsfreier IPv4- und IPv6-Betrieb sind verschiedene Aussagen.

Ein Beispiel verdeutlicht das Problem: AAAA und A treffen ein, IPv6 startet, IPv4 folgt und gewinnt; die Seite lädt normal. Nutzer und ein Dashboard aus abgeschlossenen Sitzungen sehen keinen Ausfall. IPv6 könnte aber ein Pfad- oder Dienstproblem haben – oder nur vor einer möglichen Antwort abgebrochen worden sein. Der Gewinner unterscheidet diese Fälle nicht.

RFC 8305 beschreibt das Rennen, aus dem diese Mehrdeutigkeit entstehen kann: A und AAAA werden asynchron aufgelöst, Ziele nach RFC 6724 sortiert, Adressfamilien abwechselnd angeordnet und Versuche zeitversetzt gestartet. Nach dem ersten Erfolg werden übrige Versuche abgebrochen. Nach redaktioneller Einschätzung dieses Artikels kann der Mechanismus die Verfügbarkeit schützen, weil ein defekter Kandidat dem Nutzer nicht seinen vollen Timeout auferlegt.

Ein nach IPv4-Erfolg abgebrochener IPv6-Versuch ist jedoch weder Erfolg noch zwingend Fehler, sondern zensierte Beobachtung. Auch beweist ein IPv4-Sieger keine IPv4-Präferenz. DNS-Reihenfolge, RFC-6724-Politik und historische Laufzeiten beeinflussen das Rennen.

Die oft genannten 250 Millisekunden sind kein universelles Ziel. RFC 8305 nennt sie als empfohlenen Standardwert für den Abstand zwischen Verbindungsversuchen, erlaubt Anpassung und setzt Grenzen. Dieser Wert ist zudem von der Verzögerung der Namensauflösung getrennt. Ein belastbarer Beleg braucht tatsächliche Werte und Zeitpunkte, nicht nur „aktiviert“.

Der Standard nennt das Verbergen betrieblicher Probleme ausdrücklich als Grenze. Rennen sollten nicht abgeschaltet werden; stattdessen müssen Verliererpfade messbar bleiben, ohne Nutzer warten zu lassen. Pro Episode gehören Netzkontext, Resolverpfad, A/AAAA-Zeitpunkte, Kandidatenfolge, Familie, konfigurierter Resolution Delay, konfigurierter oder angepasster Connection Attempt Delay, tatsächlicher Startversatz, Handshake-Stand, Ergebnis jedes Versuchs, Anwendungsergebnis, Abbruchgrund, Sieger sowie Netzgeltungsbereich und Lebensdauer der verwendeten zwischengespeicherten Verbindungshistorie zusammen.

Als redaktionelle Betriebsempfehlung sollten diese Daten nur befristet aggregiert werden, um die Datenschutzexposition zu begrenzen.

RFC 6555 entstand aus Verzögerungen durch defektes IPv6. RFC 8305 verbessert die Abhilfe, zertifiziert aber nicht die verlierende Familie. RFC 6724 beschreibt Auswahlpolitik, keine Erreichbarkeitsmessung.