IPv6: Auf die Plätze, fertig, los

Kommentieren Drucken

Es soll ja noch Leute geben, die ernsthaft glauben, IPv6 aussitzen zu können. Dabei ist IPv6 keine Zukunftsmusik mehr, sondern gelebte Realität. Die Provider machen bei DSL-Anschlüssen Ernst. Erst traf es einen Kollegen, dann mich selbst. Wobei es große Unterschiede zwischen den beiden Fällen gibt, die auch Konsequenzen für die Internetnutzung haben. Problemfrei sind aber beide nicht.

Auch wenn es erst später passierte, betrachten wir zunächst meinen eigenen Fall. Er ist einfacher zu verstehen, wenn auch nicht zu begreifen:
Da ich mich berufsbedingt intensiv mit IPv6 auseinandersetze, brauchte ich schon für einen Zugang zum IPv6 Internet, um sinnvoll testen zu können. Da ich keinen Provider fand, der mir natives IPv6 anbieten konnte, realisierte ich das per SIXXS-Tunnel mit AVM-Fritzbox. Für die Rechner im Netz sah es wie natives IPv6 aus. Es waren zwei Firmware-Updates notwendig, bevor es sauber lief:

  • Zunächst funktionierte der SIXXS-Tunnel gar nicht und anstatt des eingetragenen 64 bit langen ULA-Prefixes wurde nur die ersten beiden Byte mit einem /64er Prefix per Router Advertisement bekannt gegeben (vgl. Bild 1).
  • Nach einem Update funktionierten der Tunnel und auch die Router Advertisements hervorragend … für ca. 30 Minuten. Danach ging gar nichts mehr, bis man den Router per RWE-Reset (Stecker raus, Stecker rein) rebootet hatte.
  • Ein weiteres Update löste schließlich auch dieses Problem.

Anfang des Jahres bekam ich dann eine E-Mail von meinem Provider: Ob ich Interesse hätte, am Pilotprojekt IPv6 teilzunehmen, da ich doch SIXXS-Nutzer sei. Auf eigene Gefahr versteht sich. Ich sagte sofort ja.

Seitdem habe ich zu Hause einen Dual-IP-Anschluss. Soll heißen, mein Internet-Router bekommt sowohl eine IPv4-Adresse, wie auch ein /48er IPv6-Netz. Bei IPv4 wird, wie gewohnt, NAT gemacht, bei IPv6 hingegen wird das erste /64-Präfix an die Rechner verteilt und unge-NAT-et ins IPv6-Netz geroutet.

Netztechnisch habe ich seitdem keine Probleme. Wann immer ich sniffer, sehe ich IPv6 wenn möglich und IPv4 wenn nicht. Auch Performance-Einbußen sind mir (subjektiv) nicht aufgefallen.

So weit so gut. Erstaunlich ist aber, dass ein iMAC gelegentlich das IP-Prefix an der WLAN-Schnittstelle „verliert“ und es erst nach einem kompletten Reboot wieder akzeptiert. Das merke ich aber auch nur, wenn ich gezielt nachschaue, da IPv4 ja funktioniert.

Ganz anders bei meinem Kollegen:
Er beantragte bei einem anderen, aber ebenfalls lokalen Provider einen neuen DSL-Anschluss. Anders als bei mir, bekam er ungefragt sofort IPv6 nativ … und zwar nur IPv6! IPv4 wird per Dual-Stack Lite (DS-Lite) realisiert. Mit anderen Worten: An seinem WAN-Interface liegt nur IPv6 an, jeglicher IPv4-Verkehr wird vom Zugangsrouter in IPv6 enkapsuliert und zu einem „Address Family Transition Router“ (AFTR) gesendet (siehe Bild 2). Der AFTR ist auch unter dem Begriff „Carrier-grade NAT“ bekannt.

Es schien auch zunächst alles zu funktionieren, bis mein Kollege versuche, eine VPN-Verbindung in die Firma aufzubauen. Anschließend wurde ich mit Sniffer-Dumps, Konfigurationen und Ping-Traces zugemailt: „Du bist doch unser IPv6-Experte. Warum funktioniert das nicht?“

Zunächst ist es wichtig zu wissen, dass der Firmensitz noch keinen funktionierenden IPv6-Anschluss besitzt. Der VPN-Tunnel muss also via IPv4 aufgebaut werden.

Die weitere Recherche ergab, dass mein Kollege nicht allein war mit dem Problem. Aber von merkwürdigen Theorien in diversen Foren abgesehen, fand ich zunächst keine Erklärung. Dazu hilft es nämlich nicht, den Standard von DS-Lite zu lesen, der definiert nur die Funktionsweise des Routers, nicht des AFTR. Doch bei dem liegt die Erklärung: Schaut man sich beim Internet System Consortium (ISC) an, was deren AFTR leistet, so ist er eingeschränkt auf TCP, UDP und ICMP. Der Tunnel in die Firma nutzt jedoch GRE als Transportprotokoll. GRE wiederum ist IP over IP und somit als Protokoll 47 deklariert. Eine Verbindung ist folglich nicht möglich.

Unsere Lösung lag darin, eine weitere VPN-Technik einzuführen, die TCP als Transportprotokoll nutzt.

An diesen beiden Beispielen kann man folgendes sehr schön ablesen:

  1. Die Migration zu IPv6 hat bereits begonnen. Einige werden womöglich privat schon an IPv6 angeschlossen sein, ohne es gemerkt zu haben.
  2. Bei den Providern gibt es keine einheitliche Anschlusstechnik, einige setzten auf Tunnel-Techniken, andere auf Dual-IP-Netze.
  3. Die Software ist noch nicht ausgereift (Beispiele waren OS X, Router-Firmware und AFTR).

Wer für den VPN-Zugang seines Unternehmens verantwortlich ist, kommt heute somit nicht mehr darum herum, sich mit IPv6 auseinander zu setzen, um zumindest ansatzweise die Chance zu haben, die Probleme der Mitarbeiter lösen zu können.

Vielleicht hat ja auch schon der ein oder andere Leser seine Probleme mit IPv6-Providern gehabt und kann über die Probleme und Lösungen hier berichten.

zugeordnete Kategorien: Endgeräte, IP und IPv6, IT-Sicherheit
zugeordnete Tags: , ,

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.