IPv6 – Wer hat Angst vor langen IP-Adressen?

Nachdem ich ja in einigen Posts nunmehr beschrieben habe wie man sich einen eigenen DNS-Server unter Docker mit samt IPv6 hinstellen kann (inkl. einer Rückwärtskompatibilität für IPv4) habe ich mich gefragt was denn noch so problematisch ist am Umstieg auf IPv6. Mein derzeitigen, subjektiven Ergebnisse fasse ich hier einmal zusammen. Vorsicht dieser Post kann ggf. Spuren von Zynismus, Sarkasmus und auch einen Schuß Frustration meinerseits enthalten.

Natürlich ist derartige Kritik leicht daher geredet, daher werde ich auch einige Lösungen bzw. Lösungsansätze vorstellen.

Die Probleme

Betrachten wir einmal den Zeitraum seit dem es IPv6 gibt. Seit 1995 (ja sage und schreibe mehr als 25 Jahre ist es schon her …) gibt es erste Ansätze zur Ablösung von IPv4. Seit 1998 gibt es den RFC 2460 mit dem eigentlich die wichtigsten Dinge geklärt sein sollten. Aber mit ein wenig Zuwarten sind seither mehr als 20 Jahre vergangen und nach aktueller Schätzung sind wir bei rund 30% IPv6-Verkehr (je nachdem wer wie und wo gemessen hat). In meinen Augen ist hier vieles einfach nur absolut schief gelaufen und man hat sich in den Anfängen mit Dingen unbeliebt gemacht und ins Abseits katapultiert, die man auch später hätte lösen können. Stichwort sind hier die Privacy-Extensions und Multihoming. Beides sicherlich wünschenswerte Ansatzpunkte, aber die Lösungen sind teilweise so banal, dass man auch hätte sagen können: Lösen wir später (wie man es bei Software sonst ja auch immer macht – Stichwortwort YAGNI: You ain’t gonna need it).

Auch wenn ich mir derzeit die Suchvorschläge aus den diversen Suchmaschinen anschaue, dann schaudert es mich ganz kräftig. Zu IPv6 wird recht weit oben, teilweise sogar als erste Ergänzung angeführt: “abschalten”. Und noch dazu gibt es von Fachzeitschriften reihenweise Artikel dazu. Da fragt man sich wer die bezahlt – gerade von heise mit c’t und iX als fundierte Fachzeitschriften hätte ich sowas eigentlich nicht erwartet. Das ist ja fast schon auf dem Niveau einer bekannten Zeitungsmarke mit rot/weißer Schrift und vier Buchstaben.

Und auch in den technischen Foren meines derzeitigen Internet-Anbieters ist eine der häufigsten Anfragen: Bitte auf DualStack umstellen bzw. auf IPv4. Die Gründe dafür sind immer wieder die gleichen: Viele Leute haben daheim mittlerweile ein Smarthome oder NAS am Laufen, das man von außen erreichen möchte. Für den Klassiker mit IPv4, DynDNS und Portfreigabe finden sich auch reihenweise Tutorials. Eigentlich sollte man meinen mit dem Einsatz von IPv6 sollte es sogar noch leichter fallen, denn prinzipiell braucht es da ja kein Port-Forwarding mehr. Allerdings sind viele Smart-Home-Geräte an dieser Stelle etwas weniger smart bis “dump” und können von Hause aus erst mal nur IPv4. Und wenn dann hat man immer noch das Problem, dass es leider immer noch nicht selbstverständlich ist, ein fixes IPv6-Präfix zu erhalten (oder zumindest eines das man nur manuell neu auslösen kann). Musste man früher eben nur ein Gerät (im Zweifel den Router) per DynDNS erreichbar machen, so müsste man dies nunmehr für jedes der intern erreichbaren Geräte tun – der Aufwand vervielfacht sich mit der Anzahl der Geräte. Alleine wenn ich in meinen Haushalt schaue reden wir hier über Faktor 3-5 an Aufwand.

Ebenfalls völlig unverständlich ist mir die träge Adaption in Firmen. Mir ist bewusst, dass im Enterprise-Umfeld manches etwas länger dauert – wir reden hier ja im Zweifel nicht wie im Privat-Haushalt von einer niedrigen zweistelligen Geräte-Anzahl sondern durchaus auch mal im oberen fünfstelligen oder ggf. auch mal im sechstelligen Bereich. Da hat man ein wenig Arbeit als Netzwerk-Admin, soviel ist sicher. Aber es zeigt mir auch, dass hier wohl in der Ausbildung (und da schließe ich meine eigene durchaus ein) etwas grundlegend daneben gelaufen ist. Konfrontiert man derzeit Studienabgänger oder gerade mit der Ausbildung fertig gewordene Menschen im IT-Bereich mit einer IPv6-Adressen oder einer Frage zu IPv6 – so wird man häufig angeschaut als hätte man gerade in verschlüsselter Form gesprochen und dem Gegenüber vergessen mitzuteilen welcher Algorithmus und welcher Schlüssel gerade zum Einsatz kommt. Wir haben also wohl definitiv eine ganze Generation verschlafen um das Know How und auch das Bewusstsein für IPv6 zu vermitteln bzw. zu schaffen.

Ein besonders trauriges Highlight in diesem Bereich stellt die aktuelle Virtualisierungswelle mit Microservices für mich dar. Mit der Aufteilung monolitischer Architektur in kleine Mikroservices (was definitiv ein sinnvoller Architektur-Ansatz sein kann) steigt die Anzahl der zu adressierenden Endpunkte. Aber anstelle hier von Anfang an die Möglichkeiten zu nutzen die sich mit IPv6 ergeben (eben dass man nicht mehr pro Netzwerkadapter nur eine IP-Adresse hat, sondern im Regelfalle derer mindestens einmal (2^64)-1 oder gemäß der Empfehlungen sogar noch wesentlich mehr. Nota bene: kleinere Bereiche sind auch denkbar, das ist ggf. für die Aufteilung des internen Netzwerks auf Standorte / Bereiche / Abteilungen sinnvoll – auch wenn das in den offiziellen Dokumenten so nicht immer rüber kommt. Stattdessen werden Portforwarding und Reverse-Proxies einfach zum Standard erklärt (weil man das eben unter IPv4 so machen muss wenn man nur eine IP ins Internet bekommt). Der Support für IPv6 ist nur optional und man muss doch erst einmal grundlegende Dinge konfigurieren bis es läuft. Warum man hier nicht automatisiert oder zumindest einmal für die Docker-Netzwerke per default Unique-Local-Addresses (ULA) vergibt, ist mir absolut unverständlich. Zumal Docker weit nach IPv6 entwickelt wurde – mit “konnten wir nicht kennen” braucht man hier also mal gar nicht argumentieren. Wohl leider eher mit den Worten “wollten wir uns nicht mit beschäftigen, es läuft ja auch so ganz gut…”.

Lösungsansätze

Für die Problematik der langsamen Durchsetzung und Verbreitung kann man leider erst mal nichts mehr tun, hier ist das Kind in den Brunnen gefallen – jetzt hilft es nur da wieder raus zu kommen und das wenn möglich flott.

Von den bekannten Fachzeitschriften und Experten würde ich mehr sehr viel mehr wünschen als nur den Hinweis: wenn IPv6 nicht funktioniert, dann schalte es ab und nimm IPv4. Das Problem der Verknappung der IPv4-Adressen durch Aussitzen lösen zu wollen ist einfach nur naiv und bringt uns einer echten Lösung nicht wirklich näher. Hier darf man den schwarzen Peter aber nicht nur den Schreiberlingen zuschustern. Vielfach muss man auch sagen: Das Know How um IPv6 ist ingesamt noch nicht ausreichend in der Bevölkerung verteilt und das fängt bei ganz einfachen Schritten an: Es gibt noch immer Internet-Anbieter bei denen es keine native IPv6-Adresse für den Router gibt und man sich mit (K|B)rücken behelfen muss (Hurrican Electric, Teredeo, 6in4 usw.). Erst nachdem es mit den IPv4-Adressen knapp wurde weil immer mehr Kunden dauerhaft per Flatrate am Netz hängen, ist hier Bewegung in die Sache gekommen, leider hat man auch da wieder einmal die vermeintlich kostengünstigste und schrottigste Lösung implementiert: Carrier-Grade-NAT (CGN) und später derartige Konstrukte wie DualStack-Lite (DS-Lite). Mit diesen Lösungen hat man sich gerade bei den technisch afinen Leuten keinerlei Freude gemacht, denn häufig hatte man gar keine oder nur wenig Vorlaufzeit und schon ging der benötigte Zugriff aufs Heimnetzwerk nicht mehr. Der erste Verdacht ist da natürlich: IPv6 ist schuld. Aber das ist leider nur bedingt richtig – vielmehr ist IPv6 hier ja sogar eher die Lösung, nur es ist eben keiner wirklich drauf eingestellt gewesen. Eigentlich ist ja die Ursache: Wir haben nicht mehr genügend IPv4-Adressen also geben wir diese nicht mehr Default raus. Viel anderes bleibt den Providern ja auch technisch nicht übrig. Es wäre vielleicht aber hilfreich wenn man den Kunden ggf. die Umstellung samt Verzicht auf natives IPv4 entsprechend schmackhaft macht: Sei es durch günstigere Tarife (oder einen Malus für IPv4). Zudem braucht der geneigte Kunde eine Möglichkeit seine Heiminfrastruktur dann doch von außen ansprechen zu können, womit wir statischen Präfixen sind. Da schreien jetzt die Datenschützer auf, dass man damit ja viel leichter den User tracken kann. Aber seien wir ehrlich: Da gibt es bereits andere Methodiken die mir mehr Sorge bereiten Cookies und Co. Bei der Hausadresse verlangt ja auch niemand, dass man diese jeden Tag neu erhält, für die Brief und Paket-Kommunikation ist das auch kein Problem.

Die Situation in den Firmen ist auch irgendwie hausgemacht – man hat ein Konzept und das nutzt man bis es nicht mehr trägt – komme da was wolle. Es zeigt aber auch, dass die Firmen derzeit die Netzwerk-Technologie eher mit der Kneifzange anfassen. In den wenigsten Firmen gibt es derzeit Leute mit ausreichend Expertise und Willen IPv6 einzuführen. Gerade hier wäre aber eine graduelle Einführung in echtem Dualstack-Betrieb sehr einfach realisierbar. In größeren Unternehmen sind die Netzwerke schon von Haus aus gut strukturiert – man muss hier keine Anpassung für IPv6 vornehmen, man muss es ggf. nur umappen. An Stellen die vorher ggf. neuralgisch waren, kann man hingegen sehr einfach hergehen und saubere Lösungen / Unterteilungen finden, der Adressraum ist ja groß genug.

In eine ähnliche Kerbe muss ich bezüglich der aktuellen Virtualisierungstechniken schlagen: Es kann eigentlich nicht sein, dass wir eine aktuelle Technologie nutzen die im Innern nur ein veraltetes Protokoll sicher unterstützt. Der Einsatz von IPv6 im Docker-Umfeld muss deutlich einfacher werden, wenn das Einrichten von Portmappings automatisiert werden kann, dann kann auch die Untersegmentierung eines zugewiesenen Präfix und dem Einrichten einer Route und ggf. ein paar Firewall-Regeln doch keine unüberwindbare Hürde darstellen. Damit wäre schon einmal für den statischen Fall (was in Rechenzentren und gemieteten Servern ja ohnehin der Fall sein sollte) das Allermeiste gelöst. Für den dynamischen Fall des heimischen Raspi mit Docker sind die Lösungen dann auch nicht viel komplexer, zumal man ja jedem Interface ja auch erst einmal mehrere Adressen zuweisen kann.

Für den Fall der dynamischen Zuweisung bin ich gerade noch selbst ein wenig am Tüfteln – ich habe leider noch keine DynDNS-Software gefunden welche es erlaubt für ganze Subnetze direkt die Prefixe zu aktualisieren. Fürs erste wäre ich ja bereits einmal froh wenn man es für eine gesamte Subdomain wie etwas aussenstelle.meinetollefirma.org machen könnte, unter der Annahme dass alle dort gelisteten Hosts unter dem entsprechenden identischen Prefix zu finden sind und die Zuweiseung der Suffixes per DHCPv6 identisch bleibt. Das Problem einer Änderung der Prefix-Länge ist damit auch noch nicht gelöst, aber es wäre ein großer Schritt in die richtige Richtung.