IPv6 ist längst da – warum Unternehmen trotzdem an IPv4 festhalten

IPv6 – die Zukunft seit drei Jahrzehnten

IPv6 besitzt eine bemerkenswerte Eigenschaft: Seit Jahrzehnten gilt das Protokoll gleichzeitig als Zukunftstechnologie und als längst überfälliger Nachfolger von IPv4. Bereits Mitte der 1990er-Jahre nahm die Internet Engineering Task Force die wesentlichen Grundlagen des neuen Internet Protocols in ihre Standardisierung auf. Im Dezember 1995 beschrieb RFC 1883 erstmals die Spezifikation von IPv6. Seitdem sind mehr als drei Jahrzehnte vergangen.

Wer sich heute mit IPv6 beschäftigt, betritt deshalb keineswegs technologisches Neuland. Moderne Betriebssysteme unterstützen das Protokoll selbstverständlich. Internetprovider und Mobilfunkanbieter transportieren erhebliche Teile ihres Datenverkehrs über IPv6. Große Internetdienste sind über IPv6 erreichbar und aktuelle Netzwerkkomponenten beherrschen den Protokollstapel seit vielen Jahren.

Trotzdem wirkt IPv6 gerade in Unternehmensnetzen häufig noch immer wie ein Projekt für die Zukunft. IPv4 bildet dort vielerorts weiterhin das vertraute Fundament. Private Adressbereiche, Network Address Translation, IPv4-basierte Firewall-Regeln sowie über Jahre gewachsene Monitoring- und Troubleshooting-Prozesse prägen den täglichen Betrieb. Genau daraus entsteht ein bemerkenswertes Paradoxon: IPv6 ist längst etabliert, ohne IPv4 verdrängt zu haben.

IPv6 muss nicht mehr auf seine Bewährungsprobe warten

Die Diskussion über IPv6 wird häufig auf die Größe des Adressraums reduziert. Das greift inzwischen zu kurz. Natürlich war die absehbare Knappheit der 32-Bit-IPv4-Adressen ein entscheidender Auslöser für die Entwicklung eines Nachfolgeprotokolls. IPv6 stellt mit seinen 128-Bit-Adressen einen ungleich größeren Adressraum bereit.

Doch die vergangenen Jahrzehnte haben aus IPv6 mehr als eine Antwort auf Adressknappheit gemacht. Das Protokoll verändert auch grundlegende Mechanismen eines IP-Netzes. Neighbor Discovery übernimmt Aufgaben, die unter IPv4 unter anderem mit ARP verbunden sind. Router Advertisements und Stateless Address Autoconfiguration ermöglichen andere Formen der automatischen Netzwerkkonfiguration. Multicast übernimmt Funktionen, für die IPv4 noch Broadcast verwendet.

Diese technischen Grundlagen habe ich bereits ausführlich im Beitrag Adresswelten im Wandel – der strukturierte Einstieg in TCP/IPv6 behandelt. An dieser Stelle soll deshalb nicht erneut erklärt werden, wie eine IPv6-Adresse aufgebaut ist oder wie SLAAC funktioniert. Interessanter ist inzwischen eine andere Frage: Warum konnte sich ein technisch ausgereiftes und breit unterstütztes Protokoll über Jahrzehnte etablieren, ohne seinen Vorgänger vollständig abzulösen?

Ein Blick auf die Zahlen erzählt nur einen Teil der Geschichte

Aktuelle Messungen zeigen deutlich, wie weit IPv6 inzwischen verbreitet ist. Google, APNIC, die Internet Society und weitere Organisationen erfassen kontinuierlich, welcher Anteil von Benutzer:innen oder Netzwerkverbindungen IPv6 verwenden kann. Je nach Messverfahren, Region und Betrachtungsweise unterscheiden sich die Ergebnisse erheblich. Dennoch zeigen sie denselben langfristigen Trend: IPv6 ist aus dem öffentlichen Internet nicht mehr wegzudenken.

Allerdings darf eine hohe globale IPv6-Nutzung nicht mit einer vollständigen Migration gleichgesetzt werden. Ein Mobilfunkanbieter kann seine Infrastruktur weitgehend IPv6-basiert betreiben, während ein mittelständisches Unternehmen intern weiterhin ausschließlich mit privaten IPv4-Adressen arbeitet. Ein privater Internetanschluss kann IPv6 bereitstellen, obwohl die dahinter betriebenen Anwendungen und Verwaltungsprozesse weiterhin stark von IPv4 geprägt sind.

Gerade deshalb lohnt sich eine differenzierte Betrachtung. Die Frage lautet nicht mehr, ob IPv6 funktioniert. Dafür existieren längst genügend produktive Netze. Die spannendere Frage lautet, warum IPv4 trotzdem so erfolgreich weiterlebt.

Die eigentliche Herausforderung liegt nicht nur im Protokoll

Technische Migrationen folgen selten ausschließlich technischen Argumenten. Eine vorhandene Infrastruktur besitzt einen Wert, gerade weil sie funktioniert. Administrator:innen kennen ihre Eigenheiten. Werkzeuge sind darauf abgestimmt. Anwendungen wurden dafür entwickelt. Sicherheitskonzepte, Dokumentationen und Betriebsprozesse sind über Jahre gewachsen.

IPv4 profitiert in besonderem Maße von diesem Effekt. Mehrere Generationen von IT-Professionals haben gelernt, Netzwerke in IPv4 zu planen und zu betreiben. Adressen aus 10.0.0.0/8 oder 192.168.0.0/16 wirken vertraut. NAT gehört für viele selbstverständlich zur Grenze zwischen internem Netzwerk und Internet. Selbst manche Architekturentscheidungen, die ursprünglich aus der Adressknappheit entstanden, werden inzwischen kaum noch als solche wahrgenommen.

In meinen Seminaren begegnet mir an dieser Stelle regelmäßig eine interessante Reaktion. Wenn wir uns mit den Vorteilen von IPv6 beschäftigt haben und die grundsätzliche Unterstützung durch aktuelle Betriebssysteme und Netzwerkkomponenten geklärt ist, stelle ich irgendwann die naheliegende Frage: „Warum machen wir es dann nicht?“ Eine keineswegs untypische Antwort lautet: „Never change a running system!“

Aus Sicht der klassischen Administration ist diese Haltung zunächst durchaus nachvollziehbar. Ein stabiles produktives Netzwerk ohne unmittelbaren Handlungsdruck umzubauen, erzeugt Aufwand und neue Risiken. Solange IPv4 funktioniert, Anwendungen erreichbar sind und genügend Adressen zur Verfügung stehen, erscheint eine Migration schnell als technisches Projekt ohne unmittelbaren betrieblichen Nutzen.

Genau darin liegt jedoch ein wesentlicher Teil des IPv6-Paradoxons. Was kurzfristig vernünftiges Risikomanagement sein kann, entwickelt sich über Jahre zur strukturellen Beharrung. Investitionen in IPv4-basierte Prozesse machen den nächsten Schritt nicht einfacher, sondern verfestigen die bestehende Architektur weiter. Damit wird aus einer technischen Frage zunehmend eine Frage der Betriebskultur.

IPv6 muss also nicht mehr beweisen, dass es technisch funktioniert. Vielmehr konkurriert es mit einer Infrastruktur, die über Jahrzehnte optimiert, erweitert und immer wieder erfolgreich am Leben gehalten wurde. Die entscheidende Hürde liegt deshalb häufig nicht in den 128 Bit einer IPv6-Adresse, sondern in der nachvollziehbaren Frage, warum eine funktionierende Umgebung überhaupt verändert werden sollte.

Warum sich ein Blick zurück lohnt

Um diese ungewöhnlich lange Koexistenz zu verstehen, reicht der Blick auf heutige IPv6-Netze nicht aus. Die entscheidenden Weichen wurden bereits gestellt, als das Internet noch einen Bruchteil seiner heutigen Größe besaß.

Anfang der 1990er-Jahre wurde zunehmend deutlich, dass die ursprüngliche IPv4-Architektur mit dem Wachstum des Internets an Grenzen stoßen würde. Doch anstatt IPv4 unmittelbar zu ersetzen, entwickelte die Internet-Community zunächst Verfahren, die den bestehenden Adressraum effizienter nutzbar machten. CIDR veränderte die Adressvergabe und das Routing. Private Adressräume und später die breite Nutzung von NAT eröffneten weitere Möglichkeiten, öffentliche IPv4-Adressen einzusparen. Parallel begann die Suche nach einem echten Nachfolger.

Diese beiden Entwicklungen verliefen nicht unabhängig voneinander. Während die IETF mit IP Next Generation – IPng über die Architektur des zukünftigen Internets diskutierte, wurde die bestehende IPv4-Welt gleichzeitig immer besser darin, ihre eigenen Grenzen hinauszuschieben.

Zwischen Erfahrung und Veränderungsbereitschaft

Doch zur Geschichte von IPv6 gehört noch eine weitere Perspektive: die der Menschen, die solche Veränderungen im täglichen Betrieb umsetzen müssen. In Seminaren begegnet mir bei IPv6 gelegentlich eine Frage, die ähnlich auch bei Cloud, Zero Trust oder inzwischen KI auftaucht: „Muss ich mich damit in meinem Berufsleben eigentlich noch beschäftigen?“ Diese Haltung beobachte ich keineswegs flächendeckend, aber durchaus häufiger bei erfahrenen Kolleg:innen, die bereits mehrere grundlegende Technologiewechsel begleitet haben.

Gerade darin liegt eine gewisse Ironie. Viele dieser Administrator:innen haben selbst erlebt, wie TCP/IP und IPv4 ältere Netzwerkprotokolle und Architekturen verdrängten. Sie kennen nicht nur die Vorteile technologischen Fortschritts, sondern auch dessen weniger angenehme Begleiterscheinungen: Migrationen, Inkompatibilitäten, unvollständige Herstellerimplementierungen, ungeplante Ausfälle und nicht zuletzt zahlreiche Abende, an denen eine theoretisch gut vorbereitete Umstellung eben doch nicht so funktionierte wie vorgesehen.

Jüngere Kolleg:innen betrachten IPv6 dagegen häufig mit einer anderen Ausgangslage. Für sie ist die Technologie weniger mit vergangenen Migrationsrisiken verbunden. Neugier und der Ehrgeiz, eine moderne Architektur aufzubauen, können deshalb auf die Erfahrung derjenigen treffen, die sehr genau wissen, was bei grundlegenden Veränderungen alles schiefgehen kann.

Wenn Erfahrung zur Bremse wird

Das kann zu einem bemerkenswerten Spannungsfeld führen. Sinngemäß lautet die Haltung dann gelegentlich: „Wir haben in den vergangenen Jahrzehnten genug technische Umbrüche erlebt. Wenn IPv4 bis zu meinem Ruhestand funktioniert, könnt ihr die nächste große Migration danach machen.“

Das mag zunächst konservativ klingen. Vollständig irrational ist es nicht. Erfahrung verändert die Wahrnehmung von Risiken. Wer zahlreiche Migrationen begleitet hat, bewertet nicht nur den möglichen Nutzen einer neuen Technologie, sondern erinnert sich auch an deren Kosten, Nebenwirkungen und unerwartete Folgen.

Genau deshalb lohnt sich der Blick zurück. Die Geschichte von IPv6 handelt nicht nur von einem größeren Adressraum oder einem neuen Netzwerkprotokoll. Sie handelt ebenso von technischen Übergangslösungen, wirtschaftlichen Entscheidungen, gewachsenen Betriebsmodellen und Menschen, die über Jahrzehnte gelernt haben, funktionierende Infrastruktur mit einer gewissen Vorsicht zu verändern.

Genau dort beginnt die eigentliche Geschichte von IPv6 – und möglicherweise auch die Erklärung dafür, warum ein Protokoll aus den 1990er-Jahren im Jahr 2026 noch immer als Zukunftsthema wahrgenommen werden kann.

Als die IPv4-Adressen knapp wurden

Als IPv4 mit RFC 791 im Jahr 1981 spezifiziert wurde, sah die vernetzte Welt grundlegend anders aus. Das spätere globale Internet mit Milliarden angeschlossener Geräte war zwar konzeptionell denkbar, seine tatsächliche Entwicklung ließ sich jedoch kaum vorhersehen. Entsprechend geriet die ursprüngliche Adressierungs- und Routingarchitektur mit dem rasanten Wachstum Ende der 1980er- und Anfang der 1990er-Jahre zunehmend unter Druck.

Die Ausgangssituation erscheint aus heutiger Perspektive beinahe überschaubar. Als das ARPANET am 1. Januar 1983 offiziell von NCP auf TCP/IP umgestellt wurde, galt es gerade einmal 562 Hosts zu unterstützen. Doch schon wenige Jahre später hatte sich die Größenordnung grundlegend verändert. Ende der 1980er-Jahre waren bereits mehrere Zehntausend Systeme vernetzt. 1990 waren es rund 313.000 Hosts, Anfang der 1990er-Jahre wurde die Millionengrenze überschritten und Mitte des Jahrzehnts zählte das Internet bereits mehrere Millionen angeschlossene Systeme.

Eine Adressarchitektur, die zu Beginn der TCP/IP-Ära einige Hundert Hosts versorgen musste, bildete damit nur ein Jahrzehnt später die Grundlage für ein Netz mit mehr als einer Million Systemen. Und das eigentliche kommerzielle Wachstum des Internets stand zu diesem Zeitpunkt erst bevor.

Nicht nur die Zahl der Hosts wurde zum Problem

Mit der Zahl der angeschlossenen Systeme wuchs auch die Infrastruktur, die diese Systeme und ihre Netze miteinander verbinden musste. RFC 1519 dokumentiert diese Entwicklung anhand der globalen Routingtabellen besonders eindrucksvoll: Im Juli 1988 wurden lediglich 173 Routen angekündigt. Im Dezember 1990 waren es bereits 2.190, zwei Jahre später rund 8.500. Die Autor:innen gingen davon aus, dass sich dieses exponentielle Wachstum fortsetzen würde.

Hostzahlen und Routingtabelleneinträge beschreiben dabei unterschiedliche Aspekte derselben Entwicklung. Ein Host benötigte eine IP-Adresse. Ein Eintrag in der globalen Routingtabelle repräsentierte dagegen ein erreichbares Netzwerk beziehungsweise Präfix. Mit immer mehr angeschlossenen Organisationen stieg deshalb nicht nur der Bedarf an IPv4-Adressen. Router mussten zugleich immer mehr Informationen darüber verwalten, über welchen Weg die einzelnen Netze überhaupt erreichbar waren.

Damit wurden mehrere potenzielle Brandherde sichtbar: Das Problem bestand nicht einfach darin, dass irgendwann die letzte IPv4-Adresse vergeben sein würde. Bereits wesentlich früher drohten die Verfahren zur Vergabe und zum Routing dieser Adressen an ihre praktischen Grenzen zu stoßen.

Drei Probleme entstehen gleichzeitig

Anfang der 1990er-Jahre musste die Internet-Community deshalb mehrere miteinander verbundene Herausforderungen gleichzeitig lösen. Bestimmte Bereiche des IPv4-Adressraums wurden zunehmend knapp, während die globalen Routingtabellen rasant wuchsen. Gleichzeitig zeichnete sich langfristig die Erschöpfung des gesamten 32-Bit-Adressraums ab.

Diese Unterscheidung ist für die weitere Entwicklung entscheidend. IPv4 stand Anfang der 1990er-Jahre nicht plötzlich unmittelbar vor dem Aus. Vielmehr wurde sichtbar, dass die bestehende Architektur mit dem erwarteten Wachstum des Internets nicht dauerhaft skalieren konnte.

Genau daraus entstand ein strategisches Dilemma. Einerseits benötigte das Internet langfristig eine neue Architektur. Andererseits musste das bereits existierende und immer schneller wachsende Netz kurzfristig weiter funktionieren. Ein radikaler Wechsel des Internet Protocols war angesichts der vorhandenen Infrastruktur keine realistische Sofortlösung. Die Internet-Community brauchte deshalb vor allem eines: Zeit. Und genau diese Zeit sollten zunächst Technologien wie CIDR verschaffen.

Classful Networking wird zum Problem

Eine Ursache lag in der damals üblichen klassenbasierten Adressvergabe. IPv4-Netze wurden im Wesentlichen in Class A, Class B und Class C eingeteilt. Diese festen Größen passten jedoch zunehmend schlechter zu den tatsächlichen Anforderungen der Organisationen. RFC 1519 beschreibt das Problem ausgesprochen anschaulich. Ein Class-C-Netz bot maximal 254 Hostadressen und war für viele mittelgroße Organisationen zu klein. Ein Class-B-Netz stellte dagegen bis zu 65.534 Hostadressen bereit und war häufig viel zu groß. Dazwischen fehlte schlicht eine geeignete Größenklasse.

Das hatte weitreichende Folgen. Benötigte eine Organisation beispielsweise Adressen für 1.000 Systeme, konnte ein einzelnes Class-C-Netz den Bedarf nicht decken. Die Zuweisung eines Class-B-Netzes reservierte dagegen einen erheblich größeren Adressbereich, als tatsächlich benötigt wurde. Gleichzeitig ließ sich das Problem nicht beliebig durch die Vergabe mehrerer Class-C-Netze lösen. Jedes zusätzliche Netz konnte weitere Routinginformationen erzeugen. Damit verschärfte eine Maßnahme gegen die Adressknappheit potenziell das zweite Problem: das Wachstum der globalen Routingtabellen.

Die Internet-Community musste deshalb nicht einfach mehr Adressen verteilen, sondern die vorhandenen Adressen wesentlich flexibler und das Routing zugleich effizienter organisieren.

CIDR verschafft dem Internet Zeit

Eine der entscheidenden Antworten darauf war Classless Inter-Domain Routing (CIDR). RFC 1519 standardisierte 1993 eine Strategie, bei der sich die Adressvergabe zunehmend von den starren Netzwerkklassen löste. Adressblöcke konnten bedarfsgerechter vergeben und Routinginformationen zusammengefasst werden. Damit adressierte CIDR gleich zwei akute Skalierungsprobleme. Zum einen ließ sich der vorhandene IPv4-Adressraum effizienter nutzen. Zum anderen ermöglichte die Aggregation zusammenhängender Netze, mehrere einzelne Routen durch eine übergeordnete Route zu repräsentieren.

Bemerkenswert ist jedoch, wie die Autor:innen ihre eigene Lösung einordneten. RFC 1519 stellte ausdrücklich klar, dass CIDR die langfristige Erschöpfung des 32-Bit-Adressraums nicht lösen sollte. Vielmehr sollte die Strategie genügend Zeit schaffen, bis eine langfristige Lösung entwickelt und produktiv eingesetzt werden konnte. Damals ging man davon aus, dass diese Übergangsstrategie für mindestens drei Jahre ausreichen könnte. Aus heutiger Sicht besitzt diese Einschätzung eine gewisse historische Ironie. CIDR funktionierte so gut, dass aus der kurzfristigen Entlastung ein dauerhaftes Fundament des Internets wurde.

Parallel beginnt die Suche nach einem Nachfolger

Während CIDR die akuten Probleme entschärfte, arbeitete die Internet-Community bereits an der langfristigen Lösung. Unter dem Begriff IP Next Generation (IPng) begann ein umfangreicher Prozess zur Auswahl eines Nachfolgers für IPv4. Dabei ging es keineswegs nur darum, die Adresse um einige zusätzliche Bits zu verlängern. Das zukünftige Internet Protocol musste skalierbares Routing ermöglichen, einen erheblich größeren Adressraum bereitstellen und gleichzeitig einen realistischen Übergang aus der bestehenden IPv4-Welt erlauben.

Genau dieser letzte Punkt sollte sich als entscheidend erweisen. Ein neues Internet Protocol konnte nicht auf einer grünen Wiese eingeführt werden. Anfang der 1990er-Jahre existierte bereits eine produktive und schnell wachsende Internet-Infrastruktur. Millionen Systeme mussten während einer Migration weiter miteinander kommunizieren können.

RFC 1752 dokumentierte 1995 schließlich die Empfehlung für IPng. Aus dem Auswahlprozess ging die Architektur hervor, die wenig später als IPv6 standardisiert wurde. Die Entwicklung des Nachfolgers lief damit bereits. Gleichzeitig geschah jedoch etwas, das seine spätere Einführung entscheidend beeinflussen sollte: IPv4 wurde immer besser darin, weiterzuleben.

Private Adressen verändern die Netzplanung

Ein weiterer wichtiger Baustein dieser Entwicklung waren private IPv4-Adressräume. RFC 1918 definierte 1996 die heute praktisch allen Administrator:innen vertrauten Bereiche 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16 für private Netze. Dadurch benötigte nicht mehr jedes interne System eine weltweit eindeutige öffentliche IPv4-Adresse. Unternehmen konnten umfangreiche interne Netzwerke mit Adressen betreiben, die im öffentlichen Internet nicht geroutet wurden. RFC 1918 unterschied entsprechend zwischen Hosts, die lediglich innerhalb eines Unternehmens kommunizieren mussten, und solchen Systemen, die tatsächlich externe Konnektivität benötigten.

Für Unternehmensnetze war dieses Modell ausgesprochen attraktiv. Interne Adressierungspläne konnten weitgehend unabhängig vom öffentlichen Internet aufgebaut werden. Gleichzeitig ließ sich der Bedarf an öffentlichen IPv4-Adressen erheblich reduzieren. Allerdings entstand dadurch eine neue Frage: Was geschieht, wenn ein System mit einer privaten Adresse doch auf das öffentliche Internet zugreifen soll? An dieser Stelle kommt eine Technologie ins Spiel, die unser Verständnis von IPv4-Netzen nachhaltig prägen sollte.

NAT wird vom Hilfsmittel zum Architekturprinzip

Network Address Translation (NAT) ermöglicht die Übersetzung zwischen unterschiedlichen IPv4-Adressräumen. In Verbindung mit Portübersetzung können zahlreiche interne Systeme eine deutlich kleinere Zahl öffentlicher IPv4-Adressen für die Kommunikation mit dem Internet verwenden. Damit entstand eine ausgesprochen wirkungsvolle Kombination: Private Adressräume reduzierten den Bedarf an global eindeutigen Adressen innerhalb von Organisationen, während NAT die Kommunikation zwischen diesen privaten Netzen und dem öffentlichen Internet ermöglichte.

Allerdings hatte diese Architektur ihren Preis. NAT veränderte das ursprüngliche Ende-zu-Ende-Modell der IP-Kommunikation. Anwendungen und Protokolle mussten zunehmend damit umgehen, dass die Adresse eines Endsystems auf dem Kommunikationsweg verändert werden konnte. RFC 2663 dokumentierte Ende der 1990er-Jahre bereits ausführlich unterschiedliche NAT-Varianten sowie deren Auswirkungen auf Anwendungen und Protokolle.

Trotz dieser Nachteile setzte sich NAT durch. Der praktische Nutzen war schlicht zu groß. Unternehmen konnten ihre bestehenden IPv4-Infrastrukturen weiterbetreiben, Provider mit knappen Adressbeständen umgehen und Administrator:innen ihre vertrauten privaten Netze beibehalten.

Eigentlich sollte IPv4 ersetzt werden

Rückblickend zeigt sich hier ein Muster, das für die weitere IPv6-Geschichte entscheidend ist. Anfang der 1990er-Jahre waren die Skalierungsprobleme von IPv4 bekannt. Gleichzeitig arbeitete die IETF bereits an einem langfristigen Nachfolger.

Doch die Internet-Community wartete nicht darauf. CIDR machte die Adressvergabe flexibler und das globale Routing skalierbarer. Private Adressräume reduzierten den Bedarf an öffentlichen IPv4-Adressen. NAT ermöglichte schließlich, ganze Netzwerke hinter wenigen öffentlichen Adressen zu betreiben. Keine dieser Maßnahmen vergrößerte den 32-Bit-Adressraum von IPv4. Zusammen sorgten sie jedoch dafür, dass dessen Begrenzung wesentlich weniger unmittelbar spürbar wurde. Darin liegt eine der zentralen Ironien der Internetgeschichte: Eigentlich sollte IPv4 ersetzt werden. Stattdessen wurden wir immer besser darin, es nicht ersetzen zu müssen.

Während also bereits an der nächsten Generation des Internet Protocols gearbeitet wurde, entstand gleichzeitig eine erstaunlich widerstandsfähige IPv4-Infrastruktur. Was zunächst Zeit für die Entwicklung und Einführung eines Nachfolgers schaffen sollte, nahm zunehmend auch den unmittelbaren Druck, diesen Nachfolger tatsächlich einzuführen. Und damit beginnt ein Prozess, dessen Auswirkungen bis heute spürbar sind.

1995: IPv6 bekommt einen Namen – und IPv4 lebt weiter

Die Skalierungsprobleme von IPv4 waren erkannt, doch damit stand noch keineswegs fest, wie sein Nachfolger aussehen sollte. Anfang der 1990er-Jahre begann innerhalb der IETF deshalb die systematische Suche nach dem Internet Protocol der nächsten Generation – IPng. Dabei ging es um wesentlich mehr als einen größeren Adressraum. Das neue Protokoll sollte über Jahrzehnte skalieren, effizientes Routing ermöglichen, unterschiedliche Netzwerktechnologien unterstützen und zugleich einen realistischen Übergang aus der bestehenden IPv4-Welt erlauben. Genau diese Anforderungen wurden zu einer besonderen Herausforderung: Die IETF plante nicht mehr auf der grünen Wiese. Der Nachfolger musste sich in ein Internet integrieren lassen, das bereits produktiv genutzt wurde und rasant weiterwuchs.

RFC 1726 formulierte 1994 deshalb technische Kriterien für die Auswahl von IPng. Dazu gehörten unter anderem Skalierbarkeit, eine deutlich größere Zahl adressierbarer Systeme, Routing, Konfiguration, Sicherheit und die Möglichkeit einer schrittweisen Einführung. Die Diskussion war damit bewusst technologieoffen. IPv6 stand zu Beginn des Prozesses keineswegs bereits als fertige Lösung fest. Vielmehr konkurrierten unterschiedliche Entwürfe darum, die Grundlage für die nächste Generation des Internets zu bilden.

IPng war ein Auswahlprozess

Mehrere Vorschläge flossen in die Diskussion ein. Zu den bedeutenden Kandidaten gehörten unter anderem SIPP (Simple Internet Protocol Plus), TUBA (TCP and UDP with Bigger Addresses) und CATNIP (Common Architecture for Next Generation Internet Protocol). Sie verfolgten unterschiedliche Ansätze, um die erkannten Skalierungsprobleme zu lösen. Gerade daran zeigt sich, dass die Entwicklung von IPv6 weniger geradlinig verlief, als die heutige Versionsnummer vermuten lässt. Die IETF musste nicht nur technische Eigenschaften vergleichen. Sie musste zugleich bewerten, welche Architektur sich tatsächlich implementieren, betreiben und aus der bestehenden IPv4-Welt heraus einführen ließ.

RFC 1752 dokumentierte Anfang 1995 schließlich die Empfehlung des IPng Area Directorate. Die Entscheidung fiel zugunsten von SIPP, allerdings nicht unverändert. Die vorgeschlagene Architektur sollte weiterentwickelt werden und unter anderem einen erheblich größeren Adressraum erhalten. Damit war eine grundlegende Richtung festgelegt. Aus einem Wettbewerb unterschiedlicher Architekturideen entwickelte sich das Protokoll, das wenig später einen heute selbstverständlichen Namen erhielt: IPv6. Die Geschichte ist deshalb weniger die Erfindung eines einzelnen neuen Protokolls als das Ergebnis eines längeren Auswahl-, Konsolidierungs- und Standardisierungsprozesses.

Warum eigentlich 128 Bit?

Eine der sichtbarsten Entscheidungen betraf den Adressraum. IPv4 verwendet 32-Bit-Adressen und stellt damit theoretisch rund 4,3 Milliarden Kombinationen bereit. Für IPv6 entschied sich die IETF schließlich für 128 Bit. Das Ziel bestand allerdings nicht darin, lediglich möglichst viele einzelne Endgeräte abzählen zu können. Ein sehr großer Adressraum schafft zugleich Freiraum für eine hierarchische und aggregierbare Adressierung. Provider und Organisationen können umfangreiche Präfixe erhalten und ihre Netze strukturiert unterteilen, ohne jeden Adressbereich bis zur rechnerisch maximalen Effizienz ausnutzen zu müssen.

Damit reagierte IPv6 nicht nur auf die Knappheit einzelner Adressen, sondern auch auf die Erfahrungen mit dem globalen Routing. Die Größenordnung ist dennoch bemerkenswert: 128 Bit ermöglichen theoretisch 2¹²⁸ und damit rund 3,4 × 10³⁸ Adressen. Diese Zahl ist so groß, dass klassische Vergleiche mit der Zahl heutiger Geräte kaum noch sinnvoll sind. Der entscheidende Architekturgewinn liegt deshalb nicht darin, jedem denkbaren Gerät gerade noch eine Adresse zuweisen zu können. IPv6 schafft vielmehr genügend Spielraum, um Adressierung wieder nach Netzwerkstruktur statt primär nach Adressknappheit planen zu können.

Dezember 1995: RFC 1883 beschreibt IPv6

Im Dezember 1995 erschien schließlich RFC 1883 – Internet Protocol, Version 6 (IPv6) Specification. Damit lag die erste formale Spezifikation des neuen Internet Protocols vor. IPv6 war dabei bewusst keine bloße Vergrößerung von IPv4. Die IETF nutzte den Generationswechsel, um grundlegende Architekturentscheidungen neu zu ordnen. Der Basis-Header wurde gegenüber IPv4 vereinfacht und auf eine feste Größe ausgelegt. Optionale Informationen wanderten in separate Extension Header. Die Fragmentierung durch Router entfiel; entsprechende Aufgaben wurden stärker an die Endsysteme verlagert.

Auch die Adressierung änderte sich grundlegend. Broadcast gehört nicht mehr zum IPv6-Konzept. Stattdessen spielen Multicast und später spezifizierte Mechanismen wie Neighbor Discovery eine wesentlich größere Rolle.

Viele dieser Unterschiede habe ich bereits im Beitrag Adresswelten im Wandel – der strukturierte Einstieg in TCP/IPv6 ausführlich beschrieben. Für unsere historische Betrachtung ist vor allem ein anderer Punkt entscheidend: IPv6 versuchte nicht, sämtliche Mechanismen von IPv4 unverändert in einen größeren Adressraum zu übertragen. Der Generationswechsel bot die Gelegenheit, mehrere über Jahre sichtbar gewordene Architekturprobleme grundsätzlich neu zu betrachten.

Von RFC 1883 zu RFC 2460

Mit RFC 1883 war IPv6 spezifiziert, aber keineswegs fertig entwickelt. Implementierungserfahrungen, weitere Standardisierungsarbeit und die Ausarbeitung ergänzender Protokolle führten in den folgenden Jahren zu Anpassungen. Im Dezember 1998 erschien RFC 2460. Die neue Spezifikation ersetzte RFC 1883 und wurde für viele Jahre zur maßgeblichen technischen Beschreibung von IPv6.

Parallel entstand das Ökosystem, das IPv6 im praktischen Betrieb benötigt. Neighbor Discovery, Stateless Address Autoconfiguration, ICMPv6 und zahlreiche weitere Mechanismen wurden in eigenen RFCs spezifiziert beziehungsweise weiterentwickelt. Spätere Dokumente wie RFC 4861 für Neighbor Discovery und RFC 4862 für SLAAC zeigen, dass ein neues Internet Protocol nicht mit der Veröffentlichung eines einzigen Dokuments abgeschlossen war.

Das ist für die historische Einordnung wichtig. 1995 markiert einen entscheidenden Meilenstein, aber keinen fertigen Endzustand. IPv6 entwickelte sich weiter, während Hersteller erste Implementierungen bereitstellten und die Internet-Community praktische Erfahrungen mit dem neuen Protokoll sammelte. Und während all das geschah, blieb IPv4 weiterhin das Protokoll, auf dem der größte Teil des realen Internets lief.

Ein Nachfolger, der seinen Vorgänger nicht abschalten konnte

Genau hier unterscheidet sich die IPv6-Geschichte von einem klassischen Produktwechsel. RFC 1883 konnte zwar einen technischen Nachfolger für IPv4 definieren. Die Veröffentlichung eines Standards erzeugte jedoch keinen Mechanismus, der bestehende IPv4-Systeme automatisch verschwinden ließ. Vielmehr musste IPv6 von Betriebssystemen, Routern, Anwendungen, Providern und Unternehmen implementiert werden. Vor allem mussten IPv6-Systeme während einer langen Übergangsphase weiterhin mit der bestehenden IPv4-Welt kommunizieren können.

Dass die IETF diese Herausforderung früh erkannte, zeigt RFC 1933 aus dem Jahr 1996. Das Dokument beschrieb bereits Mechanismen für den Übergang von IPv4 zu IPv6. Dazu gehörten insbesondere Dual-Stack-Ansätze und Tunnelverfahren. Damit entstand schon kurz nach der ersten IPv6-Spezifikation ein Grundmuster, das die folgenden Jahrzehnte prägen sollte: IPv6 wurde nicht als globaler Umschalttag konzipiert, sondern als schrittweise Transformation einer laufenden Infrastruktur. Technisch war das notwendig. Gleichzeitig ermöglichte genau diese Koexistenz, IPv4 immer länger weiterzubetreiben.

Vom Proposed Standard zum Internet Standard

Ein weiterer Meilenstein folgte erst viele Jahre später. Im Juli 2017 veröffentlichte die IETF RFC 8200 (Internet Protocol, Version 6 (IPv6) Specification). Das Dokument ersetzte RFC 2460 und erhob IPv6 auf den Status Internet Standard. Zwischen der ersten Spezifikation in RFC 1883 und diesem Schritt lagen damit mehr als zwei Jahrzehnte. Das bedeutet allerdings nicht, dass IPv6 bis 2017 lediglich eine experimentelle Technologie gewesen wäre. Das Protokoll wurde bereits lange zuvor implementiert und produktiv eingesetzt.

Der lange Standardisierungsweg zeigt vielmehr, wie Internetstandards entstehen: Spezifikationen werden implementiert, Erfahrungen gesammelt, Unklarheiten beseitigt und technische Details überarbeitet. RFC 8200 konsolidierte zahlreiche Änderungen, die sich seit RFC 2460 ergeben hatten, und bildet bis heute die zentrale Spezifikation des IPv6-Basisprotokolls. Damit war spätestens auch formal kaum noch von einer zukünftigen Technologie zu sprechen. Und dennoch lief IPv4 weiter.

Die eigentliche Ironie beginnt jetzt

Mitte der 1990er-Jahre hatte die Internet-Community damit etwas Bemerkenswertes erreicht. Die Skalierungsprobleme des bestehenden Protokolls waren erkannt, Anforderungen an einen Nachfolger formuliert, verschiedene Architekturvorschläge bewertet und schließlich ein neues Internet Protocol standardisiert worden. IPv6 brachte einen enorm erweiterten Adressraum und zahlreiche überarbeitete Architekturprinzipien mit. In den folgenden Jahren wurde die Spezifikation weiterentwickelt, implementiert und schließlich zum Internet Standard erhoben.

Nach dem klassischen Verständnis einer Technologiemigration müsste die Geschichte an dieser Stelle eigentlich klar verlaufen: Der Nachfolger ist vorhanden, also wird der Vorgänger schrittweise bedeutungslos. Doch genau das geschah nicht. Während IPv6 technisch immer reifer wurde, entstanden beziehungsweise etablierten sich gleichzeitig immer wirkungsvollere Verfahren, mit denen sich IPv4 weiterbetreiben ließ. Private Adressräume, NAT und später noch weitergehende Formen der Adressübersetzung machten aus einem Protokoll mit knappem Adressraum eine erstaunlich langlebige Infrastruktur.

Auf die technischen Zusammenhänge zwischen IP-Adressierung, Routing, privaten Adressräumen und Network Address Translation gehe ich ausführlicher in meinem Beitrag Wenn Pakete reisen lernen – Vermittlung und Transport im IP-Zeitalter ein. Für unsere historische Betrachtung ist an dieser Stelle vor allem ihre Wirkung entscheidend: Solche Verfahren lösten die grundlegende Begrenzung des 32-Bit-Adressraums nicht – sie reduzierten jedoch den unmittelbaren Druck, diese Begrenzung durch einen vollständigen Wechsel des Internet Protocols zu beseitigen.

Damit verschob sich die entscheidende Frage. Es ging nicht mehr darum, ob ein Nachfolger für IPv4 existierte. Es ging zunehmend darum, warum man ihn einsetzen sollte, solange IPv4 weiterhin funktionierte. Und genau diese Frage sollte sich für die weitere Verbreitung von IPv6 als mindestens ebenso wichtig erweisen wie alle technischen Entscheidungen, die während des IPng-Prozesses getroffen worden waren.

Der vielleicht erfolgreichste Workaround der Internetgeschichte

Eigentlich hätte die Geschichte Mitte der 1990er-Jahre eine klare Richtung nehmen können. Die Grenzen von IPv4 waren bekannt, mit IPv6 stand ein langfristiger Nachfolger bereit und die weitere Entwicklung des Internets ließ keinen Zweifel daran, dass immer mehr Systeme miteinander kommunizieren würden. Doch IPv4 bekam erneut Zeit.

Eine entscheidende Rolle spielte dabei eine Technologie, die heute so selbstverständlich zur klassischen IPv4-Netzwerkarchitektur gehört, dass ihr historischer Einfluss leicht unterschätzt wird: Network Address Translation kurz NAT.

NAT löste das eigentliche Problem von IPv4 nicht. Keine einzige zusätzliche IPv4-Adresse entstand dadurch. Stattdessen änderte sich die Art und Weise, wie vorhandene Adressen verwendet wurden. Interne Systeme mussten nicht mehr zwangsläufig mit weltweit eindeutigen IPv4-Adressen ausgestattet sein. An der Grenze zwischen unterschiedlichen Adressräumen konnten Adressen übersetzt werden.

Was zunächst wie ein pragmatischer Umgang mit knappen Ressourcen erscheint, entwickelte sich zu einem der wirkungsvollsten Mechanismen für die Lebensverlängerung von IPv4. NAT beseitigte die Adressknappheit nicht. Es machte sie im Alltag wesentlich weniger sichtbar.

Private Adressen verändern die Rechnung

Eine wichtige Voraussetzung dafür waren private IPv4-Adressräume. RFC 1918 reservierte 1996 die heute praktisch allen Netzwerkadministrator:innen bekannten Bereiche 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16 für private Netze. Solche Adressen können unabhängig voneinander in beliebig vielen Organisationen verwendet werden. Das 10er-Netz eines Unternehmens muss deshalb nicht weltweit mit dem 10er-Netz eines anderen Unternehmens abgestimmt werden. Erst wenn Kommunikation über die Grenzen dieser privaten Adressräume hinweg stattfinden soll, entsteht die Notwendigkeit einer entsprechenden Übersetzung oder anderer Kopplungsmechanismen. RFC 1918 weist ausdrücklich auf diese Konsequenz hin.

Für Unternehmen war das außerordentlich attraktiv. Ein internes Netzwerk mit Hunderten oder Tausenden Geräten benötigte nun nicht mehr zwangsläufig einen entsprechend großen Bestand öffentlich routbarer IPv4-Adressen. Damit veränderte sich wiederum die Wahrnehmung der Adressknappheit fundamental. Der globale IPv4-Adressraum blieb begrenzt – doch innerhalb eines Unternehmens fühlte er sich plötzlich wieder erstaunlich großzügig an. Und diese privaten Adressräume entwickelten sich zu einem Architekturmodell, das Generationen von Administrator:innen prägen sollte.

Aus NAT wird PAT

Noch wirkungsvoller wurde dieses Prinzip, wenn nicht nur IP-Adressen, sondern zusätzlich Transportprotokoll-Ports in die Übersetzung einbezogen wurden. Damit konnten zahlreiche interne Verbindungen über eine wesentlich kleinere Zahl öffentlicher IPv4-Adressen geführt werden. Im Extremfall teilen sich viele Endgeräte eine einzige öffentliche Adresse, während der NAT-Router die einzelnen Kommunikationsbeziehungen anhand zusätzlicher Zustandsinformationen auseinanderhält.

Die Terminologie ist dabei historisch nicht immer einheitlich. RFC 2663 beschreibt verschiedene NAT-Ausprägungen und verwendet für die Übersetzung vieler interner Adressen auf eine externe Adresse unter Einbeziehung der Transport-Identifier den Begriff Network Address Port Translation (NAPT). Im praktischen Netzwerkalltag haben sich daneben Bezeichnungen wie PAT (Port Address Translation), NAT Overload oder schlicht NAT etabliert.

Für die IPv4-Ökonomie war der Effekt enorm: Die Zahl der Geräte hinter einem Internetanschluss musste nicht mehr der Zahl der dafür benötigten öffentlichen IPv4-Adressen entsprechen. Aus einem Host – eine öffentliche Adresse konnte viele Hosts – wenige öffentliche Adressen werden.

Der Workaround wird zum Architekturstandard

Damit veränderte NAT nicht nur die Adressierung. Es prägte zunehmend die Vorstellung davon, wie ein Unternehmensnetzwerk grundsätzlich aufgebaut sein sollte. Innen befinden sich private IPv4-Adressen. Außen liegt das öffentliche Internet. Dazwischen steht ein Router oder eine Firewall, die unter anderem Adressübersetzungen durchführt. Was ursprünglich aus konkreten technischen und wirtschaftlichen Anforderungen entstand, wurde mit der Zeit zur Normalität. Hersteller integrierten NAT selbstverständlich in Router und Firewalls. Dokumentationen und Schulungsunterlagen vermittelten private IPv4-Adressierung und NAT als normalen Bestandteil einer Internetanbindung.

Wie selbstverständlich dieses Architekturmodell inzwischen geworden ist, wurde mir erst in dieser Woche wieder in einem Seminar bewusst. Eigentlich ging es um ein vollkommen anderes Thema, doch mit Auszubildenden im ersten Lehrjahr kamen wir zwangsläufig auch auf IPv4 zu sprechen. Dabei begegnete mir erneut eine Beobachtung, die ich in Seminaren häufiger mache: Die Netzwerkrealität junger Menschen ist mitunter eine vollkommen andere als diejenige, mit der meine Generation in die vernetzte Welt eingestiegen ist. Private IPv4-Adressen, NAT und die Trennung zwischen interner und öffentlicher Adressierung werden häufig nicht mehr als besondere Architekturentscheidungen wahrgenommen. Sie sind einfach da. Der Internetrouter zu Hause übersetzt Adressen, Unternehmensnetze verwenden private Adressbereiche und irgendwo dazwischen befindet sich eine Firewall. Warum diese Architektur entstanden ist, spielt für den täglichen Umgang damit kaum noch eine Rolle.

Besonders deutlich wird dieser Unterschied, wenn ich von meinen eigenen ersten Erfahrungen mit dem Internet erzähle. Mein Rechner an der Universität besaß damals eine öffentlich routbare IPv4-Adresse. Er war über das Universitätsnetz unmittelbar mit dem Internet verbunden, ohne die heute selbstverständliche NAT-Grenze und ohne eine lokale Firewall, wie wir sie heute erwarten würden. War der entsprechende Dienst aktiv, konnte dieses System grundsätzlich von einem anderen System irgendwo im Internet direkt adressiert und erreicht werden. Für viele jüngere Teilnehmer:innen klingt diese Vorstellung zunächst erstaunlich – mitunter fast so, als würde ich von einem offensichtlichen Konstruktionsfehler erzählen.

Dabei war genau diese direkte Erreichbarkeit einmal ein grundlegendes Prinzip der Internetarchitektur: Endsysteme sollten miteinander kommunizieren können, ohne dass eine Adressübersetzung zwischen ihnen steht. NAT hat unsere Vorstellung davon über Jahrzehnte verändert. Aus einer Reaktion auf die Grenzen von IPv4 wurde ein etabliertes Architekturprinzip. Und irgendwann geriet dabei sogar die ursprüngliche Motivation in den Hintergrund. Aus dem Workaround wurde Normalität. Und was über Jahrzehnte normal erscheint, wird irgendwann nicht mehr als Workaround wahrgenommen.

NAT ist keine Firewall

Diese veränderte Wahrnehmung hat noch eine weitere Konsequenz. Wenn ein internes System mit einer privaten IPv4-Adresse aus dem Internet nicht unmittelbar adressierbar ist, während ein öffentlich adressiertes System grundsätzlich erreichbar sein kann, liegt ein Gedanke zunächst nahe: Dann ist NAT doch auch ein Sicherheitsmechanismus. Diese Vorstellung begegnet mir regelmäßig – und sie wird durchaus auch durch Darstellungen aus der IT-Sicherheitsbranche befördert. NAT, private Adressierung und Firewalling erscheinen dort mitunter als Bestandteile eines gemeinsamen Schutzwalls zwischen dem vermeintlich sicheren internen und dem unsicheren öffentlichen Netzwerk.

Der beobachtbare Effekt scheint diese Sicht zunächst zu bestätigen. Interne IPv4-Adressen sind im öffentlichen Internet nicht routbar. Bei typischen zustandsbehafteten NAT-Verfahren existiert für eine unerwartete eingehende Verbindung zudem keine passende Übersetzungszuordnung. Ein Client kann eine Verbindung nach außen initiieren, während ein beliebiges System aus dem Internet nicht ohne Weiteres eine neue Verbindung zu diesem Client herstellen kann. Dieser Effekt kann die Angriffsfläche tatsächlich beeinflussen. Er macht NAT jedoch noch nicht zu einer Firewall. Adressübersetzung und Zugriffskontrolle erfüllen unterschiedliche Aufgaben. NAT übersetzt Adressen und gegebenenfalls Transport-Identifier. Eine Firewall setzt dagegen eine Sicherheitsrichtlinie durch und entscheidet, welche Kommunikation unter welchen Bedingungen zugelassen oder verworfen wird. Dass NAT und Stateful Firewalling seit Jahrzehnten häufig auf demselben Gerät stattfinden, hat diese Trennung in unserer Wahrnehmung zunehmend verwischt.

Gerade für IPv6 wird diese Unterscheidung später entscheidend. Denn wer keine Adressübersetzung gedanklich mit keine Schutzwirkung gleichsetzt, kommt beinahe zwangsläufig zu dem Schluss, dass ein global adressiertes IPv6-System unsicherer sein müsse als ein System hinter IPv4-NAT. Damit wäre aus einem Workaround gegen Adressknappheit endgültig ein vermeintliches Sicherheitsprinzip geworden. Und genau diese Vorstellung sollten wir uns etwas genauer ansehen.

Das Internet lernt, mit NAT zu leben

Dass NAT zur Normalität wurde, bedeutet allerdings nicht, dass diese Architektur ohne technische Nebenwirkungen blieb. Im Gegenteil: Das ursprüngliche Internetmodell ging davon aus, dass Endsysteme über eindeutige Adressen unmittelbar miteinander kommunizieren können. Ein NAT-System durchbricht dieses Prinzip, indem es Adressinformationen auf dem Kommunikationsweg verändert und zusätzlich Zustände für die jeweiligen Übersetzungen verwaltet.

RFC 2663 beschreibt die daraus entstehenden Schwierigkeiten bereits Ende der 1990er-Jahre erstaunlich deutlich. Besonders problematisch werden Anwendungen und Protokolle, wenn IP-Adressen oder Portinformationen nicht nur in den Paketheadern stehen, sondern zusätzlich innerhalb der übertragenen Nutzdaten auftauchen. Auch bestimmte IPsec-Verfahren geraten mit einem Mechanismus in Konflikt, dessen Aufgabe gerade darin besteht, eigentlich zu schützende Adressinformationen unterwegs zu verändern.

Eigentlich hätte man daraus schließen können, dass NAT nur eine vorübergehende Krücke sein konnte, die möglichst bald wieder aus der Internetarchitektur verschwinden sollte. Doch es kam anders.

Nicht NAT musste sich dem Internet anpassen – das Internet lernte, sich an NAT anzupassen.

Application Level Gateways, Proxies und NAT-Traversal-Verfahren halfen dabei, die entstehenden Kommunikationsprobleme zu umgehen. Protokolle und Anwendungen wurden zunehmend unter der Annahme entwickelt, dass zwischen zwei Kommunikationspartnern eine Adressübersetzung stattfinden könnte. Wo direkte Ende-zu-Ende-Kommunikation nicht mehr selbstverständlich funktionierte, entstanden technische Verfahren, um sie trotzdem zu ermöglichen.

Das ist rückblickend bemerkenswert. Mit jedem Problem, das die Internet-Community rund um NAT löste, wurde NAT selbst ein Stück weniger problematisch. Und je weniger problematisch NAT im täglichen Betrieb erschien, desto geringer wurde wiederum der Anreiz, die zugrunde liegende Ursache – den knappen IPv4-Adressraum – durch einen grundlegenden Technologiewechsel zu beseitigen. So entstand über die Jahre eine interessante Umkehrung: Nicht mehr NAT musste seine Existenz rechtfertigen. Anwendungen und Protokolle mussten beweisen, dass sie auch hinter NAT funktionieren. Aus einem Workaround für eine technische Begrenzung war damit endgültig ein Teil der erwarteten Netzwerkumgebung geworden.

Der Preis für den Erfolg

Das bedeutet nicht, dass NAT allein die Einführung von IPv6 verhindert hätte. Eine solche Erklärung wäre historisch zu einfach. Die Entwicklung wurde von vielen Faktoren beeinflusst: Investitionszyklen, Betriebssysteme, Netzwerkhardware, Provider, Anwendungen, fehlende kurzfristige Geschäftsmodelle und nicht zuletzt die Tatsache, dass IPv4 weiterhin funktionierte. Auch die wissenschaftliche Rückschau auf NAT zeichnet deshalb ein differenzierteres Bild. NAT brachte erhebliche praktische Vorteile, veränderte aber zugleich das ursprüngliche End-to-End-Modell des Internets und erzeugte neue technische Abhängigkeiten. Für unsere IPv6-Geschichte ist jedoch eine Wirkung besonders relevant: NAT reduzierte den wirtschaftlichen und betrieblichen Druck, IPv4 kurzfristig ersetzen zu müssen.

Ein Unternehmen konnte weiter wachsen, ohne für jedes interne Gerät eine öffentliche IPv4-Adresse zu benötigen. Ein neuer PC, Drucker oder Server führte nicht automatisch zu einem zusätzlichen Bedarf an globalem Adressraum. Gleichzeitig waren die notwendigen Technologien verfügbar, bekannt und zunehmend zuverlässig.

IPv6 musste deshalb nicht gegen eine offensichtlich zusammenbrechende IPv4-Infrastruktur antreten. Es musste gegen eine IPv4-Infrastruktur antreten, deren Grenzen durch immer ausgefeiltere Mechanismen erstaunlich gut kaschiert wurden.

Aus dem Workaround wird Gewohnheit

Und damit kommen wir wieder zu einem Gedanken zurück, der uns bereits beim Thema Erfahrung und Veränderungsbereitschaft begegnet ist. Technologien prägen nicht nur Netzwerke. Sie prägen auch die Menschen, die diese Netzwerke planen und betreiben. Wer über viele Jahre IPv4-Netze administriert hat, für den erscheint die Trennung aus privatem Netz, öffentlichem Netz, NAT und Firewall irgendwann nicht mehr als historisch entstandener Workaround. Sie wird zum mentalen Referenzmodell eines Unternehmensnetzes.

Private Adressen fühlen sich richtig an. NAT fühlt sich richtig an. Ein internes System mit einer global eindeutigen Adresse kann sich dagegen zunächst falsch oder sogar unsicher anfühlen – obwohl genau diese globale Adressierbarkeit ursprünglich ein Grundprinzip des Internet Protocols war.

Hier zeigt sich erneut die Brownfield-Problematik aus unserem vorangegangenen Exkurs: Eine neue Technologie muss nicht nur technisch funktionieren. Sie muss sich gegen Prozesse, Erfahrungen und Architekturvorstellungen behaupten, die sich über Jahrzehnte bewährt haben. Aus dem Workaround wurde eine Gewohnheit. Aus der Gewohnheit wurde eine Erwartung. Und aus der Erwartung wurde ein Argument dafür, IPv4 weiterhin zu betreiben.

NAT hat IPv4 gerettet – und IPv6 damit ein Problem beschert

Vielleicht ist NAT deshalb tatsächlich einer der erfolgreichsten Workarounds der Internetgeschichte. Es half, Millionen und später Milliarden Systeme mit einem begrenzten öffentlichen IPv4-Adressraum zu verbinden. Es verschaffte dem Internet Zeit und ermöglichte weiteres Wachstum, obwohl die fundamentale Grenze von 32 Bit unverändert bestehen blieb.

Doch genau dieser Erfolg hatte eine Nebenwirkung. NAT hat IPv4 gerettet und damit gleichzeitig einen wesentlichen wirtschaftlichen Druck zur IPv6-Migration reduziert. Solange der Internetzugriff funktionierte, Anwendungen mit NAT zurechtkamen und Unternehmen ihre internen Netze mit privaten IPv4-Adressen erweitern konnten, erschien die Einführung eines zweiten Internet Protocols häufig nicht als Lösung eines akuten Problems.

In meinen Seminaren beschreibe ich das gerne anhand eines fiktiven Gesprächs mit einer IT-Leitung. Nehmen wir an, ich schlage dort vor, ein umfassendes IPv6-Projekt zu starten. Das klingt zunächst interessant und zukunftsorientiert. Doch spätestens bei der Frage, was dieses Projekt konkret bedeutet, wird aus der technischen Idee eine betriebswirtschaftliche Entscheidung.

Was kostet die Migration?

Wir würden große Teile der Netzwerkinfrastruktur betrachten und von der Transportprotokollebene aufwärts prüfen, welche Systeme, Dienste, Anwendungen und Sicherheitsmechanismen für IPv6 vorbereitet oder neu konfiguriert werden müssen. Router, Switches, Firewalls, Server, Clients, DNS, Monitoring und Management gehören ebenso auf den Prüfstand wie Anwendungen und ihre Abhängigkeiten.

Und natürlich mache ich das nicht ehrenamtlich. Für Planung, Analyse und Migration entstehen externe Kosten. Gleichzeitig benötige ich Administrator:innen und weitere Fachleute aus dem Unternehmen, denn niemand kennt Anwendungen, Abhängigkeiten und betriebliche Besonderheiten besser als die Menschen, die diese Umgebung täglich betreiben. Während sie das IPv6-Projekt unterstützen, stehen sie für andere Aufgaben nur eingeschränkt zur Verfügung. Auch diese Arbeitszeit hat einen wirtschaftlichen Wert.

Dann kommen Hard- und Software hinzu. Vielleicht muss eine ältere Firewall aktualisiert oder ersetzt werden. Ein Monitoring-System beherrscht IPv6 nur eingeschränkt. Eine Anwendung erwartet an irgendeiner Stelle IPv4-Adressen. Dokumentationen, Sicherheitsrichtlinien und Betriebsprozesse müssen angepasst werden. Schulungen werden notwendig.

Bis zu diesem Punkt wird eine IT-Leitung vermutlich noch nicht grundsätzlich widersprechen. Schließlich gehören Investitionen und Migrationen zum normalen Lebenszyklus einer IT-Infrastruktur. Dann kommt jedoch die entscheidende Frage: Und was haben wir davon?

Der schwierige Business Case für IPv6

Darauf gibt es selbstverständlich technische und strategische Antworten. IPv6 schafft langfristig skalierbare Adressierung, reduziert die Abhängigkeit von knappem öffentlichem IPv4-Adressraum und ermöglicht Architekturen, bei denen IPv4 perspektivisch selbst zum Übergangsdienst werden kann. Einige dieser Vorteile werden uns im weiteren Verlauf noch beschäftigen.

Für viele klassische Unternehmensnetze lautet die kurzfristig sichtbare Antwort allerdings zunächst wesentlich unspektakulärer: Wenn das Projekt erfolgreich abgeschlossen ist, funktioniert hinterher im Idealfall alles wieder so zuverlässig wie vorher. Und da wir über ein größeres IT-Projekt sprechen, dürfen wir zusätzlich davon ausgehen, dass auf dem Weg dorthin nicht alles auf Anhieb funktionieren wird.

Genau hier liegt eines der zentralen Probleme der IPv6-Migration. Die Kosten entstehen heute, viele Vorteile dagegen erst langfristig. Die Risiken der Veränderung sind unmittelbar sichtbar, die Risiken des Nichtstuns bleiben zunächst abstrakt. Aus Sicht einer IT-Leitung ist die nächste Frage deshalb vollkommen rational: Warum Budget, Arbeitszeit und personelle Ressourcen in eine umfassende Transformation investieren, wenn die bestehende IPv4-Infrastruktur ihren Zweck weiterhin erfüllt?

Damit musste IPv6 nicht nur technisch gegen IPv4 bestehen. IPv6 musste einen Business Case gegen eine abgeschriebene, bekannte und funktionierende Infrastruktur gewinnen. Und ausgerechnet NAT hatte wesentlich dazu beigetragen, dass diese Infrastruktur weiterhin funktionierte.

IPv4 wird zur Betriebskultur

Technologien verschwinden nicht automatisch, sobald ein technisch geeigneter Nachfolger verfügbar ist. Je länger sie eingesetzt werden, desto stärker verankern sie sich in Prozessen, Werkzeugen und im Wissen der Menschen, die täglich mit ihnen arbeiten. Bei IPv4 lässt sich dieser Effekt besonders deutlich beobachten. Über Jahrzehnte haben Administrator:innen gelernt, Netzwerke auf Grundlage von IPv4 zu planen, zu dokumentieren, abzusichern und zu analysieren. Unternehmen haben ihre Betriebsprozesse darauf abgestimmt. Hersteller haben Werkzeuge entwickelt, die diese Arbeitsweise unterstützen.

Aus einem Internet Protocol wurde damit mehr als eine technische Spezifikation. IPv4 wurde zur Betriebskultur. Und Betriebskultur lässt sich nicht mit einem Firmware-Update austauschen.

Eine vertraute Welt aus Zahlen

Wer lange mit IPv4 gearbeitet hat, erkennt viele Adressen beinahe intuitiv. 10.0.0.0/8 steht für ein großes privates Netz, 192.168.0.0/16 begegnet uns ständig in kleineren Netzwerken und Heimnetzen. Auch 172.16.0.0/12 gehört zum vertrauten Repertoire, wenngleich dieser Bereich im Alltag mitunter weniger präsent erscheint. Mit der Zeit entsteht daraus eine Art visuelles Verständnis. Erfahrene Administrator:innen sehen eine IPv4-Adresse und beginnen häufig bereits während des Lesens mit ihrer Einordnung: privat oder öffentlich, Netzwerk- oder Hostanteil, bekanntes Subnetz oder fremdes Netz?

Auch Präfixgrößen werden zu vertrauten Größenordnungen. Ein /24 lässt sich gedanklich schnell erfassen. Bei /30 oder /31 entsteht unmittelbar eine Vorstellung vom möglichen Einsatzzweck. Aus Adressen werden mentale Abkürzungen.

IPv6 durchbricht viele dieser Routinen zunächst. Eine Adresse wie 2001:db8:4711:1200::25 lässt sich technisch genauso strukturiert analysieren. Für jemanden, der jahrzehntelang IPv4 gelesen hat, fühlt sie sich jedoch zunächst weniger intuitiv an. Das ist kein Defizit von IPv6. Es ist ein Unterschied zwischen neuem Wissen und jahrzehntelang trainierter Routine.

Wir denken in IPv4

Diese Routine begegnet mir regelmäßig in Seminaren. Bei einer IPv4-Adresse können erfahrene Teilnehmer:innen häufig sehr schnell einschätzen, zu welchem Netz sie gehört oder ob eine Konfiguration plausibel erscheint. Bei IPv6 verändert sich die Situation. Selbst Administrator:innen mit jahrzehntelanger Netzwerkerfahrung beginnen plötzlich wieder genauer hinzusehen, Präfixe zu zerlegen oder eine Adresse zunächst gedanklich zu sortieren. Das ist ein interessanter Moment, denn die grundsätzlichen Aufgaben sind gar nicht so fremd: Auch unter IPv6 müssen Netze strukturiert, Präfixe geplant, Routingentscheidungen getroffen und Kommunikationsprobleme analysiert werden.

Natürlich ist die bisherige Erfahrung deshalb nicht wertlos. Wer Routing verstanden hat, muss Routing mit IPv6 nicht vollständig neu lernen. Kenntnisse über TCP und UDP, DNS, Firewalls, Paketvermittlung oder Netzdesign verschwinden ebenfalls nicht. Viele grundlegende Konzepte lassen sich übertragen und helfen dabei, IPv6 wesentlich schneller zu verstehen. Aber Erfahrung mit IPv4 ist nicht dasselbe wie Erfahrung mit IPv6. Und genau an dieser Stelle kommt neben der technischen noch eine menschliche Komponente hinzu.

Wenn Erfahrung keinen automatischen Vorsprung mehr bedeutet

Über viele Jahre waren fundierte IPv4-Kenntnisse ein sichtbarer Kompetenzindikator in IT-Abteilungen. Wer komplexe Subnetze planen, Routingprobleme analysieren, NAT-Konfigurationen verstehen und schwer nachvollziehbare Kommunikationsfehler eingrenzen konnte, verfügte über Wissen, das im Unternehmen einen konkreten Wert besaß. Ähnliches kennen wir aus anderen Bereichen. Tiefgehende Kenntnisse in Active Directory, Exchange, SQL Server oder IIS entstehen nicht innerhalb weniger Tage. Sie wachsen mit den Jahren, mit Projekten und vor allem mit den Problemen, die man irgendwann selbst lösen musste. Diese Erfahrung schafft Sicherheit – und häufig auch einen gewissen Status.

Mit einer neuen Technologie verändert sich dieses Verhältnis plötzlich. Wer zwanzig oder dreißig Jahre IPv4-Erfahrung mitbringt, besitzt beim Einstieg in IPv6 zweifellos wertvolles Grundlagenwissen. Trotzdem gibt es Bereiche, in denen diese Person zunächst genauso lernen muss wie jemand, der wesentlich weniger Berufserfahrung besitzt. Neighbor Discovery, Router Advertisements, SLAAC, unterschiedliche IPv6-Adressarten oder die veränderte Bedeutung von ICMPv6 werden nicht automatisch dadurch intuitiv verständlich, dass jemand seit Jahrzehnten IPv4-Netze administriert. Plötzlich kann eine erfahrene Fachkraft neben einem vermeintlichen Newbie sitzen und sich mit derselben neuen Fragestellung beschäftigen.

Vom Profi wieder zum Lernenden

Das kann sich zunächst wie ein Kompetenzverlust anfühlen. Tatsächlich verschwindet die vorhandene Kompetenz natürlich nicht. Was verloren geht, ist etwas anderes: der selbstverständliche Wissensvorsprung. Vielleicht erklärt auch das einen Teil der Zurückhaltung gegenüber grundlegenden technologischen Veränderungen. Eine neue Technologie verlangt nicht nur zusätzliche Lernzeit. Sie zwingt erfahrene Fachkräfte mitunter dazu, eine Rolle wieder einzunehmen, die sie seit vielen Jahren nicht mehr gewohnt sind: die Rolle des Lernenden.

Das ist bei IPv6 nicht anders als bei Cloud-Technologien, modernen Identity-Konzepten oder KI. Wer über Jahrzehnte Expertise aufgebaut hat, muss akzeptieren können, dass ein Teil dieser Expertise zwar weiterhin wertvoll ist, aber nicht automatisch alle Antworten auf die nächste Technologiegeneration liefert. Genau darin liegt für mich eine der wichtigsten Fähigkeiten langjähriger IT-Professionals: Erfahrung zeigt sich nicht darin, niemals wieder Anfänger:in sein zu müssen. Sie zeigt sich darin, vorhandenes Wissen nutzen zu können und trotzdem bereit zu sein, bei neuen Technologien wieder Lernende:r zu werden.

Für die IPv6-Migration bedeutet das: Eine Organisation migriert nicht nur ihre Netzwerkkonfiguration. Die beteiligten Menschen müssen ihre über Jahre entwickelten Denkmodelle erweitern – und manchmal auch bewusst hinterfragen. Das kostet Zeit und erzeugt zunächst Unsicherheit. Wenn parallel eine bekannte und funktionierende IPv4-Konfiguration vorhanden ist, erscheint die vertraute Lösung deshalb verständlicherweise oft attraktiver.

Auch die Werkzeuge haben IPv4 gelernt

Diese Prägung endet nicht bei den Administrator:innen. Sie steckt häufig ebenso tief in den Werkzeugen und Prozessen eines Unternehmens. Netzwerkdokumentationen enthalten IPv4-Subnetztabellen. Monitoring-Systeme wurden über Jahre mit IPv4-Zielen aufgebaut. IP-Adressmanagement erfasst gewachsene Adressbereiche und Reservierungen. Skripte verarbeiten IPv4-Adressen. Inventarisierungssysteme und CMDBs enthalten entsprechende Felder und Datenmodelle. Einzelne Werkzeuge können IPv6 technisch längst unterstützen. Damit ist jedoch noch nicht automatisch der gesamte Betriebsprozess IPv6-fähig.

Genau dieser Unterschied wird bei Migrationsprojekten schnell relevant. Es reicht nicht, dass ein Router IPv6 routen kann. Monitoring muss Störungen erkennen können. Logging muss IPv6-Adressen sinnvoll erfassen. Administrator:innen müssen sie in Protokolldaten wiederfinden. Automatisierungen dürfen nicht stillschweigend vier durch Punkte getrennte Dezimalzahlen erwarten. Selbst Dokumentationsvorlagen können Teil des Problems werden. IPv6-Fähigkeit ist deshalb keine einzelne Checkbox in einem Datenblatt. Sie entsteht erst, wenn die gesamte betriebliche Kette mit beiden Protokollwelten umgehen kann.

Firewall-Regeln erzählen Unternehmensgeschichte

Besonders sichtbar wird diese gewachsene Betriebskultur bei Firewalls. Firewall-Regelwerke entstehen selten auf der grünen Wiese. Sie wachsen über Jahre. Neue Anwendungen benötigen Freigaben, Netze werden ergänzt, Standorte angebunden, Systeme migriert und Ausnahmen dokumentiert – oder manchmal eben auch nicht ausreichend dokumentiert. Viele dieser Regeln enthalten konkrete IPv4-Netze und einzelne Adressen. Andere setzen indirekt voraus, dass interne Systeme aus privaten RFC-1918-Netzen stammen oder dass Internetkommunikation eine bestimmte NAT-Grenze passiert.

Mit IPv6 genügt es deshalb nicht, auf der Firewall lediglich das Protokoll einzuschalten. Eine entscheidende Frage lautet vielmehr: Bildet unser bestehendes Sicherheitsmodell auch die IPv6-Kommunikation vollständig ab? Dazu gehören Regeln, Objektgruppen, Logging, IDS- und IPS-Funktionen, Remote-Zugänge und die Behandlung von ICMPv6 ebenso wie die Frage, ob Administrator:innen IPv6-Verkehr im Ereignisfall genauso sicher beurteilen können wie IPv4-Verkehr. Eine Firewall kann IPv6 technisch unterstützen und ein Unternehmen trotzdem noch lange nicht IPv6-sicher betreiben.

Troubleshooting beginnt mit Erfahrung

Ähnliches gilt für die Fehlersuche. Bei einem klassischen IPv4-Problem läuft im Kopf vieler Administrator:innen beinahe automatisch eine bekannte Kette ab: Stimmt die Adresse? Passt die Netzwerkmaske? Ist das Default Gateway erreichbar? Funktioniert DNS? Existiert eine Route? Greift eine Firewall-Regel? Funktioniert NAT?

Dazu kommen vertraute Werkzeuge wie ping, tracert beziehungsweise traceroute, ipconfig, ip, route, nslookup oder PowerShell-Cmdlets. Entscheidend ist jedoch weniger das einzelne Werkzeug als die Erfahrung, seine Ausgabe schnell einordnen zu können.

IPv6 verändert Teile dieser Diagnosekette. Neighbor Discovery ersetzt ARP, Router Advertisements bekommen eine neue Bedeutung, ICMPv6 übernimmt wichtige Funktionen und ein Endsystem kann gleichzeitig mehrere IPv6-Adressen unterschiedlicher Herkunft besitzen. Das alles lässt sich lernen. Aber bis aus Wissen wieder Routine geworden ist, dauert es. Troubleshooting ist eben nicht nur Protokollwissen. Es ist zu einem erheblichen Teil Erfahrung mit bekannten Fehlerbildern.

Wenn Anwendungen heimlich IPv4 voraussetzen

Noch schwieriger wird es, wenn IPv4-Annahmen nicht in der Netzwerkinfrastruktur, sondern in Anwendungen verborgen sind. Eine Anwendung kann grundsätzlich IP-basiert kommunizieren und trotzdem an einzelnen Stellen davon ausgehen, dass eine Adresse aus vier Dezimalwerten besteht. Datenbankfelder können zu kurz dimensioniert sein. Validierungsroutinen erwarten ein IPv4-Format. Skripte zerlegen Adressen an Punkten. Konfigurationsdateien enthalten feste IPv4-Adressen statt DNS-Namen. Besonders unangenehm sind solche Abhängigkeiten, weil sie im normalen IPv4-Betrieb überhaupt nicht als Problem auffallen. Erst während einer Migration zeigt sich, dass ‚unterstützt TCP/IP‘ nicht automatisch ‚unterstützt IPv6‘ bedeutet.

Damit kehren wir zu unserem fiktiven Gespräch mit der IT-Leitung aus dem vorherigen Kapitel zurück. Die eigentliche Netzwerkkonfiguration kann vergleichsweise schnell erledigt sein. Die Suche nach versteckten IPv4-Annahmen in Anwendungen, Automatisierungen und Betriebsprozessen ist wesentlich schwieriger zu kalkulieren. Und genau diese Unsicherheit erhöht das wahrgenommene Projektrisiko.

Was wir lernen, halten wir für normal

Schließlich prägt auch die Ausbildung unsere Vorstellung davon, wie ein Netzwerk aussieht. Über viele Jahre begann der Einstieg in TCP/IP zwangsläufig mit IPv4. Netzwerkklassen, Netzwerkmasken, private Adressbereiche, Subnetting, Default Gateways, Routing und NAT gehörten zum Grundwissen. IPv6 erschien dagegen häufig später im Lernpfad – manchmal als zusätzliches Kapitel, manchmal als Ausblick auf die Zukunft.

Auch Zertifizierungen und Herstellertrainings spiegelten lange diese Realität wider. Das war nachvollziehbar, denn Ausbildung muss sich an den Technologien orientieren, denen Administrator:innen im Berufsalltag begegnen. Dabei entstand jedoch noch ein weiterer Effekt: Nicht nur die Lernenden, sondern auch die Lehrenden wurden immer besser in IPv4.

Auch Ausbilder:innen lernen aus Erfahrung

Wer über Jahre IPv4 unterrichtet, vertieft zwangsläufig die eigene Kompetenz. Ausbilder:innen sammeln Beispiele aus der Praxis, entwickeln Übungen, kennen typische Fehler und wissen irgendwann ziemlich genau, an welcher Stelle Teilnehmer:innen beim Subnetting ins Stocken geraten. Prüfungsanforderungen verstärken diesen Effekt zusätzlich: Was prüfungsrelevant ist, wird intensiv vorbereitet, gelehrt und geübt. Damit wächst nicht nur das Fachwissen. Es entsteht didaktische Erfahrung.

Bei IPv6 kann genau diese Erfahrung fehlen. Wer selbst nur begrenzte praktische Berührungspunkte mit IPv6-Netzen besitzt, kann zwar die entsprechenden Grundlagen vermitteln. Es fehlen aber möglicherweise die Geschichten aus realen Projekten, typische Fehlerbilder und jene Sicherheit, die aus jahrelanger praktischer und didaktischer Beschäftigung mit einem Thema entsteht. Dann besteht die Gefahr, dass IPv6 im Seminar zu dem wird, was es über viele Jahre ohnehin schon war: Das erwähnen wir auch noch.

Aus einer gleichberechtigten zweiten Protokollwelt wird ein zusätzliches Kapitel am Ende des TCP/IP-Themas. IPv4 wird geplant, gerechnet, konfiguriert und analysiert. IPv6 wird erklärt. Dieser Unterschied ist größer, als er zunächst erscheint.

Praxisrelevanz schlägt Zukunftsrelevanz

Hinzu kommt der verständliche Wunsch von Unternehmen, ihre Mitarbeiter:innen für die aktuelle betriebliche Realität zu qualifizieren. In der Seminarplanung begegnet mir deshalb sinngemäß durchaus die Aussage: Meine Leute müssen IPv4 können – das ist bei uns Alltag. Lassen Sie dafür lieber IPv6 weg. Aus Sicht des Unternehmens ist das zunächst vollkommen nachvollziehbar. Seminarzeit ist begrenzt. Wenn die vorhandene Infrastruktur überwiegend mit IPv4 betrieben wird, erscheint eine zusätzliche Stunde IPv4-Subnetting oder Troubleshooting unmittelbar wertvoller als die Beschäftigung mit einer Technologie, die im eigenen Netzwerk vermeintlich kaum eingesetzt wird.

Langfristig entsteht daraus jedoch ein bemerkenswertes Henne-Ei-Problem. IPv6 wird weniger intensiv geschult, weil es im Unternehmen wenig eingesetzt wird. Gleichzeitig fehlt das Wissen für einen breiteren IPv6-Einsatz, weil es weniger intensiv geschult wird. Auch Ausbilder:innen sammeln dadurch weniger praktische IPv6-Erfahrung. Unternehmen wiederum treffen auf Administrator:innen, die sich mit IPv4 sicherer fühlen. Und weil diese Sicherheit im Tagesbetrieb wichtig ist, bleibt IPv4 die bevorzugte Technologie.

Ein Kreislauf, der sich selbst verstärkt

Damit entsteht ein Kreislauf, der sich über viele Jahre selbst stabilisieren kann: Unternehmen betreiben überwiegend IPv4 → IPv4 gilt als besonders praxisrelevant → Ausbildung konzentriert sich auf IPv4 → Administrator:innen und Ausbilder:innen vertiefen ihre IPv4-Kompetenz → IPv6 bleibt weniger vertraut → Unternehmen sehen weniger Anlass, IPv6 stärker einzusetzen. Das bedeutet keineswegs, dass Ausbildung oder Unternehmen IPv6 bewusst verhindern. Jede einzelne Entscheidung innerhalb dieser Kette kann für sich betrachtet vollkommen vernünftig sein.

Gerade darin liegt das Problem. Was kurzfristig rational erscheint, kann langfristig dazu beitragen, den bestehenden Zustand zu konservieren. IPv6 musste sich deshalb nicht nur seinen Platz in produktiven Netzwerken erarbeiten. Es musste sich zunächst seinen Platz in Lehrplänen, Prüfungen, Seminaren und schließlich in den Köpfen der Menschen erarbeiten, die diese Netzwerke planen und betreiben.

Wenn die Ausnahme zur Normalität wird

Interessanterweise verändert sich diese Wahrnehmung inzwischen – und meine Seminarerfahrungen mit jüngeren Teilnehmer:innen zeigen genau das. Manche Auszubildende kennen selbstverständlich ihr WLAN, ihren Internetanschluss und eine Vielzahl vernetzter Geräte, haben aber die historische Entwicklung hinter privaten IPv4-Adressen und NAT nicht mehr erlebt. Für sie ist die heutige Netzwerkumgebung schlicht der Ausgangspunkt. Gleichzeitig treffen sie auf eine Internetwelt, in der IPv6 bereits produktiv vorhanden ist. Smartphone, Heimrouter oder Provider können IPv6 längst verwenden, ohne dass Benutzer:innen dies bewusst konfigurieren oder überhaupt bemerken.

Damit begegnen sich in heutigen IT-Abteilungen zunehmend unterschiedliche Erfahrungswelten. Die einen haben gelernt, mit knappen IPv4-Adressen umzugehen und eine Infrastruktur darum aufzubauen. Die anderen wachsen in eine technische Realität hinein, in der IPv6 längst im Hintergrund mitarbeitet.

Immerhin dürfen wir heute darüber reden

Aber nicht nur die Generationen verändern sich. Auch in den Unternehmen selbst beobachte ich einen kulturellen Wandel. In meinen Seminaren formuliere ich es gerne etwas überspitzt: Noch vor zehn Jahren wäre ich in manchen Unternehmen vermutlich mit Fackeln und Heugabeln vom Hof gejagt worden, wenn ich auch nur vorgeschlagen hätte, über IPv6 oder Cloud nachzudenken. Heute dürfen wir zumindest darüber reden.

Natürlich ist das bewusst überzeichnet. Dahinter steckt jedoch eine Entwicklung, die ich über viele Jahre beobachten konnte. Technologien wie IPv6 oder Cloud Computing wurden lange nicht nur kritisch bewertet. Mitunter stand bereits die grundsätzliche Beschäftigung damit unter Rechtfertigungsdruck. Das bekannte On-Premises-Netzwerk funktionierte. IPv4 funktionierte. Die Server standen im eigenen Rechenzentrum. Administrator:innen kannten ihre Infrastruktur. Warum sollte man daran etwas ändern?

Heute haben sich die Ausgangsbedingungen verschoben. Cloud-Dienste gehören in vielen Unternehmen zum Alltag. Microsoft 365, Entra ID, Azure und andere Plattformen haben die Grenze zwischen dem klassischen Unternehmensnetz und externen Diensten längst durchlässiger gemacht. Gleichzeitig begegnet uns IPv6 bei Providern, Betriebssystemen, mobilen Netzen und Cloud-Plattformen zunehmend als selbstverständlicher Bestandteil moderner Infrastruktur.

Das bedeutet noch lange nicht, dass Unternehmen ihre gewachsenen IPv4-Netze begeistert ablösen. Aber die Diskussion beginnt an einem anderen Punkt. Aus ‚Warum sollten wir uns überhaupt damit beschäftigen?‘ wird zunehmend ‚Wie und wann sollten wir uns damit beschäftigen?‘ Das klingt zunächst nach einer kleinen Verschiebung. Für eine Technologie, die jahrzehntelang als verzichtbares Zukunftsthema behandelt wurde, ist sie jedoch erheblich.

Migration kann eine Generationenfrage werden

Langfristig könnte daraus noch ein anderer Effekt entstehen. Für Administrator:innen, die ihre gesamte berufliche Laufbahn mit IPv4 verbracht haben, bleibt IPv6 zunächst eine zusätzliche Technologie und seine Einführung eine Migration. Für jemanden, der heute in die IT einsteigt, muss das nicht dauerhaft so bleiben. Wenn Betriebssysteme, Cloud-Plattformen, Provider und Endgeräte IPv6 selbstverständlich verwenden, wird die parallele Existenz beider Protokolle zur Ausgangssituation der eigenen Berufserfahrung.

Und irgendwann könnte sich die Perspektive vollständig umkehren. Dann lautet die Frage möglicherweise nicht mehr: ‚Warum sollten wir IPv6 einsetzen?‘, sondern: ‚Warum betreiben wir eigentlich immer noch IPv4?‘ Was für eine Generation noch Migration bedeutet, kann für die nächste bereits Normalbetrieb sein.

Die schwierigste Migration findet vielleicht im Kopf statt

Damit wird verständlich, warum die Einführung von IPv6 nicht allein als Netzwerkprojekt betrachtet werden sollte. Natürlich müssen Router, Firewalls, Server und Anwendungen IPv6 beherrschen. Ebenso müssen Dokumentation, Monitoring, Automatisierung, Sicherheitsprozesse und Troubleshooting angepasst werden. Doch eine der schwierigsten Veränderungen lässt sich weder konfigurieren noch per Softwareupdate installieren: Vertraute Denkweisen müssen sich weiterentwickeln.

IPv4 hat über Jahrzehnte hervorragend funktioniert. Genau deshalb haben Unternehmen Prozesse darum aufgebaut, Werkzeuge darauf ausgerichtet und Administrator:innen enorme Erfahrung damit gesammelt. Dieses Wissen verliert durch IPv6 keineswegs seinen Wert. Routing bleibt Routing, TCP bleibt TCP und ein fundiertes Verständnis von Netzwerken erleichtert auch den Einstieg in IPv6 erheblich. Was sich verändert, ist der selbstverständliche Kompetenzvorsprung. Erfahrene Administrator:innen müssen akzeptieren, dass bewährte IPv4-Muster nicht auf jede IPv6-Fragestellung übertragbar sind. Manchmal bedeutet technologische Weiterentwicklung deshalb auch, nach vielen Berufsjahren wieder Lernende:r zu sein.

Betriebskultur lässt sich nicht konfigurieren

Gleichzeitig zeigt unsere Betrachtung, dass diese Prägung weit über einzelne Personen hinausgeht. Ausbildung vermittelt das, was in Unternehmen benötigt wird. Unternehmen setzen bevorzugt das ein, womit ihre Fachkräfte Erfahrung besitzen. Ausbilder:innen vertiefen wiederum die Technologien, die praxis- und prüfungsrelevant sind. So stabilisiert sich eine technische Kultur über viele Jahre selbst.

Doch diese Kultur beginnt sich zu verändern. IPv6 und Cloud-Technologien müssen heute vielerorts nicht mehr grundsätzlich rechtfertigen, warum man sich überhaupt mit ihnen beschäftigen sollte. Jüngere IT-Fachkräfte wachsen zudem in eine Welt hinein, in der IPv6 längst vorhanden sein kann, ohne als Besonderheit wahrgenommen zu werden. Damit verschiebt sich langsam das Referenzmodell. Aus einer technischen Lösung wurde Routine. Aus Routine entstanden Prozesse. Aus Prozessen entwickelte sich Betriebskultur. Und Betriebskultur wird irgendwann wieder durch eine neue Generation von Erfahrungen verändert.

Eine solche Transformation lässt sich nicht per Kommandozeile starten. Vielleicht findet deshalb ein wesentlicher Teil der IPv6-Migration tatsächlich gar nicht im Router statt. Er findet in den Köpfen der Menschen statt, die Netzwerke planen, absichern, betreiben – und den nächsten Generationen erklären, wie diese Netzwerke funktionieren. Und genau deshalb ist die Frage, was heute eigentlich als normales Netzwerk gilt, möglicherweise wichtiger als die Frage, welches Internet Protocol technisch das modernere ist.

Währenddessen hat sich IPv6 längst eingeschlichen

Nach all den bisherigen Überlegungen könnte der Eindruck entstehen, IPv6 sei eine Technologie, deren Einführung Unternehmen irgendwann aktiv beschließen müssen. Es gibt ein IPv4-Netzwerk, ein Migrationsprojekt wird geplant und anschließend wird IPv6 eingeschaltet. Diese Vorstellung ist verständlich. Sie entspricht nur häufig nicht mehr der Realität.

Während Unternehmen darüber diskutieren, ob und wann sie IPv6 einführen sollten, haben Betriebssystemhersteller, Internetprovider, Mobilfunkanbieter und Cloud-Plattformen längst Fakten geschaffen. IPv6 ist auf unseren Endgeräten vorhanden, wird automatisch konfiguriert und kann für Kommunikation genutzt werden, ohne dass Benutzer:innen oder Administrator:innen dies bewusst veranlasst haben. Vielleicht ist IPv6 deshalb weniger eine Technologie, die irgendwann kommt. Vielleicht ist sie längst da – und wir haben nur nicht überall unsere Betriebsprozesse daran angepasst.

Ein Blick auf den eigenen Rechner genügt

Für einen ersten Hinweis darauf benötigen wir weder ein Rechenzentrum noch einen IPv6-fähigen Internetanschluss. Ein Blick auf die Netzwerkkonfiguration eines aktuellen Betriebssystems reicht häufig aus. Windows, Linux, macOS, iOS und Android unterstützen IPv6 seit vielen Jahren. Moderne Systeme behandeln IPv6 nicht mehr als exotische Erweiterung ihres Netzwerkstacks, sondern als selbstverständlichen Bestandteil der IP-Kommunikation.

Microsoft formuliert das für Windows ausgesprochen deutlich. Seit Windows Vista und Windows Server 2008 ist IPv6 ein verpflichtender Bestandteil des Betriebssystems. Microsoft empfiehlt ausdrücklich, IPv6 nicht zu deaktivieren oder vom Netzwerkadapter zu lösen, weil Windows-Komponenten dessen Verfügbarkeit voraussetzen können. Sind IPv4 und IPv6 gleichzeitig verfügbar, bevorzugt Windows standardmäßig globale IPv6-Adressen gegenüber IPv4.

Damit entsteht eine bemerkenswerte Situation: Ein Unternehmen kann sich organisatorisch als reines IPv4-Unternehmen verstehen, während seine Windows-Systeme IPv6 längst als normalen Bestandteil ihres Netzwerkstacks betrachten.

Link-Local braucht keine IPv6-Migration

Besonders interessant wird diese Betrachtung bei Link-Local-Adressen. IPv6-Systeme können sich Adressen aus dem Bereich fe80::/10 für die Kommunikation auf dem lokalen Netzwerksegment zuweisen. Dafür benötigt ein Client weder einen öffentlichen IPv6-Präfix noch einen DHCPv6-Server. Auch eine bewusst geplante unternehmensweite IPv6-Einführung ist dafür nicht erforderlich. Das bedeutet: Selbst in einem Netzwerk, dessen Administrator:innen überzeugt sind, ausschließlich IPv4 zu betreiben, kann auf den einzelnen Netzwerksegmenten bereits IPv6-Kommunikation stattfinden.

Das ist zunächst weder ungewöhnlich noch problematisch. Es zeigt lediglich, dass die Frage ‚Haben wir IPv6 eingeführt?‘ technisch weniger eindeutig ist, als sie klingt. Vielleicht müsste die präzisere Frage lauten: ‚Welche IPv6-Kommunikation findet in unserem Netzwerk eigentlich bereits statt?‘ Diese Perspektive wird uns später beim Thema IT-Sicherheit noch einmal beschäftigen. Denn ein Protokoll verschwindet nicht dadurch aus dem Netzwerk, dass es in der Dokumentation nicht vorkommt.

Dual Stack macht den Übergang beinahe unsichtbar

Noch deutlicher wird dieser Effekt bei einem Dual-Stack-Netzwerk. Ein Endsystem besitzt dabei IPv4- und IPv6-Konnektivität gleichzeitig. Für Benutzer:innen ist davon im Idealfall nichts zu bemerken. Sie öffnen einen Browser, starten Outlook oder greifen auf einen Cloud-Dienst zu. DNS liefert die benötigten Informationen und der Netzwerkstack entscheidet gemeinsam mit den jeweiligen Mechanismen zur Adressauswahl, über welches Protokoll eine Verbindung aufgebaut wird. Die Anwendung funktioniert.

Genau darin liegt eine der großen Stärken von Dual Stack – und gleichzeitig ein Grund dafür, warum die tatsächliche IPv6-Nutzung leicht übersehen werden kann. Benutzer:innen sehen keine Meldung: ‚Herzlichen Glückwunsch, diese Verbindung verwendet gerade IPv6.‘ Eine Webseite sieht über IPv6 genauso aus wie über IPv4. Eine E-Mail wird nicht schneller lesbar, nur weil ihre Übertragung IPv6 verwendet hat. Das Internet Protocol soll seine Aufgabe möglichst unauffällig erfüllen. Der Erfolg von IPv6 kann deshalb gerade darin bestehen, dass niemand seine Verwendung bemerkt.

Das Smartphone hat die Diskussion teilweise längst beendet

Besonders interessant ist der Blick auf Mobilfunknetze. Mobilfunkanbieter standen wesentlich früher als viele klassische Unternehmensnetze vor einem massiven Skalierungsproblem. Milliarden mobile Endgeräte ließen sich nur schwer in eine Architektur integrieren, die dauerhaft für jedes Gerät auf klassische öffentliche IPv4-Konnektivität angewiesen wäre. IPv6 und Übergangstechnologien wie NAT64, DNS64 und 464XLAT wurden deshalb gerade in mobilen Netzen zu wichtigen Architekturbausteinen.

Das Ergebnis ist aus Sicht der Benutzer:innen bemerkenswert unspektakulär. Ein Smartphone kann sich in einer IPv6-geprägten oder sogar IPv6-only Infrastruktur befinden und trotzdem auf einen Dienst zugreifen, der selbst weiterhin ausschließlich IPv4 unterstützt. Die notwendige Übersetzung findet im Hintergrund statt.

Apple verlangt beispielsweise bereits seit 2016, dass für den App Store eingereichte Apps in IPv6-only-Netzen funktionieren. Apple empfiehlt dafür ausdrücklich adressfamilienneutrale APIs und beschreibt DNS64 und NAT64 als Bestandteil entsprechender Umgebungen. Für Benutzer:innen bleibt davon wenig sichtbar. Das Smartphone funktioniert einfach.

Und genau das ist vielleicht der größte Gegensatz zu vielen IPv6-Diskussionen in klassischen Unternehmensnetzen: Während dort noch über die Risiken einer Einführung gesprochen wird, nutzen Mitarbeiter:innen möglicherweise wenige Minuten später mit ihrem Smartphone eine Infrastruktur, in der IPv6 längst selbstverständlich ist.

Auch der Internetanschluss zu Hause hat sich verändert

Ähnliches gilt für private Internetanschlüsse. Im vorherigen Kapitel haben wir gesehen, welche Bedeutung NAT für die Entwicklung moderner Heimnetze hatte. Doch auch dort ist die Architektur längst in Bewegung. Viele Provider stellen ihren Kund:innen IPv6-Konnektivität bereit. Heimrouter verteilen IPv6-Präfixe im lokalen Netzwerk und Endgeräte konfigurieren entsprechende Adressen automatisch. Damit können Smart-TV, Smartphone oder PC zu Hause bereits IPv6 verwenden, obwohl sich niemand bewusst für ein IPv6-Projekt entschieden hat.

Meine Mutter ist dafür ein schönes Beispiel. Sie hat vermutlich nicht die geringste Vorstellung davon, was eine IP-Adresse ist – und ich bin ziemlich sicher, dass sie das auch überhaupt nicht interessiert. Warum sollte es auch? Solange der PC ins Internet kommt, Netflix den gewünschten Film abspielt und Alexa auf Zuruf antwortet, erfüllt das Netzwerk seinen Zweck. Funktioniert etwas davon nicht mehr, beginnt die Fehlersuche nicht mit ipconfig, einer Analyse der Routingtabelle oder der Frage, ob gerade IPv4 oder IPv6 verwendet wird. Dann wird eben die FRITZ!Box neu gestartet. Und erstaunlich oft ist die Welt anschließend wieder in Ordnung.

Das beste Netzwerk ist das unsichtbare Netzwerk

Was zunächst nur nach einer kleinen Familienanekdote klingt, beschreibt ziemlich genau den Erfolg moderner Netzwerktechnik. Benutzer:innen möchten kein IPv4 oder IPv6 benutzen. Sie möchten Netflix schauen, mit dem Smartphone kommunizieren, Musik hören oder mit einem Sprachassistenten interagieren. Das Netzwerk ist lediglich die Infrastruktur, die all das ermöglichen soll.

Welche Version des Internet Protocols dabei einzelne Pakete transportiert, bleibt im Idealfall vollkommen unsichtbar. Ein Gerät kann heute über IPv4 kommunizieren und wenige Sekunden später für eine andere Verbindung IPv6 verwenden. Für die Person vor dem Bildschirm ändert sich dadurch nichts.

Vielleicht liegt darin sogar ein Teil des Wahrnehmungsproblems von IPv6: Eine erfolgreiche IPv6-Einführung besitzt für Endanwender:innen häufig überhaupt keinen sichtbaren Moment. Es gibt keinen neuen Desktop, keine neue Anwendung und keinen offensichtlichen Funktionsgewinn. Die Technik verändert sich unterhalb der Ebene, auf der Benutzer:innen ihre digitale Umgebung wahrnehmen.

Damit entsteht ein interessanter Gegensatz zu vielen Unternehmensnetzen: Zu Hause nutzen wir möglicherweise längst selbstverständlich eine IPv6-Infrastruktur, über deren Einführung wir am Arbeitsplatz noch diskutieren. Und während Administrator:innen dort noch über Migrationsstrategien, Dual Stack und IPv6-Kompetenzen sprechen, interessiert meine Mutter vor allem eine wesentlich pragmatischere Frage: ‚Läuft Netflix wieder?‘

Cloud verändert die Perspektive zusätzlich

Auch Cloud- und Hyperscale-Infrastrukturen verändern die Rahmenbedingungen. Cloud-Plattformen müssen Netzwerke in einer Größenordnung betreiben, die mit vielen klassischen Unternehmensumgebungen kaum vergleichbar ist. Gleichzeitig müssen sie unterschiedliche Kundennetze, Regionen, Dienste und globale Kommunikationsbeziehungen miteinander verbinden. Damit wächst der Anreiz, die Abhängigkeit von knappem IPv4-Adressraum zu reduzieren.

Für Unternehmen bedeutet das nicht automatisch, dass jede virtuelle Maschine oder jeder Cloud-Dienst ausschließlich IPv6 verwendet. Wohl aber verschiebt sich die Ausgangslage: IPv6-Unterstützung gehört bei modernen Plattformen zunehmend zur Infrastruktur, während IPv4 parallel weiterbetrieben wird.

Auch Software as a Service verstärkt diesen Effekt. Administrator:innen kontrollieren nicht mehr jede Netzwerkschicht selbst. Ein Dienst kann über IPv6 erreichbar sein, obwohl das Unternehmen nie ein eigenes IPv6-Projekt durchgeführt hat. Die Grenze zwischen unserem Netzwerk und dem Internet ist damit ohnehin wesentlich unschärfer geworden.

IPv6 kann benutzt werden, ohne dass wir es bemerken

Damit kommen wir zu einem entscheidenden Unterschied zwischen der Einführung von IPv6 und vielen klassischen IT-Migrationen. Wenn ein Unternehmen von einer lokalen Exchange-Organisation zu Exchange Online wechselt, ist die Veränderung sichtbar. Wird eine Anwendung in die Cloud verschoben oder ein neues ERP-System eingeführt, existiert ein Projekt mit einem definierten Zielzustand.

IPv6 kann sich dagegen schrittweise ausbreiten. Ein Betriebssystem verwendet Link-Local-Adressen. Ein Internetprovider stellt einen IPv6-Präfix bereit. DNS liefert einen AAAA-Record. Ein Browser entscheidet sich für IPv6. Ein Smartphone kommuniziert in einem IPv6-geprägten Mobilfunknetz. Ein Cloud-Dienst ist über beide Protokolle erreichbar. Jede einzelne Veränderung kann stattfinden, ohne dass ein Unternehmen sie als IPv6-Migration wahrnimmt. Vielleicht erklärt gerade das, warum Wahrnehmung und technische Realität mitunter so weit auseinanderliegen.

Administrieren wir längst IPv6-Netze, ohne sie so zu nennen?

Damit drängt sich eine etwas provokante Frage auf: Administrieren wir längst IPv6-Netze, ohne sie als solche zu betrachten? Natürlich wird aus einem klassischen IPv4-Unternehmensnetz nicht allein deshalb ein vollständig geplantes IPv6-Netz, weil Windows auf seinen Interfaces Link-Local-Adressen besitzt. Aber die Gegenposition ist ebenso problematisch.

Ein Netzwerk ist nicht automatisch IPv4-only, nur weil seine Administrator:innen ausschließlich IPv4 dokumentieren, überwachen und bewusst konfigurieren. Wenn Endgeräte IPv6 beherrschen, lokale IPv6-Kommunikation stattfindet, Provider IPv6 bereitstellen und externe Dienste über IPv6 erreichbar sind, existiert eine zweite Protokollwelt möglicherweise längst neben der administrativ wahrgenommenen Infrastruktur.

Und genau hier wird aus einer historischen Betrachtung eine aktuelle betriebliche Frage: Wenn IPv6 ohnehin vorhanden ist – wer administriert es eigentlich? Wer dokumentiert die IPv6-Kommunikation? Wer überwacht sie? Welche Firewall-Regeln gelten? Erkennt das SIEM entsprechende Ereignisse? Können Administrator:innen IPv6-Verkehr analysieren? Und wissen wir überhaupt, welche Systeme untereinander über IPv6 kommunizieren können? Diese Fragen führen zu einer unbequemen Erkenntnis. IPv6 nicht aktiv einzuführen bedeutet nicht zwangsläufig, IPv6 nicht zu betreiben. Es kann auch bedeuten, eine bereits vorhandene Protokollwelt nicht aktiv zu verwalten. Und damit verändert sich die Diskussion grundlegend. Aus der Frage Wann sollten wir IPv6 einführen? wird zunehmend eine andere: Wann beginnen wir damit, das IPv6, das längst vorhanden ist, genauso professionell zu behandeln wie IPv4?

Das Dual-Stack-Dilemma

Nach dem vorherigen Kapitel könnte die Konsequenz zunächst einfach erscheinen: Wenn IPv6 ohnehin längst vorhanden ist, führen wir es kontrolliert in die Unternehmensinfrastruktur ein und betreiben für eine Übergangszeit IPv4 und IPv6 parallel. Genau dafür ist Dual Stack gedacht. Ein Endsystem kann gleichzeitig über IPv4- und IPv6-Adressen verfügen. Anwendungen können beide Protokollfamilien verwenden und abhängig von Erreichbarkeit, DNS-Antworten und Adressauswahl den geeigneten Kommunikationsweg nutzen. Bestehende IPv4-Dienste funktionieren weiter, während IPv6 schrittweise ergänzt werden kann.

Technisch habe ich dieses Verfahren bereits im Beitrag Adresswelten im Wandel – der strukturierte Einstieg in TCP/IPv6 betrachtet. Für unsere aktuelle Fragestellung ist deshalb eine andere Perspektive interessanter. Denn aus Sicht des Betriebs bedeutet Dual Stack zunächst etwas ausgesprochen Banales: Wir betreiben nicht weniger IPv4, weil IPv6 hinzukommt. Wir betreiben erst einmal mehr Netzwerk.

Der naheliegende Weg in die IPv6-Welt

Die Attraktivität von Dual Stack liegt auf der Hand. Ein Unternehmen muss nicht an einem Freitagabend IPv4 abschalten und darauf hoffen, dass am Montagmorgen alle Anwendungen mit IPv6 funktionieren. Stattdessen lässt sich IPv6 schrittweise einführen. Netzwerksegmente können vorbereitet, Router und Firewalls konfiguriert, Server und Dienste ergänzt und Erfahrungen gesammelt werden. Anwendungen, die weiterhin IPv4 benötigen, bleiben erreichbar. Dual Stack reduziert damit einen wesentlichen Teil des Migrationsrisikos.

Gerade in gewachsenen Unternehmensnetzen ist das ein großer Vorteil. Wir befinden uns wieder in unserer Brownfield-Situation: Anwendungen, Abhängigkeiten und Prozesse existieren bereits. Ein paralleler Betrieb erlaubt es, die neue Protokollwelt einzuführen, ohne die alte sofort beseitigen zu müssen. Doch genau darin steckt das Dilemma. Was den Einstieg erleichtert, kann den Ausstieg aus IPv4 erschweren.

Zwei Adresswelten müssen geplant werden

Mit Dual Stack existieren zunächst zwei Adressierungsmodelle nebeneinander. IPv4-Subnetze müssen weiterhin geplant, dokumentiert und verwaltet werden. Gleichzeitig kommen IPv6-Präfixe hinzu. IP-Adressmanagement, Dokumentation und Inventarisierung müssen beide Welten abbilden können.

Dabei geht es nicht nur darum, in einer Tabelle eine zusätzliche Spalte für eine IPv6-Adresse anzulegen. IPv6 bringt eigene Adresstypen und Mechanismen mit. Ein Interface kann mehrere IPv6-Adressen besitzen, Link-Local-Adressen spielen eine besondere Rolle und die Adresskonfiguration kann je nach Architektur beispielsweise über SLAAC, DHCPv6 oder statische Konfiguration erfolgen.

Die IPv4-Welt verschwindet dadurch zunächst nicht. Dual Stack ersetzt die vorhandene Adressverwaltung nicht. Es ergänzt sie um eine zweite. Und damit steigt die betriebliche Komplexität.

Multiprotokoll-Netzwerke hatten wir schon einmal

Für erfahrenere Administrator:innen ist diese Situation allerdings keineswegs neu. Wer lange genug in Unternehmensnetzen arbeitet, erinnert sich möglicherweise noch an eine Zeit, in der TCP/IP keineswegs das einzige selbstverständliche Netzwerkprotokoll war.

IPX/SPX gehörte insbesondere in Novell-NetWare-Umgebungen zum Alltag. NetBIOS-basierte Kommunikation und NetBEUI spielten in Microsoft-Netzwerken eine wichtige Rolle. In Apple-Umgebungen begegnete uns AppleTalk. Je nach Infrastruktur liefen mehrere dieser Protokollwelten parallel über dieselben Netzwerke. Und irgendwann kam TCP/IP hinzu.

Was aus heutiger Perspektive fast selbstverständlich klingt, war damals ebenfalls eine Veränderung bestehender Infrastrukturen. TCP/IP musste eingeführt, adressiert, geroutet, dokumentiert und von Administrator:innen verstanden werden. Anwendungen und Betriebssysteme mussten damit umgehen können. Für eine gewisse Zeit bedeutete das auch damals: Die neue Protokollwelt kam hinzu, während die alte zunächst weiterbetrieben wurde.

Später drehte sich das Verhältnis um. TCP/IPv4 wurde zum Standard und die zuvor selbstverständlichen Protokolle verschwanden nach und nach aus den Unternehmensnetzen.

Erfahrung kann auch Respekt bedeuten

Vielleicht erklärt diese Erinnerung sogar einen Teil der Zurückhaltung, die mir bei IPv6 gelegentlich gerade bei sehr erfahrenen Administrator:innen begegnet. Das muss keineswegs mangelnde Veränderungsbereitschaft sein.

Wer bereits erlebt hat, wie IPX/SPX, NetBIOS-basierte Protokolle oder AppleTalk aus produktiven Umgebungen verschwanden und TCP/IP ihren Platz einnahm, weiß auch, was sich hinter dem harmlosen Begriff Protokollmigration verbergen kann. Es geht eben nicht nur darum, ein neues Protokoll auf einem Netzwerkadapter zu aktivieren. Adressierung, Routing, Namensauflösung, Anwendungen, Sicherheitskonzepte, Monitoring, Dokumentation und nicht zuletzt das Wissen der beteiligten Menschen müssen mitwachsen.

Mitunter begegnen gerade diejenigen einer IPv6-Migration mit besonderem Respekt, die schon einmal erlebt haben, wie aufwendig eine grundlegende Veränderung der Netzwerkarchitektur tatsächlich sein kann. Damit bekommt auch unsere frühere Betrachtung von Erfahrung noch einmal eine wichtige Nuance. Erfahrung kann Veränderungen bremsen, weil das Bekannte Sicherheit vermittelt. Sie kann aber ebenso zu einer realistischeren Risikoeinschätzung führen. Oder etwas zugespitzter: Wer eine Protokollmigration nur aus dem Lehrbuch kennt, sieht vor allem das Ziel. Wer schon eine erlebt hat, erinnert sich auch an den Weg dorthin.

Zwei Protokollwelten bedeuten auch zwei Routingwelten

Ähnliches gilt für das Routing. Ein Netzwerk kann über IPv4 vollständig erreichbar sein und gleichzeitig ein Problem im IPv6-Routing besitzen. Umgekehrt kann IPv6 funktionieren, während eine IPv4-Route fehlt. Auch dynamische Routingprotokolle und deren jeweilige Adressfamilien müssen entsprechend betrachtet werden. Routingtabellen, Präfixe, Filter und gegebenenfalls unterschiedliche Pfade gehören damit zur Planung und Fehlersuche.

Für Administrator:innen bedeutet das eine wichtige Veränderung im Troubleshooting. Die Feststellung ‚Das Netzwerk ist erreichbar‘ ist in einer Dual-Stack-Umgebung eigentlich nicht mehr präzise genug. Die sinnvollere Frage lautet: ‚Über welches Protokoll ist es erreichbar?‘ Doch bevor wir überhaupt bei der Fehlersuche ankommen, kann sich bereits eine wesentlich banalere Frage stellen: Lässt sich die gewünschte IPv6-Architektur mit der vorhandenen Infrastruktur überhaupt umsetzen?

IPv6-Unterstützung bedeutet nicht automatisch IPv6-Tauglichkeit

Ein Beispiel dafür steht bei mir zu Hause. Ich gönne mir dort den Luxus einer Layer-3-geswitchten Netzwerkinfrastruktur. Mehrere Netze werden über einen Cisco Layer-3-Switch miteinander verbunden, ein LANCOM-Router stellt die Verbindung zum Internet her. IPv4 und NAT bilden dabei die vertraute Grundlage. Mein Internetprovider stellt mir zusätzlich ein /56-IPv6-Präfix zur Verfügung. Damit wären grundsätzlich mehr als genug Präfixe vorhanden, um meine internen Netze sauber auch mit IPv6 zu strukturieren.

Eigentlich ideale Voraussetzungen. Und trotzdem betreibe ich diese Infrastruktur derzeit nicht so, wie ich es für ein konsequentes Dual-Stack-Netz gerne tun würde. Sowohl der LANCOM-Router als auch der Cisco-Switch unterstützen grundsätzlich IPv6. Die entscheidende Frage lautet jedoch nicht, ob irgendwo im Datenblatt IPv6 steht, sondern welche IPv6-Funktionen das konkrete Gerät in der eingesetzten Produktklasse tatsächlich zur Verfügung stellt.

Genau dort stoße ich momentan an Grenzen. Die für meine gewünschte Architektur notwendigen Konfigurationsmöglichkeiten sind bei den vorhandenen Geräten nicht in dem Umfang verfügbar, den ich benötige. Entsprechende Funktionen bleiben höherwertigen Modellen beziehungsweise Produktklassen vorbehalten. Damit wird aus einer technischen IPv6-Frage plötzlich eine wirtschaftliche.

Und was kostet mich IPv6 jetzt?

Ich könnte meine Infrastruktur entsprechend aufrüsten. Technisch wäre das sicherlich interessant – und als Trainer wäre es für mich sogar ausgesprochen sinnvoll, auch zu Hause mit einer umfangreicheren produktiven IPv6-Umgebung experimentieren zu können. Aber dafür müsste ich zunächst investieren.

Und plötzlich stelle ich mir privat ziemlich genau jene Fragen, die sich IT-Verantwortliche in Unternehmen ebenfalls stellen: Was muss ersetzt werden? Welche Geräte benötige ich? Was kostet die Umstellung? Welchen unmittelbaren Vorteil habe ich anschließend?

Meine IPv4-Infrastruktur funktioniert. Mein Internetzugang funktioniert. Die internen Netze werden geroutet und NAT erfüllt am Internetübergang seinen Zweck. Es gibt derzeit keinen betrieblichen Leidensdruck, der mich zu einer sofortigen Investition zwingt. Hausinternes IPv6 ist damit für mich momentan – etwas zugespitzt formuliert – ein nice to have.

Mittelfristig möchte ich die Infrastruktur dennoch entsprechend anpassen. Nicht weil mein Heimnetz ohne IPv6 plötzlich unbrauchbar würde, sondern weil ich praktische Erfahrung sammeln möchte. Gerade wenn ich IPv6 vermittle, möchte ich nicht ausschließlich über Labore, Dokumentationen und Kundenszenarien sprechen, sondern auch eigene Betriebserfahrung einbringen können.

Im Kleinen dasselbe Dilemma wie im Unternehmen

Gerade deshalb finde ich dieses kleine Beispiel interessant. Denn plötzlich sitze ich selbst auf der anderen Seite der Argumentation. Technisch kann ich begründen, warum ich IPv6 einsetzen möchte. Mein Provider liefert mir sogar bereits den benötigten Adressraum. Teile meiner Infrastruktur unterstützen IPv6 grundsätzlich. Und trotzdem sage ich: Noch nicht. Ich muss erst schauen, was mich das kostet.

Im Unternehmen läuft dieselbe Abwägung lediglich in einer anderen Größenordnung. Dort geht es nicht um einen Router und einen Layer-3-Switch im heimischen Netzwerk, sondern möglicherweise um zahlreiche Switches, Router, Firewalls, Load Balancer, WLAN-Infrastrukturen, Managementsysteme und Supportverträge. Die Aussage ‚Unsere Geräte unterstützen IPv6‘ ist deshalb noch kein Nachweis dafür, dass die vorhandene Infrastruktur auch die geplante IPv6-Architektur unterstützt. Und selbst wenn eine technische Lösung existiert, bleibt die wirtschaftliche Frage bestehen.

Damit schließt sich erneut der Kreis zu unserem bisherigen Business Case: IPv6 kann technisch sinnvoll, strategisch richtig und sogar bereits vom Provider verfügbar sein – und trotzdem an der vollkommen legitimen Frage hängen, ob der unmittelbare Nutzen die notwendige Investition rechtfertigt.

Auch die Firewall muss beide Welten verstehen

Besonders relevant wird die Verdopplung durch Dual Stack bei der IT-Sicherheit. Denn mit einer zweiten Protokollwelt entsteht nicht automatisch ein zweites, ebenso ausgereiftes Sicherheitskonzept. Eine Freigabe für IPv4 bedeutet nicht automatisch, dass eine entsprechende IPv6-Kommunikation erlaubt ist. Umgekehrt sollte eine sorgfältig eingeschränkte IPv4-Kommunikation nicht dadurch umgangen werden können, dass dasselbe System über IPv6 auf einem anderen Pfad erreichbar ist. Netzwerkobjekte, Regelwerke, Zonen, Protokolle und Logging müssen deshalb für beide Protokollfamilien betrachtet werden.

Dabei reicht es nicht, vorhandene IPv4-Regeln gedanklich einfach auf längere Adressen zu übertragen. Was in der IPv4-Welt als sicher gilt, muss unter IPv6 nicht automatisch dieselbe Sicherheitswirkung entfalten. Das liegt nicht daran, dass IPv6 grundsätzlich unsicherer wäre. Vielmehr unterscheiden sich Kommunikationsmechanismen und damit teilweise auch die Voraussetzungen, unter denen Sicherheitsmaßnahmen wirken.

Wenn vertraute Sicherheitsannahmen nicht mehr ausreichen

Über Jahrzehnte haben sich in IPv4-Netzen bestimmte Vorstellungen von Sicherheit etabliert. Interne Systeme verwenden häufig private RFC-1918-Adressen, am Übergang zum Internet findet NAT statt und Firewalls kontrollieren den Verkehr zwischen unterschiedlichen Sicherheitszonen. Wie wir bereits gesehen haben, wird NAT dabei mitunter selbst als Sicherheitsmechanismus wahrgenommen. Ein internes System besitzt schließlich keine unmittelbar aus dem Internet routbare private IPv4-Adresse.

Mit IPv6 verändert sich dieses vertraute Bild. Ein Client kann eine global routbare IPv6-Adresse besitzen. Das bedeutet ausdrücklich nicht, dass er deshalb automatisch ungeschützt aus dem Internet erreichbar wäre. Eine Stateful Firewall kann eingehende Verbindungen selbstverständlich ebenso für IPv6 blockieren. Aber die Sicherheitswirkung entsteht dann durch die Firewall-Regel – und nicht dadurch, dass eine private Adresse hinter NAT verborgen wird.

Das klingt nach einem kleinen Unterschied. Für das Sicherheitsverständnis ist er jedoch erheblich. IPv6 zwingt uns stärker dazu, Adressierung, Erreichbarkeit und Zugriffskontrolle gedanklich voneinander zu trennen. Eine global routbare Adresse ist zunächst eine Eigenschaft der Adressierung und des Routings. Ob ein System tatsächlich erreichbar sein darf, entscheidet die Security Policy.

Aus einer Firewall-Regel werden zwei Sicherheitsbetrachtungen

Dual Stack verschärft diese Herausforderung. Ein Server kann über IPv4 und IPv6 erreichbar sein und damit zwei unterschiedliche Kommunikationspfade besitzen. Nehmen wir an, der IPv4-Zugriff auf einen Dienst wurde über Jahre sorgfältig eingeschränkt. Netzwerkobjekte sind definiert, Firewall-Regeln dokumentiert, Logging und Monitoring eingerichtet. Dann wird IPv6 aktiviert. Jetzt muss dieselbe Frage erneut beantwortet werden: Wer darf diesen Dienst über IPv6 erreichen?

Es genügt nicht, davon auszugehen, dass die vorhandene IPv4-Policy automatisch auch für IPv6 gilt. Firewall-Produkte unterscheiden sich in ihrer Konfiguration, Netzwerkobjekte müssen IPv6 berücksichtigen und auch vorgelagerte oder nachgelagerte Sicherheitskomponenten müssen den Verkehr entsprechend analysieren können.

Sonst entsteht im ungünstigsten Fall eine paradoxe Situation: Über IPv4 ist ein System hervorragend abgesichert, während über IPv6 ein Kommunikationsweg existiert, den niemand in derselben Konsequenz betrachtet hat. Ein sicher konfigurierter IPv4-Pfad macht den IPv6-Pfad nicht automatisch sicher.

ICMPv6 ist mehr als nur ein längeres Ping

Besonders deutlich wird der notwendige Perspektivwechsel bei ICMPv6. In manchen IPv4-Umgebungen hat sich über Jahre die vereinfachte Vorstellung etabliert, ICMP sei im Zweifel unerwünscht und könne möglichst weitgehend blockiert werden. Schon für IPv4 ist eine solche pauschale Strategie problematisch. Bei IPv6 wird sie noch problematischer.

ICMPv6 übernimmt wesentliche Aufgaben für den Betrieb des Protokolls. Neighbor Discovery, Router Discovery und weitere grundlegende Mechanismen greifen auf ICMPv6 zurück. Auch für die korrekte Behandlung unterschiedlicher Paketgrößen und damit für Path MTU Discovery spielt ICMPv6 eine wichtige Rolle. Eine Firewall-Regel nach dem Muster ‚ICMP brauchen wir nicht – blockieren.‘ ist deshalb keine besonders konsequente Härtung. Sie kann schlicht die Funktion des Netzwerks beeinträchtigen.

Die richtige Fragestellung lautet auch hier nicht: ‘Wie blockieren wir ICMPv6?‘ sondern: ‚Welche ICMPv6-Nachrichten werden für den Betrieb benötigt, welche dürfen bestimmte Grenzen überschreiten und welche müssen wir kontrollieren?‘ Das ist ein gutes Beispiel dafür, warum IPv6-Security mehr verlangt als das Übersetzen vorhandener IPv4-Regeln.

Auch das lokale Netzwerk bekommt eine neue Sicherheitsdimension

Hinzu kommen Mechanismen, die innerhalb eines Netzwerksegments besondere Aufmerksamkeit verdienen. IPv6 Neighbor Discovery ersetzt funktional wesentliche Aufgaben, die wir aus der IPv4-Welt von ARP kennen. Router Advertisements können Clients Informationen über verfügbare Router und die Netzwerkkonfiguration liefern. SLAAC ermöglicht die automatische Adresskonfiguration.

Das sind zentrale Bestandteile der IPv6-Architektur – gleichzeitig müssen Administrator:innen verstehen, wie diese Mechanismen missbraucht werden können. Ein unerwünschtes Router Advertisement ist beispielsweise nicht dasselbe Problem wie eine falsch konfigurierte klassische IPv4-Adresse. Ein Client kann dadurch Informationen über einen vermeintlichen Router erhalten und seine Kommunikation entsprechend ausrichten.

Damit verschiebt sich auch hier die Sicherheitsfrage: Nicht jeder relevante Angriff kommt von außen über die Internet-Firewall. IPv6-Sicherheit beginnt bereits auf dem lokalen Netzwerksegment. Hersteller bieten dafür Schutzmechanismen wie beispielsweise RA Guard an. Entscheidend ist jedoch zunächst, dass Administrator:innen die zugrunde liegende Kommunikation kennen und in ihr Sicherheitsmodell einbeziehen.

Was wir nicht sehen, können wir schlecht absichern

Damit schließt sich dieser Abschnitt unmittelbar an das vorherige Kapitel an. Dort haben wir gefragt, ob wir möglicherweise längst IPv6-Netze administrieren, ohne sie als solche wahrzunehmen. Aus Security-Sicht wird daraus eine wesentlich unangenehmere Frage: Können wir eine Protokollwelt angemessen absichern, die wir betrieblich gar nicht als Teil unseres Netzwerks betrachten?

Wenn IPv6 auf Clients aktiv ist, muss das Monitoring IPv6-Verkehr erkennen können. Firewalls müssen entsprechende Regeln besitzen. IDS- und IPS-Systeme müssen ihn analysieren können. SIEM-Systeme müssen IPv6-Adressen sinnvoll verarbeiten und Administrator:innen müssen Logeinträge interpretieren können. Auch Incident Response und Troubleshooting müssen beide Protokollwelten berücksichtigen. Denn Angreifer:innen interessieren sich letztlich wenig dafür, welches Protokoll in der Netzwerkdokumentation als das eigentlich verwendete eingetragen wurde.

Dual Stack verdoppelt nicht automatisch die Sicherheit

Damit wird eine zentrale betriebliche Konsequenz von Dual Stack sichtbar. IPv6 einfach zu deaktivieren, um die zweite Sicherheitsbetrachtung zu vermeiden, ist keine überzeugende langfristige Strategie. IPv6 lediglich zu aktivieren und anschließend mit IPv4-Denkmustern weiterzuarbeiten, ist es ebenso wenig.

Erforderlich ist vielmehr ein Sicherheitskonzept, das beide Protokollwelten bewusst berücksichtigt. Dual Stack bedeutet deshalb nicht nur zwei Möglichkeiten zur Kommunikation. Es bedeutet zwei Kommunikationswelten, deren Erreichbarkeit, Filterung, Überwachung und lokale Kontrollmechanismen konsistent abgesichert werden müssen.

Und genau hier liegt ein weiterer Preis einer jahrelangen Übergangsphase: Solange IPv4 und IPv6 parallel betrieben werden, müssen auch die Sicherheitsprozesse beide Welten beherrschen. Das führt uns unmittelbar zu einer Frage, die ein eigenes Kapitel verdient: Was passiert eigentlich, wenn IPv6 technisch längst vorhanden ist, die Sicherheitsorganisation aber weiterhin hauptsächlich in IPv4 denkt?

Troubleshooting bekommt eine zweite Dimension

Im Tagesbetrieb wird das Dual-Stack-Dilemma besonders anschaulich. Eine Kollegin meldet: ‚Der Server ist nicht erreichbar.‘ In einem klassischen IPv4-Netz beginnt bei erfahrenen Administrator:innen häufig eine beinahe automatisierte Kette von Prüfungen. Stimmt die Adresse? Ist das Default Gateway erreichbar? Funktioniert DNS? Existiert eine Route? Blockiert eine Firewall? Vieles davon geschieht nach Jahren der Erfahrung nicht mehr streng nach Lehrbuch. Bestimmte Symptome führen unmittelbar zu bestimmten Vermutungen.

Genau darin liegt jene betriebliche Routine, die wir bereits im vorherigen Kapitel betrachtet haben. Unter Dual Stack verschwindet dieses Wissen nicht. Die bekannte Fehleranalyse bekommt jedoch eine zweite Dimension. Welche Adressen hat DNS geliefert? Existieren A- und AAAA-Records? Welche Adressfamilie hat das Betriebssystem für die Verbindung ausgewählt? Funktioniert der Dienst über IPv4, über IPv6 oder über beide Protokolle? Sind Routing und Firewall-Regeln auf beiden Pfaden konsistent? Die zunächst einfache Aussage ‚Der Server ist nicht erreichbar‘ beschreibt damit möglicherweise zwei unterschiedliche Kommunikationswege – mit jeweils eigenen Fehlerursachen.

Besonders schwierig: Wenn IPv6 fast funktioniert

Eindeutige Fehler sind dabei nicht unbedingt die unangenehmsten. Wenn IPv6 überhaupt nicht konfiguriert ist, lässt sich das vergleichsweise schnell feststellen. Interessanter wird es, wenn IPv6 fast funktioniert.

Ein Client besitzt eine IPv6-Adresse. DNS liefert einen AAAA-Record. Das Betriebssystem betrachtet IPv6 grundsätzlich als nutzbar und versucht eine entsprechende Verbindung aufzubauen. Doch irgendwo auf dem Kommunikationspfad stimmt etwas nicht: Eine Route fehlt, eine Firewall filtert anders als erwartet oder ein Dienst ist über IPv6 nicht tatsächlich erreichbar.

Je nach Betriebssystem und Anwendung kann anschließend ein anderer Kommunikationsweg versucht werden. Für Benutzer:innen bleibt die eigentliche Ursache verborgen. Die Fehlermeldung lautet dann möglicherweise gar nicht: ‚IPv6 funktioniert nicht.‘, sondern lediglich: ‚Das ist heute irgendwie langsam.‘ Und damit wird aus einem Netzwerkproblem zunächst ein diffuses Anwendungsproblem.

Erfahrung muss beide Pfade einschließen

Genau hier zeigt sich erneut, warum IPv6-Kompetenz nicht allein daraus besteht, Präfixe berechnen oder Adressen lesen zu können. Administrator:innen müssen auch Erfahrung mit den Fehlerbildern der zweiten Protokollwelt entwickeln. Sie müssen wissen, welche Rolle Neighbor Discovery und Router Advertisements spielen, wie Adressauswahl funktioniert und wie sich DNS, Routing und Firewalling auf beiden Pfaden überprüfen lassen.

Vor allem dürfen vertraute IPv4-Ergebnisse nicht vorschnell auf die gesamte Verbindung übertragen werden. Ein erfolgreicher IPv4-Ping beweist nicht, dass IPv6 funktioniert. Eine funktionierende IPv4-Verbindung bestätigt nicht die IPv6-Firewall-Regeln. Und ein korrekt aufgelöster Hostname sagt noch nichts darüber aus, welcher der zurückgelieferten Kommunikationspfade tatsächlich funktioniert. ‚Funktioniert das Netzwerk?‘ ist in einer Dual-Stack-Umgebung deshalb häufig die falsche Frage. Präziser wäre: ‚Welcher Kommunikationspfad funktioniert – und welcher vielleicht nicht?‘

Dual Stack verdoppelt nicht einfach die Fehlersuche

Dabei wäre es etwas zu einfach zu behaupten, Dual Stack verdoppele schlicht den Troubleshooting-Aufwand. Viele Grundlagen bleiben schließlich dieselben und moderne Betriebssysteme sowie Anwendungen besitzen Mechanismen, um mit mehreren verfügbaren Kommunikationswegen umzugehen. Was tatsächlich steigt, ist die Zahl möglicher Zusammenhänge.

DNS kann funktionieren, während nur einer der beiden Netzwerkpfade gestört ist. Routing kann für IPv4 korrekt und für IPv6 fehlerhaft sein. Eine Firewall kann unterschiedliche Richtlinien anwenden. Monitoring kann einen Dienst über IPv4 als verfügbar melden, obwohl Benutzer:innen unter bestimmten Voraussetzungen einen gestörten IPv6-Pfad verwenden. Aus einem Troubleshooting-Pfad werden deshalb nicht einfach zwei voneinander getrennte Checklisten. Es entsteht ein Zusammenspiel zweier Protokollwelten, deren Auswahl und Wechselwirkungen Administrator:innen verstehen müssen.

Und genau darin liegt erneut der Preis des komfortablen Übergangs: Dual Stack erlaubt uns, IPv6 einzuführen, ohne IPv4 sofort aufzugeben. Im Fehlerfall müssen wir dafür aber jederzeit beantworten können, welche der beiden Welten gerade tatsächlich benutzt wird.

DNS wird zur entscheidenden Vermittlungsinstanz

Auch DNS bekommt in einer Dual-Stack-Umgebung eine zusätzliche Bedeutung. Seine grundsätzliche Aufgabe verändert sich dabei zunächst nicht: Namen werden aufgelöst und Anwendungen erhalten Informationen darüber, unter welchen Adressen ein Dienst erreichbar sein soll. Neu ist jedoch, dass hinter einem Namen mehrere Protokollwelten gleichzeitig sichtbar werden können.

Ein A-Record verweist auf eine IPv4-Adresse, ein AAAA-Record auf eine IPv6-Adresse. Sind beide vorhanden, kennt ein Client grundsätzlich beide Möglichkeiten. Welche Verbindung anschließend tatsächlich verwendet wird, hängt jedoch nicht allein von DNS ab. Betriebssystem, Anwendung, Adressauswahl und die tatsächlich vorhandene Konnektivität wirken zusammen. Damit reicht die klassische Feststellung ‚DNS funktioniert, der Name wird aufgelöst.‘ für die Fehlersuche nicht mehr unbedingt aus. Interessanter wird die Frage: ‚Welche Adressen liefert DNS zurück – und welchen der angebotenen Kommunikationspfade verwendet der Client anschließend tatsächlich?‘

Ein AAAA-Record ist mehr als ein zusätzlicher DNS-Eintrag

Gerade bei der schrittweisen Einführung von IPv6 besitzt diese Frage eine erhebliche praktische Bedeutung. Ein Unternehmen kann seine IPv6-Infrastruktur zunächst vorbereiten. Router beherrschen IPv6, Firewalls sind konfiguriert, Server besitzen entsprechende Adressen und erste Tests verlaufen erfolgreich. Solange ein produktiver Dienst jedoch ausschließlich über einen A-Record veröffentlicht wird, verwenden reguläre Clients für diesen Namen weiterhin den bekannten IPv4-Pfad.

Das Hinzufügen eines AAAA-Records verändert diese Situation. Plötzlich erfahren Clients bei der Namensauflösung: Für diesen Dienst existiert auch ein IPv6-Ziel. Aus einer technisch vorhandenen und möglicherweise bislang nur gezielt getesteten IPv6-Infrastruktur kann damit ein regulär genutzter Kommunikationspfad werden. Der DNS-Eintrag selbst ist schnell angelegt. Die eigentliche Frage lautet deshalb vorher: Ist der gesamte dahinterliegende IPv6-Pfad wirklich produktionsreif? Dazu gehören nicht nur Server und Routing. Auch Firewalls, Load Balancer, Proxies, Monitoring und gegebenenfalls weitere Sicherheitskomponenten müssen die Kommunikation korrekt behandeln.

DNS kann Funktionalität versprechen, die das Netzwerk nicht einlöst

Damit bekommt ein AAAA-Record gewissermaßen den Charakter eines Versprechens. Er signalisiert Clients, dass ein Dienst unter einer IPv6-Adresse erreichbar ist. Die bloße Existenz dieses Eintrags beweist jedoch nicht, dass der Kommunikationspfad tatsächlich vollständig funktioniert. Genau hier entstehen jene unangenehmen Fehlerbilder, die wir im vorherigen Abschnitt betrachtet haben: DNS funktioniert einwandfrei. Der AAAA-Record ist korrekt. Die IPv6-Adresse stimmt. Und trotzdem funktioniert die Verbindung nicht zuverlässig.

Vielleicht fehlt eine Route. Vielleicht wurde eine Firewall-Regel vergessen. Vielleicht hört die Anwendung nur auf IPv4. Vielleicht berücksichtigt ein Load Balancer IPv6 anders als erwartet. DNS kann einen IPv6-Pfad bekannt machen – seine Funktionsfähigkeit garantieren kann es nicht. Das klingt selbstverständlich, wird im Dual-Stack-Betrieb aber besonders relevant, weil parallel weiterhin ein funktionierender IPv4-Pfad existieren kann und dadurch Fehler verdeckt werden können.

Auch DNS selbst muss vollständig Dual Stack können

Hinzu kommt eine zweite Ebene, die leicht übersehen wird: Nicht nur die Antworten des DNS können IPv4- und IPv6-Adressen enthalten. Auch die DNS-Infrastruktur selbst muss in die Dual-Stack-Planung einbezogen werden. Autoritative und rekursive DNS-Dienste, interne DNS-Server, Weiterleitungen, Firewall-Regeln und Monitoring müssen zur geplanten Architektur passen. Ebenso gewinnt eine saubere Pflege der Namensauflösung an Bedeutung.

Vor allem sollte IPv6 nicht dazu führen, dass Administrator:innen wieder verstärkt mit fest eingetragenen IP-Adressen arbeiten, nur weil die Adressen ungewohnt erscheinen. Eigentlich gilt das Gegenteil: Je komplexer die Adressierung wird, desto wichtiger wird eine zuverlässig gepflegte Namensauflösung. Gerade IPv6 unterstreicht damit eine alte Netzwerkweisheit: Benutzer:innen und Anwendungen sollten möglichst mit Namen arbeiten – und DNS muss zuverlässig dafür sorgen, dass daraus die richtigen Kommunikationsziele werden.

Aus Namensauflösung wird Pfadauswahl

DNS entscheidet letztlich nicht allein darüber, welchen Netzwerkpfad eine Anwendung verwendet. Aber es stellt die Informationen bereit, auf deren Grundlage diese Entscheidung überhaupt möglich wird. Damit wird DNS im Dual-Stack-Netz zu einem wichtigen Bindeglied zwischen beiden Protokollwelten. Ein A-Record kann IPv4 anbieten. Ein AAAA-Record kann IPv6 anbieten. Erst das Zusammenspiel aus DNS, Betriebssystem, Anwendung und funktionierender Netzwerkinfrastruktur entscheidet, welcher Pfad tatsächlich genutzt wird.

Für Administrator:innen verändert sich deshalb auch hier die Fragestellung. Nicht mehr nur: ‚Kann ich den Namen auflösen?‘ Sondern: ‚Welche Kommunikationsmöglichkeiten veröffentlichen wir über DNS – und können wir für jede davon garantieren, dass sie genauso zuverlässig, sicher und überwacht funktioniert wie die andere?‘

Monitoring darf nicht bei IPv4 aufhören

Dasselbe Problem begegnet uns beim Monitoring. Ein Server kann über IPv4 hervorragend erreichbar sein, während seine IPv6-Konnektivität gestört ist. Überwacht das Monitoring ausschließlich die bekannte IPv4-Adresse, bleibt dieser Fehler möglicherweise unsichtbar. Das System ist schließlich grün. Nur eben nicht über beide Protokolle.

Ein konsequent betriebenes Dual-Stack-Netz muss deshalb auch im Monitoring als solches behandelt werden. Erreichbarkeit, Dienste, Routing und DNS müssen für beide Protokollfamilien sichtbar sein. Dabei genügt es nicht unbedingt, einen vorhandenen IPv4-Check einfach ein zweites Mal mit einer IPv6-Adresse anzulegen. Denn moderne Überwachung besteht längst nicht mehr nur aus Ping, SNMP und der Frage, ob ein bestimmter TCP-Port erreichbar ist.

Aus Monitoring wird Telemetrie

In größeren Umgebungen fließen heute Informationen aus zahlreichen Quellen zusammen. Firewalls, Router, Switches, Server, Clients, Identity-Systeme, Endpoint Detection and Response, Intrusion Detection and Prevention, Cloud-Plattformen und Anwendungen erzeugen kontinuierlich Telemetriedaten. Diese Daten werden gesammelt, normalisiert, miteinander korreliert und ausgewertet. IPv6 muss durch diese gesamte Kette hindurch korrekt verarbeitet werden können.

Das beginnt bei einer scheinbar einfachen Frage: Erkennt ein Werkzeug eine IPv6-Adresse überhaupt zuverlässig als IP-Adresse? Es geht weiter mit Datenfeldern, Suchabfragen, Dashboards, Filtern, Inventarisierung und der Zuordnung von Ereignissen zu Systemen. Eine über Jahre gewachsene Monitoring- oder Security-Infrastruktur kann an vielen Stellen implizite IPv4-Annahmen enthalten. Vielleicht erwartet ein regulärer Ausdruck vier dezimale Oktette. Vielleicht besitzt ein Datenbankfeld ein ungeeignetes Format. Vielleicht arbeitet ein eigenes Skript mit Zeichenkettenoperationen, die nur für IPv4 funktionieren. Das Produkt kann IPv6 unterstützen und der darüber aufgebaute betriebliche Prozess trotzdem noch IPv4 denken.

SIEM macht die Herausforderung besonders sichtbar

Besonders deutlich wird das bei einem Security Information and Event Management, kurz SIEM. Ein SIEM lebt davon, Ereignisse aus unterschiedlichen Quellen miteinander in Beziehung zu setzen. Eine Firewall meldet eine Verbindung, ein Endpoint-System registriert einen Prozessstart, ein Identity-System eine Anmeldung und ein DNS-Server eine Namensauflösung. Erst die Korrelation dieser Informationen kann aus einzelnen Beobachtungen ein erkennbares Sicherheitsereignis machen.

Mit Dual Stack kann dasselbe System jedoch unter mehreren Adressen auftreten. Neben einer IPv4-Adresse können mehrere IPv6-Adressen existieren und sich je nach Adressierungsstrategie teilweise verändern. Damit wird die Identität eines Systems noch weniger mit der simplen Frage beantwortet: ‚Welche IP-Adresse hat der Rechner?‘ Für die Korrelation müssen vielmehr Zusammenhänge zwischen Gerät, Identität, Adresse, Zeitpunkt und Netzwerksegment hergestellt werden. Wenn das SIEM IPv4 und IPv6 nicht zuverlässig demselben Kontext zuordnen kann, entstehen aus einer Infrastruktur möglicherweise zwei scheinbar voneinander unabhängige Welten. Genau dort können blinde Flecken entstehen.

Detection Rules müssen beide Protokollwelten kennen

Noch anspruchsvoller wird es bei den eigentlichen Erkennungsregeln. Über Jahre entwickelte Detection Rules, Abfragen und Dashboards können IPv4-spezifische Annahmen enthalten. Private Adressen werden vielleicht über RFC-1918-Bereiche erkannt. Bestimmte Netzwerke sind über IPv4-Präfixe definiert. Regeln suchen nach konkreten Adressmustern oder schließen bekannte interne Bereiche von einer Analyse aus.

Unter IPv6 müssen solche Annahmen überprüft werden. Was bedeutet intern? Welche IPv6-Präfixe gehören zum Unternehmen? Welche Link-Local-Kommunikation ist normal? Welche Systeme dürfen global adressiert sein? Welche Kommunikationsbeziehungen erwarten wir innerhalb eines Segments? Eine Detection Rule, die für IPv4 hervorragend funktioniert, muss deshalb nicht zwangsläufig denselben Angriff über IPv6 erkennen. Damit begegnet uns erneut die Erkenntnis aus dem Firewall-Abschnitt: Was in der IPv4-Welt sicher überwacht wird, ist nicht automatisch auch unter IPv6 sicher überwacht.

Bei SOAR wird aus Erkennung eine Aktion

Noch kritischer kann die Situation werden, wenn auf die Erkennung automatisierte Reaktionen folgen. Security Orchestration, Automation and Response, kurz SOAR, verbindet Sicherheitsereignisse mit Playbooks und konkreten Aktionen. Eine auffällige Adresse kann beispielsweise gegen Threat-Intelligence-Daten geprüft, an einer Firewall blockiert oder einem Incident zugeordnet werden. Jetzt reicht es nicht mehr, IPv6 lediglich korrekt anzuzeigen. Die gesamte Automatisierungskette muss damit umgehen können.

Kann das Playbook IPv6-Adressen korrekt übernehmen? Unterstützt die angesprochene Firewall-API die gewünschte Aktion für IPv6? Wird das richtige Netzwerkobjekt erzeugt? Funktionieren Threat-Intelligence-Abfragen mit IPv6? Können eigene PowerShell-, Python- oder REST-basierte Automatisierungen beide Adressfamilien verarbeiten? Ein Fehler im Dashboard ist ärgerlich. Ein Fehler in einer automatisierten Sicherheitsreaktion kann dagegen dazu führen, dass ein erkannter Angriff nicht dort blockiert wird, wo er tatsächlich stattfindet.

Auch historische Daten bekommen eine neue Bedeutung

Hinzu kommt ein Aspekt, der bei einer Migration leicht unterschätzt wird: Sicherheitsanalyse lebt häufig von historischen Vergleichsdaten. Wie kommuniziert dieses System normalerweise? Welche Ziele kontaktiert es regelmäßig? Ist diese Verbindung ungewöhnlich? Gab es ähnliche Ereignisse bereits?

Wenn ein System nach Einführung von IPv6 plötzlich Kommunikationspfade verwendet, die im bisherigen IPv4-zentrierten Datenbestand nicht vorkommen, muss das nicht automatisch verdächtig sein. Es kann schlicht das Ergebnis der neuen Netzwerkarchitektur sein. Monitoring und Security Analytics müssen deshalb lernen, zwischen neuer legitimer IPv6-Kommunikation und tatsächlich auffälligem Verhalten zu unterscheiden. Auch Baselines verändern sich mit der Migration.

Dual Stack muss auch im SOC Dual Stack sein

Damit reicht es nicht, Router, Switches und Firewalls IPv6-fähig zu machen. Auch das Security Operations Center muss beide Protokollwelten verstehen. Dashboards, Logquellen, Parser, Korrelationsregeln, Detection Rules, Threat Intelligence, Incident Response und SOAR-Playbooks gehören deshalb genauso auf die IPv6-Checkliste wie Routing und Firewalling.

Das macht die Migration gerade in komplexen Unternehmensumgebungen anspruchsvoll. Je stärker Monitoring und Security bereits automatisiert und miteinander verzahnt sind, desto mehr Abhängigkeiten müssen betrachtet werden. Paradoxerweise kann eine sehr ausgereifte IPv4-Sicherheitsarchitektur damit sogar zusätzlichen Migrationsaufwand erzeugen: Je mehr Wissen über Jahre in Regeln, Korrelationen und Automatisierungen eingeflossen ist, desto sorgfältiger muss geprüft werden, ob dieses Wissen auch für IPv6 gilt.

Hier zeigt sich erneut unser zentraler Gedanke: Technische IPv6-Unterstützung allein genügt nicht. Auch die betrieblichen Prozesse, Überwachungsmodelle und Sicherheitsautomatisierungen müssen IPv6 beherrschen. Sonst betreibt ein Unternehmen zwar Dual Stack, überwacht aber weiterhin gedanklich ein IPv4-Netz. Und ausgerechnet die zweite Protokollwelt könnte dann dort am wenigsten sichtbar sein, wo Sichtbarkeit für die Sicherheit am wichtigsten wäre.

Aus der Übergangsphase wird ein Dauerzustand

Das vielleicht größte Problem von Dual Stack liegt jedoch nicht in einer einzelnen technischen Komponente. Es liegt in der Zeit. Dual Stack besitzt einen enormen organisatorischen Vorteil: IPv4 muss zunächst nicht verschwinden. Genau dadurch entfällt aber auch der unmittelbare Zwang, einen Zeitpunkt für sein Verschwinden festzulegen.

IPv6 wird eingeführt. Die wichtigsten Dienste funktionieren darüber. Die Migration gilt als erfolgreich. Und IPv4? Das bleibt erst einmal. Schließlich gibt es noch diese eine Altanwendung. Jenes Managementsystem benötigt weiterhin IPv4. Ein Dienstleister unterstützt IPv6 noch nicht vollständig. Ein altes Gerät lässt sich nicht umstellen. Und außerdem funktioniert doch alles.

Aus einer Übergangsphase von einigen Jahren können auf diese Weise sehr viele Jahre werden. Hier begegnet uns dasselbe Muster, das wir bereits bei NAT gesehen haben: Eine technisch sinnvolle Übergangslösung kann so erfolgreich sein, dass der Druck verschwindet, den Übergang jemals abzuschließen.

Dual Stack braucht eine Exit-Strategie

Deshalb wäre es falsch, Dual Stack grundsätzlich als schlechte Architektur zu betrachten. Für die Migration gewachsener Netzwerke ist der parallele Betrieb beider Protokollfamilien häufig der pragmatischste Weg. Problematisch wird er erst, wenn ein Unternehmen zwar einen Plan für die Einführung von IPv6, aber keinen Plan für die Reduzierung von IPv4 besitzt.

Eine IPv6-Strategie sollte deshalb nicht bei der Frage enden: Wie bekommen wir IPv6 in unser Netzwerk? Sie sollte von Beginn an eine zweite Frage enthalten: Wo und unter welchen Voraussetzungen können wir IPv4 anschließend wieder entfernen? Das muss keineswegs bedeuten, kurzfristig ein vollständig IPv4-freies Unternehmensnetz anzustreben. Unterschiedliche Bereiche können unterschiedliche Migrationsgeschwindigkeiten besitzen. Legacy-Systeme werden möglicherweise noch lange IPv4 benötigen. Aber es macht einen erheblichen Unterschied, ob IPv4 aufgrund einer dokumentierten Abhängigkeit weiterhin benötigt wird oder einfach deshalb bestehen bleibt, weil niemand seinen Abbau geplant hat.

Dual Stack sollte deshalb als Migrationswerkzeug verstanden werden – nicht automatisch als Zielarchitektur. Dual Stack erleichtert den Einstieg in IPv6. Ohne Exit-Strategie kann es jedoch genau jene IPv4-Abhängigkeiten konservieren, die mit der Migration langfristig reduziert werden sollten. Und damit bekommt die vermeintlich komfortable Übergangsphase ihren Preis: zwei Adresswelten, zwei Routingwelten, zwei Sicherheitsbetrachtungen, zusätzliche Anforderungen an DNS und Monitoring sowie zwei mögliche Pfade bei jeder Fehlersuche. Die entscheidende Frage lautet deshalb nicht nur, wie lange ein Unternehmen Dual Stack betreiben kann, sondern irgendwann auch: Wie lange will es sich den dauerhaften Betrieb zweier Protokollwelten leisten?

IPv6 als blinder Fleck der IT-Security

Nach dem vorherigen Kapitel könnte leicht der Eindruck entstehen, IPv6-Sicherheit sei vor allem eine Frage zusätzlicher Firewall-Regeln, Logquellen und Monitoring-Systeme. Das wäre zu kurz gegriffen. IPv6 bringt eigene Mechanismen für Adressierung, Nachbarerkennung, Router Discovery und automatische Konfiguration mit. Diese Mechanismen sind weder grundsätzlich unsicher noch konzeptionell schlechter als ihre Pendants in der IPv4-Welt. Sie funktionieren jedoch teilweise anders – und genau diese Unterschiede müssen Administrator:innen und Security-Verantwortliche verstehen.

Die NSA bringt das in ihrer IPv6 Security Guidance bemerkenswert nüchtern auf den Punkt: Viele Sicherheitsprobleme ähneln grundsätzlich denen von IPv4. Besondere Risiken entstehen jedoch dort, wo Erfahrung mit IPv6 fehlt, Konfigurationen noch nicht ausgereift sind oder Sicherheitswerkzeuge die neue Protokollwelt nicht mit derselben Qualität beherrschen.

Damit kommen wir zur vielleicht zentralen Aussage dieses Kapitels: Nicht IPv6 ist der blinde Fleck. Ein vorhandenes, aber nicht verstandenes und nicht überwachtes IPv6 kann zum blinden Fleck werden.

„Wir setzen kein IPv6 ein“

Eine Aussage begegnet mir im Unternehmensumfeld immer wieder: ‚IPv6 setzen wir nicht ein.‘ Nach unserer bisherigen Betrachtung wissen wir bereits, dass diese Aussage genauer hinterfragt werden sollte. Was bedeutet nicht einsetzen? Es kann bedeuten, dass kein globales IPv6-Präfix für das Unternehmensnetz geplant wurde. Es kann bedeuten, dass Router keine produktiven IPv6-Netze routen oder Serverdienste nicht bewusst über IPv6 veröffentlicht werden. Das bedeutet jedoch nicht zwangsläufig, dass auf den Endgeräten kein IPv6 vorhanden ist.

Moderne Betriebssysteme bringen IPv6 standardmäßig mit. Link-Local-Adressen ermöglichen Kommunikation innerhalb eines lokalen Segments und verschiedene Mechanismen können IPv6 verwenden, ohne dass zuvor ein klassisches unternehmensweites Migrationsprojekt stattgefunden hat. Aus Security-Sicht entsteht daraus eine entscheidende Frage: Was geschieht mit einem Protokoll, für das sich niemand verantwortlich fühlt, weil die Organisation davon ausgeht, es gar nicht einzusetzen?

Ein deaktiviertes Konzept ist noch keine Security Policy

Eine naheliegende Reaktion könnte lauten: ‚Dann schalten wir IPv6 eben überall ab.‘ Doch gerade in modernen Betriebssystemumgebungen ist das keine besonders überzeugende langfristige Sicherheitsstrategie. IPv6 ist Bestandteil moderner Netzwerkstacks und sollte nicht allein deshalb deaktiviert werden, weil die Organisation bislang keine Betriebs- und Sicherheitsprozesse dafür aufgebaut hat. Aus Security-Sicht wäre das ohnehin eine merkwürdige Umkehrung der Verantwortlichkeiten: Nicht die Architektur bestimmt die Security Policy, sondern fehlendes Wissen bestimmt, welche Architektur überhaupt zugelassen wird.

Sinnvoller ist deshalb zunächst eine Bestandsaufnahme. Wo ist IPv6 aktiv? Welche Adressen besitzen unsere Systeme? Welche Kommunikation findet statt? Welche Netzwerkkomponenten verarbeiten IPv6? Welche Mechanismen sind erlaubt? Und welche davon benötigen wir tatsächlich? Erst danach lässt sich bewusst entscheiden, was zugelassen, eingeschränkt oder deaktiviert werden soll. ‚Wir benutzen es nicht‘ sollte in der IT-Security niemals eine Vermutung sein. Es sollte ein überprüfbarer Zustand sein.

Neighbor Discovery verändert das lokale Netzwerk

Ein zentraler Unterschied begegnet uns unmittelbar im lokalen Netzwerk. Unter IPv4 kennen Administrator:innen ARP als Mechanismus, mit dem zu einer IPv4-Adresse die entsprechende MAC-Adresse innerhalb des lokalen Segments ermittelt wird. IPv6 verwendet dafür Neighbor Discovery, spezifiziert in RFC 4861. Doch Neighbor Discovery übernimmt deutlich mehr Aufgaben. Über ICMPv6-Nachrichten werden Nachbarn erkannt, Link-Layer-Adressen ermittelt, Router gefunden und Informationen über die Erreichbarkeit anderer Systeme verarbeitet.

Damit gehört Neighbor Discovery zu den grundlegenden Mechanismen eines funktionierenden IPv6-Netzes. Und genau deshalb ist es sicherheitsrelevant. Wie bei ARP basiert ein Teil dieser lokalen Kommunikation darauf, dass Systeme Informationen anderer Knoten im Segment verarbeiten. Angreifer:innen oder falsch konfigurierte Systeme können versuchen, diese Mechanismen zu beeinflussen.

Das Sicherheitsproblem ist damit konzeptionell keineswegs vollkommen neu. Neu sind jedoch die Protokolle, Nachrichten und Schutzmechanismen, die Administrator:innen dafür kennen müssen. Wer ARP-Spoofing versteht, besitzt eine wichtige Grundlage. Wer deshalb glaubt, Neighbor Discovery nicht mehr lernen zu müssen, besitzt noch keine IPv6-Security-Strategie.

Router Advertisements sind mächtig

Besonders interessant sind Router Advertisements, kurz RA. IPv6-Router können damit Endgeräten wichtige Informationen über das lokale Netzwerk bereitstellen. Clients erfahren unter anderem, dass ein Router vorhanden ist und erhalten Informationen, die für ihre IPv6-Konfiguration relevant sind. Diese automatische Kommunikation gehört zu den Stärken der IPv6-Architektur. Ein Endgerät kann sich in ein Netzwerk integrieren, ohne dass jede notwendige Information zuvor manuell eingetragen werden muss.

Aus Security-Sicht bedeutet Automatisierung jedoch immer auch Vertrauen. Ein Client muss entscheiden können, welchen Informationen er vertraut. Und damit stellt sich eine einfache Frage: Was passiert, wenn ein Router Advertisement gar nicht vom vorgesehenen Router stammt?

Wenn plötzlich jemand anderes Router spielt

Ein Rogue Router Advertisement ist ein unerwünschtes oder manipuliertes RA innerhalb des lokalen Netzwerks. Dabei muss hinter einem solchen Ereignis nicht einmal zwingend ein gezielter Angriff stehen. Bereits ein falsch angeschlossenes oder falsch konfiguriertes Gerät kann Router Advertisements aussenden und damit die IPv6-Konfiguration anderer Systeme beeinflussen.

Dafür lässt sich ein ausgesprochen alltägliches Szenario konstruieren: Ein Mitarbeiter bringt den eigenen Heimrouter mit ins Unternehmen, weil beispielsweise eine bestimmte Konfiguration angepasst oder ein Problem durch die IT-Abteilung untersucht werden soll. Das Gerät wird kurzerhand an einen freien Netzwerkanschluss angeschlossen. Was sollte schon passieren?

Der Heimrouter weiß nicht, dass er im Unternehmen steht

Aus Sicht des Routers hat sich zunächst nur seine Umgebung verändert. Er weiß schließlich nicht, dass er gerade nicht mehr im heimischen Arbeitszimmer, sondern an einem Switchport des Unternehmens angeschlossen ist. Ist seine IPv6-Routerfunktion auf dem betreffenden Interface aktiv, kann er unter Umständen beginnen, Router Advertisements in das lokale Segment zu senden. Andere IPv6-fähige Systeme können diese Informationen empfangen und in ihre Netzwerkkonfiguration einbeziehen.

Damit existiert plötzlich ein IPv6-Router im Segment, den die Netzwerkadministration dort niemals vorgesehen hat. Das Bemerkenswerte daran: Niemand musste einen Angriff durchführen. Niemand musste eine Sicherheitslücke ausnutzen. Niemand musste überhaupt wissen, was ein Router Advertisement ist. Es genügt möglicherweise ein Gerät, das genau das tut, wofür es ursprünglich konfiguriert wurde – nur am falschen Ort.

Gerade das macht solche Szenarien für die Security-Betrachtung interessant. Fehlkonfigurationen und unbeabsichtigte Infrastruktur können ähnliche Auswirkungen erzeugen wie ein gezielt eingebrachtes Rogue Device.

Aus dem Versehen kann ein Angriffsszenario werden

Bei einem bewussten Angriff wird dasselbe Prinzip entsprechend kritischer. Gelingt es einem System, gegenüber Clients unerwünschte Router Advertisements zu verbreiten, kann es deren IPv6-Konfiguration beeinflussen und sich beispielsweise als möglicher Kommunikationspfad präsentieren. Welche Auswirkungen daraus tatsächlich entstehen, hängt von der jeweiligen Netzwerkkonfiguration, den Endsystemen und den vorhandenen Schutzmechanismen ab. Das Grundproblem bleibt jedoch dasselbe: Clients erhalten Infrastrukturinformationen von einer Quelle, die dafür nicht autorisiert ist. Damit bekommt der klassische Gedanke eines Rogue Devices unter IPv6 eine zusätzliche Dimension.

Und wieder begegnet uns unser Wahrnehmungsproblem: In einem Unternehmen, das vermeintlich kein IPv6 einsetzt, sucht bei einem merkwürdigen Netzwerkproblem möglicherweise zunächst niemand nach unerwünschten Router Advertisements. Vielleicht wird IPv4 geprüft. DHCP sieht korrekt aus. Das Default Gateway stimmt. DNS funktioniert. Die Firewall zeigt nichts Auffälliges. Und trotzdem verhalten sich einzelne Clients merkwürdig. Wer IPv6 gedanklich aus der Infrastruktur ausgeschlossen hat, wird IPv6 möglicherweise auch bei der Fehlersuche und Sicherheitsanalyse zunächst ausschließen.

Genau darin liegt das eigentliche Risiko. Ein Angriffspfad wird besonders attraktiv, wenn die Verteidigung nicht damit rechnet, dass er überhaupt existiert. Und ein unbeabsichtigter Fehler wird besonders schwer zu diagnostizieren, wenn niemand nach dem Protokoll sucht, über das er verursacht wird.

RA Guard bringt Kontrolle auf den Switch

Für solche Szenarien existieren Schutzmechanismen. RA Guard ermöglicht es geeigneten Switches, Router Advertisements auf Layer 2 zu kontrollieren. Vereinfacht formuliert lässt sich damit festlegen, an welchen Ports legitime Router Advertisements erwartet werden und wo entsprechende Nachrichten nicht auftreten dürfen. Das erinnert konzeptionell an andere First-Hop-Security-Mechanismen, mit denen Netzwerkkomponenten unerwünschte Infrastrukturinformationen bereits möglichst nahe an ihrer Quelle begrenzen.

Allerdings zeigt auch RA Guard, warum IPv6-Security Fachwissen benötigt. RFC 7113 beschäftigt sich ausdrücklich mit Implementierungsfragen und Umgehungsmöglichkeiten früherer RA-Guard-Ansätze. Schutzmechanismen müssen also nicht nur vorhanden sein – sie müssen die IPv6-Paketstruktur und mögliche Varianten korrekt berücksichtigen. Das ist eine wichtige Lektion: Ein Haken mit der Bezeichnung ‚IPv6 Security‘ ersetzt kein Verständnis der darunterliegenden Mechanismen.

Auch DHCPv6 gehört in die First-Hop-Security

Dasselbe Prinzip gilt für DHCPv6. Wo DHCPv6 eingesetzt wird, können unerwünschte DHCPv6-Server ebenfalls falsche Konfigurationsinformationen bereitstellen. Entsprechende Schutzmechanismen wie DHCPv6 Shield sollen verhindern, dass nicht autorisierte Systeme gegenüber Clients als DHCPv6-Server auftreten. Damit entsteht im Access-Netz eine ganze Gruppe neuer beziehungsweise angepasster Sicherheitsaufgaben.

Administrator:innen müssen beispielsweise festlegen, von welchen Ports Router Advertisements akzeptiert werden, wo DHCPv6-Antworten legitim sind und wie Neighbor-Discovery-Verkehr behandelt werden soll. Die NSA empfiehlt deshalb ausdrücklich, Schutzmechanismen wie RA Guard und DHCPv6 Shield dort in Betracht zu ziehen, wo Netzwerkkomponenten diese bereitstellen. IPv6-Security beginnt damit nicht erst an der Internet-Firewall. Sie beginnt bereits am ersten Switchport.

ICMPv6 ist Teil der Infrastruktur

Damit kommen wir zu einem weiteren Punkt, der IPv4-geprägte Sicherheitsroutinen herausfordert. ICMP wird in manchen Umgebungen noch immer primär mit ping verbunden. Daraus entstand über die Jahre mitunter die Vorstellung, ICMP sei für den eigentlichen produktiven Betrieb weitgehend verzichtbar und könne sicherheitshalber großzügig blockiert werden.

Bei IPv6 funktioniert dieses Denken nicht. Neighbor Discovery und Router Advertisements basieren auf ICMPv6. Auch weitere elementare Funktionen der IPv6-Kommunikation sind darauf angewiesen. Eine Firewall oder ACL muss deshalb wesentlich genauer unterscheiden, welche ICMPv6-Nachrichten für den Betrieb benötigt werden, welche Grenzen sie überschreiten dürfen und welche Kommunikation unerwünscht ist. Das Prinzip ‚ICMP blockieren ist sicherer‘ wird damit durch eine differenziertere Frage ersetzt: ‚Welche ICMPv6-Kommunikation benötigt unsere Architektur – und wo darf sie stattfinden?‘ Gerade hier zeigt sich, warum eine unveränderte Übertragung alter IPv4-Härtungsregeln auf IPv6 nicht nur wirkungslos, sondern sogar kontraproduktiv sein kann.

Die große Adresse schützt nicht automatisch

Ein weiterer Mythos betrifft den gewaltigen IPv6-Adressraum. Ein typisches /64 enthält eine unvorstellbar große Zahl möglicher Interface-Identifier. Klassisches sequenzielles Scanning eines vollständigen Subnetzes, wie wir es aus kleinen IPv4-Netzen kennen, wird dadurch praktisch erheblich unattraktiver. Daraus sollte jedoch keine Sicherheitsstrategie entstehen. Angreifer:innen müssen nicht zwangsläufig einen vollständigen /64-Bereich durchsuchen. Adressen können über DNS, Protokolle, Logs, bekannte Adressierungsmuster, Anwendungen oder beobachtete Kommunikation bekannt werden.

Der große Adressraum verändert damit bestimmte Reconnaissance-Techniken, ersetzt aber weder Firewalling noch Segmentierung, Zugriffskontrolle oder Monitoring. ‚Die Adresse findet ohnehin niemand‘ war unter IPv4 keine gute Security Policy – und wird es mit 128 Bit ebenfalls nicht.

Übergangsmechanismen schaffen zusätzliche Pfade

Eine weitere sicherheitsrelevante Besonderheit entsteht ausgerechnet durch die lange Koexistenz von IPv4 und IPv6. Um IPv6 über bestehende IPv4-Infrastrukturen transportieren zu können, wurden verschiedene Tunnel- und Übergangsmechanismen entwickelt. Dazu gehörten beziehungsweise gehören Technologien wie 6to4, ISATAP und Teredo. Technisch waren solche Mechanismen wichtige Werkzeuge der Transition.

Aus Security-Sicht können sie jedoch zusätzliche Kommunikationspfade erzeugen. IPv6-Verkehr kann dabei innerhalb anderer Protokolle transportiert werden. Eine Sicherheitsarchitektur, die lediglich nach nativem IPv6-Verkehr sucht oder ausschließlich die offensichtlich konfigurierten Netzwerkpfade betrachtet, kann solche Kommunikation deshalb möglicherweise anders behandeln als erwartet.

Die NSA empfiehlt entsprechend, nicht benötigte automatische Tunnelmechanismen zu deaktivieren und an Netzwerkgrenzen zu erkennen beziehungsweise zu blockieren. Werden sie tatsächlich benötigt, sollte ihr Einsatz bewusst begrenzt und dokumentiert werden. Die Kernaussage ist dabei allgemeiner als einzelne Technologien wie Teredo oder ISATAP: Jeder zusätzliche Übergangsmechanismus erhöht die Zahl der Kommunikationspfade, die eine Sicherheitsarchitektur verstehen und kontrollieren muss.

Nicht jeder Tunnel ist automatisch ein Angriff

Auch hier sollten wir jedoch nicht in die andere Richtung übertreiben. Ein Tunnel ist nicht automatisch bösartig. Transitionstechnologien wurden schließlich entwickelt, um reale technische Probleme während der Koexistenz von IPv4 und IPv6 zu lösen. Problematisch wird ein Tunnel dann, wenn er ungeplant, unkontrolliert oder außerhalb der vorgesehenen Security Policy entsteht.

Damit gilt dasselbe Prinzip wie für IPv6 insgesamt: Nicht die Existenz der Technologie ist das eigentliche Risiko. Das Risiko entsteht aus fehlender Sichtbarkeit und Kontrolle. Ein bewusst eingerichteter, dokumentierter und überwachter Übergangsmechanismus ist etwas grundlegend anderes als ein Kommunikationspfad, von dessen Existenz das Security-Team nichts weiß.

Die Firewall ist nur ein Teil der Antwort

An dieser Stelle wird auch deutlich, warum wir IPv6-Security nicht auf die Frage reduzieren dürfen, ob unsere Firewall IPv6 unterstützt. Natürlich müssen Firewalls und ACLs beide Protokollfamilien kontrollieren. RFC 9099 beschäftigt sich ausführlich mit den betrieblichen Sicherheitsfragen moderner IPv6-Netze und macht deutlich, dass IPv6-Security weit über die Perimeter-Firewall hinausgeht.

First-Hop-Security, Neighbor Discovery, Router Advertisements, Adressierungsstrategien, DNS, Extension Header, Fragmentierung, Tunneling und Monitoring gehören ebenfalls zum Gesamtbild. Ein Unternehmen kann deshalb eine hervorragende IPv6-Firewall besitzen und trotzdem Sicherheitslücken im lokalen Netzwerk oder in seinen Betriebsprozessen haben. Security ist auch unter IPv6 keine Produkteigenschaft. Sie entsteht aus Architektur, Konfiguration, Überwachung und Kompetenz.

Wer ist eigentlich für IPv6 verantwortlich?

Damit kommen wir zu einem organisatorischen Problem, das technisch kaum zu lösen ist. Wer trägt in einem Unternehmen die Verantwortung für IPv6, solange offiziell noch gar kein IPv6-Projekt existiert?

Das Netzwerkteam könnte argumentieren, dass IPv6 produktiv nicht geroutet wird. Das Serverteam verweist darauf, dass es lediglich die Standardeinstellungen des Betriebssystems verwendet. Das Client-Team hat IPv6 nicht bewusst aktiviert. Das Security-Team überwacht primär die dokumentierte Netzwerkarchitektur.

Jede einzelne Aussage kann nachvollziehbar sein. Zusammen können sie jedoch dazu führen, dass eine vorhandene Protokollwelt niemandem wirklich gehört. Genau deshalb sollte IPv6 bereits vor einer eigentlichen Migration Bestandteil von Netzwerk- und Security-Governance sein. Eine Organisation muss wissen, ob IPv6 vorhanden ist, wo es verwendet wird, welche Mechanismen zugelassen sind, welche unterbunden werden sollen und wer für diese Entscheidungen verantwortlich ist.

Nicht eingesetztes IPv6 muss ebenfalls gemanagt werden

Daraus ergibt sich eine zunächst paradox klingende Konsequenz: Auch ein Unternehmen, das IPv6 noch nicht produktiv einsetzen möchte, benötigt eine IPv6-Strategie. Diese Strategie kann durchaus festlegen, dass bestimmte IPv6-Kommunikation derzeit nicht erwünscht ist. Sie kann Tunnelmechanismen unterbinden, unerwünschte Router Advertisements filtern und den Einsatz von IPv6 an Netzwerkgrenzen einschränken.

Aber diese Entscheidungen müssen bewusst getroffen, technisch umgesetzt und überwacht werden. ‚Wir haben kein IPv6‘ ist keine Strategie. ‚Wir haben untersucht, wo IPv6 vorhanden ist, und kontrollieren gezielt, welche Kommunikation wir zulassen‘ dagegen schon. Dieser Unterschied ist aus Security-Sicht erheblich.

IPv6 ist nicht das Sicherheitsproblem

Damit sollten wir zum Abschluss einen verbreiteten Fehlschluss vermeiden. IPv6 ist nicht grundsätzlich unsicherer als IPv4. Auch die NSA kommt in ihrer Sicherheitsbetrachtung zu keinem solchen Ergebnis. Viele Sicherheitsprobleme ähneln denen von IPv4. Unterschiede entstehen durch neue Mechanismen, andere Betriebsmodelle, die zusätzliche Angriffsfläche während Dual Stack und vor allem durch mangelnde Erfahrung in Umgebungen, die sich noch in der Transition befinden.

Das ist eigentlich wenig überraschend. Wir haben mehrere Jahrzehnte Erfahrung darin gesammelt, IPv4-Netze abzusichern. Best Practices entstanden, Hersteller verbesserten ihre Produkte, Administrator:innen lernten aus Fehlkonfigurationen und Security-Teams entwickelten Regeln für bekannte Angriffsmuster.

IPv6 muss denselben betrieblichen Reifeprozess durchlaufen – und vielerorts hat es das längst getan. Das eigentliche Risiko entsteht dort, wo Unternehmen IPv6 zwar technisch besitzen, organisatorisch aber weiterhin so handeln, als existiere es nicht. Ein Protokoll, das wir kennen, dokumentieren, überwachen und absichern, können wir beherrschen. Ein Protokoll, das vorhanden ist, aber niemand beachtet, kann zum blinden Fleck werden. Vielleicht lautet die entscheidende Security-Frage deshalb gar nicht: ‚Ist IPv6 sicher?‘, sondern: ‚Sind wir darauf vorbereitet, IPv6 genauso professionell abzusichern wie IPv4?‘

Warum Unternehmen trotzdem zögern

Nach unserer bisherigen Betrachtung könnte man zu einem einfachen Schluss kommen. IPv4-Adressen sind knapp. IPv6 existiert seit Jahrzehnten. Moderne Betriebssysteme unterstützen es selbstverständlich. Provider, Mobilfunknetze und Cloud-Plattformen setzen es produktiv ein. Die technischen Verfahren für Migration und Koexistenz sind standardisiert. Also los.

Doch so einfach funktionieren Unternehmensentscheidungen nicht. Denn es gibt nicht das eine technische Problem, das Unternehmen von einer IPv6-Migration abhält. Stattdessen treffen mehrere Faktoren aufeinander: gewachsene Infrastrukturen, Legacy-Systeme, fehlende Erfahrung, Herstellerabhängigkeiten, Investitionskosten, Betriebsrisiken und eine IPv4-Welt, die trotz aller historischen Prognosen weiterhin erstaunlich zuverlässig funktioniert. Genau diese Kombination macht IPv6 zu einer besonderen Transformationsaufgabe.

Das vielleicht größte Problem: IPv4 funktioniert

Beginnen wir mit dem offensichtlichsten Argument. IPv4 funktioniert.

Unternehmen betreiben damit ihre Clients, Server, Rechenzentren und Standorte. Anwendungen kommunizieren zuverlässig. Administrator:innen kennen die Infrastruktur. Monitoring und Security sind darauf abgestimmt. NAT und private Adressbereiche haben den öffentlichen Adressmangel für viele interne Unternehmensnetze über Jahrzehnte beherrschbar gemacht.

Das ist aus technischer Sicht eine bemerkenswerte Erfolgsgeschichte. Für IPv6 entsteht daraus allerdings ein Problem: Die neue Technologie konkurriert nicht mit einem ausgefallenen Vorgänger. Sie konkurriert mit einer etablierten Infrastruktur, die ihre Aufgabe weiterhin erfüllt. Ein Unternehmen muss deshalb nicht begründen, warum es IPv4 weiterbetreibt. Häufig muss vielmehr das IPv6-Projekt begründen, warum etwas verändert werden soll.

Legacy ist nicht automatisch schlechte IT

Dann gibt es die Systeme, die wir gerne unter dem Begriff Legacy zusammenfassen. Das klingt schnell nach hoffnungslos veralteter Technik, die längst hätte ersetzt werden müssen. Die betriebliche Realität ist häufig wesentlich differenzierter.

Bei klassischer Arbeitsplatz-IT sind wir vergleichsweise kurze Lebenszyklen gewohnt. Ein Desktop-PC wird nach einigen Jahren ersetzt, ein Betriebssystem aktualisiert und eine Anwendung durch eine neuere Version abgelöst. In Produktionsumgebungen gelten dagegen andere Zeitmaßstäbe. Eine Industrieanlage kann mit erheblichen Investitionskosten verbunden sein und über Jahrzehnte produktiv betrieben werden. Solange sie zuverlässig arbeitet und ihren Zweck erfüllt, gibt es aus wirtschaftlicher Sicht möglicherweise überhaupt keinen vernünftigen Grund, sie nur wegen einer veralteten IT-Komponente zu ersetzen. Die Lebensdauer der Maschine und die Lebensdauer der darin verbauten IT können damit vollkommen unterschiedliche Größenordnungen besitzen.

Wenn die Maschine länger lebt als ihr Betriebssystem

Besonders problematisch wird es, wenn sich beide Komponenten technisch nicht voneinander trennen lassen. Eine Produktionsanlage kann beispielsweise von einem PC gesteuert werden, dessen Betriebssystem längst aus dem regulären Support gefallen ist. Vielleicht benötigt die Steuerungssoftware eine bestimmte Windows-Version. Vielleicht funktioniert eine spezielle Erweiterungskarte nur mit einem alten Treiber. Vielleicht kommuniziert die Anlage über proprietäre Schnittstellen oder eine Anwendung, deren Hersteller längst keine aktuelle Version mehr anbietet.

Dann lautet die Lösung eben nicht: ‚Installieren wir einfach ein aktuelles Windows.‘ Mitunter lässt sich die IT einer solchen Anlage überhaupt nicht sinnvoll modernisieren, ohne gleichzeitig die Funktionsfähigkeit oder Herstellerfreigabe der gesamten Anlage infrage zu stellen. Dasselbe gilt für die Netzwerkkommunikation. Wenn eine solche Steuerung ausschließlich IPv4 beherrscht, wird aus der IPv6-Migration plötzlich keine Frage der richtigen Routerkonfiguration mehr. Die eigentliche Frage lautet: Wie integrieren wir ein System in eine moderne Netzwerkarchitektur, dessen Lebenszyklus noch nicht beendet ist, dessen IT-Architektur aber aus einer vollkommen anderen technologischen Epoche stammt?

Mein persönlicher Windows-NT-Haken

In Seminaren erzähle ich dazu gelegentlich von einer kleinen gedanklichen Liste, die ich inzwischen führe. Eigentlich würde ich gerne irgendwann einen Haken hinter den Satz setzen: ‚Windows NT 4.0 habe ich endgültig zum letzten Mal produktiv gesehen.‘ Für 2025 konnte ich diesen Haken noch immer nicht setzen. Vielleicht klappt es ja 2026.

Dahinter steckt aber eine ernsthafte Beobachtung: Windows NT 4.0 erschien 1996. Wenn mir ein solches System fast drei Jahrzehnte später noch in einer produktiven Umgebung begegnet, liegt das normalerweise nicht daran, dass jemand beschlossen hat, eine aktuelle Büroanwendung darauf zu installieren. Solche Systeme existieren häufig weiter, weil sie Bestandteil eines größeren technischen oder geschäftlichen Zusammenhangs sind, dessen Lebenszyklus wesentlich länger ist als der eines gewöhnlichen IT-Systems.

Abschreibung und Lebenszyklus bestimmen mit

Damit bekommt Legacy zusätzlich eine wirtschaftliche Dimension. Eine Anlage, in die ein Unternehmen erhebliche Summen investiert hat, wird nicht ausgetauscht, weil eine einzelne integrierte Komponente technologisch nicht mehr dem aktuellen Stand entspricht. Investitionszyklen, Abschreibungen, Ersatzteilversorgung, Wartungsverträge und die erwartete Restnutzungsdauer spielen ebenfalls eine Rolle.

Eine mehrere Millionen Euro teure Produktionsanlage gegen eine neue auszutauschen, nur weil ihre Steuerung kein IPv6 beherrscht, wäre offensichtlich kaum ein überzeugender Business Case. Stattdessen muss die Netzwerkarchitektur mit dieser Realität umgehen.

Das kann bedeuten, solche Systeme zu segmentieren, ihre Kommunikationsmöglichkeiten gezielt einzuschränken oder IPv4 in bestimmten Bereichen weiterhin bereitzustellen. Später werden wir sehen, dass genau daraus ein interessantes Architekturmodell entstehen kann: IPv4 muss nicht zwangsläufig überall erhalten bleiben, nur weil einzelne Legacy-Systeme weiterhin darauf angewiesen sind.

Legacy ist eine Abhängigkeit, keine moralische Kategorie

Deshalb sollten wir den Begriff Legacy nicht mit mangelnder Modernisierungsbereitschaft gleichsetzen. Natürlich gibt es technische Altlasten, die tatsächlich längst hätten beseitigt werden sollen. Es gibt aber ebenso Systeme, deren Weiterbetrieb wirtschaftlich vollkommen rational ist.

Ein Embedded System benötigt vielleicht weiterhin IPv4. Eine Fachanwendung verarbeitet nur IPv4-Adressen. Eine Produktionssteuerung läuft auf einem längst abgekündigten Betriebssystem. Und eine Industrieanlage besitzt möglicherweise noch viele Jahre wirtschaftliche Restlebensdauer. Legacy bedeutet deshalb nicht zwangsläufig, dass eine Organisation ihre IT schlecht gepflegt hat. Es bedeutet häufig schlicht, dass unterschiedliche Technologien vollkommen unterschiedliche Lebenszyklen besitzen. Für die IPv6-Migration ist genau das entscheidend. Wir können die Zukunft des Unternehmensnetzes planen – aber wir können nicht voraussetzen, dass jede Komponente gleichzeitig in dieser Zukunft ankommt.

Eine Anwendung ist selten allein

Hinzu kommen Abhängigkeiten. Eine Anwendung läuft auf einem Betriebssystem, kommuniziert mit einer Datenbank, verwendet DNS, greift auf Verzeichnisdienste zu, wird durch eine Firewall geschützt, über einen Load Balancer veröffentlicht und von Monitoring- und Security-Systemen überwacht. Jede einzelne Komponente kann IPv6 unterstützen. Entscheidend ist jedoch, ob die gesamte Kommunikationskette damit zuverlässig funktioniert.

Dazu kommen Hersteller und Dienstleister. Unterstützt die aktuelle Version IPv6 vollständig? Gilt das auch für alle benötigten Funktionen? Ist die Konfiguration offiziell supportet? Funktionieren Drittanbieter-Plug-ins und Schnittstellen? Was geschieht bei einem Fehler? Damit wird aus der vermeintlich einfachen Frage ‚Kann unsere Anwendung IPv6?‘ eine wesentlich größere: ‚Können wir den gesamten Geschäftsprozess unter IPv6 mit derselben Verfügbarkeit und demselben Support betreiben wie heute unter IPv4?‘

Know-how lässt sich nicht einschalten

Auch das notwendige Wissen muss vorhanden sein. Wir haben bereits gesehen, wie stark Jahrzehnte praktischer Erfahrung den IPv4-Betrieb geprägt haben. Administrator:innen kennen typische Fehlerbilder, Sicherheitsverantwortliche haben Regeln entwickelt und Ausbilder:innen vermitteln Technologien, die im betrieblichen Alltag benötigt werden.

IPv6 lässt sich technisch vergleichsweise schnell aktivieren. Betriebserfahrung entsteht dagegen nicht über Nacht. Ein Seminar kann Grundlagen vermitteln und Labore können wichtige Szenarien vorbereiten. Die Sicherheit, mit der erfahrene Administrator:innen ein komplexes IPv4-Problem beurteilen, entsteht jedoch erst durch praktische Arbeit.

Damit entsteht erneut unser Henne-Ei-Problem: Unternehmen zögern mit IPv6, weil praktische Erfahrung fehlt. Praktische Erfahrung entsteht aber nur begrenzt, solange IPv6 kaum produktiv eingesetzt wird. Technologie lässt sich bereitstellen. Erfahrung muss wachsen.

Dann kommt die Frage nach den Kosten

Spätestens jetzt verlassen wir die rein technische Diskussion. Eine IPv6-Migration benötigt Arbeitszeit. Netzwerke müssen analysiert, Adresskonzepte entwickelt, Systeme inventarisiert, Anwendungen getestet, Firewall-Regeln angepasst, Monitoring erweitert und Mitarbeiter qualifiziert werden. Vielleicht müssen Router, Switches, Firewalls oder andere Komponenten aktualisiert oder ersetzt werden. Software benötigt möglicherweise eine neue Version. Externe Dienstleister werden eingebunden.

Und während Administrator:innen an der IPv6-Migration arbeiten, erledigen sie andere Aufgaben nicht.

Damit entstehen neben direkten Investitionen auch Opportunitätskosten. Das IPv6-Projekt konkurriert schließlich mit anderen Vorhaben: Security-Projekten, Cloud-Migrationen, neuen Anwendungen, Betriebssystem-Upgrades, Automatisierung, KI-Initiativen oder ganz gewöhnlicher technischer Schuld. Ein Budget kann nur einmal ausgegeben werden. Dasselbe gilt für Arbeitszeit.

Und was haben wir anschließend davon?

Damit erreichen wir die vermutlich schwierigste Frage des gesamten IPv6-Business-Cases. Stellen wir uns erneut die Präsentation vor der Geschäftsführung oder IT-Leitung vor. Wir haben erklärt, warum IPv6 technisch sinnvoll ist. Wir haben Kosten kalkuliert, Risiken bewertet und einen realistischen Migrationsplan entwickelt.

Dann kommt die Frage: ‚Was haben wir davon?‘

Darauf gibt es gute strategische Antworten. IPv6 reduziert langfristig die Abhängigkeit vom knappen IPv4-Adressraum. Adressierung lässt sich großzügiger und strukturierter planen. Überschneidende private IPv4-Adressräume können insbesondere bei Fusionen, Cloud-Anbindungen oder komplexen Standortvernetzungen problematisch werden. NAT-Abhängigkeiten können reduziert und moderne IPv6-first- beziehungsweise IPv6-only-Architekturen vorbereitet werden.

Das sind relevante Vorteile. Doch die ehrliche kurzfristige Antwort kann in einem klassischen Unternehmensnetz trotzdem ernüchternd ausfallen: Wenn die Migration erfolgreich abgeschlossen ist, funktioniert hinterher im Idealfall alles wieder genauso zuverlässig wie vorher.

Das ist ein schwieriger Business Case

Genau hier unterscheidet sich IPv6 von vielen anderen IT-Investitionen. Ein schnelleres Storage-System kann messbar mehr Leistung liefern. Eine neue Anwendung ermöglicht neue Geschäftsprozesse. Automatisierung reduziert Arbeitsaufwand. Eine neue Security-Lösung adressiert ein konkretes Risiko.

Bei einer IPv6-Migration ist der unmittelbare sichtbare Nutzen häufig schwieriger zu vermitteln. Niemand arbeitet automatisch schneller, weil ein Server eine IPv6-Adresse besitzt. Eine Fachanwendung erhält dadurch nicht plötzlich neue Funktionen. Kund:innen bestellen nicht mehr Produkte, nur weil die Kommunikation über 128 statt 32 Bit adressiert wird.

Dagegen sind die Kosten sehr konkret. Und auch die Risiken sind konkret. Die Kosten entstehen heute, viele Vorteile dagegen erst langfristig. Die Risiken der Veränderung sind unmittelbar sichtbar, die Risiken des Nichtstuns bleiben zunächst abstrakt. Aus Sicht einer IT-Leitung ist Zurückhaltung unter diesen Bedingungen nicht irrational.

Betriebsrisiko schlägt technische Eleganz

Hinzu kommt eine grundlegende Veränderung der Unternehmens-IT. Netzwerke sind heute geschäftskritische Infrastruktur. Wenn eine Migration Probleme verursacht, betrifft das nicht mehr nur einige experimentierfreudige Administrator:innen. Produktionssysteme können ausfallen, Cloud-Dienste unerreichbar werden oder Mitarbeiter nicht mehr arbeiten. Entsprechend konservativ werden grundlegende Infrastrukturänderungen bewertet.

Ein Architekturdiagramm kann überzeugend zeigen, warum IPv6 langfristig die elegantere Lösung ist. Für den operativen Betrieb zählt jedoch zunächst eine andere Eigenschaft: Es muss funktionieren. Und zwar nicht nur im Labor, sondern am Montagmorgen um 9 Uhr, wenn mehrere tausend Mitarbeiter arbeiten möchten. Damit besitzt der bekannte Zustand einen erheblichen Vorteil: Seine Probleme sind bekannt.

Auch Hersteller bestimmen das Migrationstempo

Unternehmen können außerdem nicht jede Abhängigkeit selbst kontrollieren. Eine Organisation kann strategisch IPv6 einführen wollen und trotzdem auf einen Hersteller angewiesen sein, dessen Produkt bestimmte Funktionen nur über IPv4 unterstützt. Das haben wir bereits bei meinem eigenen Heimnetz im Kleinen gesehen: Die Aussage ‚Das Gerät unterstützt IPv6‘ bedeutet noch lange nicht, dass jede benötigte IPv6-Funktion in der vorhandenen Produktklasse zur Verfügung steht.

In Unternehmen vervielfacht sich dieses Problem. Netzwerkkomponenten, Security Appliances, Managementsysteme, Fachanwendungen, IoT-Geräte und externe Dienste besitzen unterschiedliche Lebenszyklen und Entwicklungsstände. Damit wird IPv6 auch zu einer Frage des Lieferanten- und Lifecycle-Managements. Nicht jedes Hindernis lässt sich durch eine bessere Konfiguration beseitigen.

Niemand bekommt Ärger, weil IPv4 heute funktioniert

Dazu kommt ein organisatorischer Mechanismus, über den in technischen Diskussionen erstaunlich selten gesprochen wird. Veränderung erzeugt Verantwortung. Wer ein großes IPv6-Projekt initiiert, muss Budget beantragen, Entscheidungen treffen und Risiken vertreten. Kommt es während der Migration zu Problemen, lässt sich häufig ziemlich genau sagen, welches Projekt die Veränderung ausgelöst hat. Wer dagegen das bestehende IPv4-Netz weiterbetreibt und damit einen zuverlässigen Betrieb gewährleistet, trifft zunächst die risikoärmere Entscheidung.

Oder zugespitzt: Für ein funktionierendes IPv4-Netz muss sich heute kaum jemand rechtfertigen. Für ein gescheitertes IPv6-Projekt möglicherweise schon. Das beeinflusst Entscheidungen. Nicht aus Technikfeindlichkeit, sondern weil Organisationen Risiken, Verantwortlichkeiten und Anreize besitzen.

Aus Vorsicht kann organisatorische Trägheit werden

Problematisch wird diese rationale Vorsicht erst dann, wenn sie zum dauerhaften Zustand wird. Heute gibt es eine Legacy-Anwendung. Nächstes Jahr steht ein großes Cloud-Projekt an. Danach muss die Firewall erneuert werden. Anschließend fehlt das Budget. Und irgendwann geht die Person in den Ruhestand, die das Thema ursprünglich vorantreiben wollte.

Jede einzelne Verschiebung kann nachvollziehbar sein. In ihrer Summe entsteht jedoch organisatorische Trägheit. Genau hier ist die verhaltenswissenschaftliche Perspektive interessant. Menschen und Organisationen bevorzugen häufig den Weg mit dem geringsten unmittelbaren Widerstand. Solange IPv4 mit NAT gut genug funktioniert, verlangt IPv6 zunächst zusätzliche Arbeit, ohne zwangsläufig einen sofort sichtbaren Vorteil zu erzeugen. Das bestehende System besitzt damit einen mächtigen Verbündeten: Gewohnheit.

Das Problem ist nicht fehlende Einsicht

Damit wäre es zu einfach, Unternehmen mangelndes Verständnis für IPv6 vorzuwerfen. Viele Administrator:innen wissen längst, dass IPv6 relevant ist. Sie haben Schulungen besucht, Zertifizierungen absolviert und technische Konzepte entwickelt. IT-Verantwortliche kennen die langfristige Problematik des IPv4-Adressraums ebenfalls.

Wissen führt jedoch nicht automatisch zu Umsetzung. Entscheidend ist, ob eine Organisation Budget, Zeit, Personal, Herstellerunterstützung und einen ausreichend starken Anlass besitzt, die Veränderung tatsächlich durchzuführen. Vielleicht erklärt genau das einen erheblichen Teil der jahrzehntelangen IPv6-Geschichte: Das technische Problem war bekannt. Die technische Lösung war vorhanden. Was häufig fehlte, war der unmittelbare wirtschaftliche Zwang, sie einzusetzen.

Wann verändert sich die Rechnung?

Damit sollten wir IPv6 vielleicht nicht ausschließlich danach beurteilen, welchen zusätzlichen Nutzen eine Migration heute gegenüber einem funktionierenden IPv4-Netz erzeugt. Interessanter wird die Frage, wie lange die bisherige Rechnung noch gilt.

• Was kostet die Beschaffung oder Nutzung knapper öffentlicher IPv4-Adressen?
• Welchen Aufwand verursachen NAT und überlappende private Adressräume?
• Wie lange müssen Dual-Stack-Infrastrukturen parallel betrieben werden?
• Welche Anforderungen stellen Cloud-Plattformen, Provider und neue Anwendungen?
• Wie viel Aufwand entsteht dadurch, eine immer stärker IPv6-geprägte Außenwelt weiterhin an eine primär IPv4-geprägte interne Infrastruktur anzubinden?

Dann verschiebt sich der Business Case. Die Frage lautet nicht mehr ausschließlich: ‚Was kostet uns die Einführung von IPv6?‘ Sie bekommt eine zweite Hälfte: ‚Was kostet es uns langfristig, an IPv4 festzuhalten?‘ Und möglicherweise ist genau dieser Perspektivwechsel entscheidend. IPv6 musste über Jahrzehnte einen Business Case gegen eine abgeschriebene, bekannte und funktionierende IPv4-Infrastruktur gewinnen. Vielleicht beginnt sich diese Rechnung erst dann grundlegend zu verändern, wenn nicht mehr die Migration zu IPv6, sondern der weitere Betrieb von IPv4 zur technisch und wirtschaftlich aufwendigeren Sonderlösung wird.

Die Perspektive dreht sich: IPv6-only statt IPv4-Migration

Über weite Strecken dieses Beitrags haben wir IPv6 aus einer bestimmten Perspektive betrachtet. Wir besitzen ein funktionierendes IPv4-Netz. Nun möchten wir IPv6 hinzufügen. Also prüfen wir Router und Switches, erweitern Firewall-Regeln, ergänzen Monitoring, testen Anwendungen und betreiben schließlich beide Protokolle parallel.

Diese Denkweise ist vollkommen nachvollziehbar. Für ein über Jahrzehnte gewachsenes Unternehmensnetz ist sie häufig sogar der einzig realistische Ausgangspunkt. Doch sie enthält eine Annahme, die wir bislang kaum hinterfragt haben: IPv4 bleibt das bestehende Netz – und IPv6 muss sich darin seinen Platz suchen. Was geschieht, wenn wir diese Perspektive umdrehen?

Was würden wir heute auf der grünen Wiese bauen?

Stellen wir uns vor, wir müssten keine bestehende Infrastruktur migrieren. Keine jahrzehntealten Anwendungen. Keine historischen Adresspläne. Keine Firewall-Regeln aus längst vergangenen Projekten. Keine Geräte, deren Managementschnittstelle ausschließlich IPv4 versteht. Wir planen ein vollkommen neues Netzwerk.

Müssen wir dort wirklich wieder IPv4 und IPv6 parallel einführen? Oder tun wir das hauptsächlich deshalb, weil wir Dual Stack inzwischen als den selbstverständlichen Weg einer IPv6-Migration betrachten? Gerade in einer Greenfield-Umgebung lässt sich eine andere Frage stellen: Warum sollten wir zwei Protokollwelten betreiben, wenn eine davon für die neue Infrastruktur möglicherweise gar nicht mehr benötigt wird?

Damit verändert sich die Ausgangslage. Wir fragen nicht länger: ‚Wie bringen wir IPv6 in unser IPv4-Netz?‘, sondern: ‚Wo benötigen wir IPv4 überhaupt noch?‘

IPv6-only bedeutet nicht: Das IPv4-Internet verschwindet

Der Begriff IPv6-only kann zunächst radikaler klingen, als das Konzept tatsächlich ist. Ein IPv6-only-Client besitzt auf dem betreffenden Netzwerkpfad keine reguläre IPv4-Konnektivität. Das bedeutet jedoch nicht zwangsläufig, dass dieser Client keine IPv4-basierten Dienste mehr erreichen kann. Genau dafür wurden Übersetzungs- und Übergangsmechanismen entwickelt.

Das grundlegende Architekturprinzip lautet: Das eigentliche Netzwerk arbeitet mit IPv6. IPv4-Kompatibilität wird nur noch dort bereitgestellt, wo sie tatsächlich benötigt wird. Damit wird IPv4 von einem gleichberechtigten Protokoll der gesamten Infrastruktur zu einem Kompatibilitätsdienst. Das ist ein fundamentaler Perspektivwechsel.

NAT64 übersetzt zwischen den Welten

Einer der zentralen Bausteine dafür ist NAT64. Stateful NAT64 wurde in RFC 6146 spezifiziert. Vereinfacht betrachtet sitzt dabei ein Übersetzer zwischen einer IPv6- und einer IPv4-Welt. Ein IPv6-only-Client kann über diesen Translator mit einem IPv4-Server kommunizieren. Der NAT64-Gateway übersetzt die entsprechenden IPv6- und IPv4-Pakete und verwaltet bei Stateful NAT64 die dafür notwendigen Zustände.

Damit benötigt der Client selbst keine native IPv4-Konnektivität mehr. Das IPv4-Netz wird gewissermaßen an den Rand der IPv6-Infrastruktur verschoben. Interessant ist dabei die historische Umkehrung. Bei klassischem NAT haben wir IPv4 so angepasst, dass viele interne Systeme mit wenigen öffentlichen IPv4-Adressen auskommen konnten.

Mit NAT64 verwenden wir Übersetzung nun dazu, eine IPv6-Infrastruktur weiterhin mit der verbliebenen IPv4-Welt kommunizieren zu lassen. Die Übersetzung dient nicht mehr primär dazu, IPv4 am Leben zu halten. Sie ermöglicht vielmehr, IPv4 aus Teilen der eigentlichen Infrastruktur zu entfernen.

DNS64 macht IPv4-Ziele für IPv6 erreichbar

NAT64 allein löst allerdings noch nicht die Frage, wie ein IPv6-only-Client ein Ziel findet, das im DNS ausschließlich über einen A-Record und damit über eine IPv4-Adresse veröffentlicht wird. Hier kommt DNS64 ins Spiel. RFC 6147 beschreibt einen Mechanismus, mit dem aus einem vorhandenen A-Record ein synthetischer AAAA-Record erzeugt werden kann.

Für den IPv6-only-Client sieht das Ziel damit zunächst wie ein IPv6-Ziel aus. Die synthetisierte IPv6-Adresse enthält die notwendigen Informationen, damit der Verkehr zum NAT64-System gelangt und dort in Richtung des eigentlichen IPv4-Servers übersetzt werden kann. DNS64 und NAT64 arbeiten damit zusammen: Der Client kommuniziert über IPv6. Das interne Netzwerk transportiert IPv6. Erst dort, wo die IPv4-Welt tatsächlich erreicht werden muss, findet die Übersetzung statt. IPv4 wird nicht mehr durch das gesamte Netzwerk mitgeführt, nur weil irgendwo am Ende eines Kommunikationspfades noch ein IPv4-System existiert.

Aber Anwendungen kennen manchmal weiterhin IPv4

Die Realität wäre allerdings ungewöhnlich einfach, wenn jede Anwendung ausschließlich über DNS-Namen kommunizieren würde. Manche Programme erwarten weiterhin IPv4-Adressen. Andere verwenden IPv4-spezifische APIs oder erhalten von Anwendungen direkt eine IPv4-Adresse, ohne dass zuvor eine DNS-Auflösung stattfindet. Damit stößt eine reine Kombination aus DNS64 und NAT64 an Grenzen. Auch dafür existieren Lösungen.

464XLAT hilft IPv4-Anwendungen im IPv6-only-Netz

464XLAT, beschrieben in RFC 6877, kombiniert zwei Übersetzungsschritte. Der Namensbestandteil XLAT steht dabei schlicht für Translation. Die Bezeichnung 464XLAT beschreibt damit bereits vereinfacht den Weg der Kommunikation: von IPv4 zu IPv6 und anschließend wieder von IPv6 zu IPv4.

Auf der Seite des Clients beziehungsweise nahe am Client arbeitet der CLAT (Customer-side Translator). Er nimmt IPv4-Kommunikation einer Anwendung entgegen und übersetzt sie stateless in IPv6. Für eine Anwendung kann dadurch weiterhin eine IPv4-Kommunikationsmöglichkeit vorhanden sein, obwohl das darunterliegende Zugangsnetz selbst ausschließlich IPv6 transportiert.

Auf der Netzseite befindet sich der PLAT (Provider-side Translator). Er übernimmt die zustandsbehaftete Übersetzung zwischen der IPv6-Infrastruktur und dem weiterhin über IPv4 erreichbaren Ziel. Funktional entspricht diese Seite der Architektur einem Stateful-NAT64-System.

Vereinfacht lässt sich der Kommunikationsweg damit so darstellen: IPv4-Anwendung → CLAT → IPv6-Netz → PLAT → IPv4-Ziel.

Der Name 464XLAT wird damit wesentlich verständlicher: Die IPv4-Kommunikation wird zunächst in die IPv6-Welt übersetzt und am anderen Ende bei Bedarf wieder in die IPv4-Welt zurückgeführt. Das klingt zunächst nach zusätzlicher Komplexität. Der entscheidende Punkt ist jedoch, wo diese Komplexität liegt.

Das eigentliche Zugangsnetz kann weiterhin IPv6-only betrieben werden. Trotzdem können Anwendungen funktionieren, die noch von IPv4 ausgehen. Die Anwendung muss dabei nicht zwangsläufig selbst wissen, dass ihre Kommunikation zwischenzeitlich über eine reine IPv6-Infrastruktur transportiert wird.

Gerade für Mobilfunknetze war dieses Prinzip von großer Bedeutung. Dort treffen enorme Mengen von Endgeräten auf einen begrenzten IPv4-Adressraum, während gleichzeitig Anwendungen weiter funktionieren müssen, die nicht vollständig für eine reine IPv6-Umgebung entwickelt wurden. Die Legacy-Kompatibilität wird damit an definierten Stellen bereitgestellt, anstatt die gesamte Infrastruktur dauerhaft als Dual Stack betreiben zu müssen.

Das Smartphone zeigt, dass dieses Modell funktioniert

Damit begegnen wir erneut einem interessanten Gegensatz zwischen Unternehmens-IT und unserem Alltag. Für viele Benutzer:innen ist vollkommen irrelevant, welche IP-Version ein Smartphone im Mobilfunknetz gerade verwendet. Eine App soll funktionieren. Eine Webseite soll laden. Nachrichten sollen ankommen. Die darunterliegende Infrastruktur kann dabei längst wesentlich stärker auf IPv6 ausgerichtet sein, als es die Benutzer:innen wahrnehmen.

Genau solche Umgebungen zeigen einen wichtigen Unterschied zur klassischen Enterprise-Migration. Mobilfunkanbieter mussten Netzwerke für eine enorme Zahl von Geräten skalieren. Öffentliche IPv4-Adressen für jedes einzelne Endgerät bereitzustellen, wäre kein besonders attraktives Architekturmodell. Damit war der wirtschaftliche Anreiz für IPv6 wesentlich unmittelbarer als in einem Unternehmen, dessen RFC-1918-Netze hinter NAT seit Jahrzehnten zuverlässig funktionieren. Wo IPv4 selbst zum Skalierungsproblem wird, verändert sich der Business Case für IPv6 grundlegend.

Cloud-native verändert die Ausgangslage ebenfalls

Eine ähnliche Überlegung lässt sich auf moderne Cloud- und Rechenzentrumsarchitekturen übertragen. Neue virtuelle Netzwerke, Containerplattformen, Microservices und automatisiert bereitgestellte Infrastruktur entstehen nicht zwangsläufig unter denselben Bedingungen wie ein Unternehmens-LAN, dessen Adressplan vor zwanzig Jahren entwickelt wurde.

Gerade bei neuen Architekturen lohnt deshalb die Frage, ob IPv4 tatsächlich noch als selbstverständlicher Bestandteil jedes Netzwerksegments benötigt wird. Das bedeutet keineswegs, dass jede Cloud-native-Anwendung automatisch IPv6-only betrieben werden sollte. Anwendungen, Plattformen, Security-Produkte und angebundene Dienste müssen die geplante Architektur vollständig unterstützen.

Der entscheidende Unterschied liegt vielmehr in der Planungsrichtung: IPv4 wird nicht mehr automatisch vorausgesetzt. Seine Notwendigkeit muss begründet werden. Damit wird aus einer IPv6-Migrationsentscheidung eine Architekturentscheidung.

IPv4 as a Service

Für diesen Perspektivwechsel existiert inzwischen sogar ein ausgesprochen passender Begriff: IPv4-as-a-Service, kurz IPv4aaS. RFC 8585 beschreibt IPv4aaS als Transitionstechnologien, mit denen IPv4 über IPv6-only-Konnektivität bereitgestellt werden kann.

Allein diese Bezeichnung ist bemerkenswert. Über Jahrzehnte war IPv4 die Infrastruktur. IPv6 war das zusätzliche Protokoll, der Tunnel, die Transitionstechnologie oder das langfristige Migrationsziel. IPv4aaS dreht diese Rollen um. IPv6 bildet die eigentliche Konnektivität. IPv4 wird zu einem Dienst für die Fälle, in denen Legacy-Systeme oder IPv4-only-Ziele weiterhin darauf angewiesen sind.

Damit lässt sich IPv4 gezielter behandeln. Nicht jedes VLAN, jeder Client und jede Anwendung benötigt automatisch beide Protokolle. IPv4 kann dort bereitgestellt werden, wo eine dokumentierte technische Abhängigkeit besteht.

Das erinnert konzeptionell an viele andere Legacy-Technologien. Wir betreiben schließlich auch nicht mehr jedes moderne Unternehmensnetz mit IPX/SPX, nur weil irgendwo eine historische Anwendung existieren könnte.

IPv4 on demand

RFC 8925 führt diesen Gedanken noch einen Schritt weiter. Mit der DHCPv4-Option IPv6-Only Preferred können entsprechend geeignete Hosts signalisieren, dass sie ohne eine IPv4-Adresse arbeiten können. In einem solchen Szenario wird IPv6 zum Normalfall, während IPv4 nur noch den Systemen bereitgestellt werden muss, die tatsächlich darauf angewiesen sind. Das RFC verwendet dafür einen bemerkenswerten Begriff: IPv4 on demand.

Damit verändert sich die Logik erneut. Heute fragen wir häufig: ‚Welche Systeme können bereits ohne IPv4 betrieben werden?‘ Eine zukünftige Infrastruktur könnte stattdessen fragen: ‚Welches System benötigt noch IPv4 – und warum?‘ Der Unterschied klingt sprachlich klein, architektonisch ist er gewaltig.

Aus der Migration wird eine Abschichtung

Damit entsteht auch für bestehende Unternehmensnetze eine interessante langfristige Strategie. Das Ziel muss nicht darin bestehen, an einem bestimmten Wochenende IPv4 im gesamten Unternehmen abzuschalten. Eine realistischere Entwicklung kann schrittweise erfolgen. Neue Netzwerkbereiche werden IPv6-first oder IPv6-only geplant. Moderne Anwendungen und Dienste benötigen kein natives IPv4 mehr. Bestehende IPv4-Abhängigkeiten werden dokumentiert und bestimmten Bereichen zugeordnet. Übersetzungsmechanismen stellen bei Bedarf die Kommunikation mit IPv4-only-Systemen sicher.

Legacy-Anwendungen können weiterhin funktionieren. Aber sie bestimmen nicht mehr zwangsläufig die Architektur des gesamten Netzes. IPv4 verschwindet damit nicht auf einen Schlag. Sein Einflussbereich wird kleiner. Aus einer großen Migration wird eine kontrollierte Abschichtung.

Das verändert auch unseren Umgang mit Legacy

Damit können wir einen Gedanken aus dem vorherigen Kapitel wieder aufnehmen. Die jahrzehntealte Produktionsanlage muss nicht plötzlich IPv6 lernen. Vielleicht wird sie das niemals tun. Das bedeutet aber nicht zwangsläufig, dass deshalb auch alle neuen Clients, Server, Cloud-Workloads und Netzwerksegmente weiterhin IPv4 benötigen.

Stattdessen kann IPv4 dort erhalten bleiben, wo die Abhängigkeit tatsächlich besteht. Das ist ein wichtiger Unterschied. Ein Legacy-System darf Legacy bleiben, ohne dass deshalb die gesamte Infrastruktur ebenfalls Legacy bleiben muss. Gerade für langlebige Industrieanlagen könnte diese Trennung langfristig wesentlich realistischer sein als die Erwartung, irgendwann sämtliche vorhandenen Systeme gleichzeitig IPv6-fähig zu machen.

Auch IPv6-only ist kein Selbstzweck

Bei aller Begeisterung für den Perspektivwechsel sollten wir allerdings nicht in dieselbe Falle geraten, die wir zuvor bei IPv4 kritisiert haben. IPv6-only ist nicht automatisch die richtige Architektur, nur weil sie moderner klingt. NAT64, DNS64 und 464XLAT erzeugen ebenfalls Abhängigkeiten. Anwendungen müssen getestet, Security-Konzepte angepasst, Monitoring aufgebaut und Fehlerbilder verstanden werden.

Auch Übersetzung ist Komplexität. Die entscheidende Frage lautet deshalb nicht: ‚Wie werden wir IPv4 möglichst schnell los?‘, sondern: ‚Welche Protokolle benötigen wir für welche Dienste tatsächlich – und welche Architektur reduziert langfristig unsere Abhängigkeiten und unseren Betriebsaufwand?‘ In manchen Bereichen kann die Antwort weiterhin Dual Stack lauten. In anderen IPv6-only mit NAT64 und DNS64. Und bei bestimmten Legacy-Systemen möglicherweise noch lange IPv4. Eine gute Architektur muss diese Unterschiede zulassen.

Vielleicht migrieren wir am Ende gar nicht zu IPv6

Damit verändert sich rückblickend sogar der Begriff IPv6-Migration. Migration klingt nach einem klaren Ausgangspunkt und einem klaren Ziel: Wir verlassen IPv4 und wechseln zu IPv6. Die Realität könnte wesentlich unspektakulärer aussehen. IPv6 breitet sich weiter aus. Neue Systeme benötigen IPv4 immer seltener. Alte Abhängigkeiten werden isoliert. Übersetzungsmechanismen halten verbliebene IPv4-Dienste erreichbar. Irgendwann existiert IPv4 nur noch in bestimmten Segmenten oder als bereitgestellter Kompatibilitätsdienst.

Und eines Tages stellt vielleicht jemand bei einer Netzwerkmodernisierung fest: ‚Warum betreiben wir diesen IPv4-Bereich eigentlich noch?‘ Damit hätten wir den Perspektivwechsel vollständig vollzogen. Über Jahrzehnte lautete die Frage: ‚Wie bringen wir IPv6 in unser IPv4-Netz?‘ Für die nächste Phase der Internetarchitektur könnte die wesentlich interessantere Frage lauten: ‚Wo benötigen wir IPv4 überhaupt noch?‘ Vielleicht besteht die eigentliche IPv6-Migration deshalb langfristig gar nicht darin, IPv6 überall zusätzlich einzuschalten. Vielleicht besteht sie darin, IPv4 nur noch dort bereitzustellen, wo es tatsächlich noch gebraucht wird.

Der Weg ins Unternehmensnetz

Nach den bisherigen Kapiteln könnte der Eindruck entstehen, eine IPv6-Einführung sei ein gewaltiges Transformationsprojekt, bei dem ein Unternehmen gleichzeitig Netzwerk, Anwendungen, Security, Monitoring und jahrzehntelang gewachsene Betriebsprozesse umbauen muss. Das wäre vermutlich der sicherste Weg, das Projekt niemals zu beginnen. Eine sinnvolle IPv6-Strategie muss nicht mit einem unternehmensweiten Rollout starten. Sie beginnt wesentlich unspektakulärer: mit Wissen über die eigene Infrastruktur, klaren Architekturentscheidungen und der Frage, an welchen Stellen IPv4 heute tatsächlich noch benötigt wird.

Dabei geht es zunächst nicht darum, einen Abschalttermin für IPv4 festzulegen. Das erste Ziel einer IPv6-Strategie sollte nicht sein, IPv4 möglichst schnell loszuwerden. Das erste Ziel sollte darin bestehen, die eigenen IPv4-Abhängigkeiten zu verstehen und keine neuen unnötigen mehr zu schaffen.

Zuerst müssen wir wissen, was wir haben

Am Anfang steht deshalb eine Bestandsaufnahme. Welche Netzwerkkomponenten unterstützen IPv6 tatsächlich in den benötigten Funktionen? Welche Betriebssysteme und Anwendungen sind vorhanden? Welche Provider stellen bereits IPv6 bereit? Welche öffentlichen Dienste besitzen AAAA-Records? Wo verwenden Systeme fest konfigurierte IPv4-Adressen? Welche Skripte, Schnittstellen oder Datenbanken gehen implizit von IPv4 aus? Und im Sinne der IT-Security gehört noch eine weitere Frage zwingend dazu: Wo findet bereits heute IPv6-Kommunikation statt, obwohl die Organisation davon ausgeht, noch kein IPv6 einzusetzen?

Eine solche Bestandsaufnahme muss deshalb über klassische Hardwareinventarisierung hinausgehen. Router, Switches und Firewalls sind nur ein Teil des Bildes. DNS, DHCP, IPAM, Load Balancer, VPN, Remote Access, Monitoring, SIEM, Automatisierung, Cloud-Anbindungen und Anwendungen gehören ebenfalls zur Betrachtung. Damit entsteht zunächst kein Migrationsplan. Es entsteht etwas viel Wertvolleres: Transparenz.

‚Unterstützt IPv6‘ ist keine ausreichende Antwort

Dabei begegnet uns erneut eine Erkenntnis aus den vorherigen Kapiteln. Ein Datenblatt mit dem Eintrag IPv6 Support beantwortet nur einen kleinen Teil der eigentlichen Frage. Unterstützt ein Layer-3-Switch die benötigten IPv6-Routingfunktionen? Beherrscht die Firewall dieselben Security-Funktionen für IPv6 wie für IPv4? Können Access-Switches First-Hop-Security wie RA Guard umsetzen? Verarbeitet das Monitoring IPv6-Adressen korrekt? Unterstützt eine Anwendung IPv6 offiziell oder funktioniert sie lediglich zufällig damit?

Entscheidend ist deshalb nicht: ‚Kann das Produkt IPv6?‘, sondern: ‚Kann das Produkt unter IPv6 genau die Funktion erfüllen, für die wir es in unserer Architektur benötigen?‘ Gerade bei langlebiger Infrastruktur und unterschiedlichen Lizenz- oder Produktklassen kann zwischen beiden Aussagen ein erheblicher Unterschied liegen.

Know-how sollte vor dem Rollout entstehen

Parallel zur technischen Bestandsaufnahme muss Wissen aufgebaut werden. Administrator:innen sollten IPv6 nicht erst dann kennenlernen, wenn die ersten produktiven Störungen auftreten. Dazu gehören selbstverständlich Adressierung, Präfixe, Neighbor Discovery, Router Advertisements, SLAAC und DHCPv6. Für den produktiven Betrieb kommen Routing, DNS, Firewalling, First-Hop-Security, Troubleshooting und Monitoring hinzu.

Noch wichtiger ist jedoch praktische Erfahrung. Ein Labor ist dafür ein guter Anfang. Testnetze, virtuelle Umgebungen oder bewusst ausgewählte Pilotsegmente ermöglichen es, typische Abläufe und Fehlerbilder kennenzulernen, ohne unmittelbar geschäftskritische Systeme zu gefährden.

Damit verändert sich auch die Wahrnehmung. IPv6 ist irgendwann nicht mehr das neue Protokoll, über das wir einmal ein Seminar besucht haben, sondern eine Technologie, mit der Administrator:innen tatsächlich gearbeitet haben. Betriebssicherheit entsteht nicht allein durch Standards und Dokumentation. Sie entsteht auch durch Erfahrung.

IPv6 gehört früh in die betrieblichen Werkzeuge

Eine weitere Lehre aus den vorherigen Kapiteln lautet, IPv6 nicht auf Router und Clients zu reduzieren. Bevor größere Bereiche produktiv migriert werden, sollte IPv6 in den Werkzeugen ankommen, mit denen das Netzwerk betrieben wird. Das betrifft insbesondere DNS und IPAM. IPv6-Präfixe, Adressen und Namensauflösung sollten genauso geplant und dokumentiert werden wie die vorhandene IPv4-Infrastruktur.

Dasselbe gilt für Monitoring und Security. Logs müssen IPv6-Adressen verarbeiten können. Dashboards müssen entsprechende Kommunikation sichtbar machen. Firewall-Regeln, IDS und IPS, SIEM-Korrelationen und gegebenenfalls SOAR-Playbooks dürfen IPv6 nicht als Sonderfall behandeln.

Das Ziel lautet dabei nicht, sofort jedes bestehende Werkzeug umzubauen. Es geht zunächst darum, Lücken zu identifizieren. IPv6 sollte nicht schneller in das produktive Netzwerk gelangen, als die Organisation in der Lage ist, es zu dokumentieren, zu überwachen, abzusichern und im Fehlerfall zu analysieren.

Pilotsegmente schaffen Erfahrung

Ist diese Grundlage vorhanden, bieten sich bewusst ausgewählte Pilotbereiche an. Dabei muss der erste produktive IPv6-Einsatz nicht ausgerechnet das kritischste Rechenzentrumssegment umfassen. Ein abgegrenztes Client-Netz, ein Teststandort, ein neues WLAN, ein Entwicklungsbereich oder eine neu aufgebaute Infrastruktur kann wesentlich geeigneter sein. Wichtig ist, dass der Pilot nicht lediglich beweist, dass ein Client eine IPv6-Adresse erhalten und eine Webseite öffnen kann.

Ein guter Pilot bildet den späteren Betrieb ab. DNS muss funktionieren. Routing muss nachvollziehbar sein. Firewall-Regeln müssen greifen. Monitoring muss Fehler erkennen. Logs müssen im SIEM erscheinen. Administrator:innen müssen typische Störungen diagnostizieren können. Erst dann beantwortet ein Pilot die eigentlich relevante Frage: Können wir IPv6 nicht nur einschalten, sondern auch betreiben?

Greenfield und Brownfield dürfen unterschiedlich behandelt werden

Dabei sollten Unternehmen nicht versuchen, alle Bereiche mit derselben Strategie zu behandeln. Ein seit zwanzig Jahren gewachsenes Produktionsnetz besitzt andere Voraussetzungen als ein neu eingerichteter Standort. Ein Rechenzentrum mit Legacy-Anwendungen unterscheidet sich von einer neuen Cloud-Umgebung.

Damit begegnen uns erneut Greenfield und Brownfield. Im Brownfield kann Dual Stack eine ausgesprochen sinnvolle Übergangsstrategie sein. Bestehende Anwendungen behalten IPv4, während IPv6 schrittweise eingeführt und getestet wird. Bei einem Greenfield-Projekt sollte dagegen zumindest die Frage erlaubt sein, ob Dual Stack tatsächlich noch notwendig ist. Nicht jede bestehende Umgebung kann IPv6-only werden. Aber nicht jede neue Umgebung muss deshalb erneut mit einer dauerhaften IPv4-Abhängigkeit beginnen. Dieser Unterschied kann langfristig entscheidend sein.

Dual Stack gezielt statt automatisch

Dual Stack bleibt damit ein wichtiges Werkzeug. Problematisch wird es erst, wenn aus dem Werkzeug automatisch die Zielarchitektur wird. Für jeden Bereich sollte deshalb klar sein, warum beide Protokolle benötigt werden und welche Voraussetzungen erfüllt sein müssen, damit IPv4 später wieder entfernt werden kann. Vielleicht benötigt eine bestimmte Fachanwendung weiterhin IPv4. Dann ist das eine dokumentierbare Abhängigkeit. Vielleicht verlangt ein Hersteller für ein Managementsystem IPv4. Auch das lässt sich erfassen.

Weniger überzeugend wäre dagegen: ‚Wir lassen IPv4 einfach überall an. Es stört ja nicht.‘ Denn damit übernimmt die Organisation dauerhaft die Kosten und Komplexität zweier Protokollwelten. Dual Stack sollte dort eingesetzt werden, wo es die Migration erleichtert – nicht dort, wo niemand entschieden hat, ob IPv4 überhaupt noch benötigt wird.

Aus Anwendungen werden Abhängigkeitsketten

Bei der Analyse sollten deshalb nicht nur einzelne Systeme mit den Kategorien IPv6-fähig oder nicht IPv6-fähig versehen werden. Entscheidend sind Kommunikationsbeziehungen. Welche Anwendung spricht mit welchem Dienst? Welche Datenbank wird benötigt? Welche externen APIs werden aufgerufen? Welche Managementsysteme greifen auf das Gerät zu? Welche Backup-, Monitoring- und Security-Komponenten hängen daran?

Damit entsteht schrittweise eine Karte der tatsächlichen IPv4-Abhängigkeiten. Das ist auch für die langfristige Architektur wertvoll. Denn erst wenn bekannt ist, warum IPv4 an einer bestimmten Stelle benötigt wird, lässt sich entscheiden, wie lange diese Abhängigkeit bestehen muss und ob sie durch Modernisierung, Übersetzung oder Isolation reduziert werden kann.

Neubeschaffungen sind der vielleicht wichtigste Hebel

Eine der wirkungsvollsten Maßnahmen benötigt zunächst überhaupt keine Migration. Unternehmen können verhindern, dass heute neue IPv4-Abhängigkeiten entstehen. IPv6-Unterstützung sollte deshalb Bestandteil von Architekturvorgaben, Ausschreibungen und Beschaffungsprozessen sein. Dabei genügt erneut kein Haken hinter IPv6 capable. Gefordert werden müssen die Funktionen, die für den geplanten Einsatz tatsächlich notwendig sind: Routing, Management, Security, Monitoring, APIs, Hochverfügbarkeit oder andere produktspezifische Anforderungen.

Auch Anwendungen sollten keine unnötigen IPv4-Annahmen mehr einführen. Datenmodelle, Schnittstellen und Automatisierungen sollten IP-Adressen grundsätzlich adressfamilienneutral verarbeiten können. Das ist wirtschaftlich interessant, weil damit ein Teil der Transformation in ohnehin stattfindende Lifecycle-Prozesse verlagert wird. Nicht jedes IPv4-System muss heute ersetzt werden. Aber sein zukünftiger Nachfolger sollte nicht dieselbe Abhängigkeit erneut für die nächsten zehn oder zwanzig Jahre festschreiben. Gerade bei den langlebigen Industrieanlagen aus dem vorherigen Kapitel ist dieser Gedanke wichtig.

Lifecycle statt Big Bang

Damit lässt sich die IPv6-Einführung stärker mit ohnehin notwendigen Modernisierungen verbinden.

• Eine Firewall wird ersetzt?
  Dann wird die IPv6-Security-Architektur mit betrachtet.
• Ein neuer Standort entsteht?
  Dann wird geprüft, ob sämtliche Segmente tatsächlich noch IPv4 benötigen.
• Eine Anwendung erhält eine neue Hauptversion?
  Dann gehört IPv6-Kompatibilität in die Abnahmekriterien.
• Ein IPAM-System wird eingeführt oder erneuert?
  Dann muss es beide Adressfamilien gleichwertig verwalten können.
• Ein neuer Providervertrag wird abgeschlossen?
  Dann gehört die IPv6-Konnektivität in die Anforderungen.

So entsteht kein spektakulärer IPv6-Tag, an dem plötzlich das gesamte Unternehmen migriert wird. Stattdessen verändert sich die Infrastruktur mit jedem Lifecycle-Schritt ein wenig. IPv6 wird damit weniger zu einem zusätzlichen Großprojekt und stärker zu einem Architekturprinzip für ohnehin stattfindende Veränderungen.

IPv4-Abhängigkeiten bekommen ein Verfallsdatum

Besonders interessant finde ich dabei einen organisatorischen Ansatz: Eine erkannte IPv4-Abhängigkeit sollte nicht einfach als unveränderliche Tatsache dokumentiert werden. Sie sollte einen Grund besitzen. Ein verantwortliches System oder einen Prozess. Und einen Zeitpunkt, zu dem sie erneut bewertet wird.

Das bedeutet nicht, einer zwanzig Jahre alten Produktionsanlage willkürlich ein Abschaltdatum zu geben. Wenn sie noch zehn Jahre benötigt wird, ist das eine legitime technische Rahmenbedingung. Aber dann wissen wir zumindest, warum an dieser Stelle IPv4 weiterlebt.

Das ist etwas vollkommen anderes als ein Unternehmensnetz, in dem IPv4 überall erhalten bleibt, weil niemand mehr weiß, welche Systeme tatsächlich darauf angewiesen sind. Aus einem historischen Zustand wird damit eine bewusst verwaltete Abhängigkeit.

IPv4 schrittweise aus der Normalität nehmen

Damit schließt sich der Kreis. Das langfristige Ziel muss nicht lauten: ‚Am 1. Januar 2030 schalten wir IPv4 ab.‘ Wesentlich realistischer ist eine schrittweise Veränderung der Normalität. Neue Systeme müssen ihre IPv4-Abhängigkeit begründen. Neue Netze werden nicht automatisch Dual Stack geplant. Bestehende IPv4-only-Anwendungen werden dokumentiert. Legacy-Bereiche können isoliert werden. Übersetzungsmechanismen stellen bei Bedarf IPv4-Konnektivität bereit.

Mit jedem modernisierten System kann der Bereich kleiner werden, in dem IPv4 tatsächlich notwendig ist. Irgendwann verändert sich damit auch die organisatorische Fragestellung. Heute muss häufig IPv6 seinen Nutzen begründen. In einer zukünftigen Architektur könnte IPv4 diese Rolle übernehmen: ‚Warum benötigt dieses System eigentlich noch IPv4?‘

Keine Migration um der Migration willen

Bei all dem sollte IPv6 kein Selbstzweck werden. Ein Unternehmen gewinnt nichts dadurch, einen möglichst frühen Termin für die Abschaltung von IPv4 zu veröffentlichen. Entscheidend sind eine tragfähige Architektur, ein sicherer Betrieb und die langfristige Reduzierung unnötiger Komplexität. Manche Legacy-Systeme werden deshalb noch lange IPv4 verwenden. Andere Bereiche können Dual Stack benötigen. Neue Infrastrukturen können möglicherweise bereits IPv6-only entstehen und verbliebene IPv4-Dienste über geeignete Transitionsmechanismen erreichen.

Eine gute Strategie lässt diese unterschiedlichen Geschwindigkeiten zu. Der Weg zu IPv6 besteht deshalb nicht darin, das gesamte Unternehmen gleichzeitig zu migrieren. Er besteht darin, bei jeder technischen Veränderung die Abhängigkeit von IPv4 ein Stück weniger selbstverständlich werden zu lassen. Vielleicht ist das auch die pragmatischste Antwort auf die Frage, warum IPv6 nach drei Jahrzehnten noch immer nicht überall angekommen ist. Wir müssen nicht auf den Tag warten, an dem das letzte IPv4-System abgeschaltet wird. Wir können damit beginnen, heute keine unnötigen neuen IPv4-Abhängigkeiten mehr für die nächsten Jahrzehnte zu schaffen.

Fazit – vielleicht war IPv6 nie die Zukunft

Wir haben diesen Beitrag mit einem scheinbaren Widerspruch begonnen. IPv6 existiert seit drei Jahrzehnten. Moderne Betriebssysteme unterstützen es selbstverständlich. Provider stellen IPv6-Konnektivität bereit. Mobilfunknetze nutzen IPv6 in großem Maßstab. Cloud-Plattformen unterstützen moderne IPv6-Architekturen. Standards für den Betrieb von IPv6-only-Netzen und die verbleibende IPv4-Kompatibilität existieren längst.

Und trotzdem begegnet uns in Unternehmensnetzen weiterhin erstaunlich viel IPv4. Nach unserer Reise durch mehr als vier Jahrzehnte Internetgeschichte erscheint dieser Widerspruch allerdings wesentlich weniger rätselhaft. IPv4 ist nicht deshalb noch da, weil IPv6 technisch gescheitert wäre. IPv4 ist noch da, weil IPv4 ausgesprochen erfolgreich war.

Der Erfolg von IPv4 wurde zum Hindernis seiner Ablösung

IPv4 hat eine technologische Entwicklung getragen, deren Ausmaß bei seiner Spezifikation 1981 kaum vorhersehbar war. Als seine Grenzen sichtbar wurden, reagierte die Internet-Community. CIDR verbesserte die Nutzung des Adressraums und die Skalierbarkeit des Routings. Private Adressbereiche und NAT reduzierten den unmittelbaren Bedarf an öffentlichen IPv4-Adressen erheblich. Anwendungen, Router, Firewalls und ganze Betriebsmodelle lernten, mit dieser Architektur umzugehen.

Aus Übergangslösungen wurden Standards des Alltags. Aus Standards wurde Erfahrung. Aus Erfahrung entstanden Prozesse. Und aus diesen Prozessen entwickelte sich schließlich eine Betriebskultur. Je erfolgreicher IPv4 wurde, desto schwieriger wurde seine Ablösung.

Vielleicht ist das die eigentliche Ironie dieser Geschichte. Die Maßnahmen, mit denen wir die Grenzen von IPv4 über Jahrzehnte beherrschbar machten, gaben gleichzeitig genau der Technologie Zeit, die IPv6 eines Tages ersetzen sollte.

Technische Schulden können ausgesprochen zuverlässig funktionieren

Dabei wäre es zu einfach, Unternehmen mangelnden Modernisierungswillen vorzuwerfen. Ein funktionierendes IPv4-Netz besitzt einen erheblichen wirtschaftlichen Vorteil: Es existiert bereits. Die Infrastruktur ist bezahlt. Administrator:innen kennen sie. Anwendungen funktionieren. Monitoring und Security sind darauf abgestimmt. Betriebsprozesse wurden über Jahre optimiert.

Demgegenüber verursacht eine IPv6-Migration zunächst Aufwand. Mitarbeiter:innen müssen qualifiziert, Systeme überprüft, Anwendungen getestet und Sicherheitskonzepte erweitert werden. Vielleicht müssen sogar Komponenten ersetzt werden.

Und wenn alles hervorragend läuft? Dann funktioniert das Netzwerk anschließend zuverlässig. So wie vorher. Genau darin liegt der schwierige Business Case. Die Kosten der Veränderung sind unmittelbar sichtbar. Die Kosten des Festhaltens am Bestehenden entstehen dagegen häufig langsam und verteilt.

Trotzdem hat sich die Welt verändert

Während Unternehmen darüber diskutierten, wann der richtige Zeitpunkt für IPv6 gekommen sei, entwickelte sich die Infrastruktur weiter. IPv6 wurde Bestandteil moderner Betriebssysteme. Provider führten es ein. Mobilfunknetze mussten enorme Mengen von Endgeräten adressieren. Smartphones kommunizieren über Netze, deren technische Details ihre Besitzer:innen weder kennen noch kennen müssen.

Meine Mutter startet ihre FRITZ!Box neu, wenn Netflix nicht funktioniert. Ob der Film anschließend über IPv4 oder IPv6 übertragen wird, ist ihr vollkommen egal. Und eigentlich ist genau das ein Zeichen erfolgreicher Infrastruktur. Das beste Netzwerk ist für seine Benutzer:innen häufig das Netzwerk, über dessen Existenz sie nicht nachdenken müssen. Vielleicht suchen wir deshalb nach einem sichtbaren Moment der IPv6-Einführung, den es in dieser Form niemals geben wird.

Vielleicht haben wir auf den falschen Tag gewartet

Bei früheren technologischen Umbrüchen lassen sich manchmal klare Zeitpunkte benennen. Am 1. Januar 1983 stellte das ARPANET auf TCP/IP um. Ein solcher Flag Day besitzt eine wunderbare historische Eindeutigkeit: vorher und nachher.

Für IPv6 wird es diesen einen Tag vermutlich niemals geben. Das Internet ist dafür längst zu groß, zu heterogen und zu wichtig geworden. Stattdessen findet die Veränderung schleichend statt.

• Ein Provider stellt ein IPv6-Präfix bereit
• Ein Betriebssystem bevorzugt unter geeigneten Bedingungen IPv6
• Ein DNS-Server liefert einen AAAA-Record
• Eine Anwendung kommuniziert über IPv6
• Ein Mobilfunknetz wird IPv6-only und stellt verbliebene IPv4-Kompatibilität über 464XLAT bereit
• Ein neues Unternehmenssegment benötigt vielleicht irgendwann gar kein natives IPv4 mehr

Keiner dieser Schritte allein ist die IPv6-Migration. Zusammen sind sie es möglicherweise längst.

Aus der Zukunft wird Gegenwart

Damit sollten wir vielleicht auch aufhören, IPv6 ausschließlich als Zukunftstechnologie zu betrachten. Natürlich gibt es weiterhin Unternehmensnetze, in denen IPv6 kaum bewusst genutzt wird. Es existieren Legacy-Anwendungen, Geräte und ganze Architekturen, die noch lange IPv4 benötigen werden.

Das widerspricht unserer These nicht. Denn eine Technologie muss nicht ihren Vorgänger vollständig verdrängt haben, um Gegenwart zu sein. Cloud Computing wurde nicht erst relevant, nachdem das letzte lokale Rechenzentrum abgeschaltet war. Elektromobilität begann nicht erst mit dem letzten Verbrennungsmotor. Und IPv6 beginnt nicht erst an dem Tag, an dem die letzte IPv4-Adresse aus dem letzten Unternehmensnetz verschwindet. IPv6 ist keine Technologie, auf deren Einführung die IT-Branche noch wartet. Diese Einführung findet längst statt – und in vielen Bereichen ist sie bereits erfolgt. Was hinterherhinkt, ist mitunter weniger die Technik als unsere Wahrnehmung davon.

Erfahrung bleibt wichtig – aber ihre Aufgabe verändert sich

Damit kommen wir noch einmal zu den Menschen zurück, die diese Infrastruktur betreiben. IPv4-Erfahrung verliert durch IPv6 nicht ihren Wert. Im Gegenteil. Wer Routing versteht, wird Routing auch unter IPv6 besser verstehen. Wer Netzwerkarchitekturen geplant, Migrationen begleitet und Produktionsausfälle erlebt hat, bringt eine Erfahrung mit, die sich nicht durch das Lesen einiger RFCs ersetzen lässt.

Aber Erfahrung verändert ihre Funktion. Sie darf nicht ausschließlich erklären, warum wir etwas weiterhin so machen sollten wie bisher. Sie kann ebenso helfen zu beurteilen, welche Prinzipien weiterhin gelten und welche Gewohnheiten wir hinterfragen müssen. Vielleicht besteht lebenslanges Lernen in der IT genau darin. Nicht alle paar Jahre das bisherige Wissen wegzuwerfen, sondern bereit zu sein, mit sehr viel Erfahrung trotzdem wieder etwas Neues lernen zu müssen. Erfahrung verliert nicht ihren Wert. Aber sie verändert ihre Funktion.

Vielleicht wird irgendwann IPv4 erklärungsbedürftig

Noch heute lautet in vielen Unternehmen die Frage: ‚Warum brauchen wir IPv6?‘ Das ist angesichts der vorhandenen Infrastruktur eine vollkommen legitime Frage. Doch vielleicht verändert sich ihre Richtung bereits. Wenn neue Netze IPv6-only geplant werden können, Cloud- und Mobilfunkinfrastrukturen IPv6 selbstverständlich nutzen und IPv4 über NAT64, 464XLAT oder andere IPv4-as-a-Service-Mechanismen nur noch dort bereitgestellt wird, wo es tatsächlich benötigt wird, entsteht eine andere Ausgangslage.

Dann lautet die Frage irgendwann nicht mehr: ‚Warum brauchen wir IPv6?‘, sondern: ‚Warum braucht dieses System eigentlich noch IPv4?‘ Für die jahrzehntealte Produktionsanlage kann es darauf eine sehr gute Antwort geben. Für die neue Anwendung, den neuen Standort oder die nächste Generation der Netzwerkinfrastruktur vielleicht nicht mehr. Und genau an diesem Punkt wird aus einer Migration ein Architekturwandel.

Vielleicht war IPv6 nie die Zukunft

Damit kommen wir zurück zum Titel dieses Kapitels: Vielleicht war IPv6 nie die Zukunft. Zumindest nicht in dem Sinne, dass irgendwo vor uns ein Zeitpunkt liegt, an dem die Welt geschlossen von IPv4 auf IPv6 umschaltet. Diese Vorstellung stammt möglicherweise noch aus einer Zeit, in der wir Protokollwechsel als klar abgegrenzte Migrationen verstanden haben.

Die tatsächliche Geschichte verläuft anders. IPv4 verschwindet nicht plötzlich, sein Einflussbereich wird kleiner. IPv6 erscheint nicht plötzlich, sein Einflussbereich wird größer. Dazwischen liegen Dual Stack, Übersetzung, Legacy-Systeme, Cloud-Dienste, Mobilfunknetze, Betriebskultur, wirtschaftliche Entscheidungen und sehr viele kleine technische Veränderungen.

Vielleicht werden wir deshalb eines Tages zurückblicken und feststellen, dass es den großen Moment der IPv6-Migration niemals gegeben hat. Weil wir ihn währenddessen längst erlebt haben. Der entscheidende Schritt besteht deshalb vielleicht gar nicht darin, endlich mit IPv6 zu beginnen. Sondern darin, zu akzeptieren, dass wir längst damit begonnen haben.

Quellenangaben

(Abgerufen am 29.08.2026)

• Grundlagen, Standardisierung und Entwicklung von IPv4 und IPv6

  • ARIN: The History of IPv6 @ ARIN
  • Bob Hinden, Steve E. Deering (IETF): IPNG (ipngwg)
  • Partridge, F. Kastenholz (IETF): RFC 1726 – Technical Criteria for Choosing IP The Next Generation (IPng)
  • Fioccola, P. Volpato, J. Palet Martinez. G. Mishra, C. Xie (IETF): RFC 9386 – IPv6 Deployment Status
  • Arkko, M. Townsley (IETF): RFC 6127 – IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios
  • Jon Postel (IETF): RFC 791 – Internet Protocol
  • Srisuresh, M. Holdrege (IETF): RFC 2663 – IP Network Address Translator (NAT) Terminology and Considerations
  • Carlson, D. Ficarella (IETF): RFC 1705 – Six Virtual Inches to the Left: The Problem with IPng
  • Gilligan, E. Nordmark (IETF): RFC 1933 – Transition Mechanisms for IPv6 Hosts and Routers
  • Bradner, A. Mankin (IETF): RFC 1752 – The Recommendation for the IP Next Generation Protocol
  • Deering, R. Hinden (IETF): RFC 1883 – Internet Protocol, Version 6 (IPv6) Specification
  • Deering, R. Hinden (IETF): RFC 2460 – Internet Protocol, Version 6 (IPv6) Specification
  • Deering, R. Hinden (IETF): RFC 8200 – Internet Protocol, Version 6 (IPv6) Specification
  • Thomson, T. Narten,T. Jinmei (IETF): RFC 4862 – IPv6 Stateless Address Autoconfiguration
  • Narten, E. Nordmark, W. Simpson, H. Soliman (IETF): RFC 4861 – Neighbor Discovery for IP version 6 (IPv6)
  • Fuller, T. Li, J. Yu, K. Varadhan (IETF): RFC 1519 – Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy
  • Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear (IETF): RFC 1918 – Address Allocation for Private Internets
  • Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi (IETF): RFC 4241 – A Model of IPv6/IPv4 Dual Stack Internet Access Service

  IPv5 und die Entwicklung zu IPng

  • Cisco Learning Network: What happened to IPv5?
  • Lutz Donnerhacke (IETF): IPv5 -- The missing transition step
  • Lutz Donnerhacke: IPv5 - das fehlende Verbindungsstück zwischen IPv4 und IPv6

  IPv4-Adressknappheit und Adressverwaltung

  • AFRINIC: AFRINIC IPv4 Exhaustion
  • APNIC: IPv4 exhaustion
  • Heise: Reservierte IPv4-Adressen
  • IANA: Number Resources
  • ICANN: Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA
  • ICANN: Remaining IPv4 Addresses to be Redistributed to Regional Internet Registries | Address Redistribution Signals that IPv4 is Nearing Total Exhaustion
  • Michael Eckert (ComputerWeekly): RFC 1918 (Adresszuweisung für private Internets)
  • Nawaz Dhandala (OneUptime): How to Understand IPv4 Address Exhaustion
  • Philipp Richter (TU Berlin): Empirical analysis of the effects and the mitigation of IPv4 address exhaustion
  • RIPE NCC: What is IPv4 Run Out?

  NAT, Dual Stack und IPv6-Übergangsmechanismen

  • Alejandro Acosta (LACNIC): Transition Mechanism IPv4 -> IPv6 (PDF-Datei)
  • Cisco: Understand and Configure NAT64
  • Boucadair (IETF): RFC 7225 – Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)
  • David Prall (Cisco): IPv6 in 2025 – Transitioning to IPv6
  • Internet Society: Case Study: T-Mobile US Goes IPv6-only Using 464XLAT
  • Jen Linkova (APNIC): Let’s talk about IPv6 DNS64 & DNSSEC
  • Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum (IETF): RFC 6147 – DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
  • Bagnulo, P. Matthews, I. van Beijnum (IETF): RFC 6146 – Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
  • Mawatari, M. Kawashima, C. Byrne (IETF): 464XLAT: Combination of Stateful and Stateless Translation
  • Mawatari, M. Kawashima, C. Byrne (IETF): RFC 6877 – 464XLAT: Combination of Stateful and Stateless Translation
  • Nawaz Dhandala (OneUptime): How to Set Up NAT64 and DNS64 for IPv6-Only Networks
  • Nawaz Dhandala (OneUptime): How to Understand 464XLAT for IPv6-Only Mobile Networks

  IPv6 in Betriebssystemen, Anwendungen und Unternehmensumgebungen

  • Andreas Kroschel (WindowsPro): IPv6 abschalten oder konfigurieren
  • Cisco: CCNA: Introduction to Networks
  • Cisco: IPv6 Deployment Guide
  • Cisco: IPv6 Neighbor Discovery
  • Internet Society: Frequently Asked Questions (FAQ) on IPv6 Adoption and IPv4 Exhaustion
  • Internet Society: IPv6
  • Microsoft Learn: About Teredo
  • Microsoft Learn: Additional IPv6 Topics
  • Microsoft Learn: Guidance for configuring IPv6 in Windows for advanced users
  • Microsoft Learn: Internet Protocol version 6 (IPv6) overview
  • Microsoft Learn: IPv6 support in Microsoft 365 services
  • Microsoft Learn: IPv6 support in Microsoft Entra ID
  • RIPE NCC Academy: IPv6 Fundamentals

  IPv6-Sicherheit und First-Hop-Security

  • Apple: IPv6 security
  • Bundesamt für Sicherheit in der Informationstechnik: IPv6: Nutzen, Fallstricke und Lösungen
  • Cisco: IPv6 RA Guard (PDF-Datei)
  • David Holder (APNIC): Common misconceptions about IPv6 security
  • É. Vyncke, K. Chittimaneni, M. Kaeo, E. Rey (IETF): RFC 9099 – Operational Security Considerations for IPv6 Networks
  • Gont (IETF): RFC 7113 – Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
  • Johannes Weber (RIPE): IPv6 Security - An Overview
  • Marco Roth (FHNW): Cybersecurity: Sicherheit und Schwachstellen von IPv6
  • National Security Agency: IPv6 Security Guidance (PDF-Datei)
  • Nawaz Dhandala (OneUptime): How to Understand IPv6 Security Threats and Attack Vectors
  • Ralf Spenneberg (Linux-Magazin): Was Admins über das Sicherheitskonzept von IPv6 wissen sollten
  • Ryan Harris (This Bridge is the Root): Using RA Guard to block man-in-the-middle attacks in IPv6
  • Stefan Luber (Security-Insider): Was ist NDP (Neighbor Discovery Protocol)?
  • Tal Kollender (Remedio): The Truth About IPv6 Security: Separating Fact from Fiction

  IPv6-only und IPv4 as a Service

  • Internet Society: Case Study: T-Mobile US Goes IPv6-only Using 464XLAT
  • Jordi Palet Martínez (RIPE): IPv6-only? IPv4-as-a-service?

  IPv6-Verbreitung, Messungen und Trends

  • APNIC: IPv6 Measurement Maps
  • César Diáz (LACNIC): From IPv5 to IPv6: A Leap That Changed the Internet
  • Google: IPv6 – Google Statistics
  • Internet Society: The data we need to build the Internet we want
  • Mat Ford (Internet Society): 18 Years Later, IPv6 Reaches Majority
  • NIST: Estimating IPv6 & DNSSEC External Service Deployment Status
  • RIPE NCC: IPv6 Statistics and Tools
  • World IPv6 Launch: Measurements

  Technologieadoption und organisatorische Perspektiven

  • Jolita Puzakova (IPXO): The IPv6 Paradox: Why the Internet’s Future Protocol Remains in Transition
  • Lauren Ballejos, Übersetzung: Sila Willsch (NinjaOne): Wie Sie Ihren Computer unter Windows von IPv4 auf IPv6 umstellen
  • Nick Buraglio (APNIC): Three reasons why IPv6 is worth the effort
  • Terry Sweetser (Internet Society): Why IPv6 Adoption is Stalled: The Behavioral Science Behind Internet Infrastructure Change

  Historische Analysen und wissenschaftliche Einordnung

  • Jan Pascal van Best: IPv6 standardisation issues (HTTP-Link)
  • Lixia Zhang (UCLA): A Retrospective View of Network Address Translation (PDF-Datei)
  • Rahmat M. Samik-Ibrahim: The Long and Windy ROAD (IPv6)
  • Robert M. Hinden (ACM Digital Library): IP Next Generation Overview (PDF-Datei)

  Fachmedien und ergänzende Einordnungen

  • Ansley Adrian Moyo (Medium): IPv6, why has it not taken over yet?
  • Aviral Srivastava (DEV Community): IPv6 Transition Mechanisms (NAT64/DNS64)
  • Dusan Zivadinovic (Heise): IETF 95: Streit um Gnadenschuss für IPv4
  • Heficed (Medium): IP Address Evolution: IPv4 vs. IPv6. Has Ipv5 Gone Missing?
  • Nermin Smajic (Medium): IPv6 Security and Comparisons with IPv4
  • Scott Bolen (Medium): Why IPv6 Keeps Getting Hacked and How to Avoid, Mitigate, and Resolve
  • Sebastian Grüner (Golem): Internetstandards sollen kein IPv4 mehr können

  Weiterlesen hier im Blog

  • Adresswelten im Wandel – der strukturierte Einstieg in TCP/IPv6
  • ARPANET, TCP/IP und das World Wide Web – Wie das Internet die Welt vernetzte
  • Externes Routing im Internet und WAN – Architektur, Historie und Bedeutung von BGP
  • Wenn die Computerkommunikation intelligent wird – Zukunftsarchitekturen, IPv6 und KI im modernen Netzdesign
  • Wenn Netzwerke intelligent werden: Wie KI, Wi-Fi 7 und Ethernet die Infrastruktur neu definieren
  • Wenn Router Entscheidungen treffen – Routingprotokolle im Cisco-Netzwerk verstehen