IPv6

IPv6, das Internet Protocol Version 6, ist der Nachfolger des gegenwärtig im Internet noch überwiegend verwendeten Internet Protocol in der Version 4. Beide Protokolle sind Standards für die Netzwerkschicht des OSI-Modells und regeln die Adressierung und das Routing von Datenpaketen durch ein Netzwerk.

Warum ein neues Internet-Protokoll?

Das alte IPv4 bietet einen Adressraum von etwas über 4 Milliarden IP-Adressen, mit denen Computer und andere Geräte angesprochen werden können. In den Anfangstagen des Internet, als es nur wenige Rechner gab, die eine IP-Adresse brauchten, galt dies als mehr als ausreichend. Kaum jemand konnte sich vorstellen, dass überhaupt jemals so viele Rechner zu einem einzigen Netzwerk zusammengeschlossen würden, dass es im vorgegebenen Adressraum eng werden könnte.

Viele der theoretisch 4 Milliarden IP-Adressen jedoch sind in der Praxis nicht nutzbar, da sie Sonderaufgaben dienen (zum Beispiel Multicast) oder zu großen Teilnetzen (Subnetzen) gehören: Den ersten großen Teilnehmern am Internet wurden riesige Adressbereiche (so genannte Class-A-Netze) mit je 16,8 Millionen Adressen zugeteilt, die diese Organisationen bis heute behalten haben, ohne sie jemals voll ausnutzen zu können. Die Amerikaner (und teilweise die Europäer) teilten die relativ wenigen großen Adressbereiche unter sich auf, während die Internet-Späteinsteiger wie Südamerika, aber vor allem Asien, zunächst außen vor blieben.

Als Resultat herrscht besonders im zukünftigen IT-Wachstumsmarkt Asiens heute eine Adressenknappheit, der man mit Notbehelfen wie PAT (Port Address Translation = NAT Overloading), Lockerung der festen Netzklassen-Unterteilung durch CIDR (Classless Inter-Domain Routing), normalem NAT, oder dynamischer Vergabe von Adressen begegnen muss.

Auf Grund des Wachstums und der Wichtigkeit des Internet konnte dies kein Dauerzustand bleiben. Auch ist abzusehen, dass in den nächsten Jahren durch neue technische Innovationen (beispielsweise Mobiltelefone mit Internet-Anschluss, bald wohl auch Autos und Elektrogeräte in Privathaushalten) der Bedarf an Adressen auch im Rest der Welt ansteigen wird.

Hauptsächlich wegen der Adressknappheit, aber auch, um einige der Probleme zu lösen, die sich im Zuge der großräumigen Verwendung von IPv4 gezeigt hatten, begann man 1995 mit den Arbeiten an IPv6 (die ersten RFCs entstanden 1983 ff.). Die folgende Liste gibt einen Überblick über die wesentlichen neuen Eigenschaften von IPv6. Einige Punkte werden weiter unten näher erklärt:

Vergrößerung des Adressraums von 2³² (entspricht ~4,3 Milliarden Adressen) bei IPv4 auf 2¹²⁸ (entspricht ~340 Sextillionen Adressen) bei IPv6
Autokonfiguration von IPv6-Adressen, DHCP für IPv6, Mobile IP und vereinfachte Umnummerierung ("Renumbering")
Dienste wie IPSec, QoS und Multicast „serienmäßig“
Vereinfachung und Verbesserung der Protokollrahmen (Header). Dies ist insbesondere wichtig für Router.

Adressaufbau von IPv6

Eine IPv6-Adresse ist 128 Bit lang (IPv4: 32 Bit). Damit gibt es etwa 3,4 × 10³⁸ IPv6-Adressen. Das bedeutet, für jeden Quadratmillimeter Erdoberfläche könnten ca. 688,8896559 Billiarden Adressen (6,888896559 × 10¹⁷) bereitgestellt werden. (gerechnet mit dem Erdradius -> 6267 km)

IPv6-Adressen werden nicht in dezimaler (zum Beispiel 80.130.234.185), sondern in hexadezimaler Notation mit Doppelpunkten geschrieben, die die Adresse in acht Blöcke mit einer Länge von jeweils 16 Bit unterteilen. Beispiel einer IPv6-Adresse:

2001:0db8:85a3:08d3:1319:8a2e:0370:7344

Eine oder mehrere 16-Bit-Gruppen mit dem Wert 0000 können durch zwei aufeinanderfolgende Doppelpunkte ersetzt werden. Die resultierende Adresse darf höchstens einmal zwei aufeinander folgende Doppelpunkte enthalten. 2001:0db8::1428:57ab ist gleichbedeutend mit 2001:0db8:0000:0000:0000:0000:1428:57ab, aber 2001::25de::cade ist nicht korrekt, da nicht nachvollzogen werden kann, wie viele 16-Bit-Gruppen durch die zwei Doppelpunkte jeweils ersetzt wurden. Führende Nullen einer 16-Bit-Gruppe dürfen ausgelassen werden, 2001:db8::28:b ist gleichbedeutend mit 2001:0db8::0028:000b.

Die ersten 64 Bit der IPv6-Adresse dienen üblicherweise der Netzadressierung, die letzten 64 Bit werden zur Host-Adressierung verwendet. Das Konzept der Netzmasken von IPv4 wird durch Angabe der Präfixlänge des adressierten Subnetzes implementiert. Die Präfixlänge in Bits wird als Dezimalzahl mit vorangehendem "/" an die IPv6-Adresse angehängt. Beispiel: hat ein Netzwerkgerät die IPv6-Adresse

2001:0db8:85a3:08d3:1319:8a2e:0370:7344/64

so stammt es aus dem Subnetz

2001:0db8:85a3:08d3::/64

das mit den ersten 64 Bit seiner Adresse identifiziert wird. Analog gehört das Subnetz 2001:0db8:85a3:08d3::/64 hierarchisch zum Subnetz mit dem kürzeren Präfix 2001:0db8:85a3::/48.

Die korrekte Form einer IPv6-Adresse in einem URL ist beispielsweise

http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]/

Diese Notation verhindert die fälschliche Interpretation von Portnummern als Teil der IPv6-Adresse:

http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:443/

Arten von IPv6-Adressen

Es gibt verschiedene IPv6-Adressen mit Sonderaufgaben und unterschiedlichen Eigenschaften. Diese werden durch die ersten Bits der Adresse (das "Präfix") signalisiert:

Das Präfix 00 steht für IPv4 und IPv4-über-IPv6-Kompatibilitätsadressen. Ein geeigneter Router kann diese Pakete zwischen IPv4 und IPv6 konvertieren und so die neue mit der alten Welt verbinden. Zwei weitere Adressen tragen ebenfalls dieses Präfix; ::0 ist die undefinierte Adresse, ähnlich der 0.0.0.0 in IPv4, und ::1 ist die Adresse des eigenen Standortes (localhost, loopback device).
Die Präfixe 2 oder 3 stehen für globale Unicast-Adressen, also eine routbare und weltweit einzigartige Adresse.
- Eine Abart davon sind die 6Bone-Testadressen 3ffe, die einem Rechner gehören, der Teil des IPv6-Testnetzwerkes 6Bone ist (der 6Bone wird am 6. Juni 2006 eingestellt).
- 2001-Adressen werden an Provider vergeben, die diese dann wieder an ihre Kunden verteilen
- 2002-Präfixe deuten auf Adressen des Tunnelmechanismus 6to4 hin.
fe80 bis febf sind so genannte linklokale Adressen (link local addresses), die von Routern nicht weitergeleitet werden dürfen und daher nur im gleichen Teilnetz erreichbar sind. Interessant werden sie bei der Autokonfiguration.
Adressen mit Präfixen fec0 bis feff waren die Nachfolger der privaten IP-Adressen (beispielsweise 192.168.x.x). Sie dürfen nur innerhalb der gleichen Organisation geroutet werden. Man nennt sie auch Site-local (standortlokal). Diese Adressen sind nach RFC 3879 inzwischen veraltet (engl. deprecated) und werden aus zukünftigen Standards möglicherweise verschwinden.
Die Nachfolger der standortlokalen Adressen (Site-local addresses) sind wohl die Unique Local Addresses mit den Präfixen fc und fd, mehr dazu siehe unten.
Das Präfix ff steht für Multicast-Adressen. Dem Präfix folgen Angaben über den Gültigkeitsbereich des Pakets. Anstelle des x in der folgenden Aufstellung steht jeweils eine 0, wenn es sich um eine permanente Multicastgruppe handelt, und eine 1, wenn die Gruppe nur temporär besteht:
- ffx1: knotenlokal, diese Pakete verlassen den Knoten nie.
- ffx2: linklokal, werden von Routern grundsätzlich nie weitergeleitet und können deshalb das Teilnetz nicht verlassen.
- ffx5: sitelokal, dürfen zwar geroutet werden, jedoch nicht von Border-Routern.
- ffx8: organisationslokal, die Pakete dürfen auch von Border-Routern weitergeleitet werden, bleiben jedoch "in der Firma" (hierzu müssen seitens des Routing-Protokolls entsprechende Vorkehrungen getroffen werden).
- ffxe: globaler Multicast, der überall hin geroutet werden darf.

Autokonfiguration

Ein IPv6-Stack kann aus der Layer 2-MAC-Adresse eines Interfaces eine so genannte link-lokale Adresse errechnen, mit der ein Gerät sich auf die Suche nach den Routern in seinem Netzwerksegment machen kann. Dies geschieht durch eine Anfrage an die Multicast-Adresse ff02::2, über die alle Router eines Links erreichbar sind. Ein Router versendet auf diese Anfrage hin u.a. Informationen über den Adressbereich, aus dem ein Gerät sich selbst eine Unicast-Adresse zuweisen darf. Die doppelte Vergabe einer Adresse wird durch einen Vorgang verhindert, der "Duplicate Address Detection" (DAD – Erkennung doppelt vergebener Adressen) genannt wird. Die DAD muss von jedem Gerät nach der Wahl einer Adresse durchgeführt werden. Ein Gerät darf bei der Autokonfiguration nur unvergebene Adressen auswählen. Dieser Vorgang läuft ohne Benutzereingriff vollautomatisch ab.

Die IPv6-Autokonfiguration unterscheidet sich konzeptionell von DHCP bzw. DHCPv6. Während bei der Adressvergabe durch DHCPv6 (definiert in RFC 3315) von "Stateful Address Configuration" gesprochen wird (sinngemäß: Adressvergabe, über die Buch geführt wird, etwa durch einen DHCP-Server), ist die Autokonfiguration eine "Stateless Address (Auto)Configuration", da Geräte sich selbst eine Adresse zuweisen und über diese Vergabe kein Buch geführt wird. Da die Autokonfiguration keine Informationen über Host-, Domainnamen, DNS, NTP-Server etc. berücksichtigt, kann sie durch den Einsatz eines DHCPv6-Servers ergänzt werden. Dieser liefert die gewünschten Zusatzinformationen, kümmert sich dabei aber nicht um die Adressvergabe. Man spricht in diesem Fall von Stateless DHCPv6 (vgl. RFC 3736). Mechanismen wie Stateless DHCPv6 oder dynamisches DNS (Geräte tragen ihren Namen selbst im DNS ein, nicht zu verwechseln mit DynDNS) können die IPv6-Autokonfiguration sinnvoll ergänzen.

Der EUI-64-Name der MAC-Adresse bildet bei der IPv6-Autokonfiguration in der Regel die letzten 64 Bit der IPv6-Adresse, es sei denn, die sog. "Privacy Extension" (s.u.) wird verwendet. Wegen einer Verwechslung in RFC 2460 wird der Algorithmus, um EUI-64-Namen aus EUI-48-Namen zu berechnen, fälschlicherweise auf MAC-48-Namen angewandt (Siehe auch: Diskussion darüber).

Umnummerierung

Unter IPv4 ist die Umnummerierung (engl. Renumbering; Änderung des IP-Adressbereichs z.B. beim Provider-Wechsel) für Netze ab einer gewissen Größe ein problematisches Unterfangen, wenn sie manuell durchgeführt werden muss. Mechanismen wie DHCP können bei der Umnummerierung helfen, trotzdem ist der Vorgang nicht trivial. Speziell der sukzessive Übergang von einem Provider zum nächsten ohne ein "hartes" Umschalten zu einem festen Zeitpunkt ist schwierig, da dies nur dann möglich ist, wenn das Netz für einen gewissen Zeitraum multihomed ist. Multihoming bedeutet in diesem speziellen Fall (Provider-Wechsel), dass ein Netz gleichzeitig von mehr als einem Provider mit Internet-Anbindung und IP-Adressbereichen versorgt wird. Die Umnummerierung unter IPv4 führt teilweise zur Fragmentierung des Adressraums in der Default Free Zone (DFZ), d.h. es werden vergleichsweise kleine Netze bis in die Routing-Tabellen der DFZ propagiert. Für die Router resultiert diese Vergrößerung der Routing-Tabellen in Leistungsverlust.

Der Vorgang der Umnummerierung wurde beim Design von IPv6 hingegen berücksichtigt. Mechanismen wie die IPv6-Autokonfiguration helfen bei der Umnummerierung erheblich. Der parallele Betrieb mehrerer IP-Adressbereiche gestaltet sich unter IPv6 ebenfalls unproblematischer als unter IPv4. Der Vorgang der Umnummerierung wird unter anderem im RFC 4076 behandelt, wo die wesentlichen Problematiken dieses Vorgangs beschrieben werden. Das Ziel eines sauber implementierten Renumberings ist u.a., dem Betreiber eines Enterprise-Netzwerkes die unkomplizierte, kurzfristige und freie Wahl von Providern zu ermöglichen und damit letztendlich den Wettbewerb der Provider untereinander zu steigern.

Mobile IPv6

Mobile IP wurde als Erweiterung des IPv6-Standards unter dem Namen "Mobile IPv6" (RFC 3775) in das IPv6 Protokoll integriert. Hierbei geht es darum, unter der gleichen IP-Adresse überall erreichbar zu sein, beispielsweise im heimischen Netzwerk und auf einer Konferenz. Normalerweise müssten dazu aufwändig Routing-Tabellen geändert werden. Mobile IPv6 benutzt stattdessen einen Schatten-Rechner ("Home Agent", HA), der das Mobilgerät in seinem Heimnetz vertritt. Eingehende Pakete werden durch diesen HA an die momentane Adresse ("Care-of-Address", CoA) des Mobilgeräts getunnelt. Der HA bekommt die aktuelle CoA des Mobilgerätes durch "Binding Updates" mit, die das Gerät an den HA sendet, sobald es eine neue Adresse im besuchten Fremdnetz erhalten hat.

Unique Local Addresses

Für private Adressen gibt es die Unique Local Addresses (ULA), wie beschrieben in RFC 4193. Dabei unterscheidet man zwischen lokal generierten ULA mit dem Präfix fd und global zugewiesenen eindeutigen ULA mit dem Präfix fc. Auf dieses Präfix folgen dann 40 Bits, die als eindeutige Site-ID fungieren. Diese Site-ID ist bei den ULA mit dem Präfix fd zufällig zu generieren und somit nur sehr wahrscheinlich eindeutig, bei den global vergebenen ULA jedoch auf jeden Fall eindeutig (RFC 4193 gibt jedoch keine konkrete Implementierung der Zuweisung von global eindeutigen Site-IDs an). Nach der Side-ID folgt eine 16-bit Subnet-ID, welche ein Netz innerhalb der Site angibt.

Eine Beispiel-ULA wäre fd9e:21a7:a92c:2323::1. Hierbei ist fd der Präfix für lokal generierte ULAs, 9e:21a7:a92c ein einmalig zufällig erzeugter 40-bit Wert und 2323 eine willkürlich gewählte Subnet-ID.

Die Verwendung von eindeutigen bzw. wahrscheinlich eindeutigen Site-IDs hat den Vorteil, dass z.B. beim Einrichten eines Tunnels zwischen getrennt voneinander konfigurierten Netzwerken Adresskollisionen nicht auftreten bzw. relativ unwahrscheinlich sind. Weiterhin wird erreicht, dass Pakete, welche an eine nicht erreichbare Site gesendet werden, immer bzw. mit großer Wahrscheinlichkeit ins Leere laufen, anstatt an einen lokalen Host, welcher die selbe Adresse hat, gesendet zu werden.

Neues Header-Format und Effizienzsteigerung

Im Gegensatz zu IPv4 hat der IP-Header bei IPv6 eine feste Länge. Optionale Informationen werden in sogenannte Erweiterungs-Headern (engl.: Extension Headers) zwischen dem IPv6-Header und der eigentlichen Nutzlast (engl. Payload) eingebettet. Der Header eines IPv6-Paketes setzt sich aus den folgenden Feldern zusammen:

Der Header eines IPv6-Paketes

Feld	Länge	Inhalt
Version	4 Bit	IP-Versionsnummer (6)
Traffic Class	8 Bit	Für Quality of Service (QoS) verwendeter Wert
Flow Label	20 Bit	Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert
Payload Length	16 Bit	Länge des IPv6-Paketinhaltes (ohne Header aber inklusive der Erweiterungs-Header)
Next Header	8 Bit	Identifiziert den Typ des nächsten Extension Headers
Hop Limit / TTL	8 Bit	Maximale Anzahl an Zwischenschritten über Router, die ein Paket zurücklegen darf; wird beim Durchlaufen eines Routers ("Hops") um Eins verringert. Pakete mit Null als Hop Limit werden verworfen
Source Address	128 Bit	Adresse des Senders
Destination Address	128 Bit	Adresse des Empfängers

Die Fragmentierung überlanger IPv6-Pakete erfolgt nicht mehr durch den Router selbst, der Absender wird stattdessen mit Hilfe von ICMP-Nachrichten aufgefordert, kleinere Pakete zu schicken (siehe in diesem Zusammenhang Maximum Transfer Unit (MTU) und Path MTU). Idealerweise sollte ein IPv6-Host vor dem Versenden einer großen Anzahl von IPv6-Paketen eine Path MTU Discovery gemäß RFC 1981 durchführen, um Pakete mit maximal möglicher Größe verschicken zu können, was eine Leistungssteigerung bewirkt. Weiterhin werden (im Gegensatz zu IPv4) keine Prüfsummen mehr über das IP-Paket berechnet, es wird nur noch die Fehlerkorrektur in den Schichten 2 und 4 genutzt. Dadurch entfällt die Fehlerbehandlung in Schicht 3 durch den Router. Die meisten Felder der Header sind auf 64-Bit-Grenzen ausgerichtet, um Speicherzugriffe im Router zu beschleunigen.

IPv6 macht intensiv Gebrauch von Multicast, der von jedem Host beherrscht werden muss. Das ARP-Protokoll wurde beispielsweise durch das neue Verfahren "Neighbor Solicitation" ergänzt: Die MAC-Adresse eines Hosts lässt sich nun auch über eine aus seiner IP gebildeten Multicastgruppe herausfinden.

Probleme

Gerade zu Anfang litt IPv6 unter einigen Kinderkrankheiten, die dem neuen Protokoll den Ruf einer "Totgeburt" einbrachten. Die Standards wurden häufig geändert, was einigen Unmut erzeugte, da man die gerade fertig gewordenen Implementierungen schon wieder verwerfen musste. Der größte Einschnitt bestand in der Einführung der IEEE-Norm EUI-64 für die linklokalen Adressen. Vorher übernahm man die MAC-Adresse des Adapters einfach in die IPv6-Adresse, nun wurde die MAC-Adresse gemäß EUI-64 in veränderter Form in die IPv6-Adresse übernommen. Das änderte jedoch nichts an dem Problem, dass aus der gleichen MAC-Adresse auch immer die gleiche IPv6-Adresse resultiert. Dynamische IP-Vergabe wie bei IPv4 sollte es ja bei IPv6 nicht mehr geben. Datenschützer waren besorgt, dass auf diese Weise der Datenverkehr einer IP auf Routern mitgeschnitten werden könnte und beispielsweise für Marketingmaßnahmen oder staatliche Interventionen aller Art verwendet werden könnte. Die IETF definierte deshalb nachträglich die Datenschutzerweiterungen ("Privacy Extensions") gemäß RFC 3041: Die MAC-Adresse wird dabei zunächst mit einer pseudozufälligen Zahl verwürfelt, und aus dem Ergebnis dann die linklokale Adresse des Gerätes ermittelt.

In der Praxis ergab sich mit den linklokalen Adressen das Problem, dass es nicht mehr reicht, die IP-Adresse im Ziel-Feld einzutragen, sondern auch eine Scope-ID angegeben werden muss, da die linklokalen Adressen relativ zum Link sind und für sich genommen noch keinen Endpunkt definieren.

Deshalb sind die linklokalen Adressen nur beschränkt zur Kommunikation tauglich (abhängig davon, ob die IPv6-Unterstützung der verwendeten Anwendung das Konzept der Scope-ID kennt).

IPv6 und DNS

Auf Grund der Länge der IP-Nummern, die man sich nur in den seltensten Fällen merken können wird, ist IPv6 in besonderem Maße von einer funktionierenden Nameserver-Infrastruktur abhängig. Gerade dieser wichtige Bereich ist jedoch bis heute eine Baustelle. Es ergaben sich im wesentlichen folgende Probleme:

IPv6-Autokonfiguration sucht normalerweise nicht nach Nameservern
Privacy Extensions und DNS sind wegen der sich häufig ändernden Adressen schlecht unter einen Hut zu bekommen
Chaos bei den DNS-Record-Typen für IPv6

Bei der Autokonfiguration erhält ein IPv6-Gerät vollautomatisch eine Adresse und ein Gateway, über das es ins Internet kommunizieren kann. Leider fehlt jedoch die Möglichkeit, auch automatisch einen DNS-Server zu suchen, was die Autokonfiguration fast wieder wertlos macht. Dies ist einer der Gründe, warum DHCP v6 entwickelt wurde, das eigentlich durch IPv6 überflüssig gemacht werden sollte. Wer ohne DHCP einen Nameserver finden will, muss auf Bastellösungen zurückgreifen, die meist ganz ähnlich wie die Router-Suche funktionieren. Statt einer Anfrage an die Multicast-Gruppe alle Router wird dabei eine Anfrage an alle Nameserver abgesetzt. Falls es mehrere DNS-Server im lokalen Netz gibt, sucht sich der Client dann den Server seiner Wahl aus den eintreffenden Antworten heraus.

Die Verwendung von Datenschutzerweiterungen ("Privacy Extensions") ist insofern eine Herausforderung an das DNS, als sich IP-Adressen dabei häufig und unvermittelt ändern. Wenn ein Client auf Erreichbarkeit unter einem DNS-Namen angewiesen ist, benötigt er ein zuverlässiges und sicheres Verfahren, um dem DNS-Server eine Adressänderung mitteilen zu können. Auf diesem Gebiet ist bis heute (2005) noch viel Bewegung zu verzeichnen und es hat sich noch kein verwendbarer Standard herauskristallisiert.

Lange Zeit bestand auch auf der grundlegendsten Ebene des DNS, den Records auf den Nameservern, Verwirrung. 1995 wurden in RFC 1886 zunächst der Record-Typ AAAA für die Forward-Auflösung von DNS-Namen in IPv6-Adressen definiert, der funktional äquivalent zum A-Record für IPv4 ist. Im Jahr 2000 wurde AAAA in RFC 2874 durch den Record-Typ A6 abgelöst, der vor allem das Umnummerieren vereinfachen sollte, indem die IP-Adresse stückweise auf das DNS abgebildet wurde, jedoch nie frei von technischen Problemen war. Im Jahr 2003 wurde das Verfahren A6 daher in RFC 3596 wieder nach "experimentell" zurückgestuft, und AAAA wurde der neue, alte Standard. Noch mehr Schwierigkeiten bereitet die Rückwärtsauflösung ("Reverse"-Auflösung) von IPv6-Adressen, da es durch das Hin- und her bei den Standards PTR-Records in zwei verschiedenen Formaten gibt, die noch dazu in drei verschiedenen Zonen liegen.

Die Umsetzung von IPv6 in der Praxis

IPv6 setzt sich im praktischen Einsatz nur langsam durch.

Das Projekt IPv6-Ready vergibt das IPv6 Logo in 3 verschiedenen Stufen, die die Implementierung des Protokolls messen. Die Webseite listet dazu auch alle IPv6-fähigen Betriebssysteme auf.

Mit der Betriebssystemunterstützung sieht es im Moment folgendermaßen aus:

AIX: Seit AIX 4 Version 4.3 ist IPv6 implementiert, seit AIX 5L Version 5.2 ist auch Mobile IPv6 implementiert.
BSD-Varianten: Die derzeit noch beste und umfassenste Unterstützung für IPv6 – vor allem ein Verdienst des japanischen KAME-Projektes. IPv6 wird von den BSDs bereits sehr lange unterstützt (z.B. bei FreeBSD seit März 2000 und bei NetBSD seit Dezember 2000). Allerdings ist zu erwähnen, dass die OpenBSD-Entwickler aus Sicherheitsgründen kein IPv4-to-IPv6-Mapping implementiert haben und somit strenggenommen den Standard verletzen.
Cisco: Cisco ist der Marktführer bei Internet-Routern. Bei der Umsetzung von IPv6 gehörte Cisco aber eher zu den Schlusslichtern. Es gibt zwar mittlerweile IPv6-fähige IOS-Versionen, diese werden aber nicht von vornherein installiert, da sie noch als experimentell eingestuft werden.
HP-UX: Seit der Version 11iv2 ist IPv6 Bestandteil des Basissystems, frühere 11.x-Versionen können mit TOUR (Transport Optional Upgrade Release) IPv6-fähig gemacht werden.
Linux: Der Kernel 2.6. bietet eine umfassende IPv6-Unterstützung auf ähnlichem Niveau wie die BSD-Derivate, die produktiv einsetzbar ist. Der Kernel 2.4 bietet eine als experimentell ausgewiesene Unterstützung für IPv6, der jedoch noch wichtige Eigenschaften wie IPSec und Datenschutzerweiterungen (Privacy Extensions, RFC 3041) fehlen. Eine experimentelle IPv6-Implementation ist ebenfalls in der Kernel-Version 2.2 enthalten.
Mac OS X: Enthält seit Version 10.2 Unterstützung für IPv6 auf der Basis von KAME. Erst seit Version 10.3 lässt sich IPv6 auch über die GUI konfigurieren.
Solaris: Seit der Version 8 ist die Unterstützung des IPv6-Protokolls auch in dem Betriebssystem der Firma SUN enthalten, das für SPARC- und i386-Rechnerarchitekturen zur Verfügung steht. Die Konfiguration erfolgt analog zu den Linux- und xBSD-Systemen über die Kommandozeile.
Symbian OS: Seit der Version 7.0 ist IPv6 fester Bestandteil des Systems. Es sind nur wenige Parameter über die GUI zu konfigurieren.
Windows 9x/ME: Lediglich eine von einem kommerziellen Drittanbieter verfügbare Unterstützung der Firma Trumpet (Winsock).
Windows 2000: Microsoft bietet einen experimentellen Protokollstapel als Patch an, der sich aber ohne weitere Maßnahmen nur zum gegenseitigen Anpingen von Rechnern eignet. Das experimentelle Patch lässt sich nur auf PCs installieren, auf denen Windows 2000 mit Servicepack 1 läuft. Mittels einer kleinen Anpassung lässt es sich auch auf PCs installieren, auf denen Windows 2000 mit Servicepack 2 bis 4 läuft. Die Schritte zur Anpassung können auf der englischsprachigen "Frequently Asked Questions about the Microsoft IPv6 Technology Preview for Windows 2000" Seite eingesehen werden.
Windows Server 2003: Enthält einen "Production Quality"-Protokollstapel, unterstützt DNS-AAAA-Records und IPv6-Routing. Die IPsec-Komponente ist jedoch noch als "für den Produktiveinsatz ungeeignet" markiert, weil sie static keying verwendet und Internet Key Exchange (IKE) nicht unterstützt. Außerdem versteht die wininet.dll, auf die sich beispielsweise der Internet Explorer stützt, keine literalen IP-Adressen nach RFC 2732. Weiterhin ist der Mobility-Support unvollständig: Die Funktion eines correspondent node ist aktivierbar, mobile node und home agent node werden hingegen nicht angeboten. Jedoch sind auch hier aufgrund des Mobile IPv6 Technology Preview diesbezügliche Erweiterungen bereitgestellt, und ihre Aufnahme in Windows Server 2003 darf mit einem der nächsten Service Packs erwartet werden.
Windows XP: Auf expliziten Wunsch (ipv6 install) kann man bei Windows XP einen experimentellen IPv6-Protokollstapel installieren. Ab ServicePack 1 hat dieser Protokollstapel "Production Quality", und wird als Protokoll in den Netzwerkeigenschaften hinzugefügt. Ab ServicePack 2 kann IPv6 ebenfalls unter den Netzwerkeigenschaften hinzugefügt werden, mit dem Namen Internet Protokoll Version 6. In Bezug auf den Mobility-Support gilt für Windows XP ab Service Pack 1 das Gleiche wie für Windows Server 2003: correspondent nodes sind verfügbar, mobile nodes und home agent nodes dagegen nicht. Im Rahmen des Mobile IPv6 Technology Preview-Programms sind entsprechende Erweiterungen verfügbar; man kann mit einem "serienmäßigen" Support mit einem der nächsten Service Packs rechnen.

Viele Anwendungen (vor allem aus dem Bereich der Freien Software) sind inzwischen ebenfalls IPv6-fähig. Im heimatlichen LAN kann man so schon relativ problemfrei IPv6 benutzen. Jenseits des eigenen Border-Routers sieht es derzeit noch düster aus: Es gibt noch keine Provider, die IPv6-Anbindung aktiv im Endkundenbereich verkaufen, so dass man im Moment auf bisweilen unbefriedigende Bastel-Lösungen mit Tunneling zurückgreifen muss. Es existiert eine Reihe von Tunnelprotokollen für jeweils unterschiedliche Anwendungsbereiche, darunter die Protokolle 6in4, 6over4, 6to4, Teredo, ISATAP und das NAT-taugliche AYIYA.

Zumindest in Europa und in Nordamerika besteht auch keine unbedingte Notwendigkeit zur Migration zu IPv6, da noch genügend freie IPv4-Adressen vorhanden sind (in Europa über 50%). In Asien geht der Trend inzwischen dahin, bei Neubauten (zum Beispiel dem NTT-Backbone) IPv6 auch zu benutzen. Von Seiten der Endbenutzer wird IPv6 auch deshalb nicht gefordert, weil außer dem größeren Adressbereich die wesentlichen neuen Eigenschaften von IPv6 inzwischen mehr oder weniger erfolgreich nach IPv4 zurückportiert wurden (beispielsweise IPSec, QoS, Multicast. Das Umnummerieren und die Autokonfiguration kann man durch DHCP in etwa erreichen) – es gibt keine weitverbreitete Anwendung, die nur mit IPv6 funktionieren würde.

In Deutschland federführend bei den Versuchen zu IPv6 ist das JOIN-Projekt der Uni Münster. JOIN und der Verein zur Förderung eines Deutschen Forschungsnetzes (DFN) haben mit dem "6WiN" einen ersten IPv6-Backbone in Deutschland aufgebaut. Das 6WiN ist ein ringförmiger Backbone durch Deutschland mit Querverbindung zwischen Essen und Berlin. Parallel dazu baute die Deutsche Telekom einen eigenen IPv6-Backbone zwischen den Standorten Darmstadt, Münster und Berlin auf und bot ihren Geschäftskunden im Rahmen eines Showcase-Projektes Anschluss daran an. Dieses Netz war in Münster und Berlin mit dem 6Win verbunden. Ebenfalls in Münster lag der deutsche zentrale Zugang zum experimentellen IPv6-Netzwerk 6Bone, der am 7. Juni 2005 im Rahmen der planmäßigen sukzessiven Beendigung des weltweiten 6Bone-Betriebs abgeschaltet wurde.

Weiterführende Informationen

Was ist mit IPv5?

Wenn es IPv4 und IPv6 gibt, was ist dann mit IPv5? gehört mit zu den häufigsten Fragen, die sich IPv6-Neueinsteiger stellen. Ein Protokoll mit dem Namen IPv5 gibt es nicht, allerdings hat die IANA die IP-Versionsnummer 5 für das Internet Stream Protocol Version 2 (ST2, definiert in RFC 1819) reserviert, das gegenüber IPv4 verbesserte Echtzeitfähigkeiten haben sollte, dessen Entwicklung dann aber zu Gunsten von IPv6 und RSVP eingestellt wurde.

Siehe auch

Weblinks

der derzeit allozierte IPv6-Adressbereich im Überblick (englisch)
Homepage des experimentellen IPv6-Netzwerks 6Bone (englisch)
der Verein Sixxs bietet Hilfe für IPv6 Tunnel an (englisch)
tunnelbroker.net bietet IPv6 Tunnel an (englisch)
Liste von IPv6-Implementationen (englisch)
Migration von IPv4 zu IPv6
Linkkatalog zum Thema IPv6 bei odp.org (ehemals DMOZ)

Vorlage:WikiReader Internet