Die halbe Nutzerbasis wird bislang nicht mitgemessen
Google erhebt seit 2008 laufend, welcher Anteil der eigenen Nutzer den Dienst nativ über IPv6 erreicht. Die Kurve hat sich in zehn Jahren mehr als vervierfacht: Im Jahresmittel lag der Anteil 2016 bei 11,0 Prozent, 2020 bei 29,9 Prozent, 2024 bei 43,4 Prozent und 2026 bislang bei 47,0 Prozent (Google, IPv6 Adoption Statistics). Aussagekräftiger als das Jahresmittel ist der Tagesverlauf: Am 28. März 2026 wurde mit 50,1 Prozent zum ersten Mal ein Tageswert oberhalb von 50 Prozent gemessen, seither ist das an mehreren Tagen wieder vorgekommen, zuletzt mit 50,9 Prozent am 18. Juli 2026 (Google, IPv6 Adoption Statistics).
Eine zweite, methodisch unabhängige Messreihe kommt von APNIC Labs, dem Forschungsbereich der Regional Internet Registry für den asiatisch-pazifischen Raum. Sie misst nicht den Zugriff auf einen einzelnen Dienst, sondern über verteilte Messkampagnen, welcher Anteil der Endgeräte IPv6 überhaupt nutzen kann und welcher Anteil IPv6 tatsächlich bevorzugt, wenn beide Protokollversionen angeboten werden. Weltweit sind demnach 41,9 Prozent der Nutzer IPv6-fähig und 40,0 Prozent bevorzugen IPv6 (APNIC Labs, IPv6 Capability Measurement, Stand 21. Juli 2026). Für Deutschland liegen die Werte bei 72,1 Prozent IPv6-fähig und 71,1 Prozent IPv6-bevorzugend (APNIC Labs, IPv6 Capability Measurement). Zwei Erhebungen, zwei Verfahren, dasselbe Bild: Der IPv6-Pfad ist in Deutschland der Regelfall, nicht die Ausnahme.
| Land | Nativer IPv6-Anteil | Was das für den Betrieb bedeutet |
|---|---|---|
| Frankreich | 86,3 % | Nahezu jede Anfrage aus dem Endkundennetz beginnt mit einem AAAA-Lookup (Google, IPv6 Adoption Statistics). |
| Deutschland | 75,7 % | Drei von vier Nutzern sind nativ über IPv6 unterwegs — der IPv4-Pfad ist der Ausweichweg (Google, IPv6 Adoption Statistics). |
| Indien | 74,7 % | Stark mobilgetrieben; relevant für Exportshops und internationale Landingpages (Google, IPv6 Adoption Statistics). |
| USA | 57,9 % | Deutlich über der Hälfte, aber mit größerer Streuung zwischen Providern (Google, IPv6 Adoption Statistics). |
| Vereinigtes Königreich | 52,1 % | Knapp über der Marke; IPv4-only-Messungen erfassen etwa die Hälfte der Nutzer nicht (Google, IPv6 Adoption Statistics). |
| Italien | 18,8 % | IPv6 bleibt Minderheitenpfad — Fehler dort fallen im Traffic kaum auf, treffen aber echte Nutzer (Google, IPv6 Adoption Statistics). |
| Spanien | 13,6 % | Niedrigster Wert der großen westeuropäischen Märkte (Google, IPv6 Adoption Statistics). |
Der Anteil schwankt zusätzlich systematisch über die Woche. In den letzten 90 Tagen lag der weltweite Tageswert samstags im Mittel bei 50,1 Prozent, dienstags dagegen bei 46,3 Prozent (eigene Auswertung der veröffentlichten Tageswerte, Google, IPv6 Adoption Statistics). Die Erklärung liegt nahe: Private Anschlüsse sind in Deutschland weitgehend Dual-Stack, viele Firmennetze noch nicht. Für einen Shop mit Abend- und Wochenendgeschäft heißt das, dass der IPv6-Anteil ausgerechnet in den umsatzstärksten Zeitfenstern am höchsten ist — und ein einseitiger Ausfall dort am teuersten wird.
Google zählt ausschließlich nativen IPv6-Zugang, nicht Tunnelverfahren. APNIC Labs unterscheidet zusätzlich zwischen Fähigkeit und Präferenz, misst also auch, ob ein Client IPv6 wählt, wenn er die Wahl hat. Beides sind Schätzungen für die Anschlusslandschaft insgesamt, keine Aussage über Ihre eigene Besucherstruktur. Wie hoch der IPv6-Anteil in Ihrem Traffic tatsächlich ist, zeigt erst die eigene Messung — im Zugriffsprotokoll des Webservers oder in einer Analytics-Auswertung, die die Adressfamilie mit erfasst. Erfahrungsgemäß liegen B2C-Angebote dabei über, reine B2B-Portale unter dem Landesdurchschnitt (Projekterfahrung).
Dual-Stack: ein Hostname, zwei vollständig getrennte Pfade
IPv6 ist seit Juli 2017 als Internet Standard verabschiedet (IETF RFC 8200, STD 86) und ersetzt IPv4 nicht, sondern läuft daneben. Bei Dual-Stack trägt derselbe Hostname zwei Adressarten im DNS: einen A-Record mit einer 32-Bit-IPv4-Adresse und einen AAAA-Record mit einer 128-Bit-IPv6-Adresse. Welchen der beiden Pfade ein Client zuerst versucht, entscheidet er selbst. Ab der DNS-Antwort sind beide Wege technisch unabhängig: Sie können über unterschiedliche Router laufen, unterschiedliche Firewall-Regeln passieren, an unterschiedlichen Load-Balancern enden und im ungünstigen Fall sogar von unterschiedlichen Serverprozessen beantwortet werden.
Der wirtschaftliche Druck hinter dieser Entwicklung kommt aus der Adressknappheit. Die RIPE NCC hat ihren letzten frei verfügbaren IPv4-Bestand am 25. November 2019 vergeben; seither können Mitglieder nur noch über eine Warteliste ein einzelnes /24 aus zurückgegebenen Beständen erhalten (RIPE NCC, IPv4 Run-out). Neue Zugangsnetze — Mobilfunk zuerst — werden deshalb IPv6-first aufgebaut und reichen IPv4 nur noch über Übersetzungsmechanismen nach. Für Website-Betreiber verschiebt sich damit die Beweislast: Nicht IPv6 ist der Sonderfall, den man optional testet, sondern IPv4 ist der Pfad, der zunehmend synthetisch bereitgestellt wird.
A- und AAAA-Records werden getrennt gepflegt. Ein AAAA-Eintrag, der beim letzten Serverumzug stehen geblieben ist, zeigt auf eine Adresse, die längst zu einem anderen System gehört — während der A-Record korrekt aktualisiert wurde.
Firewalls, Security-Groups, Rate-Limits und Geoblocking werden je Adressfamilie konfiguriert. Eine Freigabe für 0.0.0.0/0 gilt nicht automatisch für ::/0, und eine IPv4-Sperrliste greift über IPv6 gar nicht.
Webserver und Reverse-Proxys brauchen einen eigenen Listener. Fehlt listen [::]:443, nimmt der Prozess IPv4-Verbindungen an und bleibt auf IPv6 stumm — ohne dass ein Fehler im Log erscheint.
Weiterleitungen, HSTS, Sicherheits-Header, Session-Bindung, Bot-Erkennung und Logging arbeiten mit der Client-Adresse. Code, der nur vier Oktette erwartet, verhält sich über IPv6 anders — bis hin zu abgeschnittenen Adressen im Protokoll.
Aus dieser Aufteilung folgt eine unbequeme Konsequenz: Jede Schicht kann einseitig brechen, und jede einseitige Störung ist mit einer IPv4-Messung unsichtbar. Wer bereits DNS-Propagation über mehrere Resolver überwacht, hat den ersten Baustein schon im Haus — die Erweiterung besteht darin, AAAA genauso konsequent zu behandeln wie A. Im DNS- und Domain-Monitoring gehören beide Recordtypen in denselben Soll-Ist-Abgleich.
Happy Eyeballs v2 kaschiert Fehler und kostet Ladezeit
Damit Nutzer von einem gestörten IPv6-Pfad möglichst wenig merken, verwenden Browser und Betriebssysteme ein Verfahren, das die IETF im Dezember 2017 als RFC 8305 unter dem Namen Happy Eyeballs Version 2 standardisiert hat. Der Client stellt zuerst die AAAA-Anfrage und unmittelbar danach die A-Anfrage; er soll dabei nicht auf beide Antworten warten, sondern die Namensauflösung asynchron behandeln (IETF RFC 8305, Abschnitt 3). Kommt die AAAA-Antwort zuerst und enthält sie mindestens einen gültigen Eintrag, startet sofort der erste IPv6-Verbindungsversuch.
Anschließend sortiert der Client alle bis dahin erhaltenen Adressen nach der Zieladressauswahl aus RFC 6724 und verschränkt die Adressfamilien so, dass auf die erste IPv6-Adresse die erste IPv4-Adresse folgt (IETF RFC 8305, Abschnitt 4). Danach laufen die Verbindungsversuche zeitlich gestaffelt. Vier Zeitwerte bestimmen, wie lange ein defekter IPv6-Pfad die Verbindung aufhält:
- Resolution Delay — 50 Millisekunden. Trifft die A-Antwort vor der AAAA-Antwort ein, wartet der Client diese Spanne ab, damit IPv6 der Vorzug bleibt (IETF RFC 8305, Abschnitt 3).
- Connection Attempt Delay — 250 Millisekunden. Empfohlener Standardabstand zwischen zwei Verbindungsversuchen. Er darf 10 Millisekunden nicht unterschreiten, als Untergrenze werden 100 Millisekunden empfohlen (IETF RFC 8305, Abschnitt 5).
- Maximum Connection Attempt Delay — 2 Sekunden. Obere Schranke für diesen Abstand, etwa wenn eine Implementierung ihn aus historischen Laufzeiten ableitet (IETF RFC 8305, Abschnitt 5).
- Last Resort Local Synthesis Delay — 2 Sekunden. In IPv6-only-Netzen die Wartezeit, bis der Client die erhaltenen AAAA-Adressen aufgibt und sich eine Ersatzadresse aus dem A-Record bildet (IETF RFC 8305, Abschnitt 7.2).
Eine einfache Implementierung kann eine feste Verzögerung verwenden, bevor sie den nächsten Verbindungsversuch startet. Ein empfohlener Wert für diese Standardverzögerung sind 250 Millisekunden.
— IETF RFC 8305, Happy Eyeballs Version 2, Abschnitt 5 (sinngemäß übersetzt)
Das Verfahren tut genau das, wofür es entworfen wurde: Es verbirgt einen Fehler vor dem Nutzer. Für den Betrieb ist das tückisch. Ein Server, der über IPv6 auf Port 443 keine Verbindung annimmt, erzeugt keine Fehlerseite, sondern eine Verzögerung. Antwortet die Gegenstelle mit einem sofortigen TCP-Reset, bleibt der Aufschlag klein. Verwirft eine Firewall die Pakete dagegen still, wartet der Client die volle Staffelung ab. Und der Effekt zählt pro Verbindungsziel: Eine Seite, die Assets von drei eigenen Hostnamen nachlädt und bei jedem denselben Defekt hat, zahlt den Aufschlag mehrfach — mit direkter Wirkung auf die Startmetriken der Seite.
Die verbreitetste Fehlannahme im Monitoring lautet: Wenn der Uptime-Check grün ist, funktioniert die Seite. Tatsächlich sagt ein Check nur etwas über den Pfad aus, über den er gelaufen ist. Prüft die Messsonde über IPv4 — weil ihr Rechenzentrum es so vorgibt oder weil die Bibliothek IPv4 bevorzugt —, bleibt ein vollständiger IPv6-Ausfall unbemerkt, während Happy Eyeballs beim Nutzer je Verbindung mehrere hundert Millisekunden zusätzlich verbraucht. Sichtbar wird das erst, wenn beide Protokollversionen getrennt gemessen und getrennt bewertet werden.
Fünf Muster, die genau eine Protokollversion treffen
Einseitige Störungen entstehen selten spektakulär. Sie entstehen bei Umzügen, Regelwerks-Aufräumaktionen, Proxy-Updates und Zertifikatswechseln — also bei Routinearbeiten, nach denen der IPv4-Check grün bleibt und deshalb niemand weitersucht. Die folgenden Muster decken den größten Teil der Fälle ab, die uns in Betriebsprojekten begegnen (Projekterfahrung).
| Fehlerbild | Technische Ursache | Was Nutzer erleben |
|---|---|---|
| Fehlender oder veralteter AAAA-Record | Beim Umzug wurde der A-Record aktualisiert, der AAAA-Record nicht — oder er fehlt ganz. | Bei fehlendem AAAA fällt der Client sauber auf IPv4 zurück. Bei einem veralteten AAAA landet er auf einem fremden System oder im Timeout. |
| Firewall-Regel nur für IPv4 | Freigaben, Security-Groups und Sperrlisten wurden für die IPv4-Adressfamilie gepflegt, ::/0 fehlt im Regelwerk. | Stilles Verwerfen der Pakete: kein Reset, keine Fehlermeldung, nur Wartezeit bis zum Umschwenken auf IPv4. |
| Reverse-Proxy ohne IPv6-Listener | Im Serverblock fehlt listen [::]:443 ssl;, der Prozess bindet nur an die IPv4-Adresse. | Verbindungsabbruch über IPv6, danach Erfolg über IPv4 — im Serverlog taucht der Fehlversuch nicht auf. |
| Zertifikat oder SNI-Zuordnung weicht ab | Über IPv6 greift ein anderer virtueller Host oder eine ältere Konfiguration, etwa nach einer Migration ohne vollständige Übernahme. | Zertifikatswarnung oder Standardseite ausschließlich über IPv6 — reproduzierbar erst, wenn gezielt über IPv6 aufgerufen wird. |
| Weiterleitungen und Header unterscheiden sich | HSTS, Canonical-Redirects oder Sicherheits-Header werden auf einer Ebene gesetzt, die nur einen Stack sieht. | Zusätzlicher Sprung über unverschlüsseltes HTTP oder fehlende Header über IPv6 — mit Folgen für Sicherheit und Indexierung. |
| Antwortzeit deutlich schlechter über IPv6 | Asymmetrisches Routing, ein Tunnel im Pfad oder ein Load-Balancer ohne IPv6-Optimierung. | Die Seite lädt, aber spürbar langsamer — ein Befund, der ohne getrennte Messung als allgemeines Rauschen durchgeht. |
Ein typischer Befund aus der Praxis sieht so aus wie im Schaubild oben: HTTP-Status und Zertifikat sind über beide Protokollversionen identisch, aber über IPv6 läuft die Anfrage über zwei Weiterleitungen statt einer und dabei einmal über unverschlüsseltes HTTP, es fehlen zwei von sechs Sicherheits-Headern, und die Antwortzeit im 95. Perzentil liegt bei 740 Millisekunden statt 182 Millisekunden (Projekterfahrung). Keiner dieser drei Punkte löst über IPv4 einen Alarm aus. Zusammen ergeben sie für einen erheblichen Teil der Besucher eine messbar schlechtere Seite. Wie sich solche Unterschiede sauber quantifizieren lassen, zeigt der Beitrag zu Antwortzeit-Perzentilen p95 und p99.
Wenn eine Firewall IPv6-Pakete ohne Antwort verwirft, gibt es keinen Reset, kein ICMPv6-Signal und keinen Logeintrag auf dem Zielsystem. Der Client wartet, bis die Staffelung nach RFC 8305 greift, und wechselt dann auf IPv4. Das Ergebnis ist eine Seite, die funktioniert und trotzdem für einen Teil der Nutzer langsamer ist. Solche Fälle lassen sich in der Regel nur mit einer Sonde finden, die den IPv6-Verbindungsaufbau eigenständig prüft und dessen Ergebnis getrennt protokolliert.
IPv6-only-Netze, NAT64 und der kaputte AAAA-Record
In Mobilfunknetzen ist Dual-Stack vielfach nicht mehr die Betriebsform. Dort bekommt das Endgerät ausschließlich IPv6, und der Zugriff auf IPv4-Ziele läuft über eine Kombination aus NAT64 (IETF RFC 6146) und DNS64 (IETF RFC 6147): Der Resolver des Netzes bildet für Namen ohne AAAA-Record synthetische AAAA-Antworten, die auf ein Übersetzungspräfix zeigen; ein Übersetzer im Netz setzt die Pakete anschließend auf IPv4 um. Ergänzend implementieren viele Plattformen 464XLAT (IETF RFC 6877), damit auch Anwendungen funktionieren, die feste IPv4-Adressen verwenden.
DNS64 synthetisiert nur dann, wenn kein echter AAAA-Record existiert: „By default, DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs exist" (IETF RFC 6147, Abschnitt 5.1.1). Steht also ein AAAA-Record im Zonefile, der auf eine nicht erreichbare Adresse zeigt, reicht der Resolver genau diesen Eintrag durch — der Ersatzweg über NAT64 entfällt. Im Dual-Stack-Netz fällt der Client danach auf IPv4 zurück, im IPv6-only-Netz gibt es diesen Rückfallweg nicht. RFC 8305 beschreibt für diesen Fall die lokale Ersatzbildung nach zwei Sekunden Wartezeit (IETF RFC 8305, Abschnitt 7.2) — sie greift aber nur, wenn die Plattform sie implementiert, und kostet in jedem Fall zwei Sekunden.
Für die Ersatzbildung muss der Client das Übersetzungspräfix des Netzes kennen. Er ermittelt es über das Verfahren aus IETF RFC 7050 und bildet die Adresse nach den Kodierungsregeln aus IETF RFC 6052. Beides funktioniert nur für Namen, nicht für hart verdrahtete IPv4-Adressen in Konfigurationen, Skripten oder Sicherheitsrichtlinien. Wer eine IPv4-Adresse als Literal in einer Content-Security-Policy, in einer API-Basis-URL oder in einer Formular-Action hinterlegt, baut damit eine Stelle ein, die im IPv6-only-Netz auf zusätzliche Übersetzungsschritte angewiesen ist.
- Keinen AAAA-Record veröffentlichen, der nicht erreichbar ist. Ein Name ohne AAAA funktioniert im IPv6-only-Netz über DNS64; ein Name mit defektem AAAA nicht (IETF RFC 6147, Abschnitt 5.1.1).
- Auch Subdomains und Drittsysteme prüfen. Bild-, Asset-, API- und Formular-Hostnamen tragen häufig eigene Recordsätze — und werden bei Umzügen seltener kontrolliert als die Hauptdomain.
- IPv4-Literale aus Konfigurationen entfernen. Namen statt Adressen halten den Übersetzungsmechanismus intakt und vermeiden Sonderwege im Client (IETF RFC 8305, Abschnitt 7.1).
- Mobilfunk als eigenen Testfall führen. Ein Aufruf über ein Mobilfunknetz ohne WLAN ist der einfachste verfügbare Test für den IPv6-only-Fall und deckt Fehler auf, die im Büronetz unsichtbar bleiben.
Was je Protokollversion getrennt geprüft gehört
Die Grundregel ist einfach: Alles, was zwischen Client und Antwort passieren kann, kann sich zwischen den Protokollversionen unterscheiden — und muss deshalb je Version eigenständig erhoben werden. Ein zusammengefasster Check, der intern irgendeinen Pfad wählt, liefert am Ende einen Statuswert, der die entscheidende Information verloren hat.
| Prüfung | Warum je Protokollversion getrennt | Typischer einseitiger Befund |
|---|---|---|
| DNS-Auflösung | A und AAAA sind eigenständige Recordsätze mit eigener TTL und eigener Änderungshistorie. | AAAA fehlt, ist veraltet oder zeigt auf ein anderes Zielsystem als der A-Record. |
| TCP-Verbindungsaufbau | Routing und Paketfilter sind je Adressfamilie konfiguriert. | Verbindung über IPv6 wird still verworfen, über IPv4 sofort angenommen. |
| TLS-Handshake und Kette | SNI-Zuordnung und Zertifikatsauswahl können je Listener abweichen. | Über IPv6 antwortet ein anderer virtueller Host mit unpassendem Zertifikat. |
| HTTP-Statuscode | Vorgelagerte Proxys, WAF-Regeln und Wartungsschalter greifen nicht zwingend auf beiden Stacks. | Über IPv6 kommt 502 oder 403 zurück, während IPv4 sauber 200 liefert. |
| Weiterleitungskette | Canonical-Regeln und HSTS werden oft an einer Stelle gesetzt, die nur einen Pfad sieht. | Zusätzlicher Sprung, ein unverschlüsselter Zwischenschritt oder eine Schleife nur über IPv6. |
| Sicherheits-Header | Header können vom Proxy statt von der Anwendung stammen und damit pfadabhängig sein. | HSTS oder CSP fehlen über IPv6, obwohl sie über IPv4 gesetzt werden. |
| Antwortzeit und Perzentile | Der Netzpfad ist ein anderer; Tunnel und asymmetrisches Routing wirken nur auf einer Seite. | Deutlich höhere p95-Werte über IPv6 bei identischem Server. |
| Inhalt der Antwort | Geo- und Netzlogik werten die Client-Adresse aus und können pro Adressfamilie anders entscheiden. | Abweichende Sprachfassung, Preisliste oder Consent-Variante über IPv6. |
Zwei dieser Punkte lohnen eine gesonderte Betrachtung, weil sie auch ohne IPv6-Bezug häufig Probleme machen: Weiterleitungsketten und TLS-Konfiguration. Der Beitrag zu Weiterleitungsketten und ihren Nebenwirkungen beschreibt das Grundmuster, der Beitrag zur Härtung von TLS-Cipher-Suites die Prüfpunkte auf der Verschlüsselungsebene. Beide Prüfungen doppelt zu fahren — einmal über IPv4, einmal über IPv6 — ist der eigentliche Aufwand, und er ist überschaubar, sobald die Sonde die Adressfamilie erzwingen kann.
Praxis 1: Inventar aller Hostnamen mit und ohne AAAA
Bevor Alarme sinnvoll sind, braucht es ein Inventar. Die Frage lautet nicht „Ist unsere Website über IPv6 erreichbar?", sondern „Welche unserer Hostnamen haben einen AAAA-Record, welche nicht, und ist das jeweils gewollt?". Erfahrungsgemäß fördert dieser Schritt allein schon die Hälfte der späteren Befunde zutage (Projekterfahrung), weil Nebendomains, Asset-Hosts und Alt-Systeme selten dieselbe Pflege erfahren wie die Hauptdomain.
- Hostnamen sammeln. Hauptdomain mit und ohne
www, Shop- und Login-Subdomains, Asset- und Bild-Hosts, API-Endpunkte, Mailhosts, Status- und Support-Systeme sowie alle Namen aus Zertifikaten mit mehreren SAN-Einträgen. - A und AAAA je Hostname abfragen. Aus mindestens zwei unabhängigen Resolvern, damit ein Cache-Artefakt nicht als Konfigurationsfehler durchgeht.
- Soll-Zustand festlegen. Für jeden Namen entscheiden: Dual-Stack gewünscht, bewusst IPv4-only, oder Altlast zum Abschalten. Ohne diese Spalte ist jede spätere Abweichung nicht bewertbar.
- Erreichbarkeit je Adressfamilie testen. Verbindungsaufbau, TLS-Handshake und HTTP-Status getrennt über IPv4 und IPv6 prüfen, nicht nur die DNS-Antwort.
- Abweichungen dokumentieren. Unterschiede in Statuscode, Weiterleitung, Headern und Antwortzeit festhalten — sie sind die Arbeitsliste für die Behebung.
- Inventar in die Überwachung überführen. Jeder Name mit Soll-Zustand „Dual-Stack" bekommt zwei Prüfungen und eine Regel, die einen einseitigen Ausfall meldet.
Hostname A AAAA Soll Befund
-----------------------------------------------------------------------
beispiel.de ok ok Dual-Stack in Ordnung
www.beispiel.de ok ok Dual-Stack in Ordnung
shop.beispiel.de ok ok Dual-Stack p95 740 ms statt 182 ms
cdn.beispiel.de ok fehlt Dual-Stack AAAA fehlt seit Umzug
api.beispiel.de ok ok Dual-Stack 502 über IPv6
status.beispiel.de ok ok Dual-Stack HSTS fehlt über IPv6
altsystem.beispiel.de ok veraltet abschalten AAAA zeigt auf FremdsystemWer nicht sicher ist, ob das Inventar vollständig ist, findet in den eigenen Zertifikaten häufig Namen, die im Betriebshandbuch fehlen: Ein Zertifikat mit mehreren SAN-Einträgen listet jeden Hostnamen auf, der über diesen Endpunkt ausgeliefert werden soll. Dieselbe Liste eignet sich als Ausgangspunkt für das AAAA-Inventar — und deckt regelmäßig Subdomains auf, die seit Jahren niemand mehr aktiv prüft (Projekterfahrung).
Praxis 2: Alarm bei einseitigem Ausfall
Ein Alarm ist nur so gut wie die Frage, die er beantwortet. „Website nicht erreichbar" ist bei Dual-Stack die falsche Frage, weil sie in der Regel mit Nein beantwortet wird, solange ein Pfad funktioniert. Die richtige Frage lautet: Weicht das Ergebnis über IPv6 vom Ergebnis über IPv4 ab, und zwar länger als eine kurzfristige Störung erklären kann?
- Einseitiger Verbindungsausfall. Über eine Protokollversion kommt keine Verbindung zustande, über die andere schon — nach zwei aufeinanderfolgenden Prüfungen aus mindestens zwei Standorten melden.
- Statuscode-Divergenz. Unterschiedliche HTTP-Endstatuscodes je Protokollversion sind in der Regel ein Konfigurationsfehler, kein Zufall — sofort melden.
- Antwortzeit-Divergenz. Ein dauerhaft höheres p95 über eine Protokollversion, etwa Faktor drei über mindestens eine Stunde, ist ein Hinweis auf einen Netzpfad, der Aufmerksamkeit braucht.
- AAAA-Änderung ohne Freigabe. Jede Änderung am AAAA-Record wird wie eine Änderung am A-Record behandelt: erfassen, gegen den Soll-Wert prüfen, bei Abweichung melden.
Damit solche Regeln nicht in Dauerrauschen umschlagen, gelten dieselben Grundsätze wie bei jeder Verfügbarkeitsüberwachung: Bestätigung aus einem zweiten Standort, bevor eskaliert wird, und ein Prüfintervall, das zur tolerierten Erkennungszeit passt. Die Zusammenhänge sind im Beitrag zum passenden Prüfintervall und im Beitrag zu Monitoring von mehreren Standorten beschrieben; wie sich flatternde Alarme zusätzlich dämpfen lassen, steht in der Alerting-Übersicht.
Der praktische Aufbau ist unspektakulär: je Hostname eine Prüfung, die IPv4 erzwingt, eine Prüfung, die IPv6 erzwingt, und eine Vergleichsregel, die anschlägt, wenn beide Ergebnisse auseinanderlaufen. Der Mehraufwand liegt in der Einrichtung, nicht im Betrieb. Der Gewinn ist ein Datenpunkt, den ein zusammengefasster Check strukturell nicht liefern kann: die Antwort auf die Frage, für welchen Teil der Nutzer die Seite gerade tatsächlich funktioniert. In den Berichten und Statusseiten lässt sich diese Trennung anschließend auch nach außen sichtbar machen.
Praxis 3: Prüfen ohne eigenen IPv6-Anschluss
Viele Betriebe haben im eigenen Netz noch keinen IPv6-Anschluss — und schließen daraus, dass sie IPv6 nicht testen können. Das stimmt nur für den bequemsten Weg. Vier Vorgehensweisen funktionieren auch ohne eigenen Anschluss und lassen sich in wenigen Minuten aufsetzen.
- Mobilfunk statt WLAN. Ein Smartphone ohne WLAN-Verbindung ist in vielen Netzen bereits ein IPv6-only-Client mit NAT64 — der realistischste verfügbare Test für den Fall aus Abschnitt fünf.
- DNS zuerst prüfen.
dig AAAAunddig Aje Hostname aus zwei Resolvern liefern das Fundament, bevor überhaupt eine Verbindung getestet wird. - Adressfamilie erzwingen. Kommandozeilenwerkzeuge lassen sich mit
-4und-6auf eine Protokollversion festlegen; der Vergleich beider Läufe zeigt Status-, Header- und Laufzeitunterschiede unmittelbar. - Externe Messpunkte nutzen. Eine Überwachung, deren Sonden in Rechenzentren mit Dual-Stack stehen, liefert den IPv6-Blick dauerhaft — unabhängig davon, was der eigene Büroanschluss kann.
Ein einmaliger Vergleich zeigt den aktuellen Zustand, aber nicht den Zeitpunkt einer Veränderung. Genau der ist im Zweifel entscheidend: Wenn nach einem Proxy-Update die IPv6-Antwortzeit steigt, ist die Zuordnung nur möglich, wenn beide Reihen fortlaufend erfasst wurden. Der Aufwand, die vier Kommandos einmalig in eine dauerhafte Prüfung zu überführen, ist geringer als die Zeit, die eine spätere Ursachensuche ohne Datenreihe kostet (Projekterfahrung).
Dual-Stack dauerhaft im Blick behalten
Die Zahlen sind eindeutig genug, um die Prioritäten zu verschieben: Weltweit ist der native IPv6-Anteil bei Google seit Ende März 2026 mehrfach über 50 Prozent gestiegen, in Deutschland liegt er bei 75,7 Prozent (Google, IPv6 Adoption Statistics), und APNIC Labs misst für Deutschland 72,1 Prozent IPv6-fähige Nutzer (APNIC Labs, IPv6 Capability Measurement). Ein Monitoring, das ausschließlich über IPv4 misst, beschreibt damit die Minderheitsvariante des eigenen Traffics. Der Aufwand für die Korrektur ist überschaubar: ein Inventar, zwei Prüfungen je Hostname und eine Regel, die einseitige Abweichungen meldet.
Wer ohnehin gerade Nachweise für regulatorische Anforderungen aufbaut, kann diesen Schritt gleich mitnehmen — etwa parallel zur NIS2-Registrierung beim BSI und der Nachfrist bis 31. Juli 2026 oder zur Transparenzpflicht für Website-Chatbots nach der KI-Verordnung. In allen drei Fällen geht es um dasselbe Prinzip: nachvollziehbare, zeitgestempelte Daten statt Momentaufnahmen. Wie eine getrennte Erfassung je Protokollversion im Betrieb aussieht, zeigt die Übersicht zum Uptime-Monitoring; die Demo-Umgebung enthält den vollständigen Datenbestand ohne Anmeldung, und die Preisübersicht ordnet den Umfang ein.
Dieser Artikel basiert auf: Google, IPv6 Adoption Statistics (Tageswerte des nativen IPv6-Anteils seit 2008; erster Tageswert über 50 Prozent am 28. März 2026 mit 50,1 Prozent, Spitzenwert 50,9 Prozent am 18. Juli 2026; Jahresmittel 11,0 Prozent 2016, 29,9 Prozent 2020, 43,4 Prozent 2024, 47,0 Prozent 2026; Länderwerte Frankreich 86,3 Prozent, Deutschland 75,7 Prozent, Indien 74,7 Prozent, USA 57,9 Prozent, Vereinigtes Königreich 52,1 Prozent, Italien 18,8 Prozent, Spanien 13,6 Prozent, Stand 20. Juli 2026); APNIC Labs, IPv6 Capability Measurement (weltweit 41,9 Prozent IPv6-fähig und 40,0 Prozent IPv6-bevorzugend, Deutschland 72,1 Prozent und 71,1 Prozent, Stand 21. Juli 2026); IETF RFC 8305, Happy Eyeballs Version 2 (asynchrone Namensauflösung, Resolution Delay 50 Millisekunden, Connection Attempt Delay 250 Millisekunden mit Untergrenze 10 Millisekunden und Obergrenze 2 Sekunden, Adresssortierung und Verschränkung der Adressfamilien, Unterstützung von IPv6-only-Netzen mit Last Resort Local Synthesis Delay von 2 Sekunden); IETF RFC 6147, DNS64 (keine Synthese bei vorhandenen echten AAAA-Records, Abschnitt 5.1.1); IETF RFC 6146, NAT64; IETF RFC 6877, 464XLAT; IETF RFC 7050 und IETF RFC 6052 (Ermittlung und Kodierung des Übersetzungspräfixes); IETF RFC 6724 (Zieladressauswahl); IETF RFC 8200, IPv6-Spezifikation (Internet Standard, STD 86); RIPE NCC, IPv4 Run-out (Vergabe des letzten frei verfügbaren IPv4-Bestands am 25. November 2019, Warteliste für ein einzelnes /24). Ergänzend fließen eigene Erfahrungswerte aus Monitoring-Projekten ein, gekennzeichnet als (Projekterfahrung).