Quelltext der Seite IPv6

{{Netzwerk-TCP-IP-Vermittlungsprotokoll|IPv6}}

Das '''Internet Protocol Version 6''' ('''IPv6'''), früher auch ''Internet Protocol next Generation'' (IPng) genannt, ist ein von der ''[[Internet Engineering Task Force]]'' (IETF) seit 1998 standardisiertes Verfahren zur Übertragung von Daten in [[Paketvermittlung|paketvermittelnden]] [[Rechnernetz]]en, insbesondere dem [[Internet]]. In diesen Netzen werden die Daten in Paketen versendet, in welchen nach einem [[Schichtenarchitektur|Schichtenmodell]] Steuerinformationen verschiedener [[Netzwerkprotokoll]]e ineinander verschachtelt um die eigentlichen [[Nutzdaten]] herum übertragen werden. IPv6 stellt als Protokoll der Vermittlungsschicht (Schicht&nbsp;3 des [[OSI-Modell]]s) im Rahmen der [[Internetprotokollfamilie]] eine über Teilnetze hinweg gültige 128-[[Bit]]-[[IP-Adresse|Adressierung]] der beteiligten [[Netzwerkelement]]e ([[Computer|Rechner]] oder [[Router]]) her. Ferner regelt es unter Verwendung dieser Adressen den Vorgang der Paketweiterleitung zwischen Teilnetzen ([[Routing]]). Die Teilnetze können so mit verschiedenen Protokollen unterer Schichten betrieben werden, die deren unterschiedlichen physikalischen und administrativen Gegebenheiten Rechnung tragen.

Im Internet soll IPv6 im Laufe der Zeit die [[IPv4|Version&nbsp;4]] des ''[[Internet Protocol]]s'' (IPv4) vollständig ablösen, da es deutlich mehr Adressen bietet, von denen die [[Internet Assigned Numbers Authority|IANA]] bei IPv4 auf globaler Ebene 2011 die letzten vergeben hat.<ref>{{Internetquelle |autor=Publication date: 03 Feb 2011- announcement, iana, Ipv4 Depletion, icann, ipv4 |url=https://www.ripe.net/publications/news/announcements/ripe-ncc-receives-final-8-of-ipv4-address-space-from-iana |titel=RIPE NCC Receives Final /8 of IPv4 Address Space from IANA |abruf=2022-09-02}}</ref> Kritiker befürchten ein Zurückdrängen der Anonymität im Internet durch die nun mögliche zeitlich stabilere und weiter reichende öffentliche Adressierung.<ref>[https://www.heise.de/netze/meldung/Datenschuetzer-besorgt-ueber-IPv6-1382812.html ''Datenschützer besorgt über IPv6''.] Heise.de</ref> Befürworter bemängeln die zögerliche Einführung von IPv6 angesichts der ausgelaufenen globalen IPv4-Adressvergabe.<ref>[https://www.nro.net/nro-and-oecd-highlight-that-ipv6-deployment-is-too-slow ''NRO and OECD Highlight that IPv6 Deployment is Too Slow''.] Regional Internet Registries, Pressemitteilung.</ref> Zugriffe auf [[Google]] von Nutzern aus Deutschland verwendeten im April 2022 IPv6 zu etwa 60 %.<ref name="Google-Statistik">[https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption Google per country IPv6 Adoption].</ref>

== Gründe für ein neues Internet-Protokoll ==
[[Datei:Ipv4-exhaust.svg|mini|Anzahl verfügbarer IPv4-Adressblöcke zwischen 1995 2015]]
[[Datei:Rir-rate.svg|mini|Täglich zugewiesene IPv4-Adressen nach [[Regional Internet Registry|RIRs]] (Regional Internet Registries)]]

IPv4 bietet theoretisch einen Adressraum von etwas über vier Milliarden [[IP-Adresse]]n (2<sup>32</sup> = 256<sup>4</sup> = 4.294.967.296), der von der IANA in 256 /8-Netze eingeteilt wird, wovon 221<ref name="iana-v4assign">[https://www.iana.org/assignments/ipv4-address-space iana.org].</ref> weitgehend zur Nutzung freigegeben, also beispielsweise an RIRs zugewiesen wurden. Die restlichen 35 /8-Netze wurden für spezielle Zwecke (z.&nbsp;B. 127/8 für Loopback) oder für die Zukunft reserviert, was den verfügbaren Bereich rechnerisch auf 3.707.764.736 reduziert. Nachdem jedoch auch einige Unterbereiche (wie 100.64.0.0/10) der an sich freigegebenen /8-Netze für andere Zwecke reserviert wurden, reduziert sich dieser Bestand um weitere 5.506.830 IP-Adressen, sodass der tatsächlich nutzbare Adressbereich, um z.&nbsp;B. [[Computer]] und andere Geräte direkt anzusprechen, letztlich auf 3.702.257.906 IP-Adressen sinkt.<ref name="cidr-eu-ipv4-c4">IPv4 – Charts and Explanations | CIDR/EU: [https://www.cidr.eu/en/ipv4#C-4 siehe Abschnitte IV.–V.].</ref> In den Anfangstagen des [[Internet]]s, als es nur wenige Rechner gab, die eine IP-Adresse brauchten, war dies vollkommen ausreichend. Man hatte sogar größere Adressbereiche u.&nbsp;a. für große Organisationen reserviert, wodurch noch weniger freie Adressen für Privatpersonen übrig blieben.

Im Laufe der Zeit erlangte aber das Internet immer größere Verbreitung und die [[Weltbevölkerung]] war lange schon größer als die Zahl verfügbarer IPv4-Adressen. Hinzu kam, dass unter anderem eine [[Website]] bereits dauerhaft eine oder mehrere Adressen belegt. Es brauchte also ein besseres System, das ohne technische Provisorien viel mehr Adressen bereitstellt. Weitere Informationen siehe [[IPv4#Adressknappheit|Adressknappheit von IPv4]].

Durch eine kurzsichtige Vergabepraxis gibt es im IPv4-Adressraum eine starke [[IPv4#Adressfragmentierung|Fragmentierung]]. Bei IPv6 hingegen wurde eine weitsichtigere Praxis angewandt.

Aus diesen Gründen begann die [[Internet Engineering Task Force|IETF]] bereits 1995 die Arbeiten an IPv6. Im Dezember 1998 wurde IPv6 mit der Publikation von RFC 2460 auf dem ''[[Internetstandard|Standards Track]]'' offiziell zum Nachfolger von IPv4 gekürt. Im Juli 2017 veröffentlichte die IETF RFC 8200, der die ursprüngliche Fassung ersetzt.

Die wesentlichen neuen Eigenschaften von IPv6 umfassen:
* Vergrößerung des Adressraums von IPv4 mit 2<sup>32</sup> (≈&nbsp;4,3&nbsp;[[Zahlennamen|Milliarden]] = 4,3·10<sup>9</sup>) Adressen auf 2<sup>128</sup> (≈&nbsp;340&nbsp;[[Zahlennamen|Sextillionen]] = 3,4·10<sup>38</sup>) Adressen bei IPv6, d.&nbsp;h. Vergrößerung um den Faktor 2<sup>96</sup> (≈&nbsp;7,9·10<sup>28</sup>).
* Vereinfachung und Verbesserung des Protokollrahmens ([[#Header-Format|Kopfdaten]]); dies entlastet [[Router]] von Rechenaufwand.
* [[Zustandslosigkeit|Zustandslose]] [[#Autokonfiguration|automatische Konfiguration]] von IPv6-Adressen; [[Zustandsbehaftung|zustandsbehaftete]] Verfahren wie [[Dynamic Host Configuration Protocol|DHCP]] werden beim Einsatz von IPv6 damit in vielen Anwendungsfällen überflüssig.
* [[#Mobile IPv6|Mobile IP]] sowie Vereinfachung von [[#Umnummerierung und Multihoming|Umnummerierung und Multihoming]].
* Implementierung von [[IPsec]] innerhalb des IPv6-Standards.<ref>{{RFC-Internet |RFC=6434 |Titel= |Datum= |Abschnitt=11 |Abschnittstitel=}}</ref> Dadurch wird die Verschlüsselung und die Überprüfung der Authentizität von IP-Paketen ermöglicht.<ref>IPsec wurde zusätzlich auch für IPv4 spezifiziert, dort ist die Umsetzung aber optional, während sie für IPv6 zunächst in RFC 4294 vorgeschrieben war. Diese Vorschrift wurde aber mit RFC 6434 zurückgenommen.</ref>
* Unterstützung von Netztechniken wie [[Quality of Service]] und [[Multicast]].

Die hauptsächliche Motivation zur Vergrößerung des Adressraums besteht in der Wahrung des [[Direktverbindung|Ende-zu-Ende-Prinzips]],<ref name="ipv6-end-to-end">siehe etwa {{RFC-Internet |RFC=2775 |Titel= |Datum= |Abschnitt=5.1 |Abschnittstitel=}}</ref> das ein zentrales Designprinzip des Internets ist:<ref>{{RFC-Internet |RFC=3724 |Titel= |Datum= |Abschnitt=2 |Abschnittstitel=}}</ref> Nur die Endknoten des Netzes sollen aktive Protokolloperationen ausführen, das Netz zwischen den Endknoten ist nur für die Weiterleitung der Datenpakete zuständig. (Das Internet unterscheidet sich hier wesentlich von anderen digitalen Datenübertragungsnetzwerken wie z.&nbsp;B. [[Global System for Mobile Communications|GSM]].) Dazu ist es notwendig, dass jeder Netzknoten global eindeutig adressierbar ist.<ref name="ipv6-end-to-end" />

Heute übliche Verfahren wie [[Network Address Translation]] (NAT), welche derzeit die IPv4-Adressknappheit umgehen, verletzen das Ende-zu-Ende-Prinzip.<ref>{{RFC-Internet |RFC=2993 |Titel= |Datum= |Abschnitt=6 |Abschnittstitel=}}</ref> Sie ermöglichen den so angebundenen Rechnern nur, ausgehende Verbindungen aufzubauen. Aus dem Internet können diese hingegen nicht ohne Weiteres kontaktiert werden. Auch verlassen sich [[IPsec]] oder Protokolle auf höheren Schichten wie z.&nbsp;B. [[File Transfer Protocol|FTP]] und [[Session Initiation Protocol|SIP]] teilweise auf das Ende-zu-Ende-Prinzip und sind mit NAT nur eingeschränkt oder mittels Zusatzlösungen funktionsfähig.<ref>Stefan Wintermeyer: ''Asterisk 1.4 + 1.6''. 1.&nbsp;Auflage. Addison-Wesley, München 2009, Kapitel 8. [https://das-asterisk-buch.de/1.6/sip.html#sip-nat-problem das-asterisk-buch.de].</ref>

Besonders für Heimanwender bedeutet IPv6 damit einen Paradigmenwechsel: Anstatt vom [[Internetdienstanbieter|Provider]] nur eine einzige IP-Adresse zugewiesen zu bekommen und über NAT mehrere Geräte ans Internet anzubinden, bekommt man den global eindeutigen IP-Adressraum für ein ganzes Teilnetz zur Verfügung gestellt, so dass jedes seiner Geräte eine IP-Adresse aus diesem erhalten kann. Damit wird es für Endbenutzer einfacher, durch das Anbieten von Diensten aktiv am Netz teilzunehmen. Zudem entfallen die Probleme, die bei NAT durch die Adressumschreibung entstehen.

Bei der Wahl der Adresslänge und damit der Größe des zur Verfügung stehenden Adressraums waren mehrere Faktoren zu berücksichtigen. Zum einen müssen pro Datenpaket auch Quell- und Ziel-IP-Adresse übertragen werden. Längere IP-Adressen führen damit zu erhöhtem Protokoll-Overhead, d.&nbsp;h. das Verhältnis zwischen tatsächlichen Nutzdaten und der zur Vermittlung notwendigen Protokolldaten sinkt.<ref>Eine Diskussion des Problems findet sich in einem Internet-Draft von W. Eddy: [https://tools.ietf.org/html/draft-eddy-ipv6-overhead-00 ''Comparison of IPv4 and IPv6 Header Overhead''.]</ref> Auf der anderen Seite sollte dem zukünftigen Wachstum des Internets Rechnung getragen werden. Zudem sollte es zur Verhinderung der Fragmentierung des Adressraums möglich sein, einer Organisation nur ein einziges Mal Adressraum zuweisen zu müssen. Um den Prozess der [[#Autokonfiguration|Autokonfiguration]] sowie [[#Umnummerierung und Multihoming|Umnummerierung und Multihoming]] zu vereinfachen, war es außerdem wünschenswert, einen festen Teil der Adresse zur netzunabhängigen eindeutigen Identifikation eines Netzknotens zu reservieren. Die letzten 64&nbsp;Bit der Adresse bestehen daher in der Regel aus der [[EUI-64]] der Netzwerkschnittstelle des Knotens.

== Adressaufbau von IPv6 ==
IPv6-Adressen sind 128&nbsp;[[Bit]] lang (IPv4: 32&nbsp;Bit). Die ersten 64&nbsp;Bit bilden das sogenannte [[#Adresszuweisung|Präfix]], die letzten 64&nbsp;Bit bilden bis auf Sonderfälle einen für die Netzwerkschnittstelle ({{enS|network interface}}) eindeutigen ''[[EUI-64|Interface-Identifier]]''. Eine [[Netzwerkschnittstelle]] kann unter mehreren IP-Adressen erreichbar sein; in der Regel ist sie dies mittels ihrer [[#Link-Local-Unicast-Adressen|link-lokalen Adresse]] und einer [[#Global Unicast|global eindeutigen Adresse]]. Derselbe Interface-Identifier kann damit Teil mehrerer IPv6-Adressen sein, welche mit verschiedenen Präfixen auf dieselbe Netzwerkschnittstelle gebunden sind. Insbesondere gilt dies auch für Präfixe möglicherweise unterschiedlicher Internetanbieter; dies vereinfacht [[Multihoming]]-Verfahren.

Da die Erzeugung des Interface-Identifiers aus der global eindeutigen [[MAC-Adresse]] die Nachverfolgung von Benutzern ermöglicht, wurden die ''Privacy-Extensions'' (PEX, RFC 4941) entwickelt, um diese permanente Kopplung der Benutzeridentität an die IPv6-Adressen aufzuheben. Indem der Interface-Identifier zufällig generiert und regelmäßig gewechselt wird, soll ein Teil der Anonymität von IPv4 wiederhergestellt werden.

Da im Privatbereich in der IPv6-Adresse aber sowohl der Interface-Identifier als auch das Präfix allein recht sicher auf einen Nutzer schließen lassen können, ist aus Datenschutzgründen in Verbindung mit den Privacy Extensions ein vom Provider dynamisch zugewiesenes, z.&nbsp;B. täglich wechselndes Präfix wünschenswert. (Mit einer statischen Adresszuteilung geht in der Regel insbesondere ein Eintrag in der öffentlichen [[Whois]]-Datenbank einher.) Dabei ist es wie oben beschrieben grundsätzlich möglich, auf derselben Netzwerkschnittstelle sowohl IPv6-Adressen aus dynamischen als auch aus fest zugewiesenen Präfixen parallel zu verwenden. In Deutschland hat der [[Deutscher IPv6-Rat|Deutsche IPv6-Rat]] Datenschutzleitlinien formuliert, die auch eine dynamische Zuweisung von IPv6-Präfixen vorsehen.<ref>{{Webarchiv |url=http://www.ipv6council.de/documents/leitlinien_ipv6_und_datenschutz.html |wayback=20121207001716 |text=''Leitlinien IPv6 und Datenschutz''.}} German IPv6 Council.</ref>

=== Adressnotation ===
Die textuelle Notation von IPv6-Adressen ist in Abschnitt 2.2 von RFC 4291 beschrieben:

# IPv6-Adressen werden für gewöhnlich [[Hexadezimalsystem|hexadezimal]] (IPv4: [[Dezimalsystem|dezimal]]) notiert, wobei die Zahl in acht Blöcke zu jeweils 16&nbsp;Bit (4 Hexadezimalstellen) unterteilt wird. Diese Blöcke werden durch Doppelpunkte (IPv4: Punkte) getrennt notiert: <code>2001:0db8:85a3:08d3:1319:8a2e:0370:7344</code>.
# Führende Nullen innerhalb eines Blockes dürfen ausgelassen werden: <code>2001:0db8:0000:08d3:0000:8a2e:0070:7344</code> ist gleichbedeutend mit <code>2001:db8:0:8d3:0:8a2e:70:7344</code>.
# Ein oder mehrere aufeinander folgende Blöcke, deren Wert ''0'' (bzw. ''0000'') beträgt, dürfen ausgelassen werden. Dies wird durch zwei aufeinander folgende Doppelpunkte angezeigt: <code>2001:db8:0:0:0:0:1428:57ab</code> ist gleichbedeutend mit <code>2001:db8::1428:57ab</code>.<ref name="rfc5952sec422">{{RFC-Internet |Autor=S. Kawamura |RFC=5952 |Titel=A Recommendation for IPv6 Address Text Representation |Datum=2010-08 |Abschnitt=4.2.2 |Abschnittstitel=}}</ref>
# Die Reduktion durch Regel 3 darf nur einmal durchgeführt werden, das heißt, es darf höchstens eine zusammenhängende Gruppe aus Null-Blöcken in der Adresse ersetzt werden. Die Adresse <code>2001:0db8:0:0:8d3:0:0:0</code> darf demnach entweder zu <code>2001:db8:0:0:8d3::</code> oder <code>2001:db8::8d3:0:0:0</code> gekürzt werden; <code>2001:db8::8d3::</code> ist unzulässig, da dies mehrdeutig ist und fälschlicherweise z.&nbsp;B. auch als <code>2001:db8:0:0:0:8d3:0:0</code> interpretiert werden könnte. Die Reduktion darf auch dann nicht mehrfach durchgeführt werden, wenn das Ergebnis eindeutig wäre, weil jeweils genau eine einzige 0 gekürzt wurde. Es empfiehlt sich, die Gruppe mit den meisten Null-Blöcken zu kürzen.
# Ebenfalls darf für die letzten beiden Blöcke (vier [[Bytes]], also 32 Bits) der Adresse die herkömmliche dezimale Notation mit Punkten als Trennzeichen verwendet werden. So ist <code>::ffff:127.0.0.1</code> eine alternative Schreibweise für <code>::ffff:7f00:1</code>. Diese Schreibweise wird vor allem bei Einbettung des IPv4-Adressraums in den IPv6-Adressraum verwendet.

=== URL-Notation von IPv6-Adressen ===
In einer [[Uniform Resource Locator|URL]] wird die IPv6-Adresse in eckige Klammern eingeschlossen,<ref>{{RFC-Internet |RFC=3986 |Titel= |Datum= |Abschnitt=3.2.2 |Abschnittstitel=}}</ref> z.&nbsp;B.:
* <code><nowiki>http://[2001:0db8:85a3:08d3::0370:7344]/</nowiki></code>
Diese Notation verhindert die fälschliche Interpretation von Portnummern als Teil der IPv6-Adresse:
* <code><nowiki>http://[2001:0db8:85a3:08d3::0370:7344]:8080/</nowiki></code>

=== Netznotation ===
IPv6-Netzwerke werden in der [[Classless Inter-Domain Routing|CIDR]]-Notation aufgeschrieben. Dazu werden die erste Adresse (bzw. die Netzadresse) und die Länge des Präfixes in Bits getrennt durch einen Schrägstrich notiert. Zum Beispiel steht <code>2001:0db8:1234::/48</code> für das Netzwerk mit den Adressen <code>2001:0db8:1234:0000:0000:0000:0000:0000</code> bis <code>2001:0db8:1234:ffff:ffff:ffff:ffff:ffff</code>. Die Größe eines IPv6-Netzes (oder Subnetzes) im Sinne der Anzahl der vergebbaren Adressen in diesem Netz muss also eine Zweierpotenz sein. Da ein einzelner [[Host (Informationstechnik)|Host]] auch als Netzwerk mit einem 128&nbsp;Bit langen Präfix betrachtet werden kann, werden Host-Adressen manchmal mit einem angehängten „/128“ geschrieben.

== Aufteilung des IPv6-Adressraums ==
=== Adresszuweisung ===
Typischerweise bekommt ein [[Internetdienstanbieter|Internetprovider]] (ISP) die ersten 32&nbsp;Bit (oder weniger) als Netz von einer [[Regional Internet Registry]] (RIR) zugewiesen.<ref>[https://www.ripe.net/publications/docs/ripe-512#minimum_allocation ''IPv6 Address Allocation and Assignment Policy''] von [[Asia-Pacific Network Information Centre|APNIC]], [[American Registry for Internet Numbers|ARIN]], [[RIPE Network Coordination Centre|RIPE NCC]], Abschnitt 4.3.</ref> Dieser Bereich wird vom Provider weiter in [[Subnetz]]e aufgeteilt. Die Länge der Zuteilung an Endkunden wird dabei dem ISP überlassen; vorgeschrieben ist die minimale Zuteilung eines /64-Netzes.<ref>[https://www.ripe.net/publications/docs/ripe-552#assignment_size ''IPv6 Address Allocation and Assignment Policy'', Abschnitt 5.4.1].</ref> Ältere Dokumente (z.&nbsp;B. RFC 3177) schlagen eine Zuteilung von /48-Netzen an Endkunden vor; in Ausnahmefällen ist die Zuteilung größerer Netze als /48 oder mehrerer /48-Netze an einen Endkunden möglich.<ref>[https://www.ripe.net/publications/docs/ripe-512#assignment_multiple ''IPv6 Address Allocation and Assignment Policy'', Abschnitt 5.4.2].</ref> Informationen über die Vergabe von IPv6-Netzen können über die [[Whois#IP- und AS-Lookups|Whois]]-Dienste der jeweiligen RIRs abgefragt werden. Es gibt in deren [[Routing Policy Specification Language|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.

Einem einzelnen [[Segment (Netzwerk)|Netzsegment]] wird in der Regel ein 64&nbsp;Bit langes Präfix zugewiesen, das dann zusammen mit einem 64&nbsp;Bit langen Interface-Identifier die Adresse bildet.<ref>{{RFC-Internet |RFC=4291 |Titel= |Datum= |Abschnitt=2.5.4 |Abschnittstitel=}}</ref> Der Interface-Identifier kann entweder aus der [[MAC-Adresse]] der Netzwerkschnittstelle erstellt oder anders eindeutig zugewiesen werden; das genaue Verfahren ist in RFC 4291, Anhang&nbsp;A beschrieben.

Hat z.&nbsp;B. ein Netzwerkgerät die IPv6-Adresse
: <code style="border:0; padding:0;"><span style="background: #FFC0A0; padding: 1.5ex 0; line-height: 3em;"><span style="background: #A0C0FF; padding: 1ex 0;"><span style="background: #A0FFA0; padding: .5ex 0;"><span style="background:#FFA0A0">2001:0db8:</span>85a3:</span>08</span>d3:</span><span style="background:#FFFFA0">1319:8a2e:0370:7347</span><span style="background:#FFC0A0">/64</span></code>,
so lautet das Präfix
: <span style="background:#FFC0A0; font-family:monospace,monospace;">2001:0db8:85a3:08d3::/64</span>
und der Interface-Identifier
: <span style="background: #FFFFA0; font-family: monospace,monospace; margin-left: 166px;">1319:8a2e:0370:7347</span>.
Der Provider bekam von der [[Regional Internet Registry|RIR]] wahrscheinlich das Netz
: <span style="background:#FFA0A0; font-family:monospace,monospace;">2001:0db8::/32</span>
zugewiesen und der Endkunde vom Provider möglicherweise das Netz
: <span style="background:#A0FFA0; font-family:monospace,monospace;">2001:0db8:85a3::/48</span>,
oder aber nur
: <span style="background:#A0C0FF; font-family:monospace,monospace;">2001:0db8:85a3:0800::/56</span>.

=== Adressbereiche ===
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 bzw. RFC 5156 definiert. ''Unicast''-Adressen charakterisieren Kommunikation eines Netzknotens mit genau einem anderen Netzknoten; Einer-zu-vielen-Kommunikation wird durch ''Multicast''-Adressen abgebildet.

==== Besondere Adressen ====
* <code>::/128</code> bzw. in der ausgeschriebenen Variante <code>0:0:0:0:0:0:0:0/128</code>, ist die nicht spezifizierte Adresse. Sie darf keinem Host zugewiesen werden, sondern zeigt das Fehlen einer Adresse an. Sie wird beispielsweise von einem initialisierenden Host als Absenderadresse in IPv6-Paketen verwendet, solange er seine eigene Adresse noch nicht mitgeteilt bekommen hat.<ref>{{RFC-Internet |RFC=4291 |Titel= |Datum= |Abschnitt=2.5.2 |Abschnittstitel=}}</ref> Jedoch können auch Serverprogramme durch Angabe dieser Adresse bewirken, dass sie auf allen Adressen des Hosts lauschen. Dies entspricht <code>[[0.0.0.0]]/32</code> unter IPv4.
* <code>::/0</code> bzw. in der ausgeschriebenen Variante <code>0:0:0:0:0:0:0:0/0</code> bezeichnet die Standard-Route (default route), die verwendet wird, wenn in der Routingtabelle kein Eintrag gefunden wird. Dies entspricht <code>0.0.0.0/0</code> unter IPv4.
* <code>::1/128</code> bzw. in der ausgeschriebenen Variante <code>0:0:0:0:0:0:0:1/128</code>, ist die Adresse des eigenen Standortes ([[loopback]]-Adresse, die in der Regel mit [[localhost]] verknüpft ist). Unter IPv4 wird zu diesem Zweck fast ausschließlich <code>127.0.0.1/32</code> aus dem Adressraum <code>127.0.0.0–127.255.255.255</code> verwendet, wenngleich dort also nicht nur eine IP-Adresse, sondern ein ganzes /8-Subnetz für das Loopback-Netzwerk reserviert ist.

==== Link-Local-Unicast-Adressen ====
Link-Local-Adressen<ref>{{RFC-Internet |RFC=4291 |Titel= |Datum= |Abschnitt=2.5.6 |Abschnittstitel=}}</ref> sind nur innerhalb abgeschlossener Netzwerksegmente gültig. Ein Netzwerksegment ist ein lokales Netz, gebildet mit [[Switch (Netzwerktechnik)|Switches]] oder [[Hub (Netzwerktechnik)|Hubs]], bis zum ersten Router. Reserviert ist hierfür der Bereich „<code>fe80::/10</code>“.<ref>{{Internetquelle |werk=heise online |url=https://www.heise.de/IPv6-Adressen-3484199.html |titel=IPv6-Adressen |sprache=de-DE |abruf=2018-11-09}}</ref><ref>{{Internetquelle |url=https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml |titel=Internet Protocol Version 6 Address Space |abruf=2018-11-09}}</ref> Nach diesen 10 Bits folgen 54 Bits mit dem Wert 0, sodass die Link-Local-Adressen immer das Präfix „<code>fe80::/64</code>“ haben:

{| class="wikitable"
|-
! 10 Bits !! 54 Bits !! 64 Bits
|-
| 1111111010|| 0|| Interface ID
|}

Link-Local-Adressen nutzt man zur Adressierung von Knoten in abgeschlossenen Netzwerksegmenten sowie zur Autokonfiguration oder Neighbour-Discovery. Dadurch muss man in einem Netzwerksegment keinen DHCP-Server zur automatischen Adressvergabe konfigurieren. Link-Local-Adressen sind mit [[APIPA]]-Adressen im Netz <code>169.254.0.0/16</code> vergleichbar.

Soll ein Gerät mittels einer dieser Adressen kommunizieren, so muss die ''Zone ID'' mit angegeben werden, da eine Link-Lokale-Adresse auf einem Gerät mehrfach vorhanden sein kann. Bei einer einzigen Netzwerkschnittstelle würde eine Adresse etwa so aussehen: <code>fe80::7645:6de2:ff:1'''%1'''</code> bzw. <code>fe80::7645:6de2:ff:1'''%eth0'''</code>.

==== Site Local Unicast (veraltet) ====
<code>fec0::/10</code> (<code>fec0…</code> bis <code>feff…</code>), auch standortlokale Adressen (''site local addresses''), waren die Nachfolger der [[Private IP-Adresse|privaten IP-Adressen]] (beispielsweise <code>192.168.x.x</code>). Sie durften nur innerhalb derselben Organisation geroutet werden. Die Wahl des verwendeten Adressraums innerhalb von <code>fec0::/10</code> war für eine Organisation beliebig. Bei der Zusammenlegung von ehemals getrennten Organisationen oder wenn eine VPN-Verbindung zwischen eigentlich getrennten mit Site Local Addresses nummerierten Netzwerken hergestellt wurde, konnte es daher zu Überschneidungen der Adressräume an den unterschiedlichen Standorten kommen. Aus diesem und weiteren Gründen sind Site Local Addresses nach RFC 3879 seit September 2004 überholt (engl. ''deprecated'') und werden aus zukünftigen Standards verschwinden. Neue Implementierungen 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 ====
<code>fc00::/7</code> (<code>fc00…</code> bis <code>fdff…</code>). Für [[Private IP-Adresse|private Adressen]] gibt es die ''Unique Local Addresses'' (ULA), beschrieben in RFC 4193. Derzeit ist nur das Präfix <code>fd</code> für lokal generierte ULA vorgesehen. Das Präfix <code>fc</code> ist für global zugewiesene, eindeutige ULA reserviert. Auf das Präfix folgen dann 40&nbsp;Bits, die als eindeutige Site-ID fungieren. Diese Site-ID ist bei den ULA mit dem Präfix ''fd'' zufällig zu generieren<ref>Dazu siehe auch das Skript auf {{Webarchiv |url=http://www.kame.net/~suz/gen-ula.sh |wayback=20090601163048 |text=kame.net  }} (Online-Version: [https://www.sixxs.net/tools/grh/ula/ sixxs.net]).</ref> 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 <code>fd9e:21a7:a92c:2323::1</code>. Hierbei ist <code>fd</code> das Präfix für lokal generierte ULAs, <code>9e:21a7:a92c</code> ein einmalig zufällig erzeugter 40-Bit-Wert und <code>2323</code> 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.

Sofern in einem privaten Netz im Dualstack mit IPv4 nur ULA-Adressen verwendet werden, bevorzugt die Mehrheit der Clients bei einer DNS-Auflösung die IPv4-Adresse, auch wenn ein AAAA-Record existiert, da davon auszugehen ist, dass mit einer ULA-Adresse niemals der öffentliche IPv6-Adressraum erreicht werden kann. Dies führt in der Praxis dazu, dass in privaten Netzen (insbesondere beim Einsatz von NAT6) im Dualstack von ULA-Adressen abgeraten wird.<ref>[https://wiki.openwrt.org/doc/howto/ipv6.nat6#why_should_the_ula_prefix_be_changed IPv6 Masquerading Router – ''Why should the ULA prefix be changed?''] NAT6, openwrt.org</ref>

Es existiert ein [[Internet-Draft]], welcher Richtlinien für Registrare (IANA, RIR) beschreibt, konkret deren Betrieb sowie die Adressvergabe-Regeln. Allerdings ist eine derartige „ULA-Central“ noch nicht gegründet.<ref>{{cite web | url=https://tools.ietf.org/html/draft-ietf-ipv6-ula-central-02 | title= Centrally Assigned Unique Local IPv6 Unicast Addresses | publisher=tools.ietf.org | language=englisch | accessdate=2019-05-10}}</ref>

Sowohl der RFC 4193 als auch der Internet-Draft sind identisch in Bezug auf das Adressformat und den oben genannten Generierungs-Algorithmus.

==== Multicast ====
<code>ff00::/8</code> (<code>ff…</code>) stehen für Multicast-Adressen. Nach dem Multicast-Präfix folgen 4&nbsp;Bits für [[Flag (Informatik)|Flags]] und 4&nbsp;Bits für den Gültigkeitsbereich (Scope).

Für die Flags sind zurzeit folgende Kombinationen gültig:<ref name="multicast">{{RFC-Internet |RFC=2373 |Titel= |Datum= |Abschnitt=2.7 |Abschnittstitel=}}</ref>
* <code>0</code>: Permanent definierte ''wohlbekannte'' Multicast-Adressen (von der [[IANA]] zugewiesen)<ref>{{RFC-Internet |RFC=3307 |Titel= |Datum= |Abschnitt=4.1 |Abschnittstitel=}}</ref>
* <code>1</code>: (T-Bit gesetzt) Transient (vorübergehend) oder dynamisch zugewiesene Multicast-Adressen
* <code>3</code>: (P-Bit gesetzt, erzwingt das T-Bit) ''Unicast-Prefix-based'' Multicast-Adressen (RFC 3306)
* <code>7</code>: (R-Bit gesetzt, erzwingt P- und T-Bit) Multicast-Adressen, welche die Adresse des ''Rendezvous-Points'' enthalten (RFC 3956)

Die folgenden Gültigkeitsbereiche sind definiert:<ref name="multicast" />
* <code>1</code>: interfacelokal, diese Pakete verlassen die [[Schnittstelle]] nie. ([[Loopback]])
* <code>2</code>: link-lokal, werden von [[Router]]n grundsätzlich nie weitergeleitet und können deshalb das Subnetz nicht verlassen.
* <code>4</code>: adminlokal, der kleinste Bereich, dessen Abgrenzung in den Routern speziell administriert werden muss.
* <code>5</code>: sitelokal, dürfen zwar geroutet werden, jedoch nicht von [[Border-Router]]n.
* <code>8</code>: organisationslokal, die Pakete dürfen auch von Border-Routern weitergeleitet werden, bleiben jedoch „im Unternehmen“ (hierzu müssen seitens des [[Routing]]-Protokolls entsprechende Vorkehrungen getroffen werden).
* <code>e</code>: globaler Multicast, der überallhin geroutet werden darf.
* <code>0</code>, <code>3</code>, <code>f</code>: reservierte Bereiche
* die restlichen Bereiche sind nicht zugewiesen und dürfen von Administratoren benutzt werden, um weitere Multicast-Regionen zu definieren.<ref>{{RFC-Internet |RFC=4291 |Titel= |Datum= |Abschnitt=2.7 |Abschnittstitel=}}</ref>

Beispiele für ''wohlbekannte'' Multicast-Adressen:<ref>[https://www.iana.org/assignments/ipv6-multicast-addresses ''Internet Protocol Version 6 Multicast Addresses''.] IANA.</ref>
* <code>ff01::1</code>, <code>ff02::1</code>: ''All Nodes'' Adressen. Entspricht dem Broadcast.
* <code>ff01::2</code>, <code>ff02::2</code>, <code>ff05::2</code>: ''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:
* <code>::/96</code> (96 0-Bits) stand für IPv4-Kompatibilitätsadressen, welche in den letzten 32&nbsp;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 überholt (engl. ''deprecated'') erklärt.
* <code>0:0:0:0:0:ffff::/96</code> (80&nbsp;0-Bits, gefolgt von 16&nbsp;1-Bits) steht für ''IPv4 mapped (abgebildete)'' IPv6 Adressen. Die letzten 32&nbsp;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.
* <code>2000::/3</code> (<code>2000…</code> bis <code>3fff…</code>; was dem binären Präfix 001 entspricht) stehen für die von der [[Internet Assigned Numbers Authority|IANA]] vergebenen globalen Unicast-Adressen, also routbare und weltweit einzigartige Adressen.
:* <code>2001</code>-Adressen werden an Provider vergeben, die diese an ihre Kunden weiterverteilen.
::* Adressen aus <code>2001::/32</code> (also beginnend mit <code>2001:0:</code>) werden für den Tunnelmechanismus [[Teredo]] benutzt.
::* Adressen aus <code>2001:db8::/32</code> dienen Dokumentationszwecken, wie beispielsweise in diesem Artikel, und bezeichnen keine tatsächlichen Netzteilnehmer.
:* <code>2002</code>-Präfixe deuten auf Adressen des Tunnelmechanismus [[6to4]] hin.
:* Auch mit <code>2003</code>, <code>240</code>, <code>260</code>, <code>261</code>, <code>262</code>, <code>280</code>, <code>2a0</code>, <code>2b0</code> und <code>2c0</code> beginnende Adressen werden von [[Regional Internet Registry|Regional Internet Registries]] (RIRs) vergeben; diese Adressbereiche sind ihnen z.&nbsp;T. aber noch nicht zu dem Anteil zugeteilt, wie dies bei <code>2001::/16</code> der Fall ist.<ref>[https://www.iana.org/assignments/ipv6-unicast-address-assignments ''IPv6 Unicast Address Assignments''.] IANA.</ref>
:* <code>3ffe::/16</code>-Adressen wurden für das Testnetzwerk [[6Bone]] benutzt; dieser Adressbereich wurde gemäß RFC 3701 wieder an die IANA zurückgegeben.
* <code>64:ff9b::/96</code> kann für den Übersetzungsmechanismus [[NAT64]] gemäß RFC 6146 verwendet werden.

== Funktionalität ==
=== Autokonfiguration ===

Mittels ''Stateless Address Autoconfiguration'' (SLAAC, zustandslose Adressenautokonfiguration, spezifiziert in RFC 4862) kann ein Host vollautomatisch eine funktionsfähige Internetverbindung aufbauen. Dazu kommuniziert er mit den für sein [[Segment (Netzwerk)|Netzwerksegment]] zuständigen [[Router]]n, um die notwendige Konfiguration zu ermitteln.

==== Ablauf ====
Zur initialen Kommunikation mit dem Router weist sich der Host eine [[#Link-Local-Unicast-Adressen|link-lokale Adresse]] zu, die im Falle einer [[Ethernet]]-Schnittstelle etwa aus deren Hardware-Adresse berechnet werden kann. Damit kann ein Gerät sich mittels des [[Neighbor Discovery Protocol]]s (NDP, siehe auch [[#Erweiterte ICMP-Funktionalität|ICMPv6-Funktionalität]]) auf die Suche nach den Routern in seinem Netzwerksegment machen. Dies geschieht durch eine Anfrage an die [[#Multicast|Multicast]]-Adresse <code>ff02::2</code>, über die alle Router eines Segments erreichbar sind (''Router Solicitation'').

Ein Router versendet auf eine solche Anfrage hin Information zu verfügbaren [[#Adressaufbau von IPv6|Präfixen]], also Information über die Adressbereiche, aus denen ein Gerät sich selbst ''[[Unicast]]''-Adressen zuweisen darf. Die Pakete, die diese Informationen tragen, werden ''Router Advertisements'' genannt. Sie besitzen ICMPv6-Typ 134 (0x86) und besitzen Informationen über die Lifetime, die [[Maximum Transmission Unit|MTU]] und das Präfix des Netzwerks. An ein solches Präfix hängt der Host den auch für die link-lokale Adresse verwendeten Interface-Identifier an.

Um die doppelte Vergabe einer Adresse zu verhindern, ist der Mechanismus ''Duplicate Address Detection'' (DAD – Erkennung doppelt vergebener Adressen) vorgesehen.<ref>{{RFC-Internet |RFC=2462 |Titel= |Datum= |Abschnitt=5.4 |Abschnittstitel=}}</ref> Ein Gerät darf bei der Autokonfiguration nur unvergebene Adressen auswählen. Der DAD-Vorgang läuft ebenfalls ohne Benutzereingriff via NDP ab.

==== Gültigkeitsangaben ====
Router können bei der Vergabe von Adresspräfixen begrenzte Gültigkeitszeiten mitgeben: ''Valid Lifetime'' und ''Preferred Lifetime''.<ref>{{RFC-Internet |RFC=2461 |Titel= |Datum= |Abschnitt=4.6.2 |Abschnittstitel=}}</ref> Innerhalb der Valid Lifetime darf das angegebene Präfix zur Kommunikation verwendet werden; innerhalb der Preferred Lifetime soll dieses Präfix einem anderen, dessen Preferred Lifetime schon abgelaufen ist (dessen Valid Lifetime aber noch nicht), vorgezogen werden.<ref>{{RFC-Internet |RFC=2462 |Titel= |Datum= |Abschnitt=4 |Abschnittstitel=}}</ref> Router verschicken regelmäßig ''Router Advertisements'' an alle Hosts in einem Netzsegment, für das sie zuständig sind, mittels derer die Präfix-Gültigkeitszeiten aufgefrischt werden; durch Änderung der Advertisements können Hosts umnummeriert werden. Sind die Router Advertisements nicht über IPsec authentifiziert, ist die Herabsetzung der Gültigkeitszeit eines einem Host bereits bekannten Präfixes auf unter zwei Stunden jedoch nicht möglich.<ref>{{RFC-Internet |RFC=4862 |Titel= |Datum= |Abschnitt=5.5.3 |Abschnittstitel= |Kommentar=Punkt e&#41;}}</ref>

==== Verhältnis von Autokonfiguration zu DHCPv6 ====
Die IPv6-Autokonfiguration unterscheidet sich konzeptionell von [[Dynamic Host Configuration Protocol|DHCP]] beziehungsweise [[DHCPv6]]. Während bei der Adressvergabe durch DHCPv6 (definiert in RFC 3315) von „''Stateful'' Address Configuration“ gesprochen wird (sinngemäß: protokollierte Adressvergabe, etwa durch einen DHCP-Server), ist die Autokonfiguration eine „''Stateless'' Address (Auto)Configuration“, da Geräte sich selbst eine Adresse zuweisen und diese Vergabe nicht protokolliert wird.

Mittels der Autokonfiguration können an Clients keine Informationen zu Host-, Domainnamen, DNS, [[Network Time Protocol|NTP]]-Server etc. mitgeteilt werden, sofern diese nicht spezifische Erweiterungen von NDP unterstützen. Als Alternative hat sich der zusätzliche Einsatz eines DHCPv6-Servers etabliert; 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). Dem Client kann mittels des ''Managed''-Flags in der Antwort auf eine NDP-Router-Solicitation angezeigt werden, dass er eine DHCPv6-Anfrage stellen und somit die Zusatzinformationen beziehen soll.

=== 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 [[Internetdienstanbieter|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 ''[[Multihoming|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 [[Routingtabelle]]n 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 einfacher als unter IPv4, wie im Abschnitt [[#Adressaufbau von IPv6|Adressaufbau]] oben beschrieben. In RFC 3484 wird festgelegt, wie die Auswahl der Quell- und Zieladressen bei der Kommunikation geschehen soll und wie sie beeinflusst werden kann, wenn nun jeweils mehrere zur Verfügung stehen. Darüber hinaus darf diese Auswahl auch auf Anwendungsebene oder durch noch zu schaffende, z.&nbsp;B. die Verbindungsqualität einbeziehende Mechanismen getroffen werden. 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 6275) in IPv6 integriert. Die Kommunikation erfolgt dabei virtuell immer unabhängig von der aktuellen Position der Knotenpunkte.<ref>Herbert Wiese: ''Das neue Internetprotokoll IPv6''. [[Hanser Verlag]], München 2002. ISBN 3-446-21685-5, S. 197.</ref> Somit erlaubt Mobile IP Endgeräten, überall unter der gleichen IP-Adresse 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]]“), der das Mobilgerät in seinem Heimnetz vertritt. Eingehende Pakete werden durch diesen Schattenrechner an die momentane Adresse („Care-of-Address“) des Mobilgeräts getunnelt. Der Home Agent bekommt die aktuelle Care-of-Address des Mobilgerätes durch „Binding Updates“ mitgeteilt, die das Gerät an den Home Agent sendet, sobald es eine neue Adresse im besuchten Fremdnetz erhalten hat. Mobile IP ist auch für IPv4 spezifiziert; im Gegensatz zu dieser Spezifikation benötigt Mobile IPv6 jedoch keinen ''[[Foreign Agent]]'', der im Fremdnetz die Anwesenheit von Mobilgeräten registriert.

=== Header-Format ===
[[Datei:IPv6 Header.svg|mini|250x250px|Der Kopfdatenbereich eines IPv6-Paketes]]
Im Gegensatz zu IPv4 hat der IP-Kopfdatenbereich ([[Header]]) bei IPv6 eine feste Länge von 40&nbsp;Bytes (320&nbsp;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:

{| class="wikitable"
|-
! Feld
! Länge
! Inhalt
|-
|''Version''
|align="right"|4&nbsp;Bit || IP-Versionsnummer (6)
|-
|''Traffic&nbsp;Class''
|align="right"|8&nbsp;Bit || [[Quality of Service]]: Die Bits 0–5 werden für [[DiffServ|DSCP]] verwendet, die Bits 6–7 für [[Explicit Congestion Notification|ECN]]. Laut [https://www.iana.org/assignments/ipv4-tos-byte/ipv4-tos-byte.xhtml IANA] gilt die gleiche Zuteilung wie für [[IP-Paket#TOS (Type of Service)|IPv4 ToS]].
|-
|''Flow&nbsp;Label''
|align="right"|20&nbsp;Bit || Ebenfalls für ''QoS'' oder [[Echtzeit]]anwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt.
|-
|''Payload&nbsp;Length''
|align="right"|16&nbsp;Bit || Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte
|-
|''Next&nbsp;Header''
|align="right"|8&nbsp;Bit || Identifiziert den [[Protokoll (IP)|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.&nbsp;B. TCP (Typ 6) oder UDP (Typ 17).
|-
|''Hop&nbsp;Limit''
|align="right"|8&nbsp;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&nbsp;Address''
|align="right"|128&nbsp;Bit || Adresse des Senders
|-
|''Destination&nbsp;Address''
|align="right"|128&nbsp;Bit || Adresse des Empfängers
|}

Wie im ''Next Header'' Feld verwiesen, sind einige ''Extension Headers'' und ein Platzhalter definiert:

{| class="wikitable"
|-
! Name
! [[Protokoll (IP)|Typ]]
! Größe
! Beschreibung
! RFCs
|-
|''Hop-By-Hop Options''
| 0 || variabel || Enthält Optionen, die von allen IPv6-Geräten, die das Paket durchläuft, beachtet werden müssen. Wird z.&nbsp;B. für [[#Paketgrößen|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|Mobile IPv6]] verwendet. || RFC 2460, RFC 6275, RFC 5095
|-
|''Fragment''
| 44 || 64&nbsp;Bit || In diesem Header können die Parameter einer [[IP-Fragmentierung|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
|-
|''Mobility''
| 135 || variabel || Enthält Daten für ''Mobile IPv6''. || RFC 6275
|-
|''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'' im Paket, so darf davor ein weiterer ''Destination Options Header'' stehen.
Die Reihenfolge bei einer Verkettung ist bis auf die genannte Ausnahme die der Tabelle. Alle ''Extension Headers'' enthalten ein ''Next-Header''-Feld, in dem der nächste ''Extension Header'' oder das ''Upper Layer Protocol'' genannt wird.

Die Größen dieser Header sind immer Vielfache von 64&nbsp;Bit, auch sind die meisten Felder der Kopfdatenbereiche auf 64-Bit-Grenzen ausgerichtet, um [[Speicherzugriff]]e im Router zu beschleunigen. Außerdem 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&nbsp;Byte nicht unterschreiten. Somit unterschreitet auch die [[Maximum Transmission Unit|Path MTU]] (PMTU) diesen Wert nicht und es können Pakete bis zu dieser Größe garantiert ohne [[IP-Fragmentierung|Fragmentierung]] übertragen werden. Minimale IPv6-Implementierungen verlassen sich auf diesen Fall.

Ein IPv6-fähiger Rechner muss in der Lage sein, aus Fragmenten wieder zusammengesetzte Pakete mit einer Größe von mindestens 1500&nbsp;Byte zu empfangen. Für IPv4 beträgt dieser Wert nur 576&nbsp;Byte. Im anderen Extrem darf ein IPv6-Paket auch fragmentiert laut ''Payload-Length''-Feld im IPv6-Header die Größe von 65.575&nbsp;Byte einschließlich Kopfdaten nicht überschreiten, da dieses Feld 16&nbsp;Bit lang ist (2<sup>16</sup>&nbsp;−&nbsp;1 Bytes zzgl. 40&nbsp;Bytes Kopfdaten). 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&nbsp;Byte, sogenannte ''Jumbograms'' zu erzeugen. Dies erfordert allerdings Anpassungen in Protokollen höherer Schichten, wie z.&nbsp;B. [[Transmission Control Protocol|TCP]] oder [[User Datagram Protocol|UDP]], da diese oft auch nur 16&nbsp;Bit für Größenfelder definieren, außerdem muss bei jedem Paket, welches einen Jumbogram beinhaltet, im IPv6-Header die Payload-Length auf ''0'' gesetzt werden.

=== Erweiterte ICMP-Funktionalität ===
[[ICMPv6]] ([[Protokoll (IP)|Protokolltyp 58]]) stellt für das Funktionieren von IPv6 unverzichtbare Funktionen zur Verfügung. Das Verbieten aller ICMPv6-Pakete in einem IPv6-Netzwerk durch [[#Paketfilter und Firewalls|Filter]] ist daher im Normalfall nicht durchführbar.

Insbesondere wird das [[Address Resolution Protocol]] (ARP) durch das [[Neighbor Discovery Protocol]] (NDP) ersetzt, welches auf ICMPv6 basiert. Dieses macht hierbei intensiv Gebrauch von ''[[#Link-Local-Unicast-Adressen|Link-Local-Unicast-Adressen]]'' und [[Multicast]], das von jedem Host beherrscht werden muss. Im Rahmen des NDPs 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 [[User Datagram Protocol|UDP]]-Pakete benutzt.

Die [[IP-Fragmentierung|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 Transmission 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 IPv4-Adressen, ist IPv6 in besonderem Maße von einem funktionierenden [[Domain Name System]] (DNS) abhängig. RFC 3596 definiert den [[Resource Record]] (RR) Typ [[AAAA Resource Record|AAAA]] (sprich: ''Quad-A''), der genau wie ein [[A Resource Record]] für IPv4 einen Namen in eine IPv6-Adresse auflöst. Der [[Reverse DNS|Reverse Lookup]], also die Auflösung einer IP-Adresse in einen Namen, funktioniert nach wie vor über den RR-Typ [[PTR Resource Record|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 [[Subdomain]]s darin geschieht nicht mehr an 8-Bit-, sondern an 4-Bit-Grenzen.

Ein IPv6-fähiger Rechner sucht in der Regel mittels DNS zu einem Namen zunächst nach dem RR-Typ AAAA, dann nach dem RR-Typ A. Laut der ''Default Policy Table'' in RFC 3484 wird die Kommunikation über IPv6 gegenüber IPv4 bevorzugt, falls festgestellt wird, dass für eine Verbindung beide Protokolle zur Verfügung stehen. Die Anwendungsreihenfolge der Protokolle ist meistens aber auch im [[Betriebssystem]] und auf der Anwendungsebene, also z.&nbsp;B. im [[Webbrowser|Browser]], einstellbar.

Alle dreizehn [[Root-Nameserver]] und mindestens zwei Nameserver der meisten [[Top-Level-Domain]]s sind über IPv6 erreichbar. Das übertragende Protokoll ist unabhängig von den übertragenen Informationen. Insbesondere kann man über IPv4 einen Nameserver nach AAAA-RRs fragen. Anbieter großer Portalseiten denken jedoch darüber nach, nur DNS-Anfragen, die über IPv6 gestellt werden, auch mit AAAA Resource Records zu beantworten, um Probleme mit fehlerhaft programmierter Software zu vermeiden.<ref>[https://www.heise.de/netze/meldung/Weiterer-Hack-fuer-IPv6-Erreichbarkeit-grosser-Content-Anbieter-Update-964947.html ''„Hack“ für IPv6-Erreichbarkeit großer Content-Anbieter''.] heise.de</ref>

== Übergangsmechanismen ==
{{IPv6-Übergangsmechanismen}}
IPv4 und IPv6 lassen sich auf derselben Infrastruktur, insbesondere im [[Internet]], parallel betreiben. Für den Übergang werden also in der Regel keine neuen Leitungen, Netzwerkkarten oder Geräte benötigt, sofern dafür geeignete [[#Betriebssysteme|Betriebssysteme]] zur Verfügung stehen. Es gibt zurzeit kaum Geräte, welche IPv6, aber nicht gleichzeitig auch IPv4 beherrschen. Damit jedoch Geräte, die ausschließlich über IPv4 angebunden sind, auch mit Geräten kommunizieren können, die ausschließlich über IPv6 angebunden sind, benötigen sie [[#Übersetzungsverfahren|Übersetzungsverfahren]].

Um einen einfachen Übergang von IPv4- zu IPv6-Kommunikation im Internet zu ermöglichen, wurden verschiedene Mechanismen entwickelt. IPv6 wird dabei in der Regel hinzugeschaltet, ohne IPv4 abzuschalten. Grundlegend werden folgende drei Mechanismen unterschieden:
* Parallelbetrieb (''Dual-Stack'')
* Tunnelmechanismen
* Übersetzungsverfahren
Parallelbetrieb und Tunnelmechanismen setzten voraus, dass die Betriebssysteme der angebundenen Rechner beide Protokolle beherrschen.

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

=== Dual-Stack ===
Bei diesem Verfahren werden allen beteiligten [[Schnittstelle]]n 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, d.&nbsp;h. sowohl mit IPv4- als auch mit IPv6-fähigen Systemen Daten austauschen. Dieses Verfahren sollte der Regelfall sein, es scheitert derzeit oft daran, dass einige Router (meistens die [[Breitband-Zugangsserver|Zugangsserver]] des Internetproviders oder die Heimrouter bei den Kunden) auf dem Weg zum IPv6-Internet noch keine IPv6-[[Routing|Weiterleitung]] eingeschaltet haben oder unterstützen.

=== Dual-Stack Lite (DS-Lite) ===
[[Datei:DSLite.svg|mini|DS-Lite]]
Aufgrund der knappen IPv4-Adressen hat die [[IETF]] den Mechanismus „Dual-Stack Lite“ (RFC 6333) entwickelt. Hierbei werden dem Kunden nur via IPv6 global routbare IP-Adressen bereitgestellt. (Im regulären Dual-Stack-Betrieb werden sowohl IPv6 als auch IPv4 zur Verfügung gestellt.)

Im LAN des Kunden werden [[Private IP-Adresse|private IPv4-Adressen]] benutzt (analog zum Vorgehen bei [[Network Address Translation|NAT]]). Statt einer NAT-Übersetzung werden die IPv4-Pakete dann durch das [[Customer Premises Equipment]] (CPE) in IPv6-Pakete [[Datenkapselung (Netzwerktechnik)|gekapselt]]. Das CPE benutzt seine globale IPv6-Verbindung, um die Pakete in das [[Carrier-grade NAT]] (CGN) des [[Internetdienstanbieter|Internet Service Providers]] zu transportieren, welches über globale IPv4-Adressen verfügt. Hier wird das IPv6-Paket entpackt und das originale IPv4-Paket wiederhergestellt. Danach wird das IPv4-Paket mit NAT auf eine öffentliche IP-Adresse umgesetzt und ins öffentliche IPv4-Internet geroutet. Das Carrier-grade NAT identifiziert Sitzungen eindeutig mittels Aufzeichnungen über die öffentliche IPv6-Adresse des CPEs, die private IPv4-Adresse und TCP- oder UDP-Portnummern.

Diese DS-Lite-Umsetzung führt allerdings beim Endkunden zu Problemen: Zum einen sind bei portbasierten Protokollen (z.&nbsp;B. TCP, UDP) keine IPv4-basierenden Portfreigaben mehr möglich, da die Pakete an die öffentliche IP-Adresse bereits beim Provider ausgefiltert werden. Dienste, die an einem DS-Lite-Anschluss angeboten werden, können also von Geräten, die keine IPv6-Verbindungen aufbauen können, nicht erreicht werden. Auch werden vom CGN-Gateway nur bestimmte [[Protokoll (IP)|Protokolle]] verstanden und weitergeleitet, was die Nutzung anderer IP-basierter Protokolle erschwert oder völlig unmöglich macht.

=== Tunnelmechanismen ===
[[Datei:6in4 wireshark.png|mini|Protokoll 41: IPv6-Pakete werden direkt in IPv4-Pakete gepackt, die dann zu einem speziellen Tunnelserver geschickt werden]]

Um Router, die IPv6 nicht weiterleiten, auf dem Weg zum IPv6-Internet zu überbrücken, gibt es eine Vielzahl von [[Tunnel (Rechnernetz)|Tunnelmechanismen]]. Dabei werden IPv6-Pakete in den Nutzdaten anderer Protokolle, meist IPv4, zu einer Tunnelgegenstelle übertragen, die sich im IPv6-Internet befindet. Dort werden die IPv6-Pakete 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: der Weg der Pakete zum Ziel ist wegen des Umwegs über die Tunnelgegenstelle meistens nicht optimal und die mögliche Nutzlast sinkt, da mehr Kopfdaten übertragen werden müssen.

Der klassische Weg ist es, bei einem so genannten [[Tunnelbroker]] eine solche Gegenstelle für den privaten Gebrauch gebührenfrei zu beantragen. Diese Gegenstelle bleibt fest, und man bekommt über den Tunnel immer den gleichen IPv6-Adressbereich zugewiesen. [[6in4]] benutzt zum Beispiel den [[Protokoll (IP)|Protokolltyp 41]], um IPv6 direkt in IPv4 zu kapseln. Für [[Linux]] ist die Erstellung eines solchen Tunnels mit den [[Schnittstelle|Interface]]-Konfigurationswerkzeugen möglich.<ref>Peter Bieringer: [https://mirrors.deepspace6.net/Linux+IPv6-HOWTO-de/conf-ipv6-in-ipv4-point-to-point-tunnels.html Linux IPv6 Howto, Kapitel 9.3].</ref> Bei Windows ist dies seit Windows 10 April 2018 (1803) nicht mehr möglich. Komplizierter sind die Verfahren [[6over4]] oder [[ISATAP]].

Der Mechanismus [[6to4]] benötigt keine Absprache mit einer Gegenstelle, denn diese benutzt im Internet definierte ([[Anycast]])-IPv4-Adressen, und die getunnelten Pakete werden zur nächstgelegenen Gegenstelle 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.<ref>Peter Bieringer: [https://mirrors.deepspace6.net/Linux+IPv6-HOWTO-de/configuring-ipv6to4-tunnels.html Linux IPv6 Howto, Abschnitt 9.4].</ref>

Befindet sich ein Rechner in einem privaten IPv4-Adressbereich und findet beim Verbinden mit dem Internet [[Network Address Translation|NAT]] statt, so können Mechanismen wie [[AYIYA]] oder [[Teredo]] helfen. Diese Protokolle kapseln IPv6-Pakete als Nutzdaten meist in [[User Datagram Protocol|UDP]]-Paketen. Erlaubt ein Administrator diese Protokolle, kann schnell die Netzwerksicherheit in Gefahr geraten, wenn der Paketfilter die Nutzdaten nicht als IPv6-Pakete interpretieren kann und somit eventuell andere Paketfilterregeln umgangen werden.

Es ist auch möglich, IPv6 über allgemeinere Tunnelverfahren wie [[Generic Routing Encapsulation|GRE]], [[Layer 2 Tunneling Protocol|L2TP]] oder [[Multiprotocol Label Switching|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; inzwischen missbilligt<ref>{{RFC-Internet |RFC=4966 |Titel=Reasons to Move the Network Address Translator – Protocol Translator (NAT-PT) to Historic Status |Datum=}}</ref>), oder ''Transport Relay Translation'' (TRT, RFC 3142) nötig werden, um zwischen beiden Protokollen zu übersetzen. Auch bieten [[Proxy (Rechnernetz)|Proxy-Server]] für einige Protokolle höherer Schichten die Möglichkeit einer Kommunikation zwischen beiden Welten.<ref>[https://www.heise.de/netze/artikel/IPv6-Testbetrieb-fuer-heise-online-2-Update-221527.html IPv6-Testbetrieb für heise online – Web-Site per Proxy IPv6-fähig machen].</ref>

Das Verfahren [[NAT64]] bietet eine recht befriedigende Lösung, solange die Hauptanforderung darin besteht, von IPv6-Hosts initiierte Verbindungen an IPv4-Hosts weiterzuleiten.

== Technische Umsetzung ==
Die RFC 6434 (IPv6 Node Requirements) gibt einen Überblick über Funktionen, die alle IPv6-Geräte umsetzen sollten, um eine maximale Interoperabilität zu gewährleisten. In diesem Dokument wird auf die jeweiligen Spezifikationen verwiesen.

=== Betriebssysteme ===
Viele [[Betriebssystem]]e 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-)[[Router]]n bei Endkunden und den [[Breitband-Zugangsserver|Zugangsservern]] bei den Providern. Systeme (z.&nbsp;B. [[Content Delivery Network|CDN]]) zur [[Serverlastverteilung|Lastverteilung]], wie sie z.&nbsp;B. für große Webseiten eingesetzt werden, wurden und werden stückweise um IPv6 ergänzt.<ref>[https://www.akamai.com/us/en/multimedia/documents/product-brief/ipv6-adaptation-product-brief.pdf AKAMAI] (PDF) </ref><ref>[https://aws.amazon.com/de/about-aws/whats-new/2016/10/ipv6-support-for-cloudfront-waf-and-s3-transfer-acceleration AWS].</ref><ref>[https://azure.microsoft.com/de-de/documentation/articles/load-balancer-ipv6-overview/ azure].</ref><ref>[https://www.cloudflare.com/ipv6/ Cloudflare].</ref>

; [[AIX]]: Seit AIX&nbsp;4 Version&nbsp;4.3 ist IPv6 implementiert, seit AIX&nbsp;5L Version&nbsp;5.2 ist auch Mobile IPv6 implementiert.
; [[Android (Betriebssystem)|Android]]: Android unterstützt IPv6 seit Version 2.1, jedoch nicht über die [[3GPP]]-Schnittstelle.<ref>[https://code.google.com/p/android/issues/detail?id=3389 Android Issue 3389: Full IPv6 Android support].</ref> Seit 2.3.4 werden IPv6 APN unterstützt. Es fehlte allerdings bei den meisten Endgeräten die Unterstützung im UMTS Chipset (bzw. der Firmware). Ab Version 4.0 Ice Cream Sandwich sind Privacy Extensions standardmäßig aktiviert.<ref>{{Internetquelle |autor=Susanne Kirchhoff |url=http://www.teltarif.de/internet/ipv6/datenschutz.html |titel=Datenschutz und IPv6: So anonym surfen Sie wirklich |datum=2014-06-03 |abruf=2015-03-29}}</ref>
; [[Berkeley Software Distribution|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). Die Unterstützung ist zu großen Teilen dem [[KAME-Projekt]] zu verdanken, das seit 1998 einen freien [[Protokollstapel]] für IPv6 und [[IPsec]] für BSD-Betriebssysteme entwickelt hatte.
; [[Cisco]]: IPv6 wird ab [[Internetwork Operating System|IOS]] Version 12.2T experimentell, ab den 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. <!--Status auf ASA und PIX? Cisco ist kein OS-->
; [[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.
; [[Apple iOS|iOS (Apple iPhone, iPad, iPod Touch, Apple TV)]]: Apple-Geräte mit iOS ab Version 4 unterstützen IPv6 im Dual-Stack-Modus.<ref>Iljitsch van Beijnum: {{Webarchiv |url=http://lists.apple.com/archives/ipv6-dev/2010/Jun/msg00036.html |wayback=20120514102150 |text=iOS 4 IPv6  }}.</ref> Privacy Extensions werden jedoch erst ab Version 4.3 unterstützt.<ref>[https://www.heise.de/newsticker/meldung/iOS-4-3-Apple-bessert-beim-Datenschutz-nach-1206770.html ''iOS 4.3: Apple bessert beim Datenschutz nach''.] heise Netze.</ref><ref name="smartphone-privacy-ext">[https://www.heise.de/netze/artikel/IPv6-Privacy-Extensions-einschalten-1204783.html?artikelseite=4 ''IPv6: Privacy Extensions einschalten''.] heise Netze.</ref>
; [[Juniper Networks|Juniper]]: Der Hersteller unterstützt IPv6 auf seinen Routern im Betriebssystem [[JunOS]] ab Version 5.1. Das IPv6-Forwarding geschah hier schon früh in Hardware, also ohne die Routing Engine (den Hauptprozessor) zu belasten. Für Firewall-Systeme, sowohl auf der ScreenOS Serie(ScreenOS <6.x), als auch auf der SRX Serie(JunOS <10.x) ist IPv6 unterstützt. <!--ScreenOS kann es glaube ich, es gibt noch viel mehr Produkte, Juniper ist kein OS-->
; [[Linux]]: Der [[Linux (Kernel)|Kernel]] bietet seit Version 2.6 eine produktiv einsetzbare IPv6-Unterstützung auf ähnlichem Niveau wie die BSD-Derivate. Der Kernel&nbsp;2.4 bietet eine als experimentell ausgewiesene Unterstützung für IPv6, der jedoch noch wichtige Eigenschaften wie IPSec und Datenschutzerweiterungen (Privacy Extensions, RFC 4941) fehlen. Die meisten Linux-Distributionen haben im Auslieferungszustand mit Kerneln ab Version 3.x die Privacy Extensions eingeschaltet, diese können jedoch manuell deaktiviert werden. Eine experimentelle IPv6-Implementation ist auch in der Kernel-Version&nbsp;2.2 enthalten.
; [[Mac OS X]]: Seit Version&nbsp;10.2 enthält auch Mac OS X Unterstützung für IPv6 auf der Basis von [[KAME-Projekt|KAME]]. Erst seit Version&nbsp;10.3 lässt sich IPv6 auch über die [[Grafische Benutzeroberfläche|GUI]] konfigurieren. IPv6 ist standardmäßig aktiviert und unterstützt DNS-AAAA-Records. Die zur Apple-Produktfamilie gehörenden [[AirPort|Airport-Extreme]]-Consumer-Router richten standardmäßig einen [[6to4]]-Tunnel ein und fungieren als IPv6-Router. Die Privacy Extensions sind seit [[Mac OS X Lion|10.7 (Lion)]] per Default aktiviert.
; [[Virtual Memory System|OpenVMS]]: Mit HP TCP/IP Services for OpenVMS Version&nbsp;5.5 unterstützt HP&nbsp;OpenVMS (ab Version&nbsp;8.2) IPv6.
; [[Solaris (Betriebssystem)|Solaris]]: Seit der Version&nbsp;8 ist die Unterstützung von IPv6 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&nbsp;7.0 ist IPv6 fester Bestandteil des Systems. Es sind nur wenige Parameter über die [[Grafische Benutzeroberfläche|GUI]] zu konfigurieren.
; [[Microsoft Windows|Windows]]: Seit Windows XP Service Pack 1 bringt Windows einen Protokollstapel für IPv6 mit. Die Unterstützung für IPv6 ist seither durch Microsoft stetig ausgebaut und aktuellen Entwicklungen angepasst worden. Seit Windows 8 wird IPv6 als bevorzugtes Protokoll verwendet, falls der Host an ein Dual-Stack-Netzwerk angeschlossen ist.<ref>{{Internetquelle |url=http://blogs.msdn.com/b/b8/archive/2012/06/05/connecting-with-ipv6-in-windows-8.aspx |titel=Connecting with IPv6 in Windows 8 |hrsg=MSDN Blog |sprache=en |abruf=2012-08-12}}</ref>
; [[Microsoft Windows Server|Windows Server]]: Seit Windows Server 2003 enthält Windows Server einen „Production-Quality“-Protokollstapel. Die Unterstützung für IPv6 ist in den seither erschienenen Versionen von Windows Server kontinuierlich von Microsoft ausgebaut worden.
; [[Microsoft Windows Phone|Windows Phone]]: Windows Phone 7 und 7.5 unterstützen IPv6 nicht. Erst ab Version 8 ist ein IPv6-Stack integriert.<ref>{{Internetquelle |url=http://technet.microsoft.com/en-us/network/hh994905.aspx |titel=IPv6 Support in Microsoft Products and Services |hrsg=MS TechNet |sprache=en |abruf=2013-09-11 |archiv-url=https://web.archive.org/web/20160422223236/https://technet.microsoft.com/en-us/network/hh994905.aspx |archiv-datum=2016-04-22   }}</ref>
; [[z/OS]]: IBM z/OS unterstützt IPv6 seit September 2002 vollständig, schon 1998 gab es für den Vorgänger OS/390 einen experimentellen Stack.

=== Routing ===
Während statisches Routing für IPv6 analog zu IPv4 eingerichtet werden kann, ergeben sich für die dynamischen [[Routing#Routing-Protokolle|Routingprotokolle]] einige Änderungen. Zwischen [[Autonomes System|Autonomen Systemen]] wird das ''[[Border Gateway Protocol]]'' mit den ''Multiprotocol Extensions'' (definiert in RFC 4760) eingesetzt. Als ''[[Interior Gateway Protocol]]'' stehen [[Open Shortest Path First|OSPF]] in der Version 3, [[IS-IS]] mit Unterstützung von IPv6-[[Type-Length-Value|TLVs]] und [[Routing Information Protocol#RIPng|RIPng]] als offene Standards zur Verfügung. Die meisten Hersteller unterstützen für IS-IS ''Multi-Topology Routing'', also gleichzeitiges Routing für beide Adressfamilien auch dann, wenn IPv4- und IPv6-Netz sich nicht genau überdecken. OSPFv3 realisiert dieses in einem sehr neuen Standard (RFC 5838) über verschiedene Instanzen für die verschiedenen Protokolle, war ursprünglich aber nur für IPv6 vorgesehen. Ein anderer Weg ist es unterschiedliche Routingprotokolle für die beiden [[Topologie (Rechnernetz)|Topologien]] zu verwenden, also etwa OSPFv2 für IPv4 und IS-IS für IPv6.

An Endsysteme können eine oder mehrere Default-Routen per [[#Autokonfiguration|Autokonfiguration]] oder DHCPv6 übergeben werden. Mit DHCPv6-PD (''Prefix Delegation'') können auch Präfixe zwecks weiteren Routings zum Beispiel an Kundenrouter verteilt werden.

Da weder [[Resource Reservation Protocol|RSVP]] noch [[Label Distribution Protocol|LDP]] für IPv6 ausreichend standardisiert sind,<ref>Vishwas Manral: [https://tools.ietf.org/html/draft-manral-mpls-rsvpte-ipv6-01 RSVP-TE IPv6].</ref><ref>Vishwas Manral: [https://tools.ietf.org/html/draft-manral-mpls-ldp-ipv6-04 Updates to LDP for IPv6].</ref> müssen sich [[Multiprotocol Label Switching|MPLS]]-Netze weiter auf die Signalisierung mittels IPv4 verlassen, können jedoch, abhängig von der Implementierung, IPv6-Verkehr transportieren. Für IPv6 Multicast-Routing ist [[Protocol Independent Multicast|PIM]] geeignet.

=== Paketfilter und Firewalls ===
Für IPv6 müssen alle Filterregeln in [[Firewall]]s und [[Paketfilter]]n neu erstellt werden. Je nachdem, ob der filternde Prozess den IPv6-Datenverkehr überhaupt verarbeitet und abhängig von ihrer Default-Policy kann eine Firewall IPv6 ungehindert durchlassen. Auch einige [[Antivirenprogramm]]e haben Zusätze, welche den Verkehr z.&nbsp;B. auf bestimmten [[Transmission Control Protocol|TCP]]-Ports nach Signaturen durchsuchen. Für Linux kann die Filterung von IPv6 mit dem Programm ''[[ip6tables]]'' (seit Version 3.13 des Linux-Kernels auch ''nft''/''nftables'') konfiguriert werden.

Deutliche Veränderungen in der Struktur der Filter gegenüber IPv4 können sich ergeben, sofern sie [[Internet Control Message Protocol|ICMP]] bzw. [[ICMPv6]] behandeln, da sich dessen [[Protokoll (IP)|Protokollnummer]], ''Type-'' und ''Code''-Zuordnungen sowie die [[#Erweiterte ICMP-Funktionalität|Funktionalität]] verändern.<ref>{{RFC-Internet |Autor= |RFC=4890 |Titel= |Datum=}}</ref>

Das Feld ''Next Header'' im IPv6-Header eignet sich nicht in gleicher Weise wie das ''Protocol''-Feld im IPv4-Header zum Identifizieren von Protokollen höherer Schicht, denn im Falle der Verwendung von ''Extension Headers'' verändert sich dessen Wert, beispielsweise bei Fragmentierung.

Einige Aspekte von NAT wurden in der Vergangenheit oft als Sicherheitsfunktion verstanden; NAT ist in IPv6 jedoch höchstens in Ausnahmefällen vorgesehen. RFC 4864 beschreibt Vorgehensweisen, welche diese Aspekte von NAT mit IPv6-Techniken abbilden;<ref>{{Webarchiv |url=http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/white_paper_c11-474201.html |wayback=20090608180824 |text=''IPv6 Local Network Protection with Cisco IOS Routers and Switches''.}} Cisco Systems.</ref> so kann etwa die bei einigen Implementierungen bestehende Funktion von NAT, neu eingehende Verbindungen nicht an Rechner des Heimnetzes weiterzuleiten, durch einen [[Zustandsbehaftung|zustandsbehafteten]] Paketfilter im Router ersetzt werden. Dieser kann nach Wunsch neu eingehende Verbindungen generell abweisen oder diese nur für bestimmte Bereiche des Heimnetzes zulassen.

=== Anwendungssoftware ===
Für Anwendungen wie Webbrowser oder E-Mail-Programme 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.<ref>[https://www.heise.de/mac-and-i/meldung/Apple-erzwingt-IPv6-Kompatibilitaet-bei-iOS-Apps-3197620.html Apple erzwingt IPv6-Kompatibilität bei iOS-Apps].</ref><ref>[https://developer.apple.com/news/?id=05042016a Supporting IPv6-only Networks].</ref>

In den meisten Fällen sind nur kleinere Änderungen notwendig, da die Anwendungen auf Protokolle höherer Schicht aufsetzen und diese sich kaum ändern. In vielen Betriebssystemen forderten die Programmierschnittstellen jedoch von der Anwendung, [[Socket (Software)|Sockets]] explizit zur IPv4-Kommunikation anzufordern. Neuere Schnittstellen sind in der Regel so gestaltet, dass IPv6-unterstützende Anwendungen automatisch auch IPv4 unterstützen. Verarbeiten die Anwendungen Inhalte mit [[Uniform Resource Locator|URLs]], wie sie in [[Hypertext Transfer Protocol|HTTP]] oder im [[Session Initiation Protocol]] (SIP) vorkommen, so müssen sie die [[#URL-Notation von IPv6-Adressen|URL-Notation von IPv6-Adressen]] unterstützen.

Zum Teil sind Änderungen notwendig, um die Leistung der Anwendung nicht zu mindern: So muss z.&nbsp;B. eine eventuell ermittelte, verminderte [[Maximum Transmission Unit|Path MTU]] an die Anwendung übergeben werden, um Fragmentierung zu vermeiden oder die [[Maximum Segment Size]] (MSS) im [[Transmission Control Protocol|TCP]]-Header muss bei IPv6 gegenüber IPv4 verringert werden. Viele Programmiersprachen stellen spezielle [[Programmbibliothek|Bibliotheken]] zur Verfügung, um den Umgang mit dem neuen Protokoll zu vereinfachen.

=== Administration ===
Die Hauptarbeit der Umsetzung liegt auf der Verwaltungsebene: Administration und Support müssen geschult, Dokumentationen und Konfigurationen, z.&nbsp;B. für [[Routing]], [[Firewall]]s, [[Netzmanagement|Netzwerküberwachung]], das [[Domain Name System]] und evtl. [[Dynamic Host Configuration Protocol|DHCP]], müssen während der Übergangsphase für beide Protokolle erstellt und gepflegt werden. In vielen Dokumentationen oder Fehlermeldungen muss im Nachhinein zwischen IPv4 und IPv6 unterschieden werden, wo noch vor einigen Jahren nur von IP die Rede war. Die Struktur des IP-Netzes wird zunächst quasi verdoppelt.

Oft haben IP-Adressen eine Bedeutung auf höherer Ebene. So tauchen sie in [[Logdatei]]en oder [[Netflow]]-Daten auf, die teilweise mit [[Skriptsprache|Skripten]] wie beispielsweise [[Webalizer]] weiterverarbeitet werden, um Ansichten, Statistiken oder Abrechnungen zu erzeugen. Auch das Layout und die Skripte zur Erzeugung von Seiten wie Wikipedias „Versionsgeschichte“ mussten an die IPv6-Notation angepasst werden, da hier Nutzer zum Teil mit ihrer IP-Adresse identifiziert werden. Basiert eine Rechteverwaltung, wie z.&nbsp;B. in vielen Datenbanken, auf dem Zugriff durch festgelegte IP-Adressen, muss dies beim Zuschalten von IPv6 berücksichtigt werden.

== Verbreitung und Projekte ==
[[Datei:IPv6-as.svg|mini|Anzahl der [[Autonomes System|Autonomen Systeme]] mit publizierten IPv6-Routen und Anzahl der publizierten Präfixe seit 2003]]
[[Datei:Rir-ipv6-allocation-rate.svg|mini|Anzahl der neuen Zuweisungen von IPv6-Adressraum an ISPs seit 2000]]
IPv6 setzt sich im praktischen Einsatz nur langsam durch. Die Adressvergabe für IPv6 ist im Juli 1999 vom experimentellen in den Regelbetrieb übergegangen<ref>[https://www.iana.org/ipaddress/ipv6-announcement ''Delegation of IPv6 address space''.] IANA, Mailinglistenbeitrag vom 14.&nbsp;Juli 1999.</ref> und immer mehr [[Internetdienstanbieter|ISPs]] betreiben neben IPv4 auch IPv6 in ihrem Netz.

Über den Internetknoten [[AMS-IX]] werden zu Spitzenzeiten 150&nbsp;GBit/s IPv6-Traffic transportiert,<ref>[http://www.ams-ix.net/sflow-stats/ AMS-IX sFlow Statistics].</ref> das sind etwa 3 % des dort anfallenden Gesamtverkehrs von 5 TBit/s.<ref>[http://www.ams-ix.net/statistics/ AMS-IX Traffic Statistics].</ref> Auf Webseiten im Dual-Stack Betrieb werden weltweit 27 % der Zugriffe über IPv6 gemessen,<ref>[https://www.google.com/intl/en/ipv6/statistics.html Google IPv6 Adoption].</ref> für Zugriffe aus Deutschland liegt der IPv6-Anteil bei 46 %.<ref name="Google-Statistik" />

Die globale IPv6-Routingtabelle umfasste im Oktober 2016 etwa 33000 Präfixe,<ref>[[Geoff Huston]]: [http://bgp.potaroo.net/v6/as2.0/index.html AS2 IPv6 BGP Table Data].</ref> und ungefähr 26 % aller im Internet verfügbaren [[Autonomes System|Autonomen Systeme]] beteiligen sich am globalen IPv6-Routing.<ref>[http://v6asns.ripe.net/v/6 RIPE NCC.] RIPE .</ref> Die meisten der großen [[Internet-Knoten|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.<ref>APA, AP: [http://derstandard.at/?url=/?id=3326899 ''Internet-Protokoll IPv6 kommt endlich in Bewegung''.] derstandard.at, 6.&nbsp;Mai 2008.</ref>

Das ''IPv6 Forum''<ref>Website des [http://www.ipv6forum.org/ IPv6 Forums].</ref> wurde im Juli 1999, der Deutsche IPv6 Rat im Dezember 2007 gegründet. Das IPv6 Forum Projekt ''IPv6-Ready''<ref>Website [http://www.ipv6ready.org/ IPv6ready].</ref> 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 [[American Registry for Internet Numbers|nordamerikanischen Internet Registries]] und einigen US-amerikanischen Institutionen und Unternehmen direkt zugewiesen, während beispielsweise ganz China –&nbsp;mit inzwischen über 250&nbsp;Millionen Internet-Benutzern (Stand: Juni 2008<ref name="heise">[https://www.heise.de/newsticker/meldung/China-hat-nun-weltweit-die-meisten-Internetnutzer-190036.html ''China hat nun weltweit die meisten Internetnutzer''.] Heise Online, 4.&nbsp;Juli 2008.</ref>)&nbsp;– vor Jahren noch nur über etwa so viele IP-Adressen verfügte wie ein Campus der University of California (Dezember 2004).<ref name="Liu">Liu Baijia: [http://www.chinadaily.com.cn/english/doc/2004-12/27/content_403512.htm ''China launches new generation Internet''.] In: ''[[China Daily]]'', 27.&nbsp;Dezember 2004.</ref> <!-- Gibt's da neuere Zahlen? -->

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]], [[Quality of Service|QoS]], [[Multicast]]; [[#Umnummerierung und Multihoming|Umnummerierung]] und [[#Autokonfiguration|Autokonfiguration]] sind auch mittels [[Dynamic Host Configuration Protocol|DHCP]] möglich) – es gibt keine weitverbreitete Anwendung, die nur mit IPv6 funktionieren würde.

=== Frühe Projekte ===
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 ([[Verein zur Förderung eines Deutschen Forschungsnetzes|DFN]]) haben mit dem „6WiN“ einen ersten IPv6-Backbone in Deutschland aufgebaut. Das 6WiN war 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.&nbsp;Juni 2005 im Rahmen der planmäßigen sukzessiven Beendigung des weltweiten 6Bone-Betriebs abgeschaltet wurde. Zum 1.&nbsp;Januar 2006 wurde der IPv6-Betrieb im Deutschen Forschungsnetz vom JOIN-Projekt an das DFN-NOC übergeben.

Die [[Universität Wien]], die auch den ''Vienna Internet Exchange'' (VIX)<ref>[http://www.vix.at/ Vienna Internet Exchange].</ref> und mehrere [[Domain Name System|DNS]]-Server für die Zone „.at“ betreibt, spielte eine entscheidende Rolle bei der IPv6-Migration in Österreich. Beide Einrichtungen sind über IPv6 erreichbar bzw. bieten akademischen Kunden IPv6-Anbindung an. Der erste kommerzielle Anbieter in Österreich war das Unternehmen ''next layer''.

=== Anbindung von Endnutzern ===
Am 8. Juni 2011 fand der sogenannte ''[[World IPv6 Day und World IPv6 Launch Day|World IPv6 Day]]'' statt, an dem der Dual-Stack-Betrieb auf mehreren großen Webseiten getestet wurde.<ref>[http://isoc.org/wp/worldipv6day/ Offizielle Website des ''World IPv6 Days''].</ref> Der Test verlief weitestgehend problemlos.<ref>[https://www.heise.de/netze/meldung/World-IPv6-Day-Viel-Aufmerksamkeit-und-kaum-Probleme-1257943.html ''World IPv6 Day: Viel Aufmerksamkeit und kaum Probleme''.] heise Netze.</ref> Am Internetknotenpunkt [[DE-CIX]] war ein deutlich erhöhtes IPv6-Verkehrsaufkommen zu messen, das auch nach dem 8.&nbsp;Juni anhielt.<ref>[https://www.heise.de/netze/meldung/World-IPv6-Day-Unerwartete-Nachwirkungen-1259275.html ''World IPv6 Day: Unerwartete Nachwirkungen''.] heise Netze.</ref>

Im Rahmen eines weiteren Aktionstages am 6.&nbsp;Juni 2012, dem ''[[World IPv6 Day und World IPv6 Launch Day|World IPv6 Launch Day]]'', haben mehr als 1400 Unternehmen weltweit ihre Webseiten dauerhaft auf den neuesten Standard umgestellt, so dass sie mit IPv4 und IPv6 erreichbar sind.<ref>[https://www.heise.de/newsticker/meldung/World-IPv6-Launch-Day-Inhalteanbieter-schalten-IPv6-dazu-1590409.html ''World IPv6 Launch Day: Inhalteanbieter schalten IPv6 dazu''.] heise.de, 5.&nbsp;Juni 2012, abgerufen am 6.&nbsp;Juni 2012.</ref><ref>[https://www.welt.de/wirtschaft/webwelt/article106417530/Eine-unsichtbare-Revolution-fuer-das-Internet.html ''IPv6-Standard: Eine unsichtbare Revolution für das Internet''] bei welt.de, 5.&nbsp;Juni 2012, abgerufen am 6.&nbsp;Juni 2012.</ref>

Seit dem 25.&nbsp;September 2012 leistet die Deutsche Telekom IPv6 auch an DSL-Endkundenanschlüssen.<ref>[https://twitter.com/Telekom_hilft/status/251602258318479360 Twitter-Meldung der Telekom].</ref> Zunächst wurden erst die sogenannten IP-Anschlüsse IPv6-fähig gemacht, wobei zunächst mit Neukunden begonnen wurde. Die mittlerweile deaktivierten Analog- und ISDN-Anschlüsse erhielten kein IPv6.<ref>[https://www.heise.de/netze/meldung/Telekom-Kein-IPv6-fuer-Vertraege-mit-Analog-und-ISDN-Telefonie-1763557.html ''Telekom: Kein IPv6 für Verträge mit Analog- und ISDN-Telefonie''.] heise.de, 6. Dezember 2012.</ref>
In der aktuellen Leistungsbeschreibung für die Nutzung von LTE an einer fest vereinbarten Adresse („MagentaZuhause via Funk“ als Alternative zu DSL) stellt die Deutsche Telekom z.&nbsp;B. klar, dass über diesen Internetzugang nur IPv4-Adressen erreichbar sind.<ref>{{Webarchiv |url=https://www.telekom.de/dlp/agb/pdf/45484.pdf |wayback=20200215212132 |text=Leistungsbeschreibung MagentaZuhause via Funk; Stand Februar 2020 |format=PDF}}.</ref>

Nutzer weiterer Anschlussarten wie beispielsweise dem [[Mobilfunknetz]]<ref>[https://www.heise.de/newsticker/meldung/Telekom-startet-IPv6-Einfuehrung-im-Mobilfunknetz-2741029.html Telekom startet IPv6-Einführung im Mobilfunknetz].</ref> oder [[Kabelfernsehen|Kabel]]<ref>[https://www.heise.de/newsticker/meldung/Kabel-Deutschland-stellt-Internetzugaenge-auf-IPv6-um-2069367.html Kabel Deutschland stellt Internetzugänge auf IPv6 um].</ref> werden zunehmend mit IPv6 versorgt.

== Probleme ==

=== Historisch ===
Gerade zu Anfang wurden die IPv6-Standards häufig geändert, was dazu führte, dass bereits fertiggestellte Implementierungen mehrfach angepasst werden mussten.

==== Adressierung der Netzknoten ====
Der größte Einschnitt bestand in der Einführung der [[Institute of Electrical and Electronics Engineers|IEEE]]-Norm [[EUI-64]] für die [[Interface Identifier|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.<ref>[http://www.atm.tut.fi/list-archive/ipng/msg10039.html Diskussion über EUI-64, EUI-48 und MAC-48] auf der IETF-IPng-Arbeitsgruppen-Mailingliste.</ref>

Die beschriebenen Verfahren führen zu einem statischen hostspezifischen Teil der IPv6-Adresse eines autokonfigurierten IPv6-Knotens. Datenschützer waren besorgt, dass auf diese Weise Nutzer über unterschiedliche Netzwerke hinweg identifizierbar werden und dies beispielsweise für Marketingmaßnahmen oder staatliche Interventionen ausgenutzt werden könnte. Die [[Internet Engineering Task Force|IETF]] definierte deshalb nachträglich die Datenschutzerweiterungen (''Privacy Extensions'') gemäß RFC 3041, später RFC 4941 (siehe auch [[#Adressaufbau von IPv6|Adressaufbau von IPv6]]). Diese Privacy-Extensions generieren bei der Autokonfiguration via SLAAC einen zufälligen hostspezifischen Teil. Da aber die ersten 64 Bit der IPv6-Adresse eines Netzes (z.&nbsp;B. eines Haushaltes) weiterhin erhalten bleiben, muss ein weiterer Schutz durch regelmäßiges Wechseln des netzspezifischen Teils gewährleistet sein (wie heute bei DSL-Anschlüssen).

==== Integration ins Domain Name System ====
Lange Zeit war die DNS-Anpassung zur Eingliederung von IPv6 uneinheitlich. 1995 wurde in RFC 1886 zunächst der Record-Typ AAAA für die Auflösung von DNS-Namen in IPv6-Adressen definiert, der funktional äquivalent zum [[A Resource Record|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 Resource Record|PTR-Records]] in zwei verschiedenen Zonen gab, unterhalb von ip6.arpa und ip6.int. Aufgrund der traditionellen Nutzung der [[Top-Level-Domain|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 Auflösung ist vom Protokolltyp der Anfrage völlig unabhängig: Wird eine DNS-Anfrage über IPv4 gestellt, so kann auch ein AAAA-Record zurückgegeben werden, und über IPv6 erreichbare Nameserver geben auch über IPv4-Adressen (A-Records) Auskunft.

=== Aktuell ===
==== Link-lokale Adressen ====
Eine mögliche Designschwäche von IPv6 ist, dass die Adressräume für [[#Link-Local-Unicast-Adressen|link-lokale Adressen]] grundsätzlich nicht getrennt sind. Will man link-lokale Adressen also auf Anwendungsebene zur Kommunikation zwischen Rechnern im selben Netzwerksegment verwenden, ergibt sich 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 [[Schnittstelle|Interface]]) angegeben werden muss, da sich der link-lokale Adressraum mehrerer Interfaces überschneidet. Es hängt daher davon ab, ob die IPv6-Unterstützung der verwendeten Anwendung das Konzept der Zonen-Indizes kennt, ob link-lokale Adressen zu diesem Zweck eingesetzt werden können.

==== Autokonfiguration und DNS ====
Im Zusammenspiel des IPv6-Autokonfigurationsmechanismus mit dem Domain Name System ergeben sich bis heute Probleme. Ursprünglich fehlte die Möglichkeit ganz, im Rahmen der Autokonfiguration Netzknoten auch zu verwendende DNS-Server und weitere DNS-bezogene Informationen wie DNS-Suchpfade mitzuteilen, wie das für IPv4 im Rahmen von [[DHCP]] üblich ist. Heute bestehen im Wesentlichen zwei Lösungen für das Problem:
* Mittels des ''Managed''-Flags in Router-Advertisements können Netzknoten angewiesen werden, bei einem [[Dynamic Host Configuration Protocol#DHCPv6|DHCPv6]]-Server nach weiterer Konfiguration zu fragen. DHCPv6-Server können über die Multicastadressen <code>ff02::1:2</code> und <code>ff05::1:3</code> angesprochen werden. Im Gegensatz zu DHCP muss der DHCPv6-Server keine Protokolle über solche Anfragen führen, die Konfiguration kann also weiterhin zustandslos erfolgen.
* Die NDP-Spezifikation erlaubt die Angabe zusätzlicher Felder in Router Advertisements. Die so genannten RDNSS- (''Recursive DNS Server'') und DNSSL-Erweiterungen (''DNS Search List'') spezifizieren eine Möglichkeit, DNS-Server und DNS-Suchpfade im Rahmen der Router Advertisements zu versenden.
Insbesondere RDNSS und DNSSL sind erst im November 2010 mit Erscheinen von RFC 6106 standardisiert worden.

Die Unterstützung für die obengenannten Lösungen ist unter den verschiedenen Implementierungen uneinheitlich. Beispielsweise unterstützen Microsoft Windows Vista und 7 nur DHCPv6 und für Linux-Systeme sind zwar alle Verfahren verfügbar, jedoch oft von Distributoren nicht vorinstalliert. Mac OS X unterstützt allerdings seit der Version 10.7 (Lion) sowohl DHCPv6 als auch RDNSS. <!-- Wie sieht es mit der Unterstützung durch Hardware, insbesondere Router aus? -->

==== Datenschutz ====
Datenschützer bemängeln an IPv6, dass hier jedes mit dem Internet verbundene Gerät eine fixe IP-Adresse bekommen könnte, wodurch alle besuchten Seiten noch Jahre später eruiert und der Besucher identifiziert werden könnte.<ref>[https://www.heise.de/netze/meldung/Datenschuetzer-besorgt-ueber-IPv6-1382812.html ''Datenschützer besorgt über IPv6''.] Heise.de</ref><ref>[https://www.internex.at/blog/ipv6-das-internet-protokoll-der-naechsten-generation/ IPv6 – Das Internet-Protokoll der nächsten Generation].</ref><ref>{{Webarchiv |url=http://www.datenschutzraum.de/blog/ipv6/ |wayback=20131220233042 |text=IPv6}} datenschutzraum.de</ref><ref>[https://www.suspace.net/so-gehts/ip-v6/ IP Adressen werden knapp – IPv6 die Zukunft].</ref> Technisch kann dies durch die Privacy Extensions erschwert werden.

Bereits 64 Bit große Adressen hätten einen unvorstellbaren Vorrat von weit über 10<sup>19</sup> Adressen dargestellt – eine Milliarde mal 10&nbsp;Milliarden, quasi eine Milliarde Generationen der Menschheit. Mit den 128 Bit, die man bei IPv6 verwendet, sind es sogar 10<sup>38</sup>. Damit könnte man theoretisch jedem Atom jedes Menschen auf der Welt eine eigene Adresse zuteilen.

Da es so niemals zu einer Verknappung kommen kann, sind technische Vorrichtungen wie bei IPv4 überflüssig geworden, wodurch ein Internetnutzer teilweise alle paar Stunden eine andere IP-Adresse zugewiesen bekam. Bei IPv6 haben Privatpersonen praktisch eine feste IP-Adresse, die für [[Web Analytics|Webtracking]] ein Segen ist. Jede IPv6-Adresse kann sehr zuverlässig einem Haushalt oder sogar Mobiltelefon zugeordnet werden. Dadurch kann z.&nbsp;B. eine [[Suchmaschine]] oder [[Elektronischer Handel#Onlineshop|Onlineshop]] Personen identifizieren und Informationen über sie verknüpfen, ohne sich Zugriff auf fremde Rechnersysteme zu verschaffen. Dies erforderte ursprünglich so genannte „[[Cookie|Tracking Cookies]]“. Mit genügend Verbreitung von IPv6-Adressen wird dieses Verfahren obsolet.

Um dieses Problem zu umgehen, wollen Datenschützer Internet Service Provider per Gesetz dazu verpflichten, auch unter IPv6 dynamische Adressen anzubieten.<ref>[https://www.golem.de/1106/84028.html ''Dynamische Adressvergabe per Gesetz auch unter IPv6''.] golem.de</ref>

== IPv5 ==
Ein Protokoll mit dem Namen IPv5 gibt es nicht. Allerdings hat die [[Internet Assigned Numbers Authority|IANA]] die IP-Versionsnummer&nbsp;5 für das Internet Stream Protocol Version&nbsp;2 (ST2, definiert in RFC 1819) reserviert, das gegenüber IPv4 verbesserte [[Echtzeit]]fähigkeiten haben sollte, dessen Entwicklung dann aber aus Kosten-Nutzen-Erwägungen zugunsten von IPv6 und [[Resource Reservation Protocol|RSVP]] eingestellt wurde.

== Siehe auch ==
* [[Liste von IPv6-Tunnelbrokern]]
* [[M6Bone]]
* [[Peer Name Resolution Protocol]]
* [[Hurricane Electric]], ein für seinen Tunnelbroker und sein v6-Backbone bekannter ISP

== Literatur ==
=== Grundlegende Spezifikationen ===
* {{RFC-Internet |RFC=2460 |Titel=Internet Protocol, Version 6 (IPv6) Specification |Datum= |Updated=8200 |Kommentar=im Juli 2017 abgelöst}}
** {{RFC-Internet |RFC=8200 |Titel=Internet Protocol, Version 6 (IPv6) Specification |Datum=2017-07 |Obsoletes=2460}}
* {{RFC-Internet |RFC=4861 |Titel=Neighbor Discovery for IP version 6 (IPv6) |Datum=}}
* {{RFC-Internet |RFC=4862 |Titel=IPv6 Stateless Address Autoconfiguration |Datum=}}
* {{RFC-Internet |RFC=4291 |Titel=IP Version 6 Addressing Architecture |Datum=}}
* {{RFC-Internet |RFC=5942 |Titel=IPv6 Subnet Model |Datum=}}

=== Sekundärliteratur ===
* Reiko Kaps: ''WAN-Auffahrt – Mit dem IPv6-Netz online gehen''. In: ''[[c’t]]'', Heise, Hannover 2008,6.
* Silvia Hagen: ''IPv6. Grundlagen – Funktionalität – Integration''. Sunny Edition, Maur 2009, ISBN 978-3-9522942-2-2.
* Joseph Davies: ''Understanding IPv6''. 2. Auflage. Microsoft Press, Redmond 2008, ISBN 978-0-7356-2446-7 (englisch).
* Anatol Badach: ''Technik der IP-Netze. TCP/IP incl. IPv6. Funktionsweise, Protokolle und Dienste''. Hanser Fachbuch. 2. Auflage. Hanser, München 2007, ISBN 3-446-21935-8.
* Mathias Hein: ''IPv6, Das Migrationshandbuch''. Franzis, Point 2003, ISBN 3-7723-7390-9.
* Herbert Wiese: ''Das neue Internetprotokoll IPv6''. Hanser Fachbuch. Hanser, München 2002, ISBN 3-446-21685-5.
* Hans P. Dittler: ''IPv6. Das neue Internet-Protokoll. Technik, Anwendung, Migration.'' 2. Auflage. Dpunkt, Heidelberg 2002, ISBN 3-89864-149-X.
* Christian Huitema: ''IPv6 – die neue Generation''. Addison-Wesley, München 2000, ISBN 3-8273-1420-8.

== Weblinks ==
{{Commonscat}}
* [https://www.iana.org/assignments/ipv6-address-space Allokation des IPv6-Adressbereiches im Überblick] (englisch)
* [https://cre.fm/cre197-ipv6 CRE197 IPv6] Ausführlicher, deutschsprachiger Podcast über IPv6
* [https://bgp.he.net/ipv6-progress-report.cgi Messungen von Hurricane Electric zur Verbreitung von IPv6] (englisch)
* [https://www.google.de/ipv6/statistics.html#tab=per-country-ipv6-adoption Regionenspezifische IPv6-Zugriffs- und Latenzstatistiken für Google-Dienste] <small>(benötigt aktiviertes [[JavaScript]])</small>
* [https://test-ipv6.com/ Test your IPv6] – IPv6-Verbindungstest-Seite <small>(benötigt aktiviertes [[JavaScript]])</small>
* [https://www.baebeca.de/ipv4ipv6-test-zum-einbinden/ IPv4/IPv6 Test zur Einbettung in eigene Internetseite] <small>(benötigt aktiviertes [[JavaScript]])</small>

== Einzelnachweise ==
<references responsive />

{{Normdaten|TYP=s|GND=4462513-3}}

[[Kategorie:Internet Protocol]]
[[Kategorie:IP-Adressierung]]