Dieser Artikel ist für all diejenigen die noch immer denken, dass IPv6 sie nichts angeht und die nächsten Jahre IPv4 noch immer das dominierende Protokoll sei. Die jetzt keine Lust mehr haben weiter zu lesen, nehmen sich einer der blauen Pillen und alles wird gut. Der Rest greift bitte zu roten Pille und liest, so hoffe ich, bis zum Ende diesen Artikel hier im Blog. Seit einigen Wochen mehren sich die Probleme mit DS-lite Anschlüssen und Verbindungen von Home Offices und Außendienstmitarbeiter. Zwar hat in den meisten Fällen die eigentliche Ursache der Probleme weniger mit IPv6 direkt zu tun, aber es hat einen kausalen Zusammenhang.
Um die Probleme zu verstehen muss man sich vor Augen führen wie ein Internet Zugang mit DS-lite funktioniert. Vereinfacht gesagt, besteht ein solcher Zugang auf der externen Seite nur aus IPv6, intern aber aus IPv6 und IPv4. IPv6 Verbindungen sollten in der Regel transparent abgewickelt werden. IPv4 hingegen wird in IPv6 eingepackt und zum zentralen NAT Gateway des Anbieters übertragen. Hier findet dann die Umsetzung für das IPv4 Internet mittel CGN (Carrier Grade NAT) statt. Alle IPv4 Verbindungen werden somit nur über das zentrale NAT Gateway des Anbieters hergestellt. In der Theorie alles gut soweit, in der Praxis kommt es aber zu Problemen. Vor allem treten die Probleme bei (SSL) VPN Verbindungen auf. Durch das Einpacken der VPN Daten ergibt sich im Zusammenhang mit DL-lite Anschlüssen, wenn das VPN Gateway nur über IPv4 zu erreichen ist eine Konstellation in der Päckchen im Päckchen im Päckchen eingepackt ist. In IPv6 gibt es keine Fragmentierung, was dann eine passende MTU Größe voraussetzt, was letztendlich die Ursache sein dürfte. Dieses haben wir zwar noch nicht hinreichend recherchieren bzw. bei uns im Lab final nachstellen können. Aber die Indizien sprechen deutlich dafür. Es kommt nicht bei plain IPv4 Anschlüssen vor, nur bei DS-lite Zugängen mit IPv4 Verbindung. Zudem wird es richtig deutlich wenn dann noch ein VPN aufgebaut werden soll. Auch ist interessant, dass wenn es zu diesen Problemen kommt, Linux und Mac OS X seltener und Windows dagegen fast immer betroffen ist. Eine Erklärung für dieses Verhalten haben wir zum aktuellen Zeitpunkt noch nicht. Vermutlich liegt die Erklärung an den unterschiedlichen IP-Stacks zwischen den „Unixoiden“ und Microsoft Betriebssystemen. Jetzt nur aus den wenigen Anhaltspunkten zu folgern, dass Windows etwas falsch macht oder der IP-Stack fehlerhaft sei, entbehrt aber jedweder Grundlage.
Auch haben sich manche Zugangs-Anbieter bereiterklärt, Anschlüsse mit Problemen wieder auf plain IPv4 zurückzustellen. Und siehe da, die VPN Verbindungen aus den Home Office funktionieren wieder zuverlässig und mit der gewohnten Geschwindigkeit. Daher ist es eine Tatsache, dass es definitiv Probleme mit DS-lite Anschlüssen gibt. Diese Probleme alleine am Betriebssystem oder an DS-lite mit CGN fest zu machen, wäre zu kurzsichtig. Bei der „hochwertigen“ Router-Hardware die an den Consumer Anschlüssen eingesetzt wird, könnte das Problem auch an der Home-Router und DS-lite Kombination liegen. Wer weiß schon wie hochwertig die DS-lite Implementierung in einem solchen Router ist. Im Lab haben wir versucht das Szenario nachzustellen, jedoch stand uns nur eine Juniper SRX zur Verfügung und hier ist offensichtlich die DL-lite Implementierung von einer ganz anderen Qualität und ein BSD ist drunter. Daher ist es uns wohl nicht gelungen den Fehler nachzustellen. Kurzum IPv6 geht alle an, selbst wenn man noch in der nur IPv4 Welt zu Hause ist. Selbst wenn bei den Business Kunden IPv4 Adressen zu bekommen noch kein Problem ist, so ist dies aber im Consumer Umfeld bei neuen oder geänderten Anschlüssen ganz anders. Ob Unitymedia, Kabel Deutschland (oder Nachfolger), Vodafone DSL Anschlüsse, VDSL, All-IP oder Magenta irgendwas. Alle neuen sind IPv6 oder werden es! Zudem die Telekom bei allen Company Connect Anschlüssen (oder vergleichbar) die geändert oder neu sind automatisch ein /48 IPv6 Netz mit raus gibt. Tritt man einen Schritt zurück und betrachtet das Ganze, so könnte man mutmaßen, dass wenn sich die DS-lite Probleme häufen, Anbieter wie die Telekom alle Argumente auf ihrer Seite haben. Die Business Kunden verfügen über die notwendigen IPv6 Netz. Somit wären sie auch praktisch in der Lage IPv6 nativ einzusetzen. Ob das jetzt der wirkliche Grund ist, mag vielleicht zu hoch gegriffen sein. Vielleicht geht es auch nur darum IPv6 endlich mal voranzubringen, zumal in Asien, Afrika und Lateinamerika das IPv4 Problem noch größer ist.
Dies bekommen vor allem Kunden zu spüren deren Mitarbeiter in den Regionen der Welt unterwegs sind in denen IPv6 durch Mangel an IPv4 Adressen stark verbreitet ist. Da IPv4 Adressen bei der immer weiteren Flut an Geräten die eine Verbindung zum Internet benötigen nicht ausreichend werden bleibt nur der Weg zu IPv6. Daher wird das Internet der Dinge und die zunehmende Anzahl mobiler Geräte ihren Teil dazu beitragen. Dies hat natürlich auch auf alle Auswirkungen die im IPv4 beheimatet sind. Viele Businesskunden nehmen es daher nicht so wahr, dass es hier einen Wandel gibt auf den reagiert werden muss. NAT war und ist auch keine wirkliche Lösung. Dieses Konstrukt war schon unter IPv4 eine Krücke und unter IPv6 ist es nichts anderes. Irgendwann hat ein Marketing NAT als Sicherheitsfeature „NAT-Firewall“ verkauft – zwar völlig albern, aber seit her hört man immer wieder das NAT ein Sicherheitsfeature ist. Dabei ist NAT schlicht und ergreifend die Quick ’n Dirty Lösung der schon vor Jahren ausgehenden IPv4 Adressen. Jeder Administrator der sich um VPN Verbindungen kümmern muss oder Dienste in einer DMZ mit rfc Adressen betreiben muss, kennt die Ärgernisse und Probleme mit NAT. Gerade bei VPN’s und den zigfach eingesetzten identischen rfc Netzen werden die NAT Konstrukte immer komplexer. Ganze Netze werden auf beiden Seiten N:N umgeschrieben, nur weil beide die gleichen Netze verwenden, von den Transfernetzen mit NAT ganz zu schweigen. Daher ist NAT definitiv keine Lösung, sondern eine weitere Verschlimmerung der Situation.
Da IPv6 sich verbreiten wird und hier die Entwicklung schwer vorhersagbar ist, muss jetzt trotzdem gehandelt werden. Zumindest am Perimeter um einen Dual-Stack anbieten zu können. So stehen für externe Zugriffe beide Wege zur Verfügung und verschaffen den IT Abteilungen zusätzlich Zeit in Ruhe den IPv6 Ausbau voranzutreiben. Um auf der externen Seite beides bereitstellen zu können gibt es verschiedene Ansätze. Ein Ansatz ist, die Dienste mit eigenen IPv6 Adressen selbst anzubieten oder dazu ein externes Datacenter zu nutzen was unter andrem den Charme hat eine zusätzliche (D)DoS Protection einzuführen. Im externen Datacenter stehen vielleicht nicht eigene IPv6 Adressen zur Verfügung aber IP Adressen sind Schall und Rauch, der DNS Eintrag ist das was zählt. So kann man in Ruhe die eigene IPv6 Planung vorantrieben ohne schon ein Adress-Segment für die externe Seite festgelegt zu haben. Ist man später soweit den eigenen Betrieb aufzunehmen, stellt man die DNS Einträge einfach um oder bleibt im Datacenter und nutzt weiter die Vorzüge eines solchen „Außenpostens“.
An dieser Stelle sei ein klein wenig Werbung für eine IPv6 Veranstaltung bei uns im Haus gestattet sein. Ein genauer Termin steht noch nicht fest. Dieser richtet sich nach unserem Gastredner Florian Hartmann, seines Zeichens SE von A10 Networks. Er betreut u.a. die Einführungen von CGN Implementierungen bei großen Providern oder Carriern. Hier gibt es so zu sagen IPv6 und DS-lite Informationen aus erster Hand. Der Charakter der Veranstaltung ist rein technischer Natur und wird am späten Nachmittag starten und bis zum frühen Abend dauern. Das Ende ist allerdings offen da eine Diskussion im Anschluss erwünscht ist. Für das leibliche Wohl ist gesorgt. Wer vorab Fragen zum Event hat, kann sich gerne an event@salutec.de wenden.