Damit Geräte über das treffend benannte Internet Protocol (IP) im Internet miteinander kommunizieren können, müssen ihnen zunächst eindeutige numerische Adressen zugewiesen werden. Wie diese aussehen, hängt davon ab, welche IP-Version verwendet wird: IPv4 oder IPv6.
IPv4 wurde erstmals 1983 eingesetzt. Es ist die IP-Version, die das moderne Internet hervorgebracht hat, und sie ist bis heute dominant. IPv6 lässt sich bis ins Jahr 1998 zurückverfolgen. Diese Version hat aber erst im letzten Jahrzehnt begonnen, deutlich an Bedeutung zu gewinnen: Ihr Anteil ist von weniger als 1 Prozent auf irgendwo zwischen 30 und 40 Prozent gestiegen – je nachdem, von wem die Zahlen stammen, was gemessen wurde und wie.
Wegen des starken Zuwachses bei der Zahl der angeschlossenen Geräte reichen die verfügbaren IPv4-Adressen bei Weitem nicht mehr aus und auch die Kosten steigen. Eigentlich würde man annehmen, dass IPv6 aufgrund des viel größeren Adressraums, den diese Version bietet, inzwischen dominiert. Wie wir sehen werden, ist dem jedoch nicht so.
Cloudflare ist seit vielen Jahren ein vehementer Verfechter von IPv6 und mit Cloudflare Radar haben wir die Einführung von IPv6 im gesamten Internet aufmerksam verfolgt. Radar besteht allerdings erst seit drei Jahren und ist damit eine noch relativ junge Plattform. Für einen noch weiter in die Vergangenheit blicken zu können, wenden wir uns kurz unseren Freunden von APNIC1 – einem der fünf Internet-Registrare (Regional Internet Registries – RIR) – zu. Dessen bis ins Jahr 2012 zurückreichende Erhebungen zeigen, dass IPv6 bis Mitte 2017 allem Anschein nach ein exponentielles Wachstum verzeichnet hat und danach in eine bis heute andauernde Phase linearen Wachstums eingetreten ist:
Die Einführung von IPv6 wird durch die mangelnde Kompatibilität der beiden Protokolle gebremst – Geräten muss eine IPv4- und eine IPv6-Adresse zugewiesen werden. Erschwerend kommt hinzu, dass praktisch alle Geräte im Internet immer noch IPv4 unterstützen. Weil IPv6 aber für die Zukunft des Internet von entscheidender Bedeutung ist, müssen weitere Anstrengungen unternommen werden, dieser Version noch größere Akzeptanz zu verschaffen.
Die Daten von Cloudflare Radar geben – ebenso wie die von APNIC und den meisten anderen aktuellen Quellen – in erster Linie Auskunft über den Umfang, in dem IPv6 von Internetdienstleistern (Internet Service Provider – ISP) eingesetzt wird. Damit ist aber nur die Clientseite abgedeckt. Das ist zwar ein sehr wichtiger Aspekt, der direkte Auswirkungen für die Endnutzer hat, die Serverseite bleibt dabei aber außen vor.
Wir möchten daher versuchen, einen Einblick in die serverseitige IPv6-Verbreitung zu erhalten und herauszufinden, wie oft Clients wirklich (oder wahrscheinlich) über IPv6 mit Servern kommunizieren können. Zu diesem Zweck nutzen wir das DNS, und die Ergebnisse werden Sie vielleicht überraschen.
Clientseitige IPv6-Einführung (von HTTP)
Ende Oktober 2023 deckte IPv6 im gesamten Internet aus Sicht von Cloudflare etwa 36 Prozent des Datenverkehrs ab – mit leichten Schwankungen je nach Tageszeit und Wochentag. Klammert man Bots aus, steigt der Anteil schätzungsweise auf gut 46 Prozent, während er bei Ausschluss von Menschen auf annähernd 24 Prozent sinkt. Diese Zahlen beziehen sich auf den Anteil der über IPv6 bereitgestellten HTTP-Anfragen an allen IPv6-fähigen Inhalten (Standardeinstellung).
Für unsere Überlegungen kommt es vor allem auf die gemeinsame Zahl für Menschen und Bots an. Es gibt viele Gründe für die Akzeptanzlücke zwischen diesen beiden Arten von Datenverkehr – von unterschiedlichen Graden der IPv6-Unterstützung in der Fülle der verwendeten Client-Software über unterschiedliche Grade der IPv6-Bereitstellung in den vielen Netzwerken, aus denen der Traffic kommt, bis hin zur unterschiedlichen Größe solcher Netzwerke. Doch das führt heute zu weit. Wenn Sie sich für die Zahlen eines bestimmten Landes oder Netzwerks interessieren, finden Sie diese bei Cloudflare Radar und in unserem Jahresrückblick für 2023.
Es gehören immer zwei dazu
Es ließe sich einwenden, dass die Messung auf Clientseite nur ein unvollständiges Bild ergibt. Denn damit ein IPv6-fähiger Client eine Verbindung mit einem Server über IPv6 aufbauen kann, muss auch der Server mit IPv6 umgehen können.
Das wirft zwei Fragen auf:
- Wie verbreitet ist IPv6 auf Serverseite?
- Inwieweit deckt sich die clientseitige Verbreitung von IPv6 mit der serverseitigen?
Das lässt sich auf unterschiedliche Weise beantworten – je nachdem, ob man sich beispielsweise Nutzer, Geräte oder übertragene Bytes anschaut. Aus einem Grund, der gleich deutlich werden wird, wollen wir uns hier auf Verbindungen konzentrieren. Dazu stellen wir die folgende Frage:
Wie häufig kann ein IPv6-fähiger Client bei typischen Nutzungsmustern IPv6 verwenden, wenn er eine Verbindung zu Servern im Internet herstellt?
Zu den typischen Nutzungsmustern gehört, dass Menschen im Alltag bestimmte Websites häufiger besuchen als andere, oder dass Clients automatisch API-Aufrufe durchführen. Um Aufschluss zu erhalten, greifen wir auf das DNS zurück.
Bühne frei für das DNS
Bevor ein Client versuchen kann, über das herkömmliche IPv4-Protokoll oder das modernere IPv6 eine namentliche Verbindung mit einem Server herzustellen, muss er die IP-Adresse des Servers im Telefonbuch des Internet, dem Domain Name System (DNS), nachschlagen.
Das Nachschlagen eines Hostnamens im DNS (die Namensauflösung) ist ein rekursiver Vorgang. Um die IP-Adresse eines Servers zu finden, muss die Domain-Hierarchie (die durch Punkte getrennten Bestandteile eines Servernamens) über eine Reihe von autoritativen DNS-Servern verfolgt werden, bis einer von ihnen die gewünschte Antwort zurückgibt2. Die meisten Clients erledigen dies jedoch nicht direkt, sondern bitten stattdessen einen Zwischenserver, einen sogenannten Resolver für rekursive Namensauflösung, dies für sie zu tun. Cloudflare betreibt einen solchen rekursiven Resolver, den jeder nutzen kann: 1.1.1.1.
Hier ein vereinfachtes Beispiel: Fordert ein Client bei 1.1.1.1 die IP-Adresse für „www.example.com“ an, fragt 1.1.1.1 die Root-Nameserver3 nach „.com“. Dann werden die „.com“-DNS-Server nach „example.com“ und schließlich die „example.com“-DNS-Server nach „www.example.com“ gefragt, die direkte Kenntnisse davon haben und eine IP-Adresse zurückgeben. Um dieses Verfahren für den nächsten Client mit einer ähnlichen Anfrage zu beschleunigen, speichert 1.1.1.1 sowohl die endgültige Antwort als auch die Zwischenschritte im Cache (Zwischenspeicher).
Somit ist 1.1.1.1 ein sehr gutes Instrument, wenn man zählen will, wie oft Clients nach IPv4-Adressen (Abfragtyp A) und nach IPv6-Adressen (Abfragetyp AAAA) suchen, um beide Werte anschließend zu vergleichen. Auf diese Weise sich ein Großteil des beobachtbaren Internet abdecken.
Doch woher weiß ein Client, ob er nach der IPv4- oder der IPv6-Adresse eines Servers fragen muss?
Die kurze Antwort lautet: IPv6-fähige Clients fragen einfach nach beiden Adressen und führen für jeden Server, mit dem sie eine Verbindung herstellen möchten, separate A- und AAAA-Abfragen durch. Erhalten sie eine nicht leere AAAA-Antwort, priorisieren sie eine Verbindung über IPv6 – unabhängig davon, ob sie auch eine nicht leere A-Antwort erhalten (was, wie wir sehen werden, fast immer der Fall ist). Falls Sie sich für die Details interessieren: Der Algorithmus, der für diese Vorliebe für die Moderne verantwortlich ist, heißt Happy Eyeballs.
Jetzt wird es aber Zeit, dass wir uns konkrete Daten anschauen …
Clientseitige IPv6-Verbreitung (vom DNS)
Zunächst muss ein Referenzwert festgelegt werden. Dafür wird die clientseitige IPv6-Verbreitung aus Sicht von 1.1.1.1 gemessen. Dieses Ergebnis wird dann mit den Zahlen aus HTTP-Anfragen verglichen, mit denen wir begonnen haben.
Es ist verlockend, zu zählen, wie oft Clients über IPv6 eine Verbindung zu 1.1.1.1 herstellen. Doch die damit gewonnenen Zahlen sind aus mehreren Gründen irreführend. Der wichtigste liegt eigentlich auf der Hand: 1.1.1.1 ist die einprägsamste unter den IPv4- und IPv6-Adressen, die der Client für eine DNS-Auflösung über den Dienst 1.1.11 verwenden kann. Idealerweise sollten für einen IPv6-fähigen Client, der 1.1.1.1 als rekursiven Resolver verwendet, alle vier der folgenden IP-Adressen konfiguriert sein, nicht nur die ersten beiden:
- 1.1.1.1 (IPv4)
- 1.0.0.1 (IPv4)
- 2606:4700:4700::1111 (IPv6)
- 2606:4700:4700::1001 (IPv6)
Doch für Menschen sind IPv6-Adressen weniger eingängig als IPv4-Adressen. Im Fall einer manuellen Konfiguration ist die Wahrscheinlichkeit also geringer, dass IPv6 berücksichtigt wird, da man die IPv4-Adressen für ausreichend hält4.
Ein weiterer Faktor, der damit in Verbindung steht, aber weniger offensichtlich ist, sorgt für eine zusätzliche Verzerrung: Viele IPv6-fähige Clients führen selbst dann weiter DNS-Namensauflösungen über IPv4 durch, wenn sie die IPv6-Adressen von 1.1.1.1 konfiguriert haben, da das Verteilen von Namensauflösungen auf alle verfügbaren Adressen eine beliebte Standardeinstellung ist.
Zur Beurteilung der IPv6-Verbreitung anhand der DNS-Client-Aktivität ist es deshalb sinnvoller, den Anteil der Abfragen vom Typ AAAA an der Gesamtzahl der Abfragen vom Typ A zu berechnen. Denn wie bereits erwähnt ist anzunehmen, dass IPv6-Clients immer beide Arten von Abfragen durchführen5.
Bei diesem Vorgehen ergibt sich aus Sicht von 1.1.1.1 ein clienseitiger IPv6-Anteil von schätzungsweise 30,5 Prozent am gesamten Abfragevolumen. Das liegt etwas unter dem, was wir beim HTTP-Datenverkehr im gleichen Zeitraum beobachtet haben (35,9 Prozent). Allerdings ist diese Abweichung aufgrund der unterschiedlichen Betrachtungsweisen nicht überraschend.
Ein Hinweis zu TTL
Nicht nur rekursive Resolver legen DNS-Antworten im Cache ab – die meisten DNS-Clients verfügen ebenfalls über eigene lokale Zwischenspeicher. Ihr Webbrowser, Betriebssystem und sogar Ihr Heim-Router speichern solche Antworten, um nachfolgende Abfragen gegebenenfalls zu beschleunigen.
Wie lange die jeweilige Antwort im Cache verbleibt, hängt von dem Feld time-to-live (TTL) in dem zurückgesendeten DNS-Eintrag ab, das die Gültigkeitsdauer vorgibt. Wenn Sie mit dem DNS vertraut sind, fragen Sie sich vielleicht, ob sich die TTL von A- und AAAA-Einträgen ähneln. Ist das nicht der Fall, erhalten wir möglicherweise nur weniger Abfragen eines Typs, weil diese länger auf Client-Ebene zwischengespeichert werden. Das würde die resultierenden Verwendungszahlen verzerren.
Diese Tortendiagramme schlüsseln die Mindest-TTL auf, die von 1.1.1.1 als Antwort auf A- und AAAA-Abfragen zurückgesendet werden6. Wie man sieht, besteht zwar ein Unterschied zwischen den Abfragearten, dieser ist aber gering.
Serverseitige IPv6-Verbreitung
Das folgende Diagramm zeigt, wie oft Abfragen des Typs A und AAAA nicht leere Antworten erhalten, was Aufschluss über die serverseitige IPv6-Verbreitung gibt und uns der gesuchten Antwort näherbringt:
Die IPv6-Akzeptanz bei Servern beträgt gemessen am Abfragevolumen schätzungsweise 43,3 Prozent und ist damit deutlich höher als bei Clients.
Wie oft es funkt
Wenn bei 30,5 Prozent der von 1.1.1.1 verarbeiteten Abfragen von IP-Adressen zum Herstellen einer Verbindung mit den beabsichtigten Zielen eine IPv6-Adresse verwendet werden könnten, aber nur 43,3 Prozent dieser Abfragen eine nicht leere Antwort erhalten, kann uns das einen ziemlichen guten Eindruck davon vermitteln, wie oft IPv6-Verbindungen zwischen Client und Server hergestellt werden: in ungefähr 13,2 Prozent der Fälle.
Der potenzielle Einfluss beliebter Domains
Gemessen am Abfragevolumen für die Domains in der Top 100-Liste von Radar beträgt die serverseitige IPv6-Akzeptanz 60,8 Prozent. Klammern wir diese Domains aus unseren Gesamtberechnungen aus, sinkt der bisherige Wert von 13,2 Prozent auf 8 Prozent. Das ist zwar ein signifikanter Unterschied, aber nicht unerwartet, weil die Top 100-Domains mehr als 55 Prozent aller an 1.1.1.1 gerichteten A- und AAAA-Abfragen ausmachen.
Würden heute nur noch ein paar weitere dieser sehr beliebten Domains IPv6 einsetzen, würde die beobachtete Akzeptanz deutlich steigen und damit auch die Chance, dass IPv6-fähige Clients Verbindungen über IPv6 aufbauen.
Schlussbetrachtungen
Zur Ermittlung der Akzeptanz von IPv6 im Internet kann man verschiedene Wege einschlagen:
- Nutzer mit IPv6-fähigem Internetzugang zählen;
- IPv6-fähige Geräte oder Software auf diesen Geräten (Clients und/oder Server) zählen;
- Menge des über IPv6-Verbindungen laufenden Datenverkehrs in Bytes ermitteln;
- Anteil der Verbindungen (oder einzelner Anfragen) über IPv6 ermitteln.
Wir haben uns im vorliegen Fall entschieden, uns die Verbindungen und Anfragen anzusehen. Wir sind uns bewusst, dass nur die Einbeziehung verschiedener Perspektiven ein vollständiges Bild ergeben kann. Deshalb möchten wir drei verschiedene IPv6-Akzeptanzwerte präsentieren:
- 35,9 Prozent (clientseitig) bei Zählung der über das Cloudflare-CDN abgewickelten HTTP-Anfragen;
- 30,5 Prozent (clientseitig) bei Zählung der von 1.1.1.1 verarbeiteten DNS-Abfragen des Typs A und AAAA;
- 43,3 Prozent (serverseitig) bei Zählung der positiven Antworten auf von 1.1.1.1. verarbeiteten DNS-Abfragen des Typs AAAA
Wir haben die client- und serverseitigen Zahlen aus DNS-Perspektive kombiniert, um abzuschätzen, wie oft Verbindungen zu Servern von Drittanbietern wahrscheinlich über IPv6 statt über IPv4 hergestellt werden. Das trifft nur auf 13,2 Prozent der Fälle zu.
Um diese Ergebnisse zu verbessern, müssen Internet-, Cloud- und Hosting-Provider ebenso wie Unternehmen IPv6 in höherem Maße IPv6 für Geräte in ihren Netzwerken verfügbar machen. Aber auch große Websites und Content-Anbieter kommt eine entscheidende Rolle dabei zu, IPv6-fähigen Clients eine häufigere Nutzung von IPv6 zu ermöglichen. Schließlich sind 39,2 Prozent der Abfragen für Domains in den Top 100 von Radar (und damit mehr als der Hälfte aller an 1.1.1.1 gerichteten A- und AAAA-Abfragen) immer noch auf IPv4-Antworten beschränkt.
Noch hat sich IPv6 im Internet also nicht vollständig durchgesetzt. Doch alle Beteiligten können durch kontinuierliche Anstrengungen dazu beitragen, die Akzeptanz voranzutreiben oder eventuell sogar zu beschleunigen.
Serverseitig bestärkt Cloudflare diese Bemühungen weltweit seit vielen Jahren durch kostenlose IPv6-Unterstützung für alle Domains. Clientseitig aktiviert die 1.1.1.1-Anwendung Ihr Gerät automatisch für IPv6, auch wenn Ihr Internetdienstleister keine IPv6-Unterstützung bietet. Und für all diejenigen, die ein reines IPv6-Netzwerk verwalten, bietet 1.1.1.1. DNS64-Unterstützung.
***
1Der öffentliche DNS-Resolverdienst (1.1.1.1) von Cloudflare wird in Partnerschaft mit APNIC betrieben. Weitere Informationen hierzu finden Sie in dem Blog-Beitrag, in dem wir die Einführung von 1.1.1.1 bekannt gegeben haben und in der Datenschutzrichtlinie von 1.1.1.1.
2Mehr zur Funktionsweise von DNS erfahren Sie im auf unserer Website unter dem Abschnitt „Was ist DNS?“. Wenn Sie gern praxisorientiert lernen, empfehlen wir Ihnen, einen Blick auf „mess with dns“ von Julia Evans zu werfen.
3Jeder rekursive Resolverdienst kennt die IP-Adressen der 13 Root-Nameserver bereits im Voraus. Durch die Bereitstellung von Anycast-Diensten für die E- und F-Root-Instanzen ist Cloudflare auch in der obersten DNS-Ebene präsent. Somit muss 1.1.1.1 beim ersten Suchschritt keinen allzu weiten Weg zurücklegen.
4Bei Verwendung der 1.1.1.1-Anwendung werden automatisch alle vier IP-Adressen konfiguriert.
5Der Einfachheit halber gehen wir davon aus, dass die Zahl der reinen IPv6-Clients immer noch zu vernachlässigen ist. Diese Annahme ist insofern plausibel, als sie durch andere uns zur Verfügung stehende Datensätze gestützt wird.
6Bei den von 1.1.1.1 ausgegebenen Antworten werden wie bei anderen rekursiven Resolverdiensten die TTL angepasst. Dafür wird von der ursprünglichen Gültigkeitsdauer des Datensatzes die Anzahl der Sekunden abgezogen, die seit der letzten Speicherung des Datensatzes vergangen sind. Leere A- und AAAA-Antworten werden für den im Start of Authority (SOA)-Eintrag der Domain gemäß RFC 2308 definierten Zeitraum zwischengespeichert.