IPv6 für alle: Das Internet von morgen schon heute nutzen

(http://www.zdnet.de/magazin/39201232/ipv6-fuer-alle-das-internet-von-morgen-schon-heute-nutzen.htm)

von Christoph H. Hochstätter, 21. Januar 2009

NAT-Routing, Portforwarding und Tunneling sind nicht jedermanns Sache. Künftig will das Internet mit IPv6 ohne Hilfskonstrukte auskommen. ZDNet erklärt das neue Protokoll und zeigt, wie einfach man IPv6 am eigenen Anschluss nutzen kann.

Mitte der 90er Jahre führte AOL einer staunenden Öffentlichkeit ein Experiment vor. Ein bekannter Tennisspieler sollte sich ohne fremde Hilfe ins Internet einwählen. Da es sich um einen Werbefilm handelte, gelang das Experiment. Das "Versuchskaninchen" Boris Becker fragte nur erstaunt: "Bin ich da jetzt schon drin, oder was?".

Für Boris Becker gab es damals noch viele mögliche Hindernisse, beispielsweise wenn die Default-Konfiguration des Modems nicht optimal war und er die notwendigen AT-Befehle von Hand hätte eingeben müssen. Heute ist tatsächlich alles sehr einfach: Einfach den vom Provider mitgelieferten und vorkonfigurierten Router in die Telefonsteckdose stecken und per Ethernet oder WLAN mit einem oder mehreren PCs verbinden - fertig!

Für die meisten Anwender funktioniert das Internet einfach und problemlos. Doch hinter den Kulissen sieht es anders aus. Die IPv4-Adressen werden knapp. Theoretisch gibt es über vier Milliarden IP-Adressen für sechs Milliarden Menschen auf der Erde. Praktisch sind viele Bereiche wie 10.x.x.x nicht nutzbar, da sie für eine Sondernutzung reserviert sind, etwa für private IP-Adressen oder Multicasting.

Hinzu kommt, dass es quasi unmöglich ist, IP-Adressen in beliebigen Mengen an Kunden zu geben. Das geht nur in Zweierpotenzen. Ein Unternehmen, das 513 IP-Adressen benötigt, muss 1024 Adressen reservieren. Zwar ließe sich der IPv4-Adressraum theoretisch in Subnetze mit der Größe eins (zwei hoch null) aufteilen, doch das würde die Router der Provider überfordern. Die Routingtabellen wären so lang, dass sie den Verkehr nicht mehr bewältigten.

Bereits im Mai 2008 forderte Vinton Cerf[1], einer der beiden Erfinder des TCP/IP-Protokolls, dass man den neuen Standard IP Version 6, kurz IPv6, durch einen Parallelbetrieb einführen solle. IPv6 verwendet 128-Bit-Adressen, so dass insgesamt über 340 Sextillionen IP-Adressen zur Verfügung stehen. China geht davon aus[2], dass es bereits im Jahr 2010 nicht mehr genug IPv4-Adressen zur Verfügung hat. Das liegt vor allem daran, dass die ICANN die IPv4-Adressen nicht gleichmäßig an die lokalen Registries verteilt hat. So besitzt China nur etwa ungefähr so viele Adressen wie die Universität Berkeley.

Bildergalerie

So konfigurert man IPv6 am DSL-Anschluss[3]

» zur Bildergalerie ...[3]
Dass die IPv4-Adressen nicht schon längst weltweit ausgegangen sind, liegt vor allem am NAT-Routing. In der Regel sind heute sowohl Privatleute als auch Unternehmen über NAT an das Internet angebunden. Dabei bekommt jeder Rechner im Intranet eine private IPv4-Adresse, etwa 192.168.0.5. Der Internet-Router "übersetzt" diese Adresse in die öffentliche IPv4-Adresse. Auf diese Weise ist es möglich, mit einer einzigen öffentlichen IPv4-Adresse mehrere Rechner an das Internet anzuschließen.

NAT ist jedoch eine Hilfskonstruktion, an die man sich mittlerweile gewöhnt hat, denn es bietet als Nebeneffekt eine Firewallfunktionalität, die verhindert, dass aus dem Internet eine Verbindung zu Rechnern im Intranet aufgebaut werden kann. So lässt sich die Angriffsfläche stark reduzieren. Das schätzen viele Anwender.

Auf der anderen Seite besitzt NAT gravierende Nachteile. In Verbindung mit TCP bedeutet NAT einen erheblichen Rechenaufwand für den NAT-Router. Jeder, der schon einmal Peer-to-Peer-Filesharing betrieben hat, kennt das Problem. Obwohl man sein Filesharing-Programm so konfiguriert hat, dass es maximal die halbe Bandbreite des Internetanschlusses nutzt, kann man von einem zweiten Rechner kaum noch mit dem Browser arbeiten. Der Grund dafür ist, dass die meist leistungsschwachen CPUs der DSL-Router mit der Verwaltung der TCP-Verbindungen überlastet sind.

Wer Serverdienste von zu Hause anbieten[4] oder einfach nur seine PCs oder Endgeräte wie digitale Videorekorder von unterwegs erreichen[5] möchte, muss komplizierte Portforwarding-Regeln einrichten, um dies zu ermöglichen. Ansätze zur automatischen Lösung, etwa UPnP[6] und NAT-PMP[7], sind nicht wirklich zufriedenstellend und zudem sicherheitstechnisch bedenklich.

Darüber hinaus behindert NAT viele Dienste. Dazu gehören Instant Messaging (IM), VoIP und End-To-End-VPNs. Wenig problematisch ist IM. Zwar müssen alle Messages über einen Dienstanbieter, etwa MSN, AOL oder Yahoo, geleitet werden, jedoch ist das Datenvolumen einer Message recht gering. Besser wäre es natürlich, wenn die Messages direkt von User zu User gesendet würden.

Komplizierter ist es bei SIP, dass vor allem für VoIP-Telefonie eingesetzt wird. SIP berücksichtigt explizit die Möglichkeit, dass ein Vermittlungsdienst die Verbindung zweier Teilnehmer herstellt. Nach der erfolgreichen Vermittlung sollen die Teilnehmer möglichst direkt miteinander kommunizieren. Das ist über NAT nur schwer zu realisieren. Mit einigen Routern geht es überhaupt nicht. Auch Microsoft stellt in einem MSDN-Artikel[8] fest, dass Anwendungen wie Windows Meeting Space und Remote Assistance mit NAT-Routing nur sehr umständlich zu realisieren ist. Ein Windows-Live-Meeting zwischen drei Firmen ist in der Regel nur aufzusetzen, wenn die Administratoren zuvor ihre NAT-Router-Konfiguration abstimmen.

Viele Dienste und Anwendungen werden heutzutage allerdings explizit NAT-fähig entwickelt, so dass man damit zufriedenstellend zurecht kommt. Aber auch dann reichen die IPv4-Adressen nicht mehr lange. Ein wesentlicher Grund dafür ist, dass sich immer mehr Geräte mobil ins Netz einwählen. Neben Internetdiensten auf Handys und PDAs nutzen Anwender vermehrt die Möglichkeit, ihre Laptops mit UMTS-Sticks auszustatten. Bezahlbare Tarife und schnelle HSPA-Technologien[9] machen diesen Weg ins Internet interessant.

Allerdings muss man sich im Klaren darüber sein, dass man mit den mobilen Technologien keine vollwertige Internetanbindung erhält. Die Mobilfunkprovider geben den Geräten keine öffentliche IP-Adresse, sondern eine private aus dem Bereich 10.x.x.x. Das entspricht grundsätzlich einer NAT-Anbindung, wie sie auch bei jedem DSL-Router genutzt wird, jedoch lassen sich keine Ports weiterleiten. Das ist nur möglich, wenn man selbst die Kontrolle über den NAT-Router besitzt.

Darüber hinaus gibt es weitere Einschränkungen. Aus den UMTS-Netzen kann man nicht beliebig viele Internetverbindungen aufbauen. Das liegt daran, dass die beiden meistgenutzten Protokolle oberhalb von IP, nämlich TCP und UDP, eine 16 Bit lange Portadresse verwenden. Pro öffentlicher IP-Adresse können also maximal 65.536 Ports genutzt werden. Für private DSL-Nutzer ergeben sich daraus kaum Einschränkungen. Setzt man zehn Rechner hinter einen DSL-Router, so kann jeder Rechner 6553 Verbindungen pro Protokoll gleichzeitig aufbauen. Ein UMTS-Anbieter, der 1000 Benutzer über eine einzige öffentliche IP-Adresse leitet, kann seinen Kunden maximal 65 Verbindungen anbieten.

Für das normale Surfen im Web sowie für die Verbindung zu einem E-Mail-Server reicht das aus. Nutzt man ein End-to-End-VPN, etwa Hamachi[10], kann es knapp werden. Hamachi baut mit jedem VPN-Teilnehmer eine eigene UDP-Verbindung auf, durch die IP-Pakete getunnelt werden. Ein Kurztest mit T-Mobile zeigt, dass ein Laptop, der mit einem HSDPA-Stick ins Netz geht, nicht zu allen Hamachi-Partnern verbunden wird. In Bild 1[11] sieht man, dass nicht jeder Rechner einen grünen Stern erhält, der sich angemeldet hat. Bild 2[12] zeigt, dass es mit einer DSL-Verbindung hingegen einwandfrei funktioniert. Mit derartigen Problemen haben in Europa nur mobile Anwender zu kämpfen. In Asien müssen sich Endkunden wegen der knapperen Adressen auch bei einem Festanschluss damit abfinden, dass sie eigentlich keinen echten Internetanschluss haben, sondern einen Zugang zu den Diensten World Wide Web und E-Mail.

IPv6 kommt ganz ohne NAT aus, wenn man das möchte. Bei IPv6 gibt es genug Adressen, so dass jeder Rechner und jedes Endgerät eine eigene öffentliche IP-Adresse bekommen kann. IPv6 besitzt eine hohe Kompatibilität zu vielen Anwendungen, da sie in der Regel nur mit einer höheren Protokollebene, beispielsweise TCP oder UDP, kommunizieren. Diese Protokolle ändern sich nicht, wenn man IPv6 statt IPv4 verwendet. Zudem unterstützen die drei wichtigsten Betriebssysteme Linux, Mac OS und Windows das neue Protokoll.

Auffällig an IPv6-Adressen ist, dass sie etwas anders als IPv4-Adressen notiert werden, nämlich hexadezimal in 16-Bit-Gruppen. Eine gültige IPv6-Adresse ist beispielsweise 1234:5678:90AB:CDEF:0000:0000:0000:1234. Aufeinander folgende Gruppen von 0000 dürfen einmalig mit :: abgekürzt werden, so dass dieselbe IP-Adresse auch als 1234:5678:90AB:CDEF::1234 geschrieben werden kann.

Die letzten 64 Bit werden immer als Host-Adresse bezeichnet. Das bedeutet, dass auch Privatanwender über 18 Trilliarden IPv6-Adressen bekommen. Diese Zahl scheint etwas hoch gegriffen, resultiert aber daher, dass die Adressen des unterhalb von IP liegenden Protokolls, etwa MAC-Adressen, in den letzten 64 Bit kodiert werden sollen, um eine Autokonfiguration zu ermöglichen. Für Ethernet reichen dabei natürlich 48 Bit, jedoch wollte man sich jedoch eine Erweiterungsmöglichkeit schaffen.

Als öffentliche Internetadressen werden zur Zeit nur Adressen verwendet, die mit einer zwei oder einer drei beginnen. In CIDR-Schreibweise[13] heißt das 2000::/3. Berücksichtigt man, dass jeder Internetanschluss mindestens 64 Bit zur freien Verfügung hat, so können die Internetprovider weltweit 35 Trillionen IPv6-Adressen oder besser gesagt Subnetze vergeben. Unternehmen mit mehreren Subnetzen sollen in Europa pauschal 65.536 solcher Subnetze erhalten, ohne dass die RIPE den Bedarf prüft.

Das bedeutet natürlich, dass jeder Privatanwender jeden Rechner in seinem Heimnetz ins Internet nehmen kann, ohne dass NAT-Routing erforderlich ist. Gleichzeitig muss man seine Rechner besser schützen, da alle Rechner aus dem Internet erreichbar sind. Das wird am besten durch den Router erledigt. So kann man pauschal alle eingehenden Internetverbindungen sperren und einzelne Dienste freigeben, beispielsweise den eigenen Webserver oder das Webinterface für den digitalen Videorekorder. Diese Vorgehensweise hat den Vorteil, dass die eigenen Rechner im Intranet frei miteinander kommunizieren können.

Die meisten Anwender verwenden unter IPv4 private IP-Adressen vor allem aus Gründen des NAT-Routings. Auch in IPv6 gibt es private Adressen. Sie dienen allerdings nunmehr dazu, Rechner zu betreiben, die überhaupt keine Verbindung ins Internet erhalten sollten. Dazu gibt es gleich drei verschiedene Arten von privaten IPv6-Adressen:

IPv4 ist auf einen zentralen Server angewiesen, der IP-Adressen vergibt, sofern man nicht jeden Rechner manuell konfigurieren möchte. Üblicherweise macht das ein DHCP-Server. Im einfachsten Fall wird der DHCP-Server des NAT-Routers genutzt. IPv6 beherrscht eine Autokonfiguration, die einen DHCP-Server oft überflüssig macht. IPv4 beherrscht ebenfalls eine Autokonfiguration, die aber unzureichend ist. Bei IPv4 wird eine Adresse aus dem Bereich 169.254.0.0/16 zugewiesen. Damit dürfte jeder schon einmal Erfahrung gesammelt haben. Findet der Rechner keinen DHCP-Server, autokonfiguriert er sich auf eine 169.254.x.x-Adresse. So kann man zwar andere Rechner im selben Netz erreichen, die auch keinen DHCP-Server gefunden haben, ins Internet kommt man allerdings nicht.

IPv6 beherrscht eine Autokonfiguration, die den Zugang zum Internet ermöglicht. Alle Router in einem Netzwerk müssen auf die Multicast-Adresse FF02::2 hören. So kann sich ein Rechner zunächst eine linklokale Adresse selbst zuweisen. Anschließend schickt er ein Paket an die Router-Multicast-Adresse. Aus der Antwort sieht er den Netzwerkteil, sprich die oberen 64 Bit, seine öffentlichen IP-Adresse. Den Hostteil, also die unteren 64 Bit, berechnet er aus seiner MAC-Adresse. Die IP-Adresse des Routers verwendet er als Default-Gateway.

Daneben gibt es die Zuweisung über DHCPv6. Zusatzinformationen wie DNS-Server und NTP-Server erhält man nämlich über die Autokonfiguration nicht. Dazu gibt die Möglichkeit, Autokonfiguration mit DHCPv6 zu kombinieren. Alternativ kann man auch die Adressvergabe über DHCPv6 realisieren. In letzterem Fall lassen sich die Rechner fortlaufend durchnummerieren.

Eines der nützlichsten Features von IPv6 ist die Erweiterung "Mobile IPv6" nach RFC 3775[14]. Wenn man schon die Möglichkeit hat, dass jeder Rechner und jedes Smartphone über eine Internet-Adresse erreichbar ist, so will man das auch nutzen, wenn man unterwegs ist. Ein Beispiel dafür ist, dass Anrufe auf die Festnetznummer kostenfrei per VoIP an das Flatrate-UMTS-Handy weitergeleitet werden.

Abgesehen davon, dass man mit einem solchen Szenario keinen Mobilfunkanbieter begeistern kann, steht man vor dem technischen Problem, dass alle Geräte bei einer mobilen Einbuchung in ein Hotel-WLAN oder ins UMTS-Netz eine andere IPv6-Adresse bekommen als im heimischen Intranet.

Mobile IPv6 sorgt dafür, dass das Gerät trotzdem unter der bekannten Adresse zu erreichen ist. Das Gerät meldet sich dazu an einem Home-Agent an, der zweckmäßigerweise auf dem eigenen Router implementiert ist. Der Home-Agent nimmt dann zusätzlich die heimische IPv6-Adresse des mobilen Gerätes an und tunnelt alle Pakete an die momentane IP-Adresse des Geräts.

Interessant dabei ist, dass das mobile Netz nicht einmal IPv6 unterstützen muss. Der Tunnel lässt sich auch über IPv4 realisieren. Zwingende Voraussetzung ist jedoch, dass das mobile Gerät IPv6 unterstützt. In der Praxis kann man diese Funktion allerdings noch nicht einsetzen. Smartphones unterstützen in der Regel gar kein IPv6. Die neuesten Windows-Versionen Vista und 2008 beherrschen den Mobile-IPv6-Standard nicht. Allerdings gibt es eine experimentelle Implementierung[15] von Microsoft Research. Sie läuft jedoch nur auf Windows XP und 2003.

Nur wenige ISPs bieten heute natives IPv6 an. Eine der wenigen Ausnahmen ist Tal.de[16]. Dennoch kann man heute bereits IPv6 über ein 6to4-Gateway testen. Sowohl Linux als auch Windows unterstützen die 6to4-Tunnelung nach RFC 3056[17]. Mittlerweile gibt es sehr viele zuverlässige 6to4-Gateways. Besonders praktisch ist, dass man sich darauf geeinigt hat, für 6to4-Gateways die Anycast[18]-Adresse 192.88.99.1 zu nutzen. Selbst wenn der eigene ISP kein Gateway anbietet, kommt man in der Regel über normales Routing zum nächsten Gateway. Spätestens bei der DE-CIX[19] folgt der Übergang zu IPv6.

6to4 hat allerdings Nachteile. Es funktioniert nicht über NAT. Das heißt, man muss seinen Rechner direkt an das DSL- oder Kabelmodem anschließen. Aufgrund dieser Beschränkung hat Microsoft eine weitere Lösung entwickelt, um IPv6 in IPv4 zu tunneln. Das Teredo-Protokoll, dass in an allen Windows Versionen ab XP SP1 enthalten ist, verwendet UDP-Pakete. Damit kann man Rechner, die hinter einem NAT hängen, an einen Teredo-Server verbinden. Der Teredo-Server muss eine öffentliche IPv6-Adresse besitzen, die er auch über ein 6to4-Gateway beziehen darf.

Leider gibt es kaum öffentlich zugänglichen Teredo-Server. Die wenigen Server sind meist überlastet und liefern sehr lange Pings. Dabei ist die Technologie hochinteressant. Schließlich ermöglicht sie jedem, mit einer üblichen Internet-Anbindung IPv6 zu nutzen. So könnten sich technisch interessierte Nutzer auf einfache Weise Zugang zum IPv6-Netz verschaffen, ohne die gesamte Konfiguration des Heimnetzes ändern zu müssen.

Handfeste Vorteile, etwa weltweite VoIP-Telefonie ohne NAT-Probleme direkt von User zu User ohne einen Vermittlungsdienst wie Skype oder einen der zahlreichen SIP-Provider, dürften sich bald herumsprechen. Da die Konfiguration einfach ist, können sich auch weniger erfahrene Benutzer mit einem Teredo-Server verbinden. Sicherheitstechnisch ist jedoch zu beachten, dass ein Rechner, der über NAT vor eingehenden Verbindungen geschützt ist, durch die Teredo-Anbindung ungeschützt im IPv6-Netz steht. Man muss den Rechner selbst mit einer IPv6-fähigen Firewall oder IPSec[20] schützen. Auch für Linux und Mac OS X gibt es Teredo-Lösungen. Die Installation wird bei 0x1b.ch[21] beschrieben.

Ferner gibt es weitere Tunnelmöglichkeiten. Dazu gehört ISATAP[22], das von Windows und Linux ab Kernel 2.6.25 unterstützt wird. Auch hier wird es schwierig, performante Server zu finden. Wer noch weitere Zugangsmöglichkeiten zum IPv6-Internet sucht, wird bei Sixxs[23] fündig.

Relativ einfach ist eine 6to4-Anbindung ohne einen NAT-Router zu realisieren. Wer ein wenig Erfahrung besitzt, kann sein Heimnetzwerk mit IPv4 und IPv6 betreiben, indem er einen Linux-Rechner als NAT-Router für IPv4 und gleichzeitig als IPv6-Router einsetzt. Für IPv4-NAT-Routing gibt es zahlreiche Lösungen. Einen guten Einstieg, wie man das mit iptables realisiert, gibt es bei karlrupp.net[24].

Anschließend muss das 6to4-Gateway aufgesetzt werden. Dazu bedient man sich zweckmäßigerweise des Script-Generators bei 64x.org[24], siehe Bild 6[25]. In das Eingabefeld kommt die eigene IPv4-Adresse. Nach dem Klick auf den 6to4-Button erscheint das fertige Script, siehe Bild 7[26]. Zweckmäßigerweise verwendet man in der letzten Zeile nicht die angezeigte Gateway-Adresse 78.47.86.5, sondern die Anycast-Adresse 192.88.99.1 oder ein anderes Gateway, das man kennt und von dem man weiß, dass es einen hohen Durchsatz bringt.

Das 6to4-Interface ist jetzt betriebsbereit, siehe Bild 8[27]. Mit tracepath oder traceroute kann man die IPv6-Anbindung testen, siehe Bild 5[28]. Anschließend lässt sich normales IPv6-Routing verwenden, um die anderen Rechner im Heimnetz anzubinden. Diese sollten über die Autokonfiguration automatisch eine gültige öffentliche IPv6-Adresse bekommen. Die obige Methode kann natürlich auch genutzt werden, um einfach mal eine IPv6-Anbindung mit einem Linux-Rechner auszuprobieren, ohne ihn gleich als Router für das Heimnetz zu nutzen.

Auch unter Windows lässt sich für IPv6 über ein 6to4-Gateway konfigurieren, wenn der Rechner eine öffentliche IP-Adresse hat. Das geht sogar einfacher als mit Linux. Microsoft hat den Dialog allerdings ausgezeichnet versteckt. Um ihn zu finden, öffnet man den Device Manager (Geräte-Manager) und wählt "View - Show hidden devices" (Ansicht - Ausgeblendete Geräte anzeigen). Danach findet man unter "Network adapters" (Netzwerkadapter) mindestens einen 6to4-Adapter. Mit einem Rechtsklick auf "Properties" (Eigenschaften) lässt sich der gesuchte Dialog öffnen. Bild 3[29] zeigt, wie man die Anycast-Adresse 192.88.99.1 eintragen kann. Der Rechner sollte nun ohne Neustart im IPv6-Netz sein. Mit dem Befehl tracert -6 kann man das testen, wie Bild 4[30] zeigt.

Schwieriger wird es, wenn man einen Windows-Client-Rechner als IPv4-NAT- und IPv6-Router für sein Heimnetz betreiben möchte. Generell ist Microsoft der Ansicht, dass man für IP-Routing einen Windows Server kaufen muss. Die dort enthaltene Routing-and-Remote Access-Komponente besitzt umfangreiche Funktionen und beherrscht unter anderem NAT-Routing. Auf einem Windows-Client-Computer kann man IP-Routing nur mit Registry-Tricks aktivieren. Hinzu kommt, dass eine NAT-Routing-Software von einem Dritthersteller nötig ist. Es empfiehlt sich daher eine Lösung unter Linux.

Um keine falschen Erwartungen zu wecken, sei vorweggenommen, dass wenig praktischer Nutzen aus einer IPv6-Anbindung resultiert. Das kann man leicht nachprüfen, indem man im DNS nachschaut, ob man einen Anbieter im Internet über IPv6 erreichen kann. Die Antwort ist fast immer nein. Dazu verwendet man unter Windows, Linux und Mac OS X den Kommandozeilenbefehl nslookup. Auf den meisten Unix-Derivaten bietet es sich an, die moderneren Tools dig und host zu nutzten. Sie stehen unter Windows standardmäßig nicht zur Verfügung. Man kann sie jedoch herunterladen[31].

Mit dem Befehl nslookup -querytype=AAAA www.microsoft.com findet man heraus, ob der Host www.microsoft.com über IPv6 erreichbar ist. Bild 9[32] zeigt, dass keine IPv6-Adresse als Antwort kommt. Das Ganze kann man mit Apple, Google, Red Hat und so weiter wiederholen. Nur wenige Knoten im Netz besitzen eine IPv6-Adresse, beispielsweise www.kame.net[33], siehe Bild 10[32]. Einige Websites, die sich meist mit dem Thema IPv6 beschäftigen, sind ausschließlich über IPv6 erreichbar. Die URL http://www.ipv6.uni-muenster.de/[34] funktioniert nur, wenn man am IPv6-Teil des Internets hängt.

Natürlich stellt sich die Frage, warum es kaum IPv6-Anbieter im Netz gibt. Schließlich fordern die Carrier seit Jahren IPv6, um ihre Router zu entlasten. In Asien gehen die IP-Adressen aus. Dort bekommt man schon lange als Privatanwender keine öffentliche IP-Adresse, auch nicht am heimischen Breitbandanschluss. Privatanwendern nützt es, wenn sie ihre Rechner und Geräte von jedem Ort aus einfach erreichen können, ohne dafür mit NAT-Routing, VPNs und Portweiterleitungen hantieren zu müssen. Schließlich ist es grundsätzlich möglich, IPv6 mit Technologien wie 6to4 und Teredo von jedem DSL-Anschluss aus zu nutzen.

Außerdem muss die Frage erlaubt sein, was Firmen wie AVM und D-Link daran hindert, ihren Routern die IPv6-Fähigkeit über 6to4 beizubringen. Das würde einen einfache Plug-and-play-Lösung für jedermann bedeuten. Der 6to4-Zugang scheint sich als Übergangslösung für einen gemischten Betrieb von IPv4 und IPv6 zu etablieren, bis die ISPs natives IPv6 anbieten.

Der Grund für die Zurückhaltung dürfte sein, dass ein gemischter Betrieb von IPv4 und IPv6 durchaus Probleme bereiten kann. Am wenigsten Ärger bereiten Betriebssysteme, die gar kein IPv6 unterstützen. Sie funktionieren in einer gemischten Umgebung mit IPv4. Dienste und Ziele, die IPv6 benötigen, sind nicht erreichbar. Schwieriger wird es, bei Betriebssystemen, die experimentelle Unterstützung für IPv6 bieten, etwa Windows XP ohne Service Pack. Hier muss man mit Schwierigkeiten rechnen.

Technisches Hauptproblem sind die Anwendungsprogramme. Neuere Versionen von Internet Explorer und Firefox beispielsweise sind voll IPv6-fähig und erkennen URL wie http://[2001:0123::5]:8080 als IP-Adresse und Port. Ältere Programme, die IPv6 nicht explizit unterstützen, sollten dennoch eine URL wie http://www.example.com korrekt auflösen und sich über IPv6 oder mindestens IPv4 verbinden können. Das tun sie jedoch häufig nicht.

ZDNet macht dazu einen Kurztest. In einem Intranet mit gemischtem IPv4 und IPv6 wird der Vista-Rechner "Client" mit Winamp 5.54[35] aufgesetzt. Auf einen zweiten Vista-Rechner mit dem Namen "Server" kommt ein Shoutcast[36]-Server. Der Versuch, das gestreamte Radio-Programm zu empfangen, schlägt fehl. Deinstalliert man IPv6 auf mindestens einem der beiden Rechner, gibt es keine Probleme.

Der Grund ist einfach: Winamp erhält die URL http://Server:8000 und löst sie über das API gethostbyname auf. Windows erkennt, dass der Rechner Server sowohl über IPv6 als auch über IPv4 erreichbar ist. Windows versucht es über IPv6, da Winamp keine Vorgabe gemacht hat. Nun geht allerdings etwas schief. Entweder prüft Winamp überflüssigerweise, ob die Socketadresse 32 Bit lang ist, oder der Shoutcast-Server hört nicht auf den Port 8000 des IPv6-Interfaces. Das hat ZDNet im Kurztest nicht weiter geprüft. Wahrscheinlich hätte man das Problem durch Editieren von Config-Files sogar in den Griff bekommen. Das Beispiel zeigt jedoch, dass auch aktuelle Programme, die sich um IPv6 keine Gedanken machen, Probleme bereiten können, die es erst zu lösen gilt.

So erklärt sich auch, dass Unternehmen wie Microsoft, RedHat und Google keine IPv6-Adressen im DNS veröffentlichen. Auf diese Weise werden Probleme von vornherein eliminiert. Schließt man die Kommunikation über IPv6 aus, läuft der Verkehr über IPv4 und nimmt seinen gewohnten Lauf.

Nicht verschweigen darf man, dass es Unternehmen gibt, die durchaus ein Interesse daran haben, dass sich IPv6 nicht so schnell durchsetzt. Bereits erwähnt wurde das Beispiel von Mobilfunkunternehmen, die weniger Umsatz machen, wenn ihre Kunden Festnetzanrufe per VoIP und IPv6 an das Handy weiterleiten.

Generell müssen Telefongesellschaften befürchten, dass man in Zukunft überhaupt keine Gebühren mehr für Telefonate verlangen kann. Wenn Anwender jedem Gerät eine global erreichbare IPv6-Adresse geben können, und VoIP-Konfiguration somit ein Kinderspiel ist, dann gibt es eigentlich keinen Grund mehr, eine Telefongesellschaft für die Vermittlung und Führung eines Gesprächs zu bezahlen. Die Umsetzung von Telefonnummern auf SIP-Adressen lässt sich mit ENUM[37] problemlos durchführen.

Auch Hoster müssen um einen Teil ihres Umsatzes fürchten. Wenn in Ballungsgebieten in Zukunft Internet-Anschlüsse mit 100 MBit/s vorherrschen, dürften sich mit den Möglichkeiten von IPv6 viele Unternehmen entscheiden, ihre Server wieder inhouse zu betreiben. Ebenso müssen Gameserver von Privatleuten nicht mehr zwangsweise in einem Rechenzentrum angemietet werden.

Ein weiteres Problemthema ist die Sicherheit. Preiswerte Out-of-the-Box-Lösungen für Security mit IPv6 gibt es Stand heute nicht. Unternehmen scheuen sich davor, jedem Rechner eine öffentliche IPv6-Adresse zu geben. Theoretisch lässt sich mit Technologien wie IPSec und Firewalling die gleiche Sicherheit herstellen wie mit privaten IP-Adressen. Praktisch besteht aber die berechtigte Befürchtung, dass neue Konzepte und Implementierungen auch neue Sicherheitslücken aufwerfen.

Man darf sogar erwarten, dass große Unternehmen IPv6 noch lange nicht einführen werden. Sie haben teilweise viel Geld investiert, um Netzwerk- und Sicherheitskonzepte zu realisieren. Viele Tools und Monitoringprogramme sind IPv4-spezifisch. Auch eine schrittweise Einführung kostet Geld und passt nicht zur Quartalsgewinnmaximierungsstrategie großer Unternehmen.

Privatanwender müssen ebenfalls mit Sicherheitsproblemen rechnen. Die heutigen 6to4-Gateways haben keine Sicherheitsfeatures. Ein IP-Spoofing ist leicht möglich. Allerdings muss man die Dinge realistisch sehen. Cyberkriminelle haben nicht einmal die Mac-OS-Plattform als lohnendes Ziel entdeckt. Dass sie versuchen, die wenigen IPv6-Frühadopter zu attackieren, ist unwahrscheinlich.

Bedenken gibt es nicht zuletzt von Datenschutzseite. Mit dynamischen IP-Adressen ist IPv6 nicht sonderlich sinnvoll. Abgesehen davon, dass man heute keine DynDNS[38]-Provider für IPv6 findet, müsste jedes Endgerät seine IPv6-Adresse selbst an den DynDNS-Provider melden, sofern man keinen Agent betreiben möchte, der die Adressen des Intranets sammelt.

Man kann zwar aus einer statischen IPv6-Adresse nicht direkt den Anschlussbetreiber ermitteln, ist der jedoch einmal bekannt, weil der Anschlussbetreiber seinen Webserver mit Impressum im statischen IPv6-Adressraum betreibt, so könnten Datensammlungen entstehen, welche IP-Adresse zu welchem Anschlussinhaber gehört.

Hier müsste man die Provider verpflichten, dass Benutzer auf Wunsch mit einer dynamischen Adresse ins Internet gehen können, die sich mindestens täglich ändert. Dazu bedarf es einer einfachen Lösung, die jedermann verlässlich benutzen kann. Vom Prinzip her könnte das ähnlich funktionieren wie Tor[39], nur dass die Performance nicht leidet, weil die Anonymisierung direkt beim Provider erfolgt.

In Europa und in den USA spüren Anwender im Vergleich zu Asien relativ wenig von den Restriktionen, die IPv4 und NAT-Routing mit sich bringen. Hierzulande tauchen Probleme bestenfalls beim mobilen Zugang auf. Am Festanschluss bekommt man üblicherweise mindestens eine öffentliche IP-Adresse, so dass man sich mit Technologien wie NAT, Portforwarding und VPNs behelfen kann, auch wenn eine VoIP-Konfiguration hinter dem NAT-Router zu einer Herausforderung wird, die viele Anwender nicht bewältigen können.

IPv6 scheint diese Probleme auf einen Schlag zu lösen. Mit dem neuen Protokoll kann jeder Rechner und jedes internetfähige Gerät eine öffentliche IP-Adresse erhalten. Das liegt im Ermessen des Benutzers. Anwendungen für VoIP, Remote Assistance, Live Meeting können aufgesetzt werden, ohne dass man sich in die Tiefen des NAT-Routing einarbeiten muss.

Die neuen Möglichkeiten finden allerdings mitnichten ausschließlich Befürworter. Telefongesellschaften fürchten um ihre Gesprächsgebühren, Hoster sehen einen Teil ihrer Server wieder inhouse beim Kunden stehen. Nicht zuletzt spielen datenschutzrechtliche Aspekte eine Rolle, da IPv6 erst richtig genutzt werden kann, wenn alle Teilnehmer feste IP-Adressen bekommen.

Auf reiner Netzwerkebene funktioniert IPv6 heute problemlos. Nahezu alle Betriebssystemhersteller haben IPv6-Stacks in Produktionsqualität. Von einem Rechner mit öffentlicher IP-Adresse kann sich heute jeder Zugang zum Internet mit IPv6 verschaffen. Ebenso gibt es Lösungen für Rechner hinter einem NAT-Router.

Wer sich heute entscheidet, IPv6 einmal auszuprobieren, muss sich im Klaren darüber sein, dass dies primär etwas für die persönliche und berufliche Weiterbildung bringt. Wenn in einigen Jahren tatsächlich ernsthaft mit einer Umstellung auf IPv6 begonnen wird, dann ist man für die Zukunft gerüstet und kennt die Möglichkeiten, die IPv6 bietet.

Sinnvoll ist es vor allem, sich auch mit Problemen in einer gemischten Umgebung zu beschäftigen. Probleme machen vor allem Anwendungen, die keine explizite Unterstützung für IPv6 beinhalten. Das kann in gemischten Umgebungen dazu führen, dass keine Verbindung zustande kommt.

URLs in diesem Artikel:
[1] = http://www.silicon.de/cio/b2b/0,39038988,39190463,00/vint+cerf+_ipv6+schnell+einfuehren.htm
[2] = http://www.zdnet.de/news/tkomm/0,39023151,39196747,00.htm
[3] = http://www.zdnet.de/galerie/39201431/so-konfigurert-man-ipv6-am-dsl-anschluss.htm#sid=39201232
[4] = http://www.zdnet.de/sicherheit_in_der_praxis_server_zu_hause_hosten_sichere_dienste_ueber_den_dsl_anschluss_story-39001543-39201064-1.htm
[5] = http://www.zdnet.de/sicherheit_in_der_praxis_sicherer_zugriff_auf_unsichere_dienste_so_nutzt_man_stunnel_story-39001543-39197451-1.htm
[6] = http://de.wikipedia.org/wiki/Upnp
[7] = http://de.wikipedia.org/wiki/NAT_Port_Mapping_Protocol
[8] = http://msdn.microsoft.com/en-us/library/aa965913(VS.85).aspx
[9] = http://de.wikipedia.org/wiki/Hspa
[10] = http://www.zdnet.de/sicherheit_in_der_praxis_vpn_ohne_grenzen_per_tunnel_durch_die_firewall_story-39001543-39190212-1.htm
[11] = http://www.zdnet.de/enterprise/server/0,39035443,39201431-1,00.htm
[12] = http://www.zdnet.de/enterprise/server/0,39035443,39201431-2,00.htm
[13] = http://de.wikipedia.org/wiki/CIDR
[14] = http://tools.ietf.org/html/rfc3775
[15] = http://www.microsoft.com/germany/technet/datenbank/articles/600560.mspx#ERG
[16] = http://www.tal.de/
[17] = http://tools.ietf.org/html/rfc3056
[18] = http://www.6to4.64x.org/e107_plugins/nwtools/6to4.php
[19] = http://www.decix.com/
[20] = http://de.wikipedia.org/wiki/Ipsec
[21] = https://www.0x1b.ch/blog/1201021372/index_html
[22] = http://en.wikipedia.org/wiki/ISATAP
[23] = http://www.sixxs.net/
[24] = http://www.6to4.64x.org/e107_plugins/nwtools/64.php
[25] = http://www.zdnet.de/enterprise/server/0,39035443,39201431-6,00.htm
[26] = http://www.zdnet.de/enterprise/server/0,39035443,39201431-7,00.htm
[27] = http://www.zdnet.de/enterprise/server/0,39035443,39201431-8,00.htm
[28] = http://www.zdnet.de/enterprise/server/0,39035443,39201431-5,00.htm
[29] = http://www.zdnet.de/enterprise/server/0,39035443,39201431-3,00.htm
[30] = http://www.zdnet.de/enterprise/server/0,39035443,39201431-4,00.htm
[31] = http://serghei.net/windows/dig/
[32] = http://www.zdnet.de/enterprise/server/0,39035443,39201431-9,00.htm
[33] = http://www.kame.net
[34] = http://www.ipv6.uni-muenster.de/
[35] = http://www.winamp.com/
[36] = http://www.shoutcast.com/
[37] = http://de.wikipedia.org/wiki/Telephone_Number_Mapping
[38] = http://de.wikipedia.org/wiki/Dyndns
[39] = http://de.wikipedia.org/wiki/Tor_(Netzwerk)