Internet Protocol Next Generation

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. IPv4 und IPv6 lassen sich auf derselben Infrastruktur (im Internet) parallel betreiben, insbesondere gibt es zurzeit kaum Geräte, welche IPv6, aber nicht gleichzeitig IPv4 beherrschen. Allein über IPv4 angebundene Geräte können nicht ohne Übersetzungsverfahren mit ausschließlich über IPv6 angebundenen Geräten kommunizieren.

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 sind jedoch 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 (so genannte 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 ^[1].

Als Resultat herrscht heute Adressenknappheit. Eine Schätzung^[2], welche auch ARIN zur Bewertung ihrer Vergabepolitik heranzieht^[3], 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.

Durch die mit der Zeit mehrmals geänderte Vergabepraxis von IPv4-Adressraum ist dieser inzwischen auch stark fragmentiert. Dies führt in Verbindung mit der heutigen Routingstrategie (Classless Inter-Domain Routing) zu langen Routingtabellen, die für die CPUs von Embedded-Routern, deren spezialisierte Architektur für heutige Datendurchsatzraten notwendig ist, zunehmend ein Problem darstellen. Zudem erfordert IPv4 von Routern, Headerdaten umzuschreiben und entsprechend auch Prüfsummen neu zu berechnen, was eine weitere Rechnerbelastung darstellt.

Aus diesen Gründen 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.
• Mobile IP, sowie vereinfachte Umnummerierung und Multihoming.
• Implementierung von IPsec innerhalb des IPv6-Standards^[4]. Dadurch wird die Verschlüsselung und Authentizität von IP-Paketen ermöglicht. Für IPv4 ist die Unterstützung von IPsec nur optional.
• Unterstützung von Netztechniken wie Quality of Service und Multicast.
• Vereinfachung und Verbesserung des Protokollrahmens (Kopfdaten). Dies ist insbesondere wichtig für Router.

Adressaufbau von IPv6

IPv6-Adressen sind 128 Bit lang (IPv4: 32 Bit). Typischerweise bekommt ein Internetprovider die ersten 32 Bit als Netz von einer Regional Internet Registry (RIR) zugewiesen. Dieser Bereich wird vom Provider weiter in Subnetze aufgeteilt. Oft wird dabei, wie in RFC 4291 beschrieben, einem Netzsegment ein 64-Bit langes Präfix zugewiesen, das dann zusammen mit einem 64-Bit langen Interface Identifier die Adresse bildet. Der Interface Identifier kann entweder aus der MAC-Adresse der Netzwerkkarte erstellt oder anders eindeutig zugewiesen werden. Hat z. B. ein Netzwerkgerät die IPv6-Adresse 2001:0db8:85a3:08d3:1319:8a2e:0370:7347/64, so lautet das Präfix 2001:0db8:85a3:08d3::/64, der Interface Identifier 1319:8a2e:0370:7347 und der Provider bekam von der RIR wahrscheinlich das Netz 2001:0db8::/32 zugewiesen.

Ein Interface Identifier kann in mehreren IPv6-Adressen, welche mit verschiedenen Präfixen auf dieselbe Netzwerkkarte gebunden sind, auftauchen. Insbesondere gilt dies auch für link-lokale Adressen und Präfixe möglicherweise verschiedener Provider, was zur Entwicklung neuer Multihoming-Verfahren benutzt werden könnte.

Da die global eindeutige MAC-Adresse die Nachverfolgung von Benutzern ermöglicht, wurde die Privacy Extension (RFC 4941) entwickelt, um die permanente Kopplung zwischen einer Benutzeridentität und einem Interface Identifier aufzuheben. Damit soll ein Teil der Anonymität von IPv4 wiederhergestellt werden. RFC 4941 ermöglicht die Identifikation der Netzwerkkarte über ständig wechselnde, zufällige Interface Identifier, statt diesen aus der MAC-Adresse zu errechnen. Da aber in der IPv6-Adresse sowohl der Interface Identifier als auch das Präfix allein recht eindeutig auf einen Nutzer deuten können, benötigt man in Verbindung mit der Privacy Extension ein vom Provider dynamisch zugewiesenes (z. B. täglich wechselndes) Präfix. Dieses könnte wie oben beschrieben parallel zu einem fest zugewiesenen Präfix auf derselben Netzwerkkarte verwendet werden.

Adressnotation

1. IPv6-Adressen werden gewöhnlicherweise für Menschen 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. Führende Nullen innerhalb eines Blockes dürfen ausgelassen werden: 2001:0db8:0000:08d3:0000:8a2e:0070:7344 ist gleichbedeutend mit 2001:db8:0:8d3:0:8a2e:70:7344.
3. Ein oder mehrere aufeinander folgende Blöcke, deren Wert 0 (bzw. 0000) beträgt, dürfen ausgelassen und durch zwei Doppelpunkte ersetzt werden^[5]: 2001:db8:0:0:0:0:1428:57ab ist gleichbedeutend mit 2001:db8::1428:57ab.
4. Die Reduktion durch Regel 3 darf nur einmal durchgeführt werden, d. h. es darf nur eine zusammenhängende Gruppe aus Null-Blöcken in der Adresse ersetzt werden, sonst wäre keine Eindeutigkeit gegeben.

URL-Notation von IPv6-Adressen

In einer URL wird die IPv6-Adresse in eckige Klammern eingeschlossen. Beispiel einer 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/

Netznotation

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-Adressbereiche mit Sonderaufgaben und unterschiedlichen Eigenschaften. Diese werden meist schon durch die ersten Bits der Adresse signalisiert. Sofern nicht weiter angegeben, werden die Bereiche in RFC 4291 definiert. Informationen über die Vergabe von IPv6-Netzen können über die Whois-Dienste der jeweiligen RIRs erhalten werden. Es gibt in deren RPSL-Datenbanken dazu inet6num- und route6-Objekte und in vielen anderen Objekttypen Attribute zur Multi-Protocol-Erweiterung (mp) mit Angabe der Address-Family (afi) zum spezifizieren des neuen Protokolls.

Besondere Adressen

• ::/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).

Link Local Unicast

fe80::/10 (fe80… bis febf…) sind so genannte link-lokale 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. Bei der Kommunikation mittels dieser Adressen muss die Schnittstelle mit angegeben werden, da link-lokale Präfixe auf einem Gerät mehrfach vorhanden sein können und damit unterschiedliche Netzsegmente den gleichen Adressraum beanspruchen (siehe Probleme).

Site Local Unicast (veraltet)

fec0::/10 (fec0… bis feff…), auch standortlokale Adressen genannt (site local addresses), waren die Nachfolger der privaten IP-Adressen (beispielsweise 192.168.x.x). Sie durften nur innerhalb der gleichen Organisation geroutet werden. Diese Adressen sind nach RFC 3879 inzwischen veraltet (engl. deprecated) und werden aus zukünftigen Standards verschwinden. Neue Implementationen müssen diesen Adressbereich als Global-Unicast-Adressen behandeln. Nachfolger der standortlokalen Adressen sind die Unique Local Addresses, die im nächsten Abschnitt beschrieben werden.

Unique Local Unicast

fc00::/7 (fc… und fd…). 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^[6] 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.

Multicast

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: link-lokal, 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 ^[7].

Beispiele für wohlbekannte Multicast-Adressen ^[8]:

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

Global Unicast

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.^[9]
• 3ffe::/16-Adressen wurden für das Testnetzwerk 6Bone benutzt; dieser Adressbereich wurde gemäß RFC 3701 wieder an die IANA zurückgegeben.

Funktionalität

Autokonfiguration

Für eine IPv6-fähige Ethernet-Schnittstelle kann aus deren MAC-Adresse eine link-lokale Adresse automatisch errechnet werden (siehe auch Probleme). Damit kann ein Gerät sich mittels Neighbor Discovery Protocol (NDP, siehe auch ICMPv6-Funktionalität) auf die Suche nach den Routern in seinem Netzwerksegment machen. Dies geschieht durch eine Anfrage an die Multicast-Adresse ff02::2, über die alle Router eines Segments erreichbar sind. Ein Router versendet über NDP unter anderem Präfixe, das sind Informationen über die Adressbereiche, aus denen ein Gerät sich selbst Unicast-Adressen 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 ebenfalls via NDP automatisch 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.

Umnummerierung und Multihoming

Unter IPv4 ist die Umnummerierung (Änderung des IP-Adressbereichs) für Netze ab einer gewissen Größe problematisch, auch wenn Mechanismen wie DHCP dabei helfen. Speziell der Ü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, also ein Netz gleichzeitig von mehr als einem Provider mit Internet-Anbindung und IP-Adressbereichen versorgt wird. Die Umgehung des Umnummerierens unter IPv4 mittels Border Gateway Protocol (BGP) führt zur Fragmentierung des Adressraums. Es geraten also viele, vergleichsweise kleine Netze bis in die Routing-Tabellen im Kernbereich des Internets, und die Router dort müssen darauf ausgelegt werden.

Der Vorgang der Umnummerierung wurde beim Design von IPv6 hingegen berücksichtigt, er wird in RFC 4076 behandelt. Mechanismen wie die IPv6-Autokonfiguration helfen dabei. Der parallele Betrieb mehrerer IP-Adressbereiche gestaltet sich unter IPv6 ebenfalls unproblematischer als unter IPv4, wie im Abschnitt Adressaufbau oben beschrieben. Das Ziel ist unter anderem dem Betreiber eines Netzwerkes den unkomplizierten Wechsel zwischen Providern oder gar den dauerhaften Parallelbetrieb mehrerer Provider zu ermöglichen, um damit den Wettbewerb zu fördern, die Ausfallsicherheit zu erhöhen oder den Datenverkehr auf Leitungen mehrerer Anbieter zu verteilen.

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

Im Gegensatz zu IPv4 (Protokoll Typ 4) hat der IP-Kopfdatenbereich (Header) bei IPv6 (Protokoll Typ 41) eine feste Länge von 40 Bytes (320 Bits). Optionale, seltener benutzte 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 laut RFC 2460 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 Kopfdatenbereiches dieser kann entweder einen Erweiterungs-Kopfdatenbereich (siehe nächste Tabelle) oder ein Protokoll höherer Schicht (engl.: Upper Layer Protocol) bezeichnen, wie z. B. TCP (Typ 6) oder UDP (Typ 17).
Hop Limit	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. Es entspricht dem Feld Time to Live (TTL) bei IPv4.
Source Address	128 Bit	Adresse des Senders
Destination Address	128 Bit	Adresse des Empfängers

Wie im Next Header Feld verwiesen sind sechs Extension Headers und ein Platzhalter definiert:

Name	Typ	Größe	Beschreibung	RFCs
Hop-By-Hop Options	0	variabel	Enthält Optionen, die von allen IPv6-Geräten, welche das Paket durchläuft beachtet werden müssen, wird z. B. für Jumbograms benutzt.	RFC 2460, RFC 2675
Routing	43	variabel	Durch diesen Header kann der Weg des Paketes durch das Netzwerk beeinflusst werden, er wird unter anderem für Mobile IPv6 verwendet.	RFC 2460, RFC 3775, RFC 5095
Fragment	44	64 Bit	In diesem Header können die Parameter einer Fragmentierung festgelegt werden.	RFC 2460
Authentication Header (AH)	51	variabel	Enthält Daten, welche die Vertraulichkeit des Paketes sicherstellen können (siehe IPsec).	RFC 4302
Encapsulating Security Payload (ESP)	50	variabel	Enthält Daten zur Verschlüsselung des Paketes (siehe IPsec).	RFC 4303
Destination Options	60	variabel	Enthält Optionen, die nur vom Zielrechner des Paketes beachtet werden müssen.	RFC 2460
No Next Header	59	leer	Dieser Typ ist nur ein Platzhalter, um das Ende eines Header-Stapels anzuzeigen.	RFC 2460

Die meisten IPv6-Pakete sollten ohne Extension Headers auskommen, diese können bis auf den Destination Options Header nur einmal in jedem Paket vorkommen. Befindet sich nämlich ein Routing Extension Header in dem Paket, so darf davor ein weiterer Destination Options Header stehen. Alle Extension Headers enthalten ein Next Header Feld in dem der nächste Extension Header oder das Upper Layer Protocol genannt wird.

Die Reihenfolge lautet: IPv6 Header, Hop-By-Hop Options, Destination Options (falls ein Routing Header folgt), Routing, Fragment, Authentication Header (AH), Encapsulating Security Payload (ESP), Destination Options (diesmal für den Zielhost), Upper Layer Protocol Header.

Die Größen dieser Header sind immer Vielfache von 64 Bit, auch sind die meisten Felder der Kopfdatenbereiche auf 64-Bit-Grenzen ausgerichtet, um Speicherzugriffe im Router zu beschleunigen. Des Weiteren 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.

Paketgrößen

Die Maximum Transmission Unit (MTU) darf in einem IPv6-Netzwerk 1280 Byte nicht unterschreiten. Somit unterschreitet auch die Path MTU (PMTU) diesen Wert nicht und es können Pakete bis zu dieser Größe garantiert ohne Fragmentierung übertragen werden. Minimale IPv6-Implementierungen verlassen sich auf diesen Fall.

Ein IPv6-Paket darf auch fragmentiert laut Payload Length Feld im IPv6-Header die Größe von 65.575 Byte einschließlich Kopfdaten nicht überschreiten, da dieses Feld 16 Bit lang ist. RFC 2675 stellt aber über eine Option des Hop-by-Hop Extension Headers die Möglichkeit zur Verfügung, Pakete mit Größen bis zu 4.294.967.335 Byte, sogenannte Jumbograms zu erzeugen. Dies erfordert allerdings Anpassungen in Protokollen höherer Schichten, wie z. B. TCP oder UDP, da diese oft auch nur 16 Bit für Größenfelder definieren.

Erweiterte ICMP-Funktionalität

Der Gebrauch von ICMPv6 (Protokoll Typ 58) beschränkt sich bei IPv6 nicht auf den Erreichbarkeitstest mittels Echo-Request und Echo-Reply (z. B. mit ping), sondern stellt unverzichtbare Funktionen zur Verfügung. Das Verbieten aller ICMPv6-Pakete in einem IPv6-Netzwerk durch Filter ist daher im Normalfall nicht durchführbar.

Das Address Resolution Protocol (ARP) wird durch das Neighbor Discovery Protocol (NDP) ersetzt, welches auf ICMPv6 basiert. Dieses macht hierbei intensiv Gebrauch von Link Local Unicast Adressen und Multicast, das von jedem Host beherrscht werden muss. Im Rahmen des NDP werden auch die automatische Adressvergabe und die automatische Zuordnung einer oder mehrerer Default-Routen über ICMPv6 abgewickelt, so stellt es die meisten Funktionen zur Verfügung, die oben unter IPv6-Autokonfiguration erklärt wurden. NDP kann auf die Möglichkeit weiterer Konfiguration durch DHCPv6 verweisen, welches allerdings UDP-Pakete benutzt.

Die Fragmentierung überlanger IPv6-Pakete erfolgt nicht mehr durch die Router, der Absender wird stattdessen mit Hilfe von ICMPv6-Nachrichten aufgefordert, kleinere Pakete, auch unter Zuhilfenahme des Fragment Extension Headers, zu schicken (siehe in diesem Zusammenhang Maximum Transfer Unit (MTU)). Idealerweise sollte ein IPv6-Host, bzw. eine Anwendung 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.

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 einem funktionierenden Domain Name System (DNS) abhängig. RFC 3596 definiert den Resource Record (RR) Typ AAAA (sprich: Quad-A), welcher genau wie ein Typ A Resource Record für IPv4, einen Namen in eine IPv6-Adresse auflöst. Der Reverse Lookup, also die Auflösung einer IP-Adresse in einen Namen funktioniert nach wie vor über den RR Typ PTR, nur ist für IPv6 die reverse Domain nicht mehr IN-ADDR.ARPA wie für IPv4, sondern IP6.ARPA und die Delegation von Subdomains darin geschieht nicht mehr an 8-Bit, sondern an 4-Bit Grenzen.

Laut der Default Policy Table in RFC 3484 wird die Kommunikation über IPv6 gegenüber IPv4 bevorzugt, falls mittels DNS festgestellt wird, dass für eine Verbindung beide Protokolle zur Verfügung stehen. Es stellt daher bei der derzeitigen Qualität des IPv6-fähigen Internets ein Risiko dar, z. B. dem Namen einer Portalseite einen Typ A und einen Typ AAAA RR zuzuweisen, was dazu führt, dass mit IPv6 neue Namen auftauchen, die oft „ipv6“ oder „ip6“ beinhalten, wie ipv6.google.com, so kann der Nutzer schon bei der Angabe des Namens das Protokoll wählen. Dieses Verhalten ist meistens aber auch auf der Anwendungsebene, also z. B. im Browser, einstellbar.

Sieben der dreizehn Root-Nameserver und mindestens zwei Nameserver der meisten Top-Level-Domains sind bereits über IPv6 erreichbar. Das übertragende Protokoll ist unabhängig von den übertragenen Informationen. Insbesondere kann man über IPv4 einen Nameserver nach Typ AAAA RRs fragen. Windows XP kann Nameserver nur über IPv4 befragen, auch wenn eine IPv6-Verbindung besteht.

Es ergaben sich bei der Integration des IPv6-Adressraums in das DNS im Wesentlichen folgende Probleme:

1. Die IPv6-Autokonfiguration sucht nicht nach Nameservern. Diese Funktionalität wurde erst in RFC 5006 vorgeschlagen. Link-lokale DNS-Server können 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 DHCPv6. 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.

Übergangsmechanismen

Um einen einfachen Übergang von IPv4- zu IPv6-Kommunikation im Internet zu ermöglichen wurden verschieden Mechanismen erdacht. IPv6 wird dabei in der Regel hinzugeschaltet, ohne IPv4 abzuschalten. Sie unterteilen sich in einfachen Parallelbetrieb (Dual-Stack), Tunnelmechanismen und Übersetzungsverfahren. Die beiden ersten Verfahren setzten voraus, dass die Betriebssysteme der angebundenen Rechner beide Protokolle beherrschen.

Es gibt bereits heute Bereiche des Internets, die nur mittels IPv6 erreichbar sind, andere Teile, die über beide Protokolle angebunden sind, und große Teile, die sich nur auf IPv4 verlassen. Im Folgenden werden die ersten beiden Bereiche zusammen als IPv6-Internet bezeichnet.

Dual-Stack

Bei diesem Verfahren werden allen beteiligten Schnittstellen neben der IPv4-Adresse zusätzlich mindestens eine IPv6-Adresse und den Rechnern die notwendigen Routinginformationen zugewiesen. Die Rechner können dann über beide Protokolle unabhängig kommunizieren. Dieses Verfahren sollte der Regelfall sein, es scheitert derzeit oft daran, dass einige Router auf dem Weg zum IPv6-Internet noch keine IPv6-Weiterleitung eingeschaltet haben oder unterstützen.

Tunnelmechanismen

Um solche Router auf dem Weg zum IPv6-Internet zu überbrücken, welche IPv6 nicht weiterleiten, gibt es eine Vielzahl von Tunnelmechanismen. Dabei werden immer IPv6-Pakete in der Nutzlast anderer Protokolle (meist IPv4), zu einer Tunnelgegenstelle übertragen, die sich im IPv6-Internet befindet. Dort werden sie aus der Nutzlast herausgelöst und zum Ziel via IPv6-Routing übertragen. Der Rückweg funktioniert analog. Jedes Tunnelverfahren ist abhängig von der Qualität des tunnelnden Protokolls, und die mögliche Nutzlast sinkt, da mehr Kopfdaten übertragen werden müssen.

Der klassische Weg ist es, bei einem sog. Tunnelbroker eine solche Gegenstelle zu beantragen, diese bleibt fest, und man bekommt über den Tunnel immer den gleichen IPv6-Adressbereich zugewiesen. 6in4 benutzt zum Beispiel den Protokoll Typ 41, um IPv6 direkt in IPv4 „einzupacken“. Für Linux ist die Erstellung eines solchen Tunnels mit den Interface-Konfigurationswerkzeugen möglich^[10]. Komplizierter sind die Verfahren 6over4 oder ISATAP.

Der Mechanismus 6to4 benötigt keine Absprache mit einer Gegenstelle, denn diese benutzt wohlbekannte, mehrfach im Internet vergebene, IPv4-Adressen (Anycast), und die getunnelten Pakete werden zur nächstgelegenen zugestellt und dort verarbeitet. Dem angebundenen Rechner steht dann ein IPv6-Adressbereich zur Verfügung, der sich aus dessen öffentlicher IPv4-Adresse errechnet. Auch ein solcher Tunnel kann auf aktuellen Linux-Rechnern mit öffentlicher IPv4-Adresse durch wenige Handgriffe eingerichtet werden^[11].

Befindet sich ein Rechner in einem privaten IPv4-Adressbereich und findet beim Verbinden mit dem Internet NAT statt, so können Mechanismen wie AYIYA oder Microsofts recht automatisch funktionierendes Teredo helfen. Erlaubt ein Administrator diese Protokolle, die meist auf UDP basieren, kann schnell die Netzwerksicherheit in Gefahr geraten.

Natürlich ist es auch möglich IPv6 über allgemeinere Tunnelverfahren wie GRE, L2TP oder MPLS zu transportieren, insbesondere, wenn noch Routingprotokolle wie IS-IS parallel übertragen werden müssen.

Übersetzungsverfahren

Kann auf einem Gerät IPv6 nicht aktiviert werden oder stehen nicht mehr genügend IPv4-Adressen zur Verfügung, können Verfahren wie Network Address Translation/Protocol Translation (NAT-PT, RFC 2766), oder Transport Relay Translation (TRT, RFC 3142) nötig werden, um zwischen beiden Protokollen zu übersetzen.

Technische Umsetzung

Betriebssysteme

Viele Betriebssysteme unterstützen inzwischen IPv6, ein Überblick folgt. Entscheidend für eine tunnelfreie Anbindung ist aber auch die Unterstützung durch die Firmware, bzw. die Betriebssysteme, auf den (DSL-)Routern bei Endkunden, sie fehlt bei noch fast allen solchen Geräten. Systeme zur Lastverteilung, wie sie z. B. für große Webseiten eingesetzt werden, können in der vorhandenen Form für IPv6 nicht weiter benutzt werden, sofern sie auf NAT basieren.

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, bei NetBSD seit Dezember 2000 und bei OpenBSD seit Mitte 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 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. IPv6 ist standardmäßig aktiviert und unterstützt DNS-AAAA-Records. Die zur Apple-Produktfamilie gehörenden Airport-Extreme-Consumer-Router richten standardmäßig einen 6to4-Tunnel ein und fungieren als IPv6-Router.

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 Microsystems 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. Der experimentelle Patch lässt sich nur mit Servicepack 1 nutzen. Mit einer kleinen Anpassung lässt der Patch sich auch mit Servicepack 2 bis 4 nutzen. ^[12]

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. Die Kommunikation mit den DNS-Servern funktioniert nicht über IPv6, sondern nur über IPv4. 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. Hat das System eine global routbare IPv4-Adresse, richtet Windows XP automatisch einen 6to4-Tunnel ein.^[13]

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. Windows Server 2003 kann wie Windows XP automatisch 6to4-Tunnel konfigurieren.

Windows Vista

IPv6 wird hier von Anfang an unterstützt, da das Betriebssystem mit einer „Dual-IP-Layer-Architektur“ arbeitet und somit sowohl IPv4 als auch IPv6 unterstützt. Ist Internet Connection Sharing aktiviert, so fungiert Windows Vista auch als IPv6-Router und versendet entsprechende Router Advertisements zur Autokonfiguration von Clients. Mobile IPv6 wird nicht unterstützt.

Microsoft Windows Server 2008

IPv6 ist standardmäßig installiert und aktiviert. Viele Komponenten setzen eine Konfiguration beider Protokolle voraus. Wie in Windows Vista fehlt die Unterstützung für Mobile IPv6.

Paketfilter und Firewalls

Für IPv6 müssen alle Filterregeln in Firewalls und Paketfiltern neu erstellt werden. Eine Firewall, die nicht ausdrücklich mit IPv6 umgehen kann, wird in der Regel IPv6-Datenverkehr nicht bemerken und durchlassen. Auch einige Antivirenprogramme haben Zusätze, welche den Verkehr z. B. auf bestimmten TCP-Ports nach Signaturen durchsuchen.

Dadurch, dass NAT für IPv6 nicht angedacht ist und viel mehr Netzwerkgeräte mit öffentlichen (Global Unicast) Adressen versehen sind, sehen Filterregeln für IPv6 deutlich anders aus als für IPv4. Wie oben schon erwähnt, darf ICMPv6 im allgemeinen nicht mehr pauschal gefiltert werden. Einige Aspekte von NAT wurden in der Vergangenheit oft als Sicherheitsfunktion verstanden, es gibt laut RFC 4864 jedoch Vorgehensweisen unter IPv6, welche diese Aspekte abbilden^[14].

Anwendungssoftware

Bei Anwendungen, wie Webbrowser oder E-Mail-Programm, sind Änderungen in der Programmierung notwendig, damit sie über IPv6 kommunizieren können. Dies ist für die wichtigsten Programme, die mit aktuellen Betriebssystemen ausgeliefert werden, bereits geschehen, nicht aber bei weniger häufig benutzten Anwendungen, auch in Linux-Distributionen.

In den meisten Fällen sind nur kleinere Änderungen notwendig, da die Anwendungen auf Protokolle höherer Schicht aufsetzen und diese ändern sich kaum. So muss z. B. eine evtl. ermittelte, verminderte Path MTU an die Anwendung übergeben werden, um Fragmentierung zu vermeiden, oder die Maximum Segment Size (MSS) im TCP-Header muss bei IPv6 gegenüber IPv4 verringert werden. Viele Programmiersprachen stellen spezielle Bibliotheken zur Verfügung, um den Umgang mit dem neuen Protokoll zu vereinfachen.

Verbreitung und Projekte

IPv6 setzt sich im praktischen Einsatz nur langsam durch. Die Adressvergabe für IPv6 ist im Juli 1999 vom experimentellen in den Regelbetrieb übergegangen^[15] und immer mehr ISPs betreiben neben IPv4 auch IPv6 in ihrem Netz, dieses aber zumeist nur testweise und entweder ohne entsprechende Produkte, oder ohne Verfügbarkeitsgarantien für ihre Kunden. Somit werden vollwertige IPv6-Anbindungen im Dual-Stack-Verfahren fast nur von kleineren Providern angeboten, so dass man im Moment auf Tunnel zurückgreifen muss. Die meisten der großen Austauschpunkte für Internetverkehr 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.^[16] In LANs kann IPv6 bereits zum Einsatz kommen.

Das IPv6 Forum^[17] wurde im Juli 1999, das Deutsche IPv6 Council^[18] im Dezember 2007 gegründet. Das IPv6 Forum Projekt IPv6-Ready^[19] 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.

Derzeit sind 74 % aller IPv4-Adressen den nordamerikanischen Internet Registries und einigen US-amerikanischen Institutionen und Unternehmen direkt zugewiesen, während beispielsweise ganz China – mit inzwischen über 250 Millionen Internet-Benutzern (Stand: Juni 2008^[20]) – nur über etwa so viele IP-Adressen verfügt wie ein Campus der University of California (Dezember 2004).^[21] In Asien geht der Trend daher inzwischen dahin, bei Neubauten (zum Beispiel dem insbesondere Japan und die USA verbindenden NTT-Backbone) IPv6 auch zu benutzen. 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.^[22]

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; Umnummerierung und Autokonfiguration sind auch mittels DHCP möglich) – es gibt keine weitverbreitete Anwendung, die nur mit IPv6 funktionieren würde.

In Deutschland federführend bei den Versuchen zu IPv6 war das JOIN-Projekt der Universität 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.

Das Freifunk.net-Projekt baut in Berlin ein selbstroutendes IPv6-Mesh-Netzwerk auf. Hierbei soll nach der Erprobungsphase auf rund 100 km² ein IPv6 Funknetzwerk entstehen, das auch einfach in anderen Städten reproduzierbar sein soll.

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.

Probleme

Gerade zu Anfang litt IPv6 unter einigen Kinderkrankheiten. 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 Interface Identifier als Teil der Adressen. Um die Einzigartigkeit einer Adresse im Netzwerk auf einfache Weise zu garantieren, wurde vorher die MAC-Adresse einer Schnittstelle unverändert in die IPv6-Adresse übernommen, nun wird die MAC-Adresse gemäß EUI-64 in veränderter Form in die IPv6-Adresse geschrieben; dabei wird aufgrund einer Verwechslung in RFC 3513 der Algorithmus, um EUI-64-Namen aus EUI-48-Namen zu berechnen, fälschlicherweise auf MAC-48-Namen angewandt^[23].

Die beschriebenen Verfahren führen zu einem statischen Host-Teil der IPv6-Adresse eines autokonfigurierten IPv6-Knotens. Datenschützer waren besorgt, dass auf diese Weise der Datenverkehr zu einer bestimmten IP-Adresse mitgeschnitten und beispielsweise für Marketingmaßnahmen oder staatliche Interventionen verwendet werden könnte. Die IETF definierte deshalb nachträglich die Datenschutzerweiterungen (Privacy Extensions) gemäß RFC 3041, später RFC 4941 (siehe auch Adressaufbau von IPv6).

In der Praxis ergab sich mit den link-lokalen Adressen das Problem, dass es für diese nicht ausreichend ist, die IP-Adresse im Ziel-Feld einzutragen, sondern auch ein Zone Index nach RFC 4007 (in den meisten Fällen ein Interface) angegeben werden muss, da nicht klar ist, über welche Schnittstelle die Adresse angesprochen werden soll. Deshalb sind die link-lokalen Adressen nur beschränkt zur Kommunikation tauglich, abhängig davon, ob die IPv6-Unterstützung der verwendeten Anwendung dieses Konzept kennt.

Weitere Probleme sind in dem Abschnitt IPv6 und DNS beschrieben.

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.
• Silvia 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

• Internet
• Internet Protocol
• IPv4
• IP-Adresse
• IP-Paket
• Routing
• TCP/IP-Referenzmodell
• Protokollstapel
• M6Bone
• DoD Standard Internet Protocol
• Teredo

Weblinks

• RFC 2460, „Internet Protocol, Version 6 (IPv6) Specification“, Dezember 1998 (englisch)
• Allokation des IPv6-Adressbereiches im Überblick (englisch)
• SixXS, ein IPv6 Tunnelbroker (englisch)
• IPv6 Resource, Beschreibung IPv6-Implementationen und Software (englisch)
• Verzeichnis von über IPv6 erreichbaren Websites

Einzelnachweise

1. ↑ Globale IPv4 Adressbereichsverteilung
2. ↑ Schätzung des voraussichtlichen Endes der IPv4 Adressvergabe
3. ↑ ARIN Board Statement on the Future of Addressing Policy
4. ↑ (RFC 4294, Kap 8)
5. ↑ (RFC 4291, Kap 2.2.2)
6. ↑ Dazu siehe auch das Skript auf hznet.de
7. ↑ (RFC 4291, Kap. 2.7)
8. ↑ Zugewiesene Multicast-Adressen
9. ↑ IANA: IPv6 Unicast Address Assignments, Version vom 22. Dezember 2006
10. ↑ Konfiguration eines IPv6-in-IPv4 Tunnels
11. ↑ Konfiguration eines 6to4 Tunnels
12. ↑ Schritte zur Anpassung des Windows-2000-Protokollstapels an SP2 bis 4: [1]
13. ↑ Microsoft TechNet: Routing IPv6 Traffic over IPv4 Infrastructure: TCP/IP, aufgerufen am 29. Januar 2009
14. ↑ NAT-artige Sicherheit in IPv6 Netzwerken mit Cisco Routern
15. ↑ Ankündigung zur Vergabe von IPv6-Adressen im Regelbetrieb durch die IANA
16. ↑ APA, AP: Internet-Protokoll IPv6 kommt endlich in Bewegung, derstandard.at, 6. Mai 2008
17. ↑ Website des IPv6 Forum
18. ↑ Website des Deutschen IPv6 Council
19. ↑ Website IPv6ready
20. ↑ Heise Online: China hat nun weltweit die meisten Internetnutzer (24. Juli 2008)
21. ↑ Liu Baijia: China launches new generation Internet (China Daily, 27. Dezember 2004)
22. ↑ Ingrid Marson: China launches largest IPv6 network (CNET News.com, 29. Dezember 2004)
23. ↑ Diskussion über EUI-64, EUI-48 und MAC-48

Dieser Artikel ist ein Kandidat für lesenswerte Artikel, beteilige dich an der Diskussion!