IPv6 in Kürze
Grundsätzlich kann IPv6 alles, was auch IPv4 kann, hat aber wesentlich mehr IP-Adressen. Diese IP-Adressen wiederum sind die Basis der Internet-Kommunikation: sie sind quasi das "Benzin" des Internets, ohne sie geht nichts. Langsam geht dieses "Benzin" aber zuneige, daher kommt mit IPv6 eine "neue" Energiequelle an den Start, die das gleiche kann, uns aber nicht mehr so schnell ausgehen wird.

Technisch sind Adressen des bislang genutzten Internet Protokolls Version 4 (IPv4) nicht unbegrenzt verfügbar, es gibt rechnerisch "nur" rund 4,3 Milliarden. Durch verschiedene Fehler der Vergangenheit (die man größten Teils bereits Mitte der 1990er Jahre behoben hat) und das unerwartet hohe Wachstum im Internet der letzten 15 Jahre werden voraussichtlich im Sommer nächsten Jahres der Internet Assigned Numbers Authority die IPv4-Adressen ausgehen. Sie kann dann die "IPv4-Lager" der darunter angesiedelten regionalen Internet Registries wie RIPE und ARIN nicht weiter auffüllen, denen gegenüber wiederum die Internet Service Provider ihren Bedarf an  IPv4-Adressen nachweisen und entsprechend erhalten. Soll das Internet weiter wachsen, braucht man für "danach" eine Alternative.

Auch das Nachfolgeprotokoll IPv6 wurde bereits Mitte der 1990er Jahre begonnen und gegenüber IPv4 um viele Features erweitert, die man als wichtig ansah. Die wichtigsten (z. B. IP/Sec) wurden allerdings sukzessive auch für IPv4 verfügbar  oder sind in der heutigen Realität nicht so einfach nutzbar, wie man es sich mal gedacht hat (Quality of Service per Flow, Mobile IP). Bei Quality of Service ist beispielsweise zu befürchten, dass  jeder Filesharer "seine" Datenpakete als "besonders wichtig" markiert, um "besonders schnell" an seine Daten zu kommen. Ohne klare Regelungen zwischen den Providern wird sich daher kaum ein Provider auf die QoS-Werte verlassen, die "irgendjemand" im Internet "einfach so" gesetzt hat. Im Wesentlichen ist damit von IPv6 also nur "mehr Adressen" übrig geblieben - aber das allein ist inzwischen wichtig genug.

IPv4 und IPv6 können nicht direkt miteinander kommunizieren, sondern bilden quasi zwei getrennte Netzwerke. Wer also "nur" IPv6 hat, braucht weiterhin (etwas) IPv4, um mit dem "alten" IPv4-Internet zu reden. "Pure" IPv6-Verbindungen machen heute nur als einen sehr niedrigen Prozentsatz des Internet-Traffics aus, über IPv4-Adressen kann man aber das gesamte Internet erreichen - weil eben auch jeder IPv6-Nutzer im IPv4-Internet erreichbar sein möchte. Aus Sicht der Content-Provider (Hosting, Portale, etc.) und der Access-Provider (z.B. DSL-Anbieter) war daher lange Zeit die Frage: warum Zeit und Geld in etwas stecken, was keiner benutzt?

Dieser Teufelskreis zwischen Access und Content konnte lange nicht so recht zerschlagen werden.
Erst die späte Einsicht, dass die beschränkte Anzahl von IPv4-Adressen auch das Wachstum des Internets limitiert und dass dieses Limit in den nächsten Jahren eintreten wird, führt nun dazu, dass die verschiedenen Provider, Softwareentwickler, Hardwarehersteller der Reihe nach aufwachen und sich "ernsthaft"  auf IPv6 vorbereiten.

Wie lange reichen IPv4 und IPv6?

Je nach Wahrsager und Trübung der Glaskugel schwanken die "exakten" Termine für IPv4. Zusätzlich zur vielzitierten Prognose von Geoff Huston (APNIC) emfehle ich auch gern die Prognose von Stephan Lagerholm (IANA), die auf einem etwas anderen mathematischen Modell basiert und das jeweilige Datum um 1-2 Monate vorrückt. Die jeweiligen Prognosen werden immer wieder feinjustiert und an die aktuelle Realität angepasst, dadurch verschiebt sich das "exakte" Datum durchaus immer wieder; die Abstände sind aber immer geringer, so dass man inzwischen den Zahlen recht gut trauen kann.

Zusammen mit allen "Restbeständen" von IANA, Regionalen Internet Registries und den Providern reichen die IPv4-Adressen bei gleichbleibendem Wachstum noch bis etwa Ende 2012. Als Provider wird man schon in naher Zukunft nicht mehr zehntausende, sondern maximal 1024 IPv4-Adressen erhalten.

Bei IPv6 gibt es nicht mehr 32 Bit, sondern 128 Bit an Information für die Adresse. Jedes weitere Bit an Information verdoppelt dabei die Anzahl der IP-Adressen: wir reden also nicht mehr von 4,3 Milliarden, sondern von 340 Sextillionen möglichen Adressen. Böse Zungen behaupten, mit IPv6 könnte man jedes Atom des Universums, mindestens aber der Erdoberfläche einzeln adressieren.

Etwas anschaulicher wird die Verdoppelung pro Bit bei der Weizenkornlegende vom Erfinder des Schachspiels: für das erste der 64 Felder verlangte er von seinem König ein Reis- oder Weizenkorn (je nach Erzähler), für  jedes weitere Feld das Doppelte des jeweils vorherigen Feldes. Der König willigt voreilig ein, ehe er merkte, dass die Ernte seines ganzen Landes nicht ausreicht, um auch nur einen Bruchteil der Menge an Körnern aufs letzte Feld zu legen. Bei IPv6 wird mit 128 Bit gerechnet, d.h. das Schachbrett wäre doppelt so gross und das "Körnerlegen" könnte um ein Vielfaches länger durchgespielt werden.

Die Menge an IPv6-Adressen ist so hoch, dass man jedem einzelnen IPv6-Nutzer einfach pauschal mindestens 64 Bit an IPv6-Adressen zugesteht und jedem Internet Service Provider ohne weitere Fragen 96 Bit an IPv6-Adressen zuteilt. Schon der einfache IPv6-Nutzer hat so ein 4,3-Milliarden-faches an IPv6-Adressen dessen, was mit IPv4 im Internet theoretisch möglich wäre. Trotz dieser enormen Verschwendung werden in Summe so nur ca. 15% der möglichen IPv6-Adressen verteilt: sollte sich also in 20 Jahren herausstellen, dass uns die IPv6-Adressen ausgehen, hat man noch 85% möglicher IPv6-Adressen, mit denen man sparsamer umgehen kann. Ein Ende von IPv6 ist also trotz der aktuellen "Verschwendungssucht" weder abzusehen noch im gröbsten zu erraten.

Wann muss ich etwas tun?

Die verschiedenen "Exhaustion" oder "Depletion" Counter suggerieren ein Ende des Internets im Sommer nächsten Jahres, voraussichtlich aber erst gegen Ende 2012 wird der erste Provider weder freie IPv4-Adressen  haben noch neue erhalten und so gezwungen sein, seine neuen Dienste dann nur noch via IPv6 anbieten. Was auch immer derjenige dann anbieten möchte: er muss darauf setzen, dass nicht nur er, sondern auch der Rest des Internets IPv6 kann. Um das zu erreichen, muss jeder Provider, Hard- und Softwarehersteller spätestens heute dafür sorgen, daß IPv6 in allen Produkten berücksichtigt wird, die Ende 2012 verbreitet sein werden.

Für Endanwender hinter dem heimischen DSL-Anschluss ist das recht einfach: die Betriebssysteme seit Windows XP können gut IPv6 sprechen und Migrationstechniken wie 6to4 können bereits heute dafür sorgen, daß man an jedem normalen DSL-Anschluss automatisch ein getunneltes IPv6 erhalten kann, das kaum ein Prozent an Leistungsverlust gegenüber "nativem" IPv6 aufweist. Das Sommer-Update der aktuellen Fr!tz-Boxen ist hier beispielsweise ein wichtiger Schritt, durch den bereits heute viele DSL-Anwender IPv6 nutzen können, obwohl die BRAS am eigenen DSLAM noch nicht für "echtes" IPv6 vorbereitet sind. Und andere Migrationstechniken wie Teredo sorgen dafür, dass selbst Rechner hinter einem DSL-Router ohne diese Techniken IPv6 nutzen können, wenn ein Dienst nicht mehr per IPv4 erreichbar wäre. Soweit die Situation heute: wir arbeiten aber daran, IPv6 "richtig" am DSL-Anschluss anbieten zu können.

Das ist allerdings noch nicht die ganze Praxis: zwar sind z. B. Betriebssysteme, Webbrowser und E-Mail-Programme in der Regel inzwischen alle IPv6-fähig, einige andere Anwendungen aber noch nicht. Das kann ein Onlinespiel sein, aber auch die Personal Firewall, die etwa IPv6-Traffic  nicht beachtet (schlecht) oder aber nicht durchlässt (noch schlechter). Im Zweifelsfall: einfach mal den Hersteller fragen.

Die 1&1 Hostingkunden erhalten im nächsten Jahr alle wesentlichen Vorbereitungen, damit ihre Website ohne Einschränkungen über IPv6 erreichbar ist. Wir können es allerdings den Kunden nicht ersparen, die eigenen Anwendungen zu aktualisieren, sofern diese IP-Adressen auswerten.

Für Kunden der 1&1 Root-Server bietet 1&1 schon länger an, sich einen IPv6-Tunnel legen zu lassen (formlose Mail an ipv6 (a) 1und1.de mit Vertragsnummer und erster IPv4-Adresse reicht) oder unsere 6to4-Relays zu benutzen. In beiden Fällen ist der Performanceverlust sehr gering, dennoch arbeiten wir daran, allen Serverkunden natives IPv6 zur Verfügung zu stellen. Allerdings gilt auch hier: wertet eine eigene Anwendung die IP-Adressen aus, muss diese Software vermutlich angepasst oder aktualisiert werden.

Wann das "wir arbeiten dran" erledigt ist? Das hängt in vielen Teilen auch davon ab, wann Drittanbieter und Partnerfirmen ihre Arbeiten  abgeschlossen haben. Genaue Termine sind daher aktuell genauso unzuverlässig sind wie die tagesexakten Prognosen, wann der IANA die IPv4-Adressen ausgehen werden.

ipv6.google.com beim Abschalten von "Google Instant"

Eines ist klar: Softwareanbieter und Internet Service Provider müssen spätestens heute anfangen, IPv6 umzusetzen. Aller Erfahrungen nach dauert es etwa 1-2 Jahre, bis die grossen Eigenentwicklungen an IPv6 angepasst sind. Selbst Firmen wie Google, die sehr offensiv das Thema IPv6 in die Presse bringen, brauchten mit ihrer Entwicklerschar etwa 1,5-2 Jahre, um von "null" an die wesentlichen Eigenentwicklungen an IPv6 anzupassen. Vollständig fertig ist man aber dort auch noch nicht.

Wie sieht es bei den Softwareentwicklern aus?

Damit man als Softwareentwickler IPv6-fähige Anwendungen entwickeln kann, braucht man etwas Unterstützung durch die APIs, Frameworks und Bibliotheken der eigenen Programmiersprache. Und hier beginnt schon ein Teil der holprigen Reise.

In C muss man klassischerweise sehr weit "unten" arbeiten, selbst DNS-Records auflösen und eine Verbindung selbst handhaben. Seit der Jahrtausendwende ist IPv6-Support in C vorhanden, in den folgenden Jahren kamen geradezu luxuriöse Erweiterungen wie getaddrinfo() hinzu. Die Funktion getaddrinfo löst einen DNS-Record auf und sortiert die Ergebnisse gemäss RFC 3484 (IPv6 bevorzugt, danach IPv4, zuletzt IPv6 via Teredo-Tunneling), so dass sie einem auch eine Reihe von Handarbeit ersparen kann.

Java unterstützt seit 2002 (JDK 1.4) transparent IPv4 und IPv6: gibt man beim Verbindungsaufbau zu einem fremden Server nur dessen DNS-Namen an, versucht die Java Virtual Machine von sich aus, den Server per IPv6, per IPv4 oder per Tunneling zu erreichen. Genauso ist ein in Java geschriebener Server automatisch per IPv4 und IPv6 erreichbar.

Auf ähnlichem Niveau bewegt sich hier auch PHP: gibt man einen DNS-Namen an, wird im Hintergrund gegebenenfalls eine IPv6-Verbindung aufgebaut. Soweit, so gut. Sobald man allerdings IP-Adressen aus dem DNS heraus auflösen oder mit IP-Adressen arbeiten möchte, ist leider viel Handarbeit angesagt. In PHP gibt es zum Beispiel für IPv4 und IPv6 verschiedene Pear-Module, mit denen man prüfen kann, ob man eine gültige IPv4- oder IPv6-Adresse vor sich hat. Und wer in PHP einen DNS-Namen auflösen möchte, hat die Wahl zwischen vier verschiedenen Methoden - wovon aber nur zwei für IPv6 einsetzbar sind (get_dns_record, Net_DNS).

Perls grosse Stärke sind die Module, die einem viele Arbeiten abnehmen können. Leider unterstützen die mitgelieferten Module IPv6 nahezu nicht, was wiederum  dazu führt, dass auch die Entwickler anderer Perl-Module bislang darauf und damit IPv6-Fähigkeiten verzichten. Grundsätzlich ist IPv6 in Perl möglich, durch die sehr unterschiedliche Unterstützung der verschiedenen Perlmodule kann es allerdings erschwert und so mehr Programmierarbeit notwendig sein, als man sich wünschen möchte.

Bei Ruby und Python sieht es etwas besser aus, immerhin erhielt z. B. Python bereits 2004 ersten IPv6-Support. Dennoch brachten auch jüngste Releases wie Ruby 1.9.2 vom August 2010 eine neue Socket-API mit IPv6-Support und Python 2.7 vom Juli 2010 ergänzte Standardmodule wie urlparse, imaplib und nntplib um IPv6.

Gemeinsam über alle Programmiersprachen hinweg besteht das Problem, dass die gleiche IPv6-Adresse verschieden gekürzt und so in verschiedenen Formaten dargestellt werden. Wer also IP-Adressen auswertet (z.B. bei einer Logfileauswertung) muss diese ggf. erst in ein gemeinsames Format überführen, ehe er sie auswerten kann.

Wie ist die Situation unter den Providern?

Bei 1&1 haben wir 1999 mit dem Thema IPv6 angefangen, bieten seit 2003 6in4-Tunnel für 1&1-Root-Server an und haben natives IPv6 seit 2005 in den Office-Netzen ausgewählter Technik-Abteilungen verschiedener Standorte, 2007 wurden die ersten eigenen Softwares für IPv6 angepasst. Auch eigene IPv6-Server betreiben wir seit einigen Jahren, darunter z. B. unsere Linux-Mirrorserver in Deutschland und USA - das Knowhow ist also grundsätzlich da, aber es bleibt weiterhin viel zu tun.

Die Mehrzahl anderer Provider hat IPv6 bereits seit Jahren, allerdings sieht man überall ähnliche Probleme: an einigen Stellen wird noch zuviel im "Handbetrieb" gemacht, z. B. mangels passender Software werden Router nicht automatisch konfiguriert und so weder wirtschaftlich noch in eindeutiger Qualität gearbeitet. Auch an anderen Stellen müssen die selbstentwickelten Softwares noch für IPv6 angepasst oder Schnittstellen neu abgestimmt werden.

Beispielsweise bestätigte Yahoo in seinen Folien der Google IPv6 Implementors Conference, dass  sie nicht vor Ende 2011 mit ihren Produkten via IPv6 online sein werden, weil einfach noch an sehr vielen Stellen Software anzupassen ist, die sehr eng miteinander verzahnt arbeitet. Anfang September gab der Techniker unserer Kollegen von Strato einen Überblick über verschiedene "offene Baustellen", die noch zu lösen sind und die auch ich genauso bestätigen kann.

Der "100%" IPv6-fähige Router, dessen IPv6-Fähigkeiten beim Management-Interface endeten und der über kein Routingprotokoll IPv6 verwenden konnte, ist leider keine Legende.

Viele Drittanbietern fangen aktuell erst mit dem Thema IPv6 an, arbeiten unter hohem Zeitdruck ("sonst geht im Sommer 2011 das Internet unter") und bei schlechter Qualitätssicherung, so dass immer wieder Detailprobleme auftreten. In Summe sorgen diese ganzen Arbeiten für einen noch nicht so wirtschaftlichen Betrieb, eine schlechtere Qualität und für eine ungewisse Nicht-Erreichbarkeit von Internet-Nutzern über IPv6. Ähnlich wie der Heise Verlag mit seinem IPv6-Tag startete das japanische Portal biglobe.ne.jp vor einigen Monaten mal einen Parallelbetrieb mit IPv4 und IPv6: dem Heise-Verlag wurden an seinem IPv6-Tag nahezu keine Probleme gemeldet, das japanische Portal hingegen verlor sofort 5% seiner Page Views und nahm notgedrungen nach wenigen Stunden seine IPv6-DNS-Einträge zurück (siehe hier). An Erfahrung fehlte es dabei nicht: auch Biglobe.ne.jp betreibt seit Jahren erfolgreich eine Reihe von Webservern mit IPv4 und IPv6. Bestimmte Fehler und Konstellationen sind aber eben so selten, dass man sie im eigenen Labor nicht entdecken kann - für die Internet-Provider quer durch die Branche hinweg bleibt also weiterhin viel zu tun.

Pseudo-Techniken

Wie im vorigen Abschnitt schon angesprochen, muss man für IPv6 eine Reihe von Programmen anpassen, und der typische Aufwand von ca.1,5-2 Jahren kommt vielen sehr unpassend.

Wessen Programmiersprache (wie z. B. C) einen dazu zwingt, explizit mit IP-Adressen zu arbeiten, muss seine Softwares in bestimmten Details anpassen. Solange man als Programmierer aber nicht explizit mit IP-Adressen arbeitet, hat man es bei den im Web verwendeten oder modernen Programmiersprachen recht schwer, IPv6 nicht zu unterstützen. In fast allen Progammiersprachen ist allerdings Entwicklungsaufwand nötig, sobald man IPv6-Adressen auswerten, mit ihnen rechnen oder weiter umgehen möchte.

Vermutlich um der "das Internet wird im Sommer 2011 untergehen"-Presse zuvor kommen, nutzen einige Anbieter Proxies und spezielle NAT-Systeme. Gegenüber einem IPv6-Brower tritt so ein System als IPv6-Webserver auf, zur eigenen Serverfarm spricht der Proxy aber nur noch IPv4. Auf einfache Weise kann man so "jede" IPv4-Anwendung in wenigen Minuten ins IPv6-Internet bringen und so eine "vollständige Vorbereitung" vorgaukeln - wenn da nicht ein paar Haken zu bedenken sind.

Aus Angst davor, durch Fehler Dritter beim IPv6-Zugriff eigene Kunden zu verlieren, werden diese Proxies nicht unter dem gleichen DNS-Eintrag veröffentlicht wie die eigentliche Website, sondern bekommen eine andere URL. So kommt es dann eben zu v6.facebook.com, six.heise.de und weiteren Variationen, deren Namensschema voneinander abweichen und nicht geeignet sind, "dauerhaft" Nutzer für einen "richtigen" Test zu gewinnen. Für einen ersten vorsichtigen Test des Anwenders, ob er IPv6 nutzen kann, mag das noch okay sein, viel mehr an Information gewinnt aber auch der Website-Betreiber nicht daraus. Da der Anwender ausser einer unmerkbaren Adresse nichts davon hat, bleibt so auch die Anzahl der Seitenabrufe über diese Spezial-URL auf Dauer gering. Der Proxy arbeitet dann nur noch, um mit "ich kann IPv6" werben zu können.

Durch den Proxy bzw. NAT-Router erhält die Anwendung keine Information, welche IPv6-Adresse auf den eigenen Dienst zugegriffen hat. Funktionen wie eine Reload- oder Klick-Sperre bei Countern sowie Login-Beschränkungen werden aber eben auch an der IP-Adresse festgemacht, dementsprechend kommt es hier zu Problemen. Auch bei Bestellungen wird die IP-Adresse protokolliert, um Missbrauch verfolgen zu können. Logins werden oft auf eine IP-Adresse beschränkt, damit nicht ein Dritter die Login-Session übernehmen kann. Und bei Maßnahmen im Rahmen der Telekommunikations-Überwachungsverordnung sind die Provider auch dazu verpflichtet, den berechtigten Behörden auch die IP-Adresse zu melden, von der aus auf das Postfach einer "überwachten" Person zugegriffen wird. Erscheinen IPv6-User nun alle unter einer gemeinsamen, eigenen IPv4-Adresse, führt das in Summe zu einem kleinen Chaos: verschiedene Sicherheitsfunktionen werden ausser Kraft gesetzt, rechtliche Verpflichtungen ignoriert.

Die IPv6-Adresse können verschiedene Proxy-Systeme auch als besonderen HTTP-Header an die Webanwendung weiterreichen. Damit das allerdings in der Praxis greift, müssen auch die Anwendungen darauf vorbereitet und angepasst werden: allerdings mit einem Aufwand, der einer "richtigen" IPv6-Anpassung vergleichbar ist oder diesen sogar übersteigt. In Summe ist dieser Proxy-Weg somit meiner Meinung nach eher ein weiteres Problem als eine universelle Lösung.

Für einen ersten, rudimentären Test der eigenen IPv6-Fähigkeiten ist ein Proxy durchaus geeignet, nicht aber für einen dauerhaften Betrieb; und somit erspart er einem auch nicht, seine IPv6-Hausaufgaben "richtig" zu machen.

Möchte man als "Surfer" wissen, ob über die eigenen Kombination und Konfiguration von Browser, Rechner, DSL-Router, Internetzugang und ggf. Tunnelingsystem vollständig auf IPv6-Inhalte zugegriffen werden kann, sollte man eher Websites wie testmyipv6.com (einfach) oder test-ipv6.com (detailiert) bemühen.

Möchte ein Website-Betreiber wissen, wie viele seiner Nutzer  IPv6 nutzen können, kann er auch Zählpixel auf seiner "echten" Website einbinden: einer auf einer IPv4-Adresse, ein weiterer auf einer IPv6-Adresse, ein dritter auf einem DNS-Eintrag, der beides anbietet. Durch Nachladen der Zählpixel via Javascript kann man auch vermeiden, dass die Website bei IPv6-Zugriffsproblemen nur noch mit langem Timeout laden sollte. Passende Zählpixel und eine einfache Auswertung dazu kann man sich beim IPv6 Deployment Monitoring einrichten.
Wer komplexere Auswertungen vor hat, sollte sich die Skripte vom Cisco-Techniker Erik Vyncke bei Sourceforge anschauen, dort wird sehr viel detaillierter unterschieden. Ein passender Zählpixel ist übrigens auch in diesem Artikel eingebunden.