Die Geschichte der IPv6-Umstellung überrascht uns alle immer wieder. RFC 2460, der erste vollständige Versuch einer Spezifikation des IPv6-Protokolls, wurde im Dezember 1998, also vor mehr als zwanzig Jahren, veröffentlicht. Das Ziel von IPv6 war es, ein Nachfolgeprotokoll für IPv4 zu spezifizieren, da die IPv4-Adressen knapp wurden. Inzwischen sind die IPv4-Adressen schon vor mehr als einem Jahrzehnt ausgegangen. Die Umstellung auf IPv6 läuft nun schon seit 20 Jahren, und wenn die Aussicht auf die Erschöpfung der IPv4-Adressen den Bemühungen eine gewisse Dringlichkeit verliehen hat, dann leben wir nun schon seit einem Jahrzehnt damit sehr gut. Vielleicht ist es also an der Zeit, die Frage zu stellen: Wie lange wird diese Umstellung noch dauern?
Ein kleiner Abriss der IP-Geschichte
Im Jahr 1991 war klar, dass das Internet-Protokoll (IP) ein Problem hat. Damals war das Internet noch winzig, aber das Netz der Netze verdoppelten sich alle 12 Monate. Der Bestand an IPv4-Adressen der Klasse B war bereits überstrapaziert. Man erahnte, ohne Abhilfemaßnahmen würde dieser Adressbestand im Jahr 1994 vollständig ausgeschöpft werden. Auch das Routing-System stand unter Druck, und die 1992 eingesetzten Router verfügten nur über genügend Speicherplatz, um ein weiteres 12- bis 18-monatiges Routing-Wachstum zu unterstützen. Die Kombination aus Routing- und Adressierungsdruck wurde das Problem von der IETF in der ROAD-Arbeitsgruppe (RFC 1380) angegangen. Man veröffentlichte eine Reihe von kurz-, mittel- und längerfristigen Maßnahmen, um das Problem zu lösen.
- Kurzfristig wurde auf den klassenbasierten Adressplan verzichtet und stattdessen das Modell der Adresspräfixe mit variabler Größe eingeführt. Routing-Protokolle, einschließlich BGP, wurden geändert, um diese klassenlosen Adress-Präfixe zu unterstützen. Die variablen Adresspräfixe führten jedoch zu einer zusätzlichen Belastung bei der Adresszuweisung.
- Mittelfristig ermöglichte die Struktur des Regional Internet Registry (RIR) jeder Region, ihre Adressenzuweisungs- und Registrierungsfunktionen mit eigenen Ressourcen auszustatten, was eine sorgfältigere Anwendung relativ konservativer Adressenzuweisungspraktiken ermöglichte, und eine erhebliche Steigerung der Effizienz der Adressennutzung erlaubte. Zu dieser Zeit setzte sich in der Welt der Internet-Diensteanbieter auch das Konzept der gemeinsamen Nutzung von Adressen unter Verwendung von Network Address Translation (NATs) durch. Dies vereinfachte nicht nur die Abläufe in den Internet Service Providern (ISPs) drastisch, sondern NATs spielten auch eine wichtige Rolle bei der Verringerung des Drucks auf den Adressverbrauch.
- Diese Maßnahmen verlängerten den möglichen Adressraum von IPv4 auf ein überschaubares zehnjähriges Szenario. Trotzdem bestand noch immer die langfristige Notwendigkeit das in IPv4 verwendete 32-Bit-Adressfeld zu erweitern.
Die Arbeitsgremien erkannten, dass es keine Möglichkeit gab, dass eine solche Adresserweiterung mit der installierten Basis von IPv4-Systemen rückwärtskompatibel sein würde. Infolgedessen gab es einige neue Denkansätze zur Beseitigung des Problems. Ein Lösungsansatz war die Umstellung auf das verbindungslose Transportprofil der OSI-Protokollsuite und die Übernahme von OSI-NSAP-Adressen. Ein anderer Lösungsansatz lautete: So wenig wie möglich an IP zu ändern, außer der Größe der Adressfelder.
Im Jahr 1994 hatte sich die IETF auf den Ansatz der minimalen Änderung geeinigt, nämlich IPv6. Das Adressfeld wurde auf 128 Bit erweitert, ein Flow-ID-Feld wurde eingeführt, das Fragmentierungsverhalten wurde geändert und in einen optionalen Header verschoben, und ARP wurde durch Multicast ersetzt.
Unterm Strich bot IPv6 keine neuen Funktionen, die nicht bereits in IPv4 vorhanden waren. Es führte keine wesentlichen Änderungen an der Funktionsweise von IP ein. Es war einfach nur IP mit größeren Adressen.
Übergang auf IPv6
Angesichts der rasanten Verbreitung von IPv4 bestand damals die naive Erwartung, dass auch IPv6 einfach durchstarten würde und man sich darüber keine Gedanken machen müsste. In der ersten Phase wurde erwartet, dass Anwendungen, Hosts und Netze zusätzlich zu IPv4 auch IPv6 unterstützen und das Internet in eine Dual-Stack-Umgebung verwandeln würden. In der zweiten Phase sollte dann die Unterstützung für IPv4 auslaufen.
Dieser Plan enthielt jedoch mehrere Probleme: Das vielleicht gravierendste war das Problem der Ressourcenzuweisung. Das Internet wuchs extrem schnell, und die meisten Anstrengungen waren darauf gerichtet, mit der Nachfrage Schritt zu halten. Mehr Nutzer, mehr Kapazität, größere Server, mehr Inhalte und Dienste, reaktionsschnellere Dienste, mehr Sicherheit – all dies hatte ein gemeinsames Thema: die Größe. Das Internet konnte entweder seine Ressourcen darauf konzentrieren, die ständigen Anforderungen der Skalierung zu erfüllen, oder an der Einführung von IPv6 arbeiten.
Die kurz- und mittelfristigen Maßnahmen, die die Internet-Community ergriffen hatte, waren auf die unmittelbare Problematik der Adressverknappung ausgerichtet, so dass die Skalierung eine weitaus wichtigere Priorität darstellte als die Umstellung auf IPv6.
Mitte der 2000er Jahre verschärfte sich das Skalierungsproblem mit der Einführung des iPhones und seiner Geschwister um eine ganz neue Größenordnung. Plötzlich war dies nicht mehr nur ein Skalierungsproblem für Haushalte und Unternehmen, sondern es wurde zu einem Skalierungsproblem für Einzelpersonen und Mobilität.
Der ursprüngliche Grund, warum wir IPv6 entwickelt hatten, kam zum Tragen, aber das Internet war noch immer nicht bereit, IPv6 als Reaktion darauf einzusetzen. Also wurde der Verbrauch der verbleibenden IPv4-Adressen erhöht und die erste Welle mobiler Dienste im großen Stil mit IPv4 unterstützt. Dual-Stack war zu dieser Zeit in der Mobilfunkwelt noch nicht einmal eine Option.
Gleichzeitig behinderte der dezentrale Charakter des Internets die Bemühungen um die Umstellung auf IPv6. Welchen Sinn machte es, Anwendungsunterstützung für IPv6-Dienste zu entwickeln, wenn kein Host IPv6 in seinen Netzwerkstack integriert hatte? Welchen Sinn hatte es, IPv6 zu einem Host-Netzwerkstack hinzuzufügen, wenn kein ISP IPv6-Unterstützung anbot? Und welchen Sinn hatte ein ISP, IPv6 zu implementieren, wenn keine Hosts und keine Anwendungen davon Gebrauch machen würden? Also passiert nichts.
Die ersten, die versuchten, diese Sackgasse der gegenseitigen Abhängigkeit zu durchbrechen, waren die Menschen, die für die Betriebssysteme verantwortlich zeichneten. Es wurden voll funktionsfähige IPv6-Stacks zu den verschiedenen Varianten von Linux, Windows und MAC OS sowie zu den mobilen Host-Stacks von iOS und Android hinzugefügt.
Aber selbst dies reichte nicht aus, um die Umstellung auf IPv5 in Gang zu bringen. Man könnte argumentieren, dass diese Situation die IPv6-Situation verschlimmert und die Umstellung um einige Jahre verzögert hat. Das Problem bestand darin, dass bei den IPv6-fähigen Hosts ein gewisser Wunsch nach Nutzung von IPv6 vorhanden war. Diese Hosts waren jedoch isolierte IPv6-Inseln in einem Ozean von IPv4.
Die Umstellungsbemühungen konzentrierten sich dann auf verschiedene Tunnelmethoden, um IPv6-Pakete durch die IPv4-Netze zu tunneln. Dies kann zwar manuell durchgeführt werden, wenn man die Kontrolle über beide Tunnelendpunkte hat, aber dieser Ansatz war nicht wirklich praxisnah. Was die Welt benötigte, war ein automatischer Tunnelmechanismus, der sich um all die technischen Details kümmert.
Der erste Ansatz dieser Art, der eine gewisse Verbreitung fand, war 6to4. Das erste Problem mit 6to4 war, dass es öffentliche IPv4-Adressen benötigte und daher keine Dienste für IPv6-Hosts hinter einem NAT bereitstellen konnte. Das kritischere Problem bestand darin, dass Firewalls nicht wussten, wie sie mit 6to4-Paketen umgehen sollten, und im Zweifelsfall standardmäßig den Zugang verweigern. So führte der Einsatz von 6to4 zu einer Fehlerquote von 20 Prozent, was es unbrauchbar machte. Das NAT stellte ebenfalls ein Problem dar, so dass ein zweiter Autotunnel-Mechanismus entwickelt wurde, der die NAT-Erkennung und -Überwindung durchführt. Dieser Mechanismus war in Bezug auf die Fehlerquote noch schlechter – etwa 40 Prozent der Teredo-Verbindungsversuche schlugen fehl. Nicht nur, dass diese anfänglichen Übergangstools extrem unzuverlässig waren, sondern selbst wenn sie funktionierten, war die Verbindung sowohl anfällig als auch langsamer als IPv4.
Bis 2011 wurde IPv6 infolgedessen weitgehend ignoriert. Eine kleine Anzahl von Dienstanbietern versuchte, die neue IP-Variante einzuführen. Doch in jedem Fall sahen sie sich mit einer Reihe einzigartiger Herausforderungen konfrontiert, die gelöst werden mussten. Und ohne ein reichhaltiges Angebot an IPv6-Inhalten und -Diensten war der Wert des ganzen Unterfangens höchst zweifelhaft! Also geschah nichts.
Endlich Bewegung in der Migration
Erst als der von der IANA verwaltete zentrale IPv4-Adresspool Anfang 2011 erschöpft war und das erste RIRs ihre Zuweisungspools auslaufen ließen, begann die ISP-Branche, diesem Übergang mehr Aufmerksamkeit zu schenken. Zunächst waren dies nur zögerliche Schritte, doch in den letzten zehn Jahren hat die Umstellung an Dynamik gewonnen. Die IPv6-Zahlen verdreifachten sich von 5 Prozent Anfang 2016 auf 17 Prozent Ende 2017. Dies ist größtenteils auf die rasche Einführung von IPv6 in indischen Mobilfunknetzen zurückzuführen.
In den folgenden drei Jahren (2018-2020) stieg diese Zahl von 17 Prozent auf 30 Prozent. Ein großer Teil dieser zweiten Wachstumsphase ist auf die Einführung von IPv6 in China zurückzuführen.
Es geht jedoch nicht nur um den Einsatz in Indien und China. Auch in anderen Volkswirtschaften wie Mexiko, Brasilien und den Vereinigten Staaten ist die IPv6-Fähigkeit in diesem Fünfjahreszeitraum stetig und nachhaltig gewachsen. Wenn wir den Anteil des IPv6-Einsatzes an der Gesamtzahl der Nutzer als Maßstab nehmen – etwa 30 Prozent aller Nutzer -, dann kann man davon ausgehen, dass die Umstellung voll im Gange ist. Natürlich sind diese 30 % nicht gleichmäßig verteilt. Wenn man die Volkswirtschaften berücksichtigt, ergibt sich ein differenziertes Bild des derzeitigen Stands der Umstellung. Die Umstellung auf IPv6 ist in einer relativ kleinen Gruppe von Volkswirtschaften im Gange. Nur 32 Volkswirtschaften haben IPv6-Einführungsraten, die über dem weltweiten Durchschnitt von 30 Prozent liegen. Regional gesehen scheint der Grad der IPv6-Einführung in Südasien, Nordamerika und Westeuropa am höchsten zu sein, während die niedrigsten Raten in Afrika und im Pazifikraum (Ozeanien) zu verzeichnen sind.
Wie lange noch?
Nun, da wir uns mitten in diesem Übergang befinden, stellt sich die nächste Frage: Wie lange wird dieser Übergang noch dauern? Das scheint eine einfache Frage zu sein, aber sie bedarf einer etwas genaueren Erklärung. Was ist der „Endpunkt“, an dem wir den Übergang für beendet erklären können? Das heißt, wann wird dieser Übergang „abgeschlossen“ sein? Ist es der Zeitpunkt, an dem es keinen IPv4-basierten Verkehr im Internet mehr gibt? Oder ist es der Zeitpunkt, an dem für öffentliche Dienste im Internet kein Bedarf mehr an IPv4 besteht? Oder meinen wir den Zeitpunkt, an dem reine IPv6-Dienste rentabel sind? Oder sollten wir vielleicht den Markt für IPv4-Adressen betrachten und den Endpunkt dieses Übergangs zu dem Zeitpunkt definieren, an dem der Preis für IPv4-Adressen vollständig zusammenbricht?
Vielleicht sollten wir hier einen pragmatischeren Standpunkt einnehmen und den Abschluss der Umstellung nicht als den Zeitpunkt ansehen, an dem das Internet vollständig von IPv4-Adressen befreit ist, sondern als den Zeitpunkt, an dem die Verwendung von IPv4 nicht mehr notwendig ist. Das würde bedeuten, dass wir den Übergang abgeschlossen haben, wenn ein Diensteanbieter einen lebensfähigen Internetdienst nur mit IPv6 betreiben kann und keine unterstützten IPv4-Zugangsmechanismen mehr bereitstellen muss.
Was bedeutet das? Natürlich müssen die ISP IPv6 anbieten. Aber auch alle angeschlossenen Netze und die Hosts in diesen Netzen müssen IPv6 unterstützen. Schließlich hat der ISP zu diesem Zeitpunkt der Umstellung keine IPv4-Dienste mehr. Das bedeutet auch, dass alle Dienste, die von den Kunden dieses ISP genutzt werden, über IPv6 zugänglich sein müssen. Dazu gehören alle gängigen Cloud-Dienste und Cloud-Plattformen, alle Content-Streamer und alle Plattformen für die Verbreitung von Inhalten.
Wir sind heute sicher noch nicht so weit und werden diesen Punkt in den nächsten zwei oder drei Jahren wohl auch nicht erreichen. Aus den auf der World IPv6 Launch Site veröffentlichten Daten geht hervor, dass nur etwa 30 Prozent der Alexa Top 1.000 Websites über IPv6 erreichbar sind, und es liegt auf der Hand, dass mehrere Serviceplattformen noch erhebliche Arbeit vor sich haben.
Warum dauert dieser Übergang so lange?
Der Übergang von IPv4 auf IPv6 dauert so lange, weil es kein gemeinsames Bewusstsein für die Dringlichkeit gibt. Während einige Akteure die notwendigen Änderungen vorgenommen haben, um Dual-Stack-Dienste und -Infrastrukturen einzurichten, sind andere Akteure der Meinung, dass solche Maßnahmen derzeit keine Priorität haben. Und solange das Aufschieben solcher Maßnahmen keine unannehmbaren geschäftlichen Konsequenzen hat, wird es einfach weiter aufgeschoben.
Ein Teil des Problems besteht darin, dass durch die Einführung von IPv6 kein größerer Wettbewerbsvorteil zu erzielen ist. Es bietet gegenüber IPv4 keine einzigartigen Fähigkeiten, die zu größerer Effizienz, niedrigeren Kosten oder einzigartigen Dienstleistungsprofilen führen würden. Die Anfangsphase des Betriebs einer Dual-Stack-Umgebung ist mit höheren Kosten und einem höheren Support-Aufwand verbunden und bringt keine wirklichen Vorteile mit sich.
Die Argumente für IPv6 basierten ursprünglich auf einer Risikovorsorge. Die gemeinsame Nutzung von Adressen in Form von NATs wurde als inakzeptable Maßnahme angesehen. Und als der Pool der verfügbaren IPv4-Adressen erschöpft war, ging man davon aus, dass ein weiteres Wachstum des Internets unmöglich sein würde, da wir die Verwendung von NATs vollständig aufgeben würden. Die rechtzeitige Einführung von IPv6 wurde als zwingende Maßnahme angesehen, um eine solche Situation zu vermeiden.
NATs waren jedoch zunächst keine Angelegenheit der Internetdienstleister. Die ISP lagerten NATs effektiv an die Anbieter von Endgeräten aus und verlagerten damit das gesamte Problem auf die Endnutzer und den Anwendungsbereich. Die Anwendungsentwickler sahen sich mit der simplen Tatsache konfrontiert, dass ihre Anwendung entweder nahtlos mit NATs zusammenarbeitet oder einfach nicht funktioniert. Die Anwendungen entfernten sich von dem ursprünglichen Ende-zu-Ende-Verbindungsmodell des Internets und übernahmen stattdessen Server/Client-Service-Modelle.
Der nächste Schritt wurde mit der Einführung von Mobilfunknetzen vollzogen, bei denen es am Client-Ende der Verbindung kein CPE gab. ISPs bauten das NAT in ihre eigene Infrastruktur ein und sogenannte Carrier-Grade NATs (CGNs) wurden alltäglich. All dies hätte vermieden werden können, wenn wir die Umstellung auf IPv6 vor der massenhaften Einführung von Mobilfunkdiensten abgeschlossen hätten. Da dies jedoch während der Umstellung geschah, musste jeder Mobilfunkanbieter eine Lösung finden, um seinen Kunden IPv4-Dienste anbieten zu können, unabhängig davon, ob sie bereits IPv6 eingeführt hatten oder nicht. CGNs in der einen oder anderen Form waren somit für alle eine Pflicht. IPv6 war nur ein optionales Extra.
Es hat den Anschein, dass der Druck, einen Dual-Stack-Dienst einzuführen, in verschiedenen Teilen des Internets mit unterschiedlicher Intensität realisiert wird. Einige Betreiber sahen sich gezwungen, IPv6 mit einer gewissen Dringlichkeit einzuführen, um den Druck auf einen ansonsten unzureichenden Pool an öffentlichen IPv4-Adressen zur Unterstützung ihrer CGNs zu mindern. Andere Betreiber verspüren derzeit keinen Druck zur Einführung und sind bereit, den richtigen Zeitpunkt abzuwarten.
Gemeinsame Bedürfnisse signalisieren
Es ist nützlich, sich daran zu erinnern, dass das Internet keine Einheit darstellt. Es gibt viele Einzelnetze, Unternehmensnetze, Netze zur Unterstützung des Internets der Dinge (IoT) usw. Es gibt eine große Vielfalt von Anbietern im Internet-Ökosystem. Es gibt IP-Zugangsbetreiber, IP-Transportanbieter, Plattformanbieter, Anwendungsanbieter, Inhaltsplattformen und so weiter. Diese einzelnen Akteure kommunizieren ihre jeweiligen Bedürfnisse in der Regel durch Marktsignale miteinander, und Marktsignale werden normalerweise in Form von Preisen ausgedrückt. Nachgefragte Güter und Dienstleistungen stehen unter Preisdruck, während nicht mehr benötigte Güter und Dienstleistungen einen Preisverfall erfahren.
Viele Jahre lang haben wir jedoch IP-Adressen von solchen marktbasierten Verteilungsmechanismen ferngehalten. Dafür gab es viele Gründe, u. a. die Betrachtung von Adressen als öffentliches Gut und der Wunsch, den Verbrauch von Adressen nach den Grundsätzen der Bestandserhaltung zu steuern, um eine gewisse Form von Gleichheit beim Zugang zu Adressen (Fairness) zu erreichen und möglichen Störungen der Adressverteilung durch Marktverzerrungen entgegenzuwirken.
Das Ergebnis war, dass die Signalisierung einer drohenden IPv4-Knappheit nicht durch herkömmliche Preisbildungsmechanismen erfolgte. Erst als in den 2010er Jahren der Markt für den Adresstransfer hinzukam, waren Preisinformationen als eine Form der Marktsignalisierung verfügbar.
Wenn der Anstieg eines Preises für eine Ware ein Signal für eine Änderung der Marktstimmung ist, dann gab es von Anfang 2014 bis Anfang 2018 keine wesentliche Änderung der allgemeinen Stimmung. Der relativ langsame Preisanstieg für IP-Adressen zeigt, dass die Besorgnis über die drohende Verknappung des Angebots an IPv4-Adressen nicht groß ist. Selbst der Preisanstieg im Jahr 2018 wurde durch die gleichbleibenden, wenn nicht sogar leicht sinkenden Preise in den Jahren 2019 und 2020 ausgeglichen.
Im Jahr 2021 änderte sich die Situation radikal, und der Preis für IP-Adressen verdoppelte sich. Dies kann nur heißen: Die Nachfrage nach IP-Adressen übersteigt derzeit das Angebot. Aber daraus kann man auch schließen, dass es keinen allgemeinen Konsens darüber gibt, dass die Umstellung bald abgeschlossen ist und dass die Nachfrage nach IPv4-Adressen das Angebot noch einige Zeit übersteigen wird. Wie lange diese Situation andauern wird, lässt sich aus den derzeitigen Marktpreisinformationen jedoch kaum ableiten.
Wird der Übergang ewig dauern?
Wenn wir schon nicht vorhersagen können, wann die Migration von IPv4 auf IPv6 tatsächlich beendet sein wird, haben wir dann wenigstens eine Idee, ob dieser Übergang überhaupt jemals abgeschlossen sein wird?
Nachdem der Beginn der IPv6-Umstellung fast 25 Jahre zurückliegt und das Internet für die Nutzer und die Dienste immer noch sehr gut auf Basis von IPv4 funktioniert, entsteht der immer mehr der Eindruck, dass der Übergang zwischen den beiden Protokollvarianten noch eine unbestimmte Zeit andauern kann. Der Migrationszeitraum hängt davon ab, welchem Modell des Internet-Wachstums man Glauben schenken möchte. Wenn die große Wachstumsphase des Internets tatsächlich vorbei ist und wir es mit einem gesättigten Markt zu tun haben, dann wird der Übergang wahrscheinlich ewig dauern. In der gegenwärtigen Situation gibt es jedoch kaum noch Möglichkeiten, weiteres Wachstum zu absorbieren. Gründe hierfür sind darin zu suchen, dass neue Marktteilnehmer immer noch irgendeine Form des Zugangs zu IPv4-Adressen benötigen würden. Dies bedeutet, dass die etablierten Märkte, einschließlich der privaten Massendienste in vielen Teilen der Welt, nicht unbedingt unter großem Druck stehen, ihre Plattform zu erweitern und sich mehr IPv4-Adressen zu sichern. Aber das ist keineswegs die Gesamtheit der Netzumgebung.
Die Wachstumsbereiche scheinen im Bereich der Cloud-Dienste und des Internet der Dinge zu liegen, ebenso wie die fortgesetzte Expansion der konventionellen Einzelhandelsmärkte für den Internetzugang in Afrika und in Teilen Asiens. Derzeit wird die Zahl der Internetnutzer auf etwa 4,2 Milliarden geschätzt, bei einer Weltbevölkerung von insgesamt 7,8 Milliarden. Das Internet muss also noch wachsen.
Ist die Umstellung auf IPv6 die einzige Option?
Bei dieser Diskussion über den Übergang wird davon ausgegangen, dass IPv6 die einzige verfügbare Option ist. Und wenn dies der Fall ist, dann spricht die kontinuierliche Ausweitung des Umfangs digitaler Systeme in eine Welt eingebetteter Objekte dafür, dass reine IPv6-Dienste früher oder später unvermeidlich sind. Vielleicht sollten wir uns fragen, ob diese Sichtweise einer sehr begrenzten Anzahl von Optionen, nämlich einer einzigen, tatsächlich zutreffend ist.
Wir haben im Laufe der Jahre verschiedene Netzmodelle diskutiert. Namensbasierte Netze scheinen eine potenziell brauchbare Alternative zu bieten. Im ursprünglichen Konzept der namensbasierten Netze wurde festgelegt, die Adressfelder in einem Paketkopf durch Dienstidentifikationsnamen zu ersetzen und Pakete auf der Grundlage dieser Namen weiterzuleiten. Was wir jedoch in der NAT-Welt von IPv4 aufgebaut haben, ist etwas ganz anderes. Wenn wir einen Dienstnamen im DNS auflösen, versucht das DNS, uns eine Adresse zur Verfügung zu stellen, die uns den Zugriff auf den Dienst ermöglicht. Die Adresse ist nicht notwendigerweise eindeutig für diesen bestimmten Dienstnamen, da Auflösungsanfragen für verschiedene DNS-Dienstnamen auch die gleiche IP-Adresse ergeben können. Die Adresse ist nicht zeitlich festgelegt, da dieselbe DNS-Auflösungsabfrage zu einem anderen Zeitpunkt zu unterschiedlichen Adressen führen kann. Und die Adresse ist nicht universell, da verschiedene Benutzer, die dieselbe DNS-Auflösungsanfrage stellen, unterschiedliche Adressen erhalten können.
Diese potenzielle Mehrdeutigkeit bei der Zuordnung von Dienstnamen zu IP-Adressen wird auf der Transport- und Anwendungsebene gelöst. Wenn eine Verbindung zu einer Adresse hergestellt wird, muss der Client den Namen des Dienstes angeben, mit dem er sich verbinden möchte. Diese explizite Identifizierung des Dienstes ist Teil des Client-Hallo-Austauschs im TLS-Protokoll, Teil des HTTP-Anfangsaustauschs und Teil vieler anderer Dienstprotokolle. Diese indirekte Identifizierung soll es ermöglichen, dass ein Server viele Dienste beherbergt und dass ein Dienst auf vielen Servern beherbergt werden kann. Das Ergebnis ist, dass IP-Adressen einfach nicht eindeutig mit Diensten oder Netzendpunkten verbunden sind. Das heutige Netz ist eine Version eines benannten Netzes, und die Rolle der IP-Adressen sind flüchtige Token auf Sitzungsebene, die es dem Netz ermöglichen, zwischen gleichzeitigen Paketflüssen zu unterscheiden, und sonst nichts.
Bei der weiteren Erforschung dieses digitalen Raums ist es ein wenig vermessen anzunehmen, dass die Architekturen, die wir in den 1970er Jahren für paketvermittelte Netze entwickelt haben, die einzigen sind, die funktionieren können, und dass wir niemals andere Architekturen entwickeln werden. Die heutigen Kombinationen von NATs, Anycast-Systemen, Content-Distributionsnetzen und verbesserter Funktionalität auf Anwendungsebene deuten alle auf einen anderen Übergang hin, der im Internet bereits leise im Gange ist. Es ist ein Übergang, der sich nicht mehr auf die IP-Schicht als universelles Anpassungsprotokoll zwischen verschiedenen Netzmedien und Anwendungen stützt, sondern die kritische gemeinsame Abhängigkeit weiter oben im Protokollstapel in die Anwendungsschicht verschiebt.
Sind wir mit IPv6 schon so weit?
Die Antwort auf diese Frage lautet: Eindeutig nein. Aber wir nähern uns dem Ziel. Wenn das Ziel darin besteht, den Kunden einen reinen IPv6-Dienst anzubieten, der den jeweiligen Anforderungen entspricht, dann haben die laufenden Bemühungen um die Einführung von IPv6 im Bereich der Inhalte und Diensteplattformen einen gewissen Einfluss darauf, wann wir diesen Punkt erreichen könnten.
Ich kenne keine veröffentlichten Daten zu den Bereitstellungsregeln für die Anzahl der in CGNs verwendeten gepoolten IPv4-Adressen im Verhältnis zur Größe der Benutzerbasis. Angesichts der zunehmenden Nutzung von IPv6 in den Dienstplattformen und der Verwendung von IPv6-Präferenzregeln in Anwendungen vermute ich jedoch stark, dass dieses Verhältnis zwischen der erforderlichen IPv4-Poolgröße und der Kundenbasis im Laufe der Zeit abnimmt.
Dies führt zu einer weiteren Beobachtung: Es ist wahrscheinlich, dass wir das Ende dieser Umstellung nicht mit einem Knall, sondern langsam und stetig erreichen werden. Es ist nicht so, dass alle ISPs ihre CGNs abschalten und IPv4 zu einem bestimmten Datum aufgeben werden. Wahrscheinlicher ist, dass die Zahl der IPv4-Adressen, die für die Versorgung der ISP-Kunden erforderlich sind, weiter abnimmt. Irgendwann macht es keinen Sinn mehr, weiterhin Ressourcen für den Betrieb dieser CGN-Dienste innerhalb der eigenen Infrastruktur des Internet-Diensteanbieters bereitzustellen. Kunden, die IPv4-Dienste benötigen, müssten sich einen anderen ISP suchen, der noch IPv4 anbietet, oder zu einem externen IPv4-Dienst wechseln und eine Art VPN-Tunnel für den Zugang zu diesem Dienst nutzen. Dies wird wahrscheinlich nicht überall auf einmal geschehen, sondern schrittweise über einen längeren Zeitraum.
Wann wird diese Umstellung also abgeschlossen sein?
Ich weiß es einfach nicht!
Von Mathias Hein, Consultant, Autor, Journalist
