IPv6

IPv6, das Internet Protocol Version 6, (auch IPnG, Internet Protocol Next Generation) 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 vier 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 weit mehr als ausreichend. Kaum jemand konnte sich vorstellen, dass überhaupt jemals so viele Rechner zu einem einzigen Netzwerk zusammengeschlossen würden und es somit im vorgegebenen Adressraum eng werden könnte.

Viele der theoretisch vier Milliarden IP-Adressen jedoch sind in der Praxis nicht nutzbar, da sie Sonderaufgaben dienen (z. B. 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 Nordamerikaner (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 Notlösungen 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³² (=4.294.967.296 ≈4,3 Milliarden) Adressen bei IPv4 auf 2¹²⁸ (=340.282.366.920.938.463.463.374.607.431.768.211.456 ≈340 Sextillionen) Adressen bei IPv6
• Autokonfiguration von IPv6-Adressen (stateless), DHCP (stateful) für IPv6 damit in der Regel überflüssig
• Mobile IP und vereinfachte Umnummerierung („Renumbering“)
• Dienste wie IPSec, QoS und Multicast „serienmäßig“
• Vereinfachung und Verbesserung der Protokollrahmen (Kopfdaten). 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³⁸ (340,28 Sextillionen) IPv6-Adressen. Zum Vergleich: Für jeden Quadratmillimeter Erdoberfläche könnten ca. 667 Billiarden IPv6-Adressen (6,67 × 10¹⁷) bereitgestellt werden (bei einem angenommenen Erdradius von 6373 km), während auf einen Quadratkilometer Erdoberfläche gerade mal 8,4 Adressen im IPv4-Format entfallen.

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. Im Extremfall können sämtliche Adressteile entfallen ::, was 0:0:0:0:0:0:0:0 entspricht.

Adressbereiche werden bei IPv6 durch Präfixe angegeben. Dazu wird die Präfixlänge (Anzahl der „gültigen“ Bits) als Dezimalzahl mit vorangehendem „/“ an die IPv6-Adresse angehängt. Subnetze werden als Adressbereiche ebenfalls durch den Präfix bestimmt. Netzmasken, wie sie bei IPv4 verwendet wurden, gibt es bei IPv6 nicht mehr, stattdessen wird eine ähnliche Notation wie beim IPv4-CIDR verwendet.

Die ersten 64 Bit der IPv6-Adresse dienen üblicherweise der Netzadressierung, die letzten 64 Bit werden zur Host-Adressierung verwendet. Beispiel: hat ein Netzwerkgerät die IPv6-Adresse

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

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.

In einer URL wird die IPv6-Adresse in eckigen Klammern eingeschlossen. Beispiel einer korrekten URL:

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

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

https://[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:

• ::/128 (128 0-Bits) ist die undefinierte Adresse, ähnlich der 0.0.0.0 in IPv4
• ::1/128 (127 0-Bits, 1 1-Bit) ist die Adresse des eigenen Standortes (localhost, loopback).
• fe80::/10 (fe80... bis febf...) sind so genannte linklokale Adressen (link local unicast addresses)

Diese sollen von Routern nicht weitergeleitet werden und sind daher nur im gleichen Teilnetz erreichbar. Interessant werden sie bei der Autokonfiguration.

• fec0::/10 (fec0... bis feff...) waren die Nachfolger der privaten IP-Adressen (beispielsweise 192.168.x.x)

Sie durften nur innerhalb der gleichen Organisation geroutet werden. Man nannte sie auch Site-local (standortlokal). Diese Adressen sind nach RFC 3879 inzwischen veraltet (engl. deprecated) und werden aus zukünftigen Standards möglicherweise verschwinden. Neue Implementationen müssen diesen Adressbereich als Global-Unicast Adressen behandeln.

Die Nachfolger sind wohl die Unique Local Addresses RFC 4193 mit dem Präfix fc00::/7, mehr dazu siehe unten.

• ff00::/8 (ff...) stehen für Multicast-Adressen.

Nach dem Multicast-Präfix folgen 4 Bits für Flags und 4 Bits für den Gültigkeitsbereich (Scope). Für die Flags sind z.Zt. folgende Kombinationen gültig:

• 0: Permanent definierte wohlbekannte Multicast-Adressen
• 1: (T-Bit gesetzt) Transient (vorübergehend) oder dynamisch zugewiesene Multicast-Adressen
• 3: (P-Bit gesetzt, erzwingt das T-Bit) Unicast-Prefix-based Multicast-Adressen (RFC 3306)
• 7: (R-Bit gesetzt, erzwingt P- und T-Bit) Multicast-Adressen, welche die Adresse des Rendezvous Point enthalten (RFC 3956)

Die folgenden Gültigkeitsbereiche sind definiert:

• 1: interfacelokal, diese Pakete verlassen das Interface nie. (Loopback)
• 2: linklokal, werden von Routern grundsätzlich nie weitergeleitet und können deshalb das Teilnetz nicht verlassen.
• 4: adminlokal, der kleinste Bereich, dessen Abgrenzung in den Routern speziell administriert werden muss
• 5: sitelokal, dürfen zwar geroutet werden, jedoch nicht von Border-Routern.
• 8: 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).
• e: globaler Multicast, der überall hin geroutet werden darf.
• 0, 3, f: reservierte Bereiche
• die restlichen Bereiche sind nicht zugewiesen und dürfen von Administratoren benutzt werden, um weitere Mulitcast-Regionen zu definieren .

Beispiele für wohlbekannte Multicast-Adressen :

• ff01::1, ff02::1: All Nodes Adressen. Entspricht dem Broadcast.
• ff01::2, ff02::2, ff05::2: All Routers Adressen, adressiert alle Router in einem Bereich.

Alle anderen Adressen gelten als Global Unicast Adressen. Von diesen sind jedoch bisher nur die folgenden Bereiche zugewiesen:

• ::/96 (96 0-Bits) stand für IPv4-Kompatibilitätsadressen, welche in den letzten 32 Bits die IPv4-Adresse enthielten (dies galt nur für globale IPv4 Unicast-Adressen). Diese waren für den Übergang definiert, jedoch im RFC 4291 vom Februar 2006 für veraltet (engl. deprecated) erklärt.
• 0:0:0:0:0:FFFF::/96 (80 0-Bits, gefolgt von 16 1-Bits) steht für IPv4 mapped (abgebildete) IPv6 Adressen. Die letzten 32 Bits enthalten die IPv4-Adresse. Ein geeigneter Router kann diese Pakete zwischen IPv4 und IPv6 konvertieren und so die neue mit der alten Welt verbinden.
• 2000::/3 (Bitfolge 001..., also 2... und 3...) stehen für die von der IANA vergebenen globalen Unicast-Adressen, also routbare und weltweit einzigartige Adressen.

• 2001-Adressen werden an Provider vergeben, die diese dann wieder an ihre Kunden verteilen
• 2002-Präfixe deuten auf Adressen des Tunnelmechanismus 6to4 hin
• 3ffe:0000-Adressen wurden für das Testnetzwerk 6Bone benutzt

• fc00::/7 (fc... und fd...) sind Unique Local Adressen (RFC 4193).

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 unter anderem 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 „Privacy Extension“ (siehe unten) 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 etwa 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), es werden also 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 unter anderem 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), 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 (s.a. folgendes Skript) 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 Site-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 zum Beispiel beim Einrichten eines Tunnels zwischen getrennt voneinander konfigurierten Netzwerken Adresskollisionen nicht auftreten bzw. sehr 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 gleiche Adresse hat, gesendet zu werden.

Kopfdaten-Format und Effizienzsteigerung

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

Der Kopfdatenbereich 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. Eine Art Prioritätsvergabe.
Flow Label	20 Bit	Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete die ein Flow Label tragen werden alle gleich behandelt.
Payload Length	16 Bit	Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich aber inklusive der Erweiterungs-Kopfdaten)
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 die IP-Kopfdaten 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 Kopfdatenbereiche sind auf 64-Bit-Grenzen ausgerichtet, um Speicherzugriffe im Router zu beschleunigen.

IPv6 macht intensiv Gebrauch von Multicast, das 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 erneut anpassen 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 über eine bestimmte IP-Adresse 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 eine temporäre global-erreichbare 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:

1. IPv6-Autokonfiguration sucht normalerweise nicht nach Nameservern
2. Privacy Extensions (Datenschutzerweiterungen) und DNS sind wegen der sich häufig ändernden Adressen schlecht unter einen Hut zu bekommen
3. 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 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 bereitete 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 Zonen gibt, unterhalb von ip6.arpa und ip6.int. Aufgrund der traditionellen Nutzung der TLD .arpa für die Rückwärtsauflösung bei IPv4 hat sich die erstere Variante gegen ip6.int durchgesetzt, woraufhin die Delegierung von ip6.int im Juni 2006 gelöscht wurde.

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 (zum Beispiel 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. IPv6 wird ab 12.2T experimentell, in den aktuellen IOS Versionen 12.3 und 12.4 produktiv unterstützt.
• 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.
• OpenVMS: Mit HP TCP/IP Services for OpenVMS Version 5.5 unterstützt HP OpenVMS (ab Version 8.2) IPv6.
• 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 in begrenzter Form enthalten (die Implementierung und große Teile der Betriebssystemapplikationen erfordern immer noch, dass IPv4 konfiguriert ist), das für SPARC- und i386-Rechnerarchitekturen zur Verfügung steht. Die Konfiguration erfolgt analog zu den Linux- und xBSD-Systeme
• 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 NT 4.0: Microsoft bietet einen experimentellen Protokollstapel als Hotfix an. Dieser ist sehr alt, aber im Quellcode verfügbar.
• 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.
• Windows Vista: IPv6 wird hier von Anfang an unterstützt, da es mit einer "Dual-IP-Layer-Architektur" arbeitet und somit sowohl IPv4 als auch IPv6 unterstützt. Stehen in einem Netzwerk keine IPv6-Einträge zur Verfügung, so greift der PC automatisch auf IPv4 zurück.

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 größeren 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 Prozent). 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. Zum 1. Januar 2006 wurde der IPv6-Betrieb im Deutschen Forschungsnetz vom JOIN-Projekt an das DFN-NOC übergeben.

Die Adressvergabe für IPv6 ist inzwischen vom experimentellen in den Regelbetrieb übergegangen und immer mehr ISPs betreiben neben IPv4 auch IPv6-Netze, diese aber zumeist noch testweise und entweder ohne entsprechende Produkte, oder ohne Verfügbarkeitsgarantien für ihre Kunden. Die meisten der großen Austauschpunkte für Internettraffic erlauben und fördern neben IPv4 auch den Austausch von IPv6 über ihre Infrastruktur.

Was ist mit IPv5?

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

• Anycast, Multicast
• M6Bone, 6Bone
• XORP

Tunnel-Broker

• en:Tunnel broker detaillierter Artikel in der englischen Wikipedia

Weblinks

• RFC 2460, „Internet Protocol, Version 6 (IPv6) Specification“, Dezember 1998 (englisch)
• RFC 4291, „IP Version 6 Addressing Architecture“, Februar 2006 (englisch)
• Der derzeit allozierte IPv6-Adressbereich im Überblick (englisch)
• Homepage des bis zum 06.06.2006 betriebenen experimentellen IPv6-Netzwerks 6Bone (englisch)
• c't-Artikel von Felix von Leitner
• Liste von IPv6-Implementationen (englisch)
• IPv6 – The Next Generation Internet Protocol oder „Wie man die Turtle zum Tanzen bringt“
• Ein Skript zur Generierung von „uniq local IPv6 unicast“ Adressen
• Linkkatalog zum Thema IPv6 bei curlie.org (ehemals DMOZ)