IPv6

IPv6 im TCP/IP-Protokollstapel:

Anwendung	HTTP	IMAP	SMTP	DNS	…
Transport	TCP			UDP
Internet	IPv6
Netzzugang	Ethernet	Token Bus	Token Ring	FDDI	…

Das Internet Protocol Version 6 (IPv6) (früher auch IPnG, Internet Protocol Next Generation) ist der Nachfolger des gegenwärtig im Internet noch überwiegend verwendeten Internet Protocols in der Version 4. Beide Protokolle sind Standards für die Vermittlungsschicht (Schicht 3) des OSI-Modells und regeln die Adressierung und das Routing von Datenpaketen durch ein Netz.

Gründe für 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 Netz 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 Teilnehmern am Internet (Universitäten, US-Behörden und große Firmen) wurden riesige Adressbereiche (sogenannte Class-A-Netze) mit je 16,8 Millionen Adressen zugeteilt, ohne dass sie von diesen Organisationen voll ausgenutzt werden. Bisher wurden nur wenige dieser Adressbereiche wieder zurückgegeben .

Als Resultat herrscht heute Adressenknappheit. Eine Schätzung, welche auch ARIN zur Bewertung ihrer Vergabepolitik heranzieht, geht davon aus, dass die IANA im Januar 2011 die letzten IPv4 Netze an die Regional Internet Registries vergeben wird und dass diese dann ca. ein Jahr später der Internetgemeinde keine Adressen mehr bereitstellen werden.

Notlösungen wie NAT-Verfahren oder die dynamische Vergabe von Adressen erhöhen die Komplexität der Anbindung.

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, begannen 1995 die Arbeiten an IPv6. Die folgende Liste gibt einen Überblick über die wesentlichen neuen Eigenschaften von IPv6:

• 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
• automatische Konfiguration von IPv6-Adressen (stateless), DHCP (stateful) für IPv6 damit in der Regel überflüssig – siehe unten
• Mobile IP und vereinfachte Umnummerierung („Renumbering“) – siehe unten
• Netztechniken wie IPSec, Quality of Service und Multicast „serienmäßig“
• Vereinfachung und Verbesserung des Protokollrahmens (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 = eine Zahl mit insgesamt 39 Stellen) IPv6-Adressen. IPv4 kann maximal 2³² Adressen vergeben, das entspricht einer Zahl mit „nur“ 10 Stellen.

IPv6-Adressen sind typischerweise aus zwei logischen Teilen zusammengesetzt; einem 64-bit langen (Sub-)Netzwerkpräfix und einer 64-bit langen Host-Adresse, welche entweder aus der MAC des NICs erstellt oder einfach sequentiell zugewiesen werden kann. 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. Analog gehört dieses Subnetz hierarchisch zum Subnetz mit dem kürzeren Präfix 2001:0db8:85a3::/48.

Da die global eindeutige MAC-Adresse die Nachverfolgung von Benutzern ermöglicht, wurde RFC 3041 entwickelt um die permanente Kopplung zwischen einer Benutzeridentität und einer IPv6-Adresse aufzuheben. Damit soll ein Teil der Anonymität von IPv4 wiederhergestellt werden. RFC 3041 ermöglicht die Identifikation des NICs über zufällige Strings statt der MAC.

Notation

1. IPv6-Adressen werden hexadezimal (IPv4: dezimal) beschrieben, wobei die Zahl in acht Blöcke zu jeweils 16 Bit unterteilt wird. Diese Blöcke werden durch Doppelpunkte (IPv4: Punkte) getrennt notiert: 2001:0db8:85a3:08d3:1319:8a2e:0370:7344
2. Ein oder mehrere aufeinander folgende Blöcke, deren Wert 0 (bzw. 0000) beträgt, dürfen ausgelassen und durch den führenden und abschließenden Doppelpunkt ersetzt werden: 2001:0db8::1428:57ab ist gleichbedeutend zu 2001:0db8:0000:0000:0000:0000:1428:57ab
3. Die Reduktion durch Regel 2 darf nur einmal durchgeführt werden, d.h. es darf nur eine zusammenhängende Gruppe aus Null-Blöcken in der Adresse ersetzt werden (ansonsten ist keine Eindeutigkeit gegeben).
4. Führende Nullen innerhalb eines Blockes dürfen ausgelassen werden.

URL-Notation von IPv6-Adressen

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:

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

Netzwerke

IPv6-Netzwerke werden in der CIDR-Notation aufgeschrieben. Dazu wird die erste Adresse (bzw. die Netzadresse) und die Länge (in Bits) des Präfixes getrennt durch den Schrägstrich notiert. Als Beispiel steht 2001:0db8:1234::/48 für das Netzwerk mit den Adressen 2001:0db8:1234:0000:0000:0000:0000:0000 bis 2001:0db8:1234:ffff:ffff:ffff:ffff:ffff. Die Größe eines IPv6-Netzwerkes (oder Subnetzwerkes) im Sinne der Anzahl der vergebbaren Adressen in diesem Netz muss also eine Zweierpotenz sein.

Da ein einzelner Host auch als Netzwerk mit einem 128-bit langen Präfix betrachtet werden kann, werden Host-Adressen manchmal mit einem angehängten "/128" geschrieben.

Aufteilung des IPv6-Adressraumes

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, ein 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 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 zurzeit 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 die Schnittstelle 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 Multicast-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…, auch 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 an ihre Kunden weiterverteilen.

• Adressen aus 2001:db8::/32 dienen Dokumentationszwecken, wie beispielsweise in diesem Artikel, und bezeichnen keine tatsächlichen Netzteilnehmer.

• 2002-Präfixe deuten auf Adressen des Tunnelmechanismus 6to4 hin.
• Auch mit 2003, 240, 260, 261, 262, 280, 2a0 und 2c0 beginnende Adressen werden von Regional Internet Registries (RIRs) vergeben; diese Adressbereiche sind ihnen z.T. aber noch nicht zu dem Anteil zugeteilt, wie dies bei 2001::/16 der Fall ist.
• 3ffe::/16-Adressen wurden für das Testnetzwerk 6Bone benutzt; dieser Adressbereich wurde gemäß RFC 3701 wieder an die IANA zurückgegeben.

• fc00::/7 (fc… und fd…) sind Unique-Local-Adressen (RFC 4193), die die Site-Local-Adressen der ursprünglichen Adressarchitektur ersetzen. Sie sollen zwar nur innerhalb eines privaten Netzwerks geroutet werden, durch eine 40-bit-Zufallsfolge im gewählten Adresspräfix sind sie aber mit hoher Wahrscheinlichkeit global eindeutig, was das Verbinden mehrerer Netze mit bereits zugewiesenen Unique-Local-Adressen ermöglicht.

Unique-Local-Adressen

Für private Adressen gibt es die Unique Local Addresses (ULA), beschrieben in RFC 4193. Dabei wird zwischen lokal generierten ULA mit dem Präfix fd und global zugewiesenen eindeutigen ULA mit dem Präfix fc unterschieden. 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 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 wahrscheinlich eindeutigen Site-IDs hat den Vorteil, dass zum Beispiel beim Einrichten eines Tunnels zwischen getrennt voneinander konfigurierten Netzwerken Adresskollisionen sehr unwahrscheinlich sind. Weiterhin wird erreicht, dass Pakete, welche an eine nicht erreichbare Site gesendet werden, mit großer Wahrscheinlichkeit ins Leere laufen, anstatt an einen lokalen Host gesendet zu werden, der zufällig die gleiche Adresse hat.

Funktionalität

Autokonfiguration

Ein IPv6-Stack kann aus der Layer-2-MAC-Adresse einer Schnittstelle 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 beziehungsweise 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 Probleme) 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.

Routing-Prozess

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.

Header-Format und Effizienzsteigerung

Im Gegensatz zu IPv4 hat der IP-Kopfdatenbereich (Header) bei IPv6 eine feste Länge von 40 Bytes (320 Bits). 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 ICMPv6-Nachrichten aufgefordert, kleinere Pakete zu schicken (siehe in diesem Zusammenhang Maximum Transfer Unit (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.

Das ARP-Protokoll wurde durch das Neighbor Discovery Protocol (NDP) ersetzt, welches auf ICMPv6 basiert. Dieses macht intensiv Gebrauch von Multicast, das von jedem Host beherrscht werden muss.

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 die gerade fertig gewordenen Implementierungen erneut angepasst werden mussten.

Der größte Einschnitt bestand in der Einführung der IEEE-Norm EUI-64 für die linklokalen Adressen. Um die Einzigartigkeit der Adresse im Netzwerk auf einfache Weise zu garantieren, wurde vorher die MAC-Adresse des Adapters unverändert in die IPv6-Adresse übernommen, 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 immer die gleiche IPv6-Adresse resultiert. 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 4941: Die MAC-Adresse wird dabei zunächst mit einer pseudozufälligen Zahl verwürfelt, und aus dem Ergebnis wird 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

Wegen der Länge der IP-Adressen, die an das menschliche Erinnerungsvermögen höhere Anforderungen stellt, als dies bei IPv4 der Fall war, ist IPv6 in besonderem Maße von einer funktionierenden Nameserver-Infrastruktur abhängig. Es ergaben sich bei der Integration des IPv6-Adressraums in das DNS im Wesentlichen folgende Probleme:

1. Die IPv6-Autokonfiguration suchte in ihrer früheren Form nicht nach Nameservern. Diese Funktionalität wurde erst in RFC 5006 spezifiziert. Link-lokale DNS-Server konnten jedoch mittels einer speziellen Multicast-Adresse gefunden werden.
2. Privacy Extensions (Datenschutzerweiterungen) und die zustandslose Autokonfiguration sind wegen der häufigen Adressänderungen mit DNS wenig kompatibel.
3. Unterschiedliche DNS-Record-Typen für IPv6 und verschiedene Methoden der Rückwärtsauflösung von Namen.

Im IPv6-Autokonfigurationsmechanismus erhält ein IPv6-Gerät vollautomatisch eine Adresse und ein Gateway, über das es mit dem Internet kommunizieren kann. Es fehlte allerdings ursprünglich die Möglichkeit, auch automatisch einen DNS-Server zu suchen. Dies ist einer der Gründe für die Entwicklung des DHCP v6, das eigentlich durch IPv6 überflüssig gemacht werden sollte. Wer ohne DHCP einen Nameserver finden wollte, musste auf provisorische Lösungen zurückgreifen, die meist ganz ähnlich wie die Router-Suche funktionierten. Statt einer Anfrage an die Multicast-Gruppe alle Router wurde dabei eine Anfrage an alle Nameserver abgesetzt. Falls es mehrere DNS-Server im lokalen Netz gab, suchte sich der Client den Server seiner Wahl aus den eintreffenden Antworten aus.

Die Verwendung von Datenschutzerweiterungen ist insofern eine Herausforderung an das DNS, als sich IP-Adressen dabei häufig und unvermittelt ändern und durch das Fehlen eines DHCP-Servers im Falle der Autokonfiguration auch kein Status eines Clients gehalten wird. 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 hat die Entwicklung von IPv6 noch kein allgemein akzeptiertes Verfahren hervorgebracht.

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. 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 aufgrund der Wechsel der Standards PTR-Records in zwei verschiedenen Zonen gab, 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 IPv6 Forum wurde im Juli 1999 gegründet.

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

Das Deutsche IPv6 Council wurde im Dezember 2007 gegründet.

Die meisten Betriebssysteme unterstützen inzwischen IPv6:

AIX

Seit AIX 4 Version 4.3 ist IPv6 implementiert, seit AIX 5L Version 5.2 ist auch Mobile IPv6 implementiert.

BSD-Varianten

IPv6 wird von den BSDs bereits sehr lange und sehr umfassend unterstützt (zum Beispiel bei FreeBSD seit März 2000 und bei NetBSD seit Dezember 2000).

Cisco

IPv6 wird ab IOS Version 12.2T experimentell, in den aktuellen Versionen 12.3 und 12.4 produktiv unterstützt. Auf älteren Geräten und Karten ist das IPv6-Forwarding aufgrund der Hardwareausstattung jedoch nur in Software, also mit Hilfe des Hauptprozessors möglich, was die Sicherheit und Leistung gegenüber IPv4 deutlich vermindert.

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.

Juniper

Der Routerhersteller unterstützt IPv6 in seinem Betriebssystem JunOS ab Version 5.1. Das IPv6-Forwarding geschah schon früh in Hardware, also ohne die Routing Engine (den Hauptprozessor) zu belasten.

Linux

Der Kernel 2.6. bietet eine 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.

OpenVMS

Mit HP TCP/IP Services for OpenVMS Version 5.5 unterstützt HP OpenVMS (ab Version 8.2) IPv6.

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-Systemen.

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.

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 einer „serienmäßigen“ Unterstützung mit einem der nächsten Service Packs rechnen.

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 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. Ist Internet Connection Sharing aktiviert, so fungiert Windows Vista auch als IPv6-Router und versendet entsprechende Router Advertisements zur Autokonfiguration von Clients.

Microsoft Windows Server 2008

IPv6 ist standardmäßig installiert und aktiviert, parallel zu IPv4. Viele Komponenten setzen eine Konfiguration beider Protokolle voraus.

Viele Anwendungen (vor allem aus dem Bereich der Freien Software) sind inzwischen ebenfalls IPv6-fähig. Im heimatlichen LAN kann so schon relativ problemfrei IPv6 benutzt werden. IPv6-Anbindung wird im Endkundenbereich allerdings fast nur von kleineren Providern angeboten, so dass man im Moment auf 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.

Die USA kontrollieren derzeit 74 % aller IP-Adressen, während beispielsweise ganz China – mit inzwischen über 250 Millionen Internet-Benutzern (Stand: Juni 2008) – nur über etwa so viele IP-Adressen verfügt wie ein Campus der University of California. In Asien geht der Trend daher 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.

Das Bildungsnetzwerk CERNET2 in China ist derzeit das größte Netzwerk, das ausschließlich mit IPv6 betrieben wird. Es verbindet 25 Universitäten in 20 Städten.

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.

In Österreich spielt die Universität Wien, auch als Betreiber des Vienna Internet Exchange (VIX) und mehrerer DNS-Server für die Zone "at.", eine entscheidende Rolle bei der IPv6-Migration. Beide Einrichtungen sind über IPv6 erreichbar bzw. bieten IPv6-Anbindung an.

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. Beim DE-CIX nutzten im April 2008 etwa 70 bis 80 von insgesamt 240 Providern IPv6.

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 aus Kosten-Nutzen-Erwägungen zugunsten von IPv6 und RSVP eingestellt wurde.

Weiterführendes

Literatur

• Reiko Kaps: WAN-Auffahrt – Mit dem IPv6-Netz online gehen. c’t 6/2008, Heise Verlag
• Sivia Hagen: IPv6. Grundlagen – Funktionalität – Integration. Auflage: 1 (3. Juni 2004), Sunny Connection
• Herbert Wiese: Das neue Internetprotokoll IPv6. Januar 2002, Hanser Fachbuch
• Anatol Badach: Technik der IP-Netze. TCP/IP incl. IPv6. Funktionsweise, Protokolle und Dienste. Auflage: 2 (5. September 2007), Hanser Fachbuch
• Hans P. Dittler: IPv6. Das neue Internet-Protokoll. Technik, Anwendung, Migration.. Auflage: 2 (Januar 2002), Dpunkt Verlag
• Mathias Hein: IPv6, Das Migrationshandbuch. 2003, Franzis
• Christian Huitema: IPv6 – die neue Generation. 2000, Addison-Wesley

Siehe auch

• TCP/IP-Referenzmodell
• Protokollstapel
• M6Bone
• en:Tunnel broker
• DoD Standard Internet Protocol

Weblinks

• RFC 2460, „Internet Protocol, Version 6 (IPv6) Specification“, Dezember 1998 (englisch)
• Allokation des IPv6-Adressbereiches im Überblick (englisch)
• c’t-Artikel von Felix von Leitner
• Reihe von Fachartikeln über IPv6
• Liste von IPv6-Implementationen (englisch)
• IPv6 – The Next Generation Internet Protocol oder „Wie man die Turtle zum Tanzen bringt“ (PDF)
• Ein Skript zur Generierung von „unique local IPv6 unicast“ Adressen (ULA) nach RFC 4193
• Linkkatalog zum Thema IPv6 bei curlie.org (ehemals DMOZ)
• Heise Netze: Das Mega-Netz IPv6 wird Wirklichkeit
• ECAI6 – European Conference on Applied IPv6
• Liste mit Webservern mit IPv6-Unterstützung
• Vom Ende der Gleichheit, Die Zeit, Nr. 11, März 2008