Zerlegung einer IPv6-Adresse in ihre Binärform

Eine IPv6- Adresse ( Internet Protocol Version 6 ) ist eine numerische Kennung, die zur Identifizierung und Lokalisierung einer Netzwerkschnittstelle eines Computers oder Netzwerkknotens in einem IPv6- Netzwerk dient . IP-Adressen sind im Paketkopf enthalten , um Quelle und Ziel jedes Pakets anzugeben. Die Ziel-IP-Adresse wird verwendet, um Entscheidungen über das Routing von IP-Paketen in andere Netzwerke zu treffen.

IPv6 ist der Nachfolger der ersten Adressierungsinfrastruktur des Internets , dem Internetprotokoll Version 4 (IPv4). Im Gegensatz zu IPv4, das eine IP-Adresse als 32-Bit-Wert definierte, haben IPv6-Adressen eine Größe von 128 Bit. Daher verfügt IPv6 im Vergleich über einen deutlich größeren Adressraum .

Adressierungsmethoden

IPv6-Adressen werden nach den in Netzwerken üblichen primären Adressierungs- und Routingmethoden klassifiziert: Unicast-Adressierung, Anycast-Adressierung und Multicast-Adressierung. [ 1 ]

Eine Unicast -Adresse identifiziert eine einzelne Netzwerkschnittstelle. Das Internetprotokoll leitet Pakete, die an eine Unicast-Adresse gesendet werden, an diese spezifische Schnittstelle weiter.

Eine Anycast -Adresse wird einer Gruppe von Schnittstellen zugewiesen, die üblicherweise zu verschiedenen Knoten gehören. Ein an eine Anycast-Adresse gesendetes Paket wird genau an eine der zugehörigen Schnittstellen zugestellt, typischerweise an den nächstgelegenen Host, gemäß der Distanzdefinition des Routing-Protokolls. Anycast-Adressen sind nicht leicht zu identifizieren; sie haben dasselbe Format wie Unicast-Adressen und unterscheiden sich lediglich dadurch, dass sie an mehreren Stellen im Netzwerk vorkommen. Nahezu jede Unicast-Adresse kann auch als Anycast-Adresse verwendet werden.

Eine Multicast -Adresse wird auch von mehreren Hosts verwendet, die die Zieladresse durch die Teilnahme am Multicast-Verteilungsprotokoll zwischen den Netzwerkroutern erhalten. Ein an eine Multicast-Adresse gesendetes Paket wird an alle Schnittstellen zugestellt, die der entsprechenden Multicast-Gruppe beigetreten sind. IPv6 implementiert keine Broadcast-Adressierung . Die traditionelle Rolle von Broadcasts wird durch die Multicast-Adressierung an die knotenübergreifende, link-lokale Multicast-Gruppe ff02::1 übernommen . Die Verwendung dieser Gruppe wird jedoch nicht empfohlen, und die meisten IPv6-Protokolle verwenden protokollspezifische, link-lokale Multicast-Gruppen, um zu vermeiden, dass alle Schnittstellen eines Netzwerks beeinträchtigt werden.

Adressformate

Eine IPv6-Adresse besteht aus 128 Bit. [ 1 ] Für jede der wichtigsten Adressierungs- und Routingmethoden werden verschiedene Adressformate unterschieden, indem die 128 Adressbits in Bitgruppen unterteilt und festgelegte Regeln zur Zuordnung der Werte dieser Bitgruppen zu speziellen Adressierungsmerkmalen verwendet werden.

Unicast- und Anycast-Adressformat

Unicast- und Anycast -Adressen bestehen typischerweise aus zwei logischen Teilen: einem 64-Bit-Netzwerkpräfix, das für das Routing verwendet wird , und einer 64-Bit-Schnittstellenkennung, die zur Identifizierung der Netzwerkschnittstelle eines Hosts dient.

Allgemeines Unicast-Adressformat (die Größe des Routing-Präfixes variiert)
Bits 48 (oder mehr) 16 (oder weniger) 64
Feld Routing-PräfixSubnetz-IDSchnittstellenkennung

Das Netzwerkpräfix (das Routingpräfix kombiniert mit der Subnetz-ID ) ist in den höchstwertigen 64 Bits der Adresse enthalten. Die Größe des Routingpräfixes kann variieren; ein größeres Präfix bedeutet eine kleinere Subnetz -ID. Die Bits des Subnetz-ID- Felds stehen dem Netzwerkadministrator zur Verfügung , um Subnetze innerhalb des Netzwerks zu definieren. Die 64-Bit- Schnittstellenkennung wird automatisch zufällig generiert, von einem DHCPv6- Server bezogen oder manuell zugewiesen. (Früher wurde sie automatisch aus der MAC-Adresse der Schnittstelle im modifizierten EUI-64 -Format generiert , diese Methode wird jedoch aus Datenschutzgründen nicht mehr empfohlen. [ 2 ] )

Eindeutige lokale Adressen sind Adressen, die den privaten IPv4- Netzwerkadressen analog sind.

Einzigartiges lokales Adressformat
Bits 7 1 40 16 64
Feld PräfixLzufälligSubnetz-IDSchnittstellenkennung

Das Präfixfeld enthält den Binärwert 1111110. Das L- Bit ist für lokal zugewiesene Adressen auf 1 gesetzt; der Adressbereich mit L = 0 ist derzeit nicht definiert. Das Zufallsfeld wird einmalig beim Start des / 48 -Routingpräfixes zufällig gewählt.

Eine Link-Local-Adresse basiert ebenfalls auf der Schnittstellenkennung, verwendet aber ein anderes Format für das Netzwerkpräfix.

Link-lokales Adressformat
Bits 10 54 64
Feld PräfixNullenSchnittstellenkennung

Das Präfixfeld enthält den Binärwert 1111111010. Die darauf folgenden 54 Nullen machen das gesamte Netzwerkpräfix für alle Link-Local-Adressen gleich ( fe80:: / 64 Link-Local-Adresspräfix ), wodurch diese nicht routingfähig werden.

Multicast-Adressformat

Multicast- Adressen werden je nach Anwendung nach mehreren spezifischen Formatierungsregeln gebildet.

Allgemeines Multicast-Adressformat
Bits 8 4 4 112
Feld PräfixFlaggescGruppen-ID

Bei allen Multicast-Adressen enthält das Präfixfeld den Binärwert 11111111.

Aktuell sind drei der vier Flag-Bits im flg- Feld definiert; [ 1 ] das höchstwertige Flag-Bit ist für zukünftige Verwendung reserviert.

Multicast-Adressflags [ 3 ]
Bit [ a ]Flagge Bedeutung, wenn 0 Bedeutung, wenn 1
8 reserviertreserviertreserviert
9 R (Rendezvous) [ 4 ]Treffpunkt nicht eingebettet Rendezvous-Punkt eingebettet
10 P (Präfix) [ 5 ]Ohne Präfixinformationen Adresse basierend auf Netzwerkpräfix
11 T (Transient) [ 1 ]Bekannte Multicast-Adresse Dynamisch zugewiesene Multicast-Adresse

Das vier-Bit-Bereichsfeld ( sc ) dient dazu, anzugeben, wo die Adresse gültig und eindeutig ist.

Darüber hinaus wird das Bereichsfeld verwendet, um spezielle Multicast-Adressen wie beispielsweise den angeforderten Knoten zu identifizieren .

Multicast-Adressformat für angeforderte Knoten
Bits 8 4 4 79 9 24
Feld PräfixFlaggescNulleneinsUnicast-Adresse

Das Feld sc(ope) enthält den Binärwert 0010 (Link-lokal). Multicast-Adressen von angeforderten Knoten werden als Funktion der Unicast- oder Anycast-Adressen eines Knotens berechnet. Eine solche Multicast-Adresse entsteht, indem die letzten 24 Bit einer Unicast- oder Anycast-Adresse in die letzten 24 Bit der Multicast-Adresse kopiert werden.

Unicast-Präfix-basiertes Multicast-Adressformat [ 4 ] [ 5 ]
Bits 8 4 4 4 4 8 64 32
Feld PräfixFlaggescresriidplenNetzwerkpräfixGruppen-ID

Linkbezogene Multicast-Adressen verwenden ein vergleichbares Format. [ 6 ]

Darstellung

Eine IPv6-Adresse wird als acht Gruppen von je vier Hexadezimalziffern dargestellt , wobei jede Gruppe 16 Bit umfasst. [ b ] Die Gruppen werden durch Doppelpunkte (:) getrennt. Ein Beispiel für eine IPv6-Adresse ist:

2001:0db8:85a3:0000:0000:8a2e:0370:7334

Die Standards bieten Flexibilität bei der Darstellung von IPv6-Adressen. Die vollständige Darstellung aus acht vierstelligen Gruppen kann durch verschiedene Techniken vereinfacht werden, indem Teile der Darstellung entfernt werden. Im Allgemeinen werden Darstellungen so weit wie möglich gekürzt. Diese Vorgehensweise erschwert jedoch einige gängige Operationen, insbesondere die Suche nach einer bestimmten Adresse oder einem Adressmuster in Textdokumenten oder Datenströmen sowie den Vergleich von Adressen zur Bestimmung der Äquivalenz. Um diese Komplikationen zu minimieren, hat die Internet Engineering Task Force (IETF) ein kanonisches Format für die Darstellung von IPv6-Adressen in Text definiert: [ 9 ]

  • Die Hexadezimalziffern werden immer unabhängig von Groß- und Kleinschreibung verglichen, die IETF-Empfehlungen legen jedoch die Verwendung von Kleinbuchstaben nahe. Beispielsweise ist 2001:db8::1 gegenüber 2001:DB8::1 vorzuziehen .
  • Führende Nullen in jedem 16-Bit-Feld werden unterdrückt, aber jede Gruppe muss mindestens eine Ziffer behalten. Zum Beispiel wird 2001:0db8::0001:0000 als 2001:db8::1:0 dargestellt ;
  • Die längste Folge aufeinanderfolgender Nullfelder wird durch zwei Doppelpunkte ( : :) ersetzt. Enthält die Adresse mehrere gleich lange Nullfelder, wird zur Vermeidung von Mehrdeutigkeiten das erste komprimiert. Beispielsweise wird 2001:db8:0:0:1:0:0:1 als 2001:db8::1:0:0:1 und nicht als 2001:db8:0:0:1::1 dargestellt . :: wird nicht verwendet, um nur ein einzelnes Nullfeld darzustellen. So wird beispielsweise 2001:db8:0:0:0:0:2:1 zu 2001:db8::2:1 verkürzt , 2001:db8:0000:1:1:1:1:1 hingegen als 2001:db8:0:1:1:1:1:1 .

Diese Methoden können zu sehr kurzen Darstellungen für IPv6-Adressen führen. Beispielsweise werden die Localhost -Adresse (Loopback-Adresse), 0:0:0:0:0:0:0:1 , und die nicht spezifizierte IPv6-Adresse, 0:0:0:0:0:0:0:0 , auf ::1 bzw. :: reduziert .

Beim Übergang des Internets von IPv4 zu IPv6 ist der Betrieb in einer Umgebung mit gemischten Adressierungsformaten üblich. Für solche Anwendungsfälle wurde eine spezielle Notation eingeführt, die IPv4-zugeordnete und IPv4-kompatible IPv6-Adressen darstellt. Dabei werden die niedrigstwertigen 32 Bits einer Adresse in der bekannten IPv4 -Punktdezimalnotation geschrieben , während die 96 höchstwertigen Bits im IPv6-Format dargestellt werden. Beispielsweise wird die IPv4-zugeordnete IPv6-Adresse ::ffff:c000:0280 als ::ffff:192.0.2.128 geschrieben , wodurch die ursprüngliche IPv4-Adresse, die auf IPv6 abgebildet wurde, klar erkennbar ist.

Netzwerke

Ein IPv6-Netzwerk verwendet einen Adressblock, der eine zusammenhängende Gruppe von IPv6-Adressen mit einer Größe, die eine Zweierpotenz ist, darstellt . Die führenden Bits der Adressen sind für alle Hosts in einem bestimmten Netzwerk identisch und werden als Netzwerkadresse oder Routing- Präfix bezeichnet .

Netzwerkadressbereiche werden in CIDR-Notation geschrieben . Ein Netzwerk wird durch die erste Adresse im Block (die mit Nullen endet), einen Schrägstrich (/) und einen Dezimalwert , der der Bitlänge des Präfixes entspricht, dargestellt. Beispielsweise beginnt das Netzwerk 2001:db8:1234:: / 48 bei der Adresse 2001:db8:1234:0000:0000:0000:0000:0000 und endet bei 2001:db8:1234:ffff:ffff:ffff:ffff:ffff .

Das Routing-Präfix einer Schnittstellenadresse kann direkt mit der Adresse in CIDR-Notation angegeben werden. Beispielsweise wird die Konfiguration einer Schnittstelle mit der Adresse 2001:db8:a::123, die mit dem Subnetz 2001:db8:a:: / 64 verbunden ist, als 2001:db8:a::123 / 64 geschrieben .

Adressblockgrößen

Die Größe eines Adressblocks wird durch einen Schrägstrich (/) gefolgt von einer Dezimalzahl angegeben, deren Wert der Länge des Netzwerkpräfixes in Bit entspricht. Beispielsweise wird ein Adressblock mit 48 Bit im Präfix durch / 48 gekennzeichnet . Ein solcher Block enthält 2 <sup>128</sup> − 48 = 2 <sup>80 </sup> Adressen. Je kürzer die Länge des Netzwerkpräfixes, desto größer der Block: Ein / 21- Block ist achtmal so groß wie ein / 24- Block.

Literale IPv6-Adressen in Netzwerkressourcenbezeichnern

Doppelpunkte (:) in IPv6-Adressen können mit der etablierten Syntax von Ressourcenbezeichnern wie URIs und URLs in Konflikt geraten . Der Doppelpunkt wird üblicherweise verwendet, um den Hostpfad vor einer Portnummer abzuschließen . [ 10 ] Um diesen Konflikt zu beheben, werden IPv6-Adressen in solchen Ressourcenbezeichnern in eckige Klammern gesetzt , zum Beispiel:

http://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/

Wenn die URL auch eine Portnummer enthält, lautet die Notation:

https://[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443/

wobei die nachfolgende 443 die Portnummer des Beispiels ist.

Bereichsbezogene IPv6-Literaladressen (mit Zonenindex)

Bei Adressen mit anderem als globalem Gültigkeitsbereich (wie in Abschnitt „Adressbereiche “ beschrieben ), insbesondere bei Link-Local-Adressen, kann die Wahl der Netzwerkschnittstelle zum Senden eines Pakets von der Zone abhängen, zu der die Adresse gehört. Dieselbe Adresse kann in verschiedenen Zonen gültig sein und in jeder dieser Zonen von einem anderen Host verwendet werden. Selbst wenn eine einzelne Adresse nicht in verschiedenen Zonen verwendet wird, können die Adresspräfixe für Adressen in diesen Zonen dennoch identisch sein. Dies verhindert, dass das Betriebssystem anhand der Informationen in der Routing-Tabelle (die präfixbasiert ist) eine ausgehende Schnittstelle auswählen kann.

Um die Mehrdeutigkeit in textlichen Adressen aufzulösen,Der Zonenindex muss an die Adresse angehängt werden. Er wird durch ein Prozentzeichenvon der Adresse getrennt. [ 11 ] Obwohl numerische Zonenindizes universell unterstützt werden müssen, kann der Zonenindex auch eine implementierungsabhängige Zeichenkette sein. Die Link-Local-Adresse

fe80::1ff:fe23:4567:890a

könnte ausgedrückt werden durch

fe80::1ff:fe23:4567:890a%eth2 [ c ]

oder

fe80::1ff:fe23:4567:890a%3

Die erstgenannte Methode (mit einem Schnittstellennamen ) ist auf den meisten Unix -ähnlichen Betriebssystemen (z. B. BSD , Linux , macOS ) üblich. [ 12 ] Die zweite Methode (mit einer Schnittstellennummer) ist die einzige Syntax unter Microsoft Windows , da die Unterstützung dieser Syntax jedoch laut Standard obligatorisch ist, ist sie auch auf anderen Betriebssystemen verfügbar. [ d ]

BSD-basierte Betriebssysteme (einschließlich macOS) unterstützen auch eine alternative, nicht standardkonforme Syntax, bei der ein numerischer Zonenindex im zweiten 16-Bit-Wort der Adresse kodiert wird. Beispiel:

fe80:3::1ff:fe23:4567:890a

In allen oben genannten Betriebssystemen bezieht sich der Zonenindex für Link-Local-Adressen tatsächlich auf eine Schnittstelle, nicht auf eine Zone. Da mehrere Schnittstellen zur selben Zone gehören können (z. B. bei Verbindung mit demselben Netzwerk), können zwei Adressen mit unterschiedlichen Zonenkennungen in der Praxis äquivalent sein und sich auf denselben Host über dieselbe Verbindung beziehen. [ e ]

Bei Verwendung in Uniform Resource Identifiers (URIs) führt die Verwendung des Prozentzeichens zu einem Syntaxkonflikt und muss daher mittels Prozentkodierung maskiert werden [ 13 ] z . B .:

http://[fe80::1ff:fe23:4567:890a %25 eth0]/

Literale IPv6-Adressen in UNC-Pfadnamen

In Microsoft Windows- Betriebssystemen sind IPv4-Adressen gültige Standortbezeichner in UNC-Pfadnamen ( Uniform Naming Convention ). Der Doppelpunkt ist jedoch in UNC-Pfadnamen unzulässig. Daher ist auch die Verwendung von IPv6-Adressen in UNC-Pfaden nicht zulässig. Aus diesem Grund implementierte Microsoft einen Transkriptionsalgorithmus, um eine IPv6-Adresse als Domänennamen darzustellen, der in UNC-Pfaden verwendet werden kann. Zu diesem Zweck registrierte und reservierte Microsoft die Second-Level-Domain ipv6-literal.net im Internet (gab die Domain jedoch im Januar 2014 wieder auf [ 14 ] ). IPv6-Adressen werden innerhalb dieses Namensraums als Hostname oder Subdomain -Name wie folgt transkribiert :

2001:db8:85a3:8d3:1319:8a2e:370:7348

wird geschrieben als

2001-db8-85a3-8d3-1319-8a2e-370-7348.ipv6-literal.net

Diese Notation wird von Microsoft-Software automatisch lokal aufgelöst, ohne dass Anfragen an DNS-Namensserver erfolgen.

Enthält die IPv6-Adresse einen Zonenindex, wird dieser nach dem Zeichen 's' an den Adressteil angehängt:

fe80::1ff:fe23:4567:890a%3

wird geschrieben als

fe80--1ff-fe23-4567-890a s3 .ipv6-literal.net

Adressbereiche

Jede IPv6-Adresse, außer der nicht spezifizierten Adresse ( :: ), hat einen Gültigkeitsbereich , [ 11 ] der angibt, in welchem ​​Teil des Netzwerks sie gültig ist.

Unicast

Für Unicast -Adressen werden zwei Bereiche definiert: Link-lokal und global.

Link-lokale Adressen und die Loopback-Adresse haben einen Link-lokalen Gültigkeitsbereich, d. h., sie können nur in einem direkt angeschlossenen Netzwerk verwendet werden. Alle anderen Adressen (einschließlich eindeutiger lokaler Adressen ) haben einen globalen (oder universellen ) Gültigkeitsbereich, d. h., sie sind potenziell global routingfähig und können verwendet werden, um Verbindungen zu Adressen mit globalem Gültigkeitsbereich überall oder zu Adressen mit Link-lokalem Gültigkeitsbereich im direkt angeschlossenen Netzwerk herzustellen.

Lokale Adressen haben zwar globalen Gültigkeitsbereich, werden aber nicht global verwaltet. Daher können diese Adressen nur von anderen Hosts innerhalb derselben administrativen Domäne (z. B. einer Organisation) oder einer kooperierenden administrativen Domäne erreicht werden, sofern die Weiterleitung korrekt erfolgt. Da ihr Gültigkeitsbereich global ist, sind diese Adressen als Quelladresse für die Kommunikation mit jeder anderen globalen Adresse gültig, selbst wenn es unmöglich ist, Pakete vom Ziel zurück zum Quelladressen weiterzuleiten.

Anycast

Anycast -Adressen sind syntaktisch identisch mit Unicast-Adressen und von diesen nicht zu unterscheiden. Der einzige Unterschied liegt in der Administration. Daher sind die Gültigkeitsbereiche für Anycast-Adressen dieselben wie für Unicast-Adressen.

Multicast

Bei Multicast -Adressen identifizieren die vier niedrigstwertigen Bits des zweiten Adressoktetts ( ff0 s : :) den Adressbereich , d. h. die Domäne, in der das Multicast-Paket weitergeleitet werden soll. Vordefinierte und reservierte Bereiche sind:

Bereichswerte [ 1 ] : 2.7
Wert Bereichsname Anmerkungen
0x0reserviert
0x1SchnittstellenlokalDer Interface-lokale Gültigkeitsbereich erstreckt sich nur über eine einzige Schnittstelle eines Knotens und ist nur für die Loopback-Übertragung von Multicast nützlich.
0x2Link-lokalDer Link-lokale Gültigkeitsbereich umfasst die gleiche topologische Region wie der entsprechende Unicast-Gültigkeitsbereich.
0x3realm-lokalDer Realm-lokale Bereich ist größer als der Link-lokale Bereich, wird automatisch durch die Netzwerktopologie bestimmt und darf die folgenden Bereiche nicht überschreiten. [ 15 ]
0x4admin-lokalDer Admin-lokale Bereich ist der kleinste Bereich, der administrativ konfiguriert werden muss, d.h. er kann nicht automatisch aus der physischen Konnektivität oder anderen, nicht mit Multicast zusammenhängenden Konfigurationen abgeleitet werden.
0x5StandortlokalDer standortbezogene Geltungsbereich ist auf einen einzelnen Standort innerhalb einer Organisation beschränkt.
0x8Organisation-lokalDer organisationsinterne Geltungsbereich umfasst alle Standorte, die zu einer einzelnen Organisation gehören.
0xeglobalDer globale Geltungsbereich umfasst alle erreichbaren Knoten im Internet – er ist grenzenlos.
0xfreserviert

Alle anderen Bereiche sind nicht zugewiesen und stehen Administratoren zur Verfügung, um zusätzliche Regionen zu definieren.

Adressraum

Allgemeine Zuteilung

Die Verwaltung des IPv6-Adressvergabeprozesses wurde vom Internet Architecture Board und der Internet Engineering Steering Group an die Internet Assigned Numbers Authority (IANA) [ 16 ] delegiert . Ihre Hauptaufgabe ist die Zuweisung großer Adressblöcke an die regionalen Internet-Registrierungsstellen (RIRs), die diese wiederum an Netzwerkdienstanbieter und andere lokale Registrierungsstellen weiterleiten . Die IANA führt seit Dezember 1995 die offizielle Liste der IPv6-Adresszuweisungen. [ 17 ]

Um eine effiziente Routenaggregation zu ermöglichen und dadurch die Größe der Internet-Routingtabellen zu reduzieren, ist derzeit nur ein Achtel des gesamten Adressraums ( 2000:: / 3 ) für die Nutzung im Internet reserviert . Der restliche IPv6-Adressraum ist für zukünftige Verwendung oder spezielle Zwecke vorgesehen. Der Adressraum wird den RIRs in Blöcken von / 23 bis / 12 zugewiesen . [ 18 ]

Die RIRs weisen lokalen Internet-Registries kleinere Adressblöcke zu , die diese an die Nutzer verteilen. Diese Blöcke haben typischerweise eine Größe von / 19 bis / 32 . [ 19 ] [ 20 ] [ 21 ] Globale Unicast-Zuweisungsdatensätze sind bei den verschiedenen RIRs oder auf anderen Websites zu finden. [ 22 ]

Die Adressen werden dann typischerweise in Blöcken der Größe / 48 bis / 56 an die Endnutzer verteilt. [ 23 ] IPv6-Adressen werden Organisationen in deutlich größeren Blöcken zugewiesen als IPv4-Adressen – die empfohlene Zuweisung ist ein / 48 -Block, der 2 <sup>80 </sup> Adressen enthält , also 2 <sup>48 </sup> oder etwa2,8 × 10 <sup> 14 </sup>-mal größer als der gesamte IPv4-Adressraum von 2<sup> 32 </sup> Adressen und etwaDer Pool ist 7,2 × 10 <sup>16 </sup>-mal größer als die / 8 -Blöcke von IPv4-Adressen, die die größten Zuteilungen von IPv4-Adressen darstellen. Der Gesamtpool ist jedoch für absehbare Zeit ausreichend, da er 2 <sup>128</sup> (genau 340.282.366.920.938.463.463.374.607.431.768.211.456) umfasst.3,4 × 10 38 oder 340 Undezillionen ) eindeutige IPv6-Adressen.

Jedes RIR kann seine verschiedenen / 23 -Blöcke in 512 / 32 -Blöcke unterteilen, typischerweise einen für jeden ISP; ein ISP kann seinen / 32- Block in 65.536 / 48 - Blöcke unterteilen, typischerweise einen für jeden Kunden; [ 24 ] Kunden können aus ihrem zugewiesenen / 48- Block 65.536 /64 Netzwerke erstellen, von denen jedes 2³64 ( genau 18.446.744.073.709.551.616 ; oder etwa 18.446.744.073.709.551.616) umfasst .1,8 × 10¹⁹ Adressen. Im Gegensatz dazu umfasst der gesamte IPv4 - Adressraum nur 2³² ( genau 4.294.967.296; oder etwa4,3 × 10 9 ) Adressen.

Systembedingt wird nur ein kleiner Teil des Adressraums aktiv genutzt. Der große Adressraum gewährleistet, dass Adressen nahezu immer verfügbar sind, wodurch der Einsatz von Network Address Translation (NAT) zur Adresseinsparung überflüssig wird. NAT wird jedoch zunehmend für IPv4-Netzwerke verwendet, um die IPv4-Adressknappheit zu verringern .

Sonderzuweisung

Providerunabhängige Adressräume werden von den RIRs direkt dem Endbenutzer aus dem speziellen Bereich ( 2001:678:: / 29 für Zuweisungsempfänger in der RIPE NCC-Serviceregion) zugewiesen und ermöglichen es den Kunden, Providerwechsel vorzunehmen, ohne ihre Netze neu nummerieren zu müssen.

Internet-Knoten (IXPs) erhalten spezielle Adressen aus den Bereichen 2001:7f8:: / 32 , 2001:504:: / 30 , und 2001:7fa:: / 32 [ 25 ] zur Kommunikation mit ihren angeschlossenen ISPs .

Den Root-Nameservern wurden größtenteils Adressen aus den Bereichen 2001:500:: / 30 und 2001:7f8:: / 29 zugewiesen . [ 26 ]

Reservierte Anycast-Adressen

Die niedrigste Adresse innerhalb jedes Subnetzpräfixes (die Schnittstellenkennung ist auf Nullen gesetzt) ​​ist als Anycast-Adresse des Subnetz-Routers reserviert. [ 1 ] Anwendungen können diese Adresse für die Kommunikation mit einem beliebigen verfügbaren Router verwenden, da Pakete, die an diese Adresse gesendet werden, genau an diesen Router zugestellt werden.

Die 128 höchsten Adressen innerhalb jedes / 64- Subnetzpräfixes sind für die Verwendung als Anycast-Adressen reserviert. [ 27 ] Bei diesen Adressen sind üblicherweise die ersten 57 Bits der Schnittstellenkennung auf 1 gesetzt, gefolgt von der 7-Bit-Anycast-ID. Netzwerkpräfixe können für Routingzwecke beliebig lang sein, Subnetze müssen jedoch 64 Bit lang sein. Die Adresse mit dem Wert 0x7e in den 7 niedrigstwertigen Bits ist als Anycast-Adresse für mobile IPv6- Home-Agents definiert. Die Adresse mit dem Wert 0x7f (alle Bits 1) ist reserviert und darf nicht verwendet werden. Da keine weiteren Zuweisungen aus diesem Bereich vorgenommen wurden, sind auch alle verbleibenden Werte von 0x00 bis 0x7d reserviert.

Spezielle Adressen

Es gibt eine Reihe von Adressen mit besonderer Bedeutung in IPv6. [ 28 ] Die IANA führt ein Register dieser Spezialadressen. [ 29 ] Sie machen weniger als 2 % des gesamten Adressraums aus:

Spezielle Adressblöcke
Adressblock ( CIDR ) Erste Adresse Letzte Adresse Anzahl der Adressen Verwendung Zweck
::/128 :: :: 1 Software Nicht angegebene Adresse
::1/128 ::1 ::1 1 Gastgeber Loopback-Adresse – eine virtuelle Schnittstelle, die den gesamten Datenverkehr zurück zum lokalen Host leitet.
::ffff:0:0/96 ::ffff:0.0.0.0 ::ffff:0:0 ::ffff:255.255.255.255 ::ffff:ffff:ffff 2 32Software IPv4-zugeordnete Adressen
64:ff9b::/96 64:ff9b::0.0.0.0 64:ff9b::0:0 64:ff9b::255.255.255.255 64:ff9b::ffff:ffff 2 32Das globale Internet NAT64 IPv4/IPv6-Übersetzung [ 30 ]
64:ff9b:1::/48 64:ff9b:1:: 64:ff9b:1:ffff:ffff:ffff:ffff:ffff 2 80 , wobei 2 48 für jede IPv4-Adresse gilt Private Internets Lokale IPv4/IPv6-Übersetzung [ 31 ]
100::/64 100:: 100::ffff:ffff:ffff:ffff 2 64Routing Präfix verwerfen [ 32 ]
2001::/32 2001:: 2001:0:ffff:ffff:ffff:ffff:ffff:ffff 2 96Das globale Internet Teredo-Tunnelbau [ 33 ]
2001:20::/28 2001:20:: 2001:2f:ffff:ffff:ffff:ffff:ffff:ffff 2 100Software ORCHIDv2 [ 34 ]
2001:db8::/32 2001:db8:: 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff 2 96Dokumentation Adressen, die in der Dokumentation und im Beispielquellcode verwendet werden [ 35 ]
2002::/16 2002:: 2002:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2 112Das globale Internet Das 6to4- Adressierungsschema
3fff::/20 3fff:: 3fff:0fff:ffff:ffff:ffff:ffff:ffff:ffff 2 108Dokumentation Adressen, die in der Dokumentation und im Beispielquellcode verwendet werden [ 36 ]
5f00::/16 5f00:: 5f00:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2 112Routing IPv6 Segment Routing (SRv6) [ 37 ]
fc00::/7 fc00:: fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2 121Private Internets Die eindeutige lokale Adresse (Hinweis: Das L-Bit gleich 0 ist reserviert, daher ist die erste Adresse derzeit fd00::, für 2 <sup>120 </sup> Adressen) [ 38 ]
fe80::/64 von fe80::/10 fe80:: fe80::ffff:ffff:ffff:ffff 2 64Link Linklokale Adresse
ff00::/8 ff00:: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2 120Das globale Internet Multicast-Adresse

Früher wurde ::ffff: 0 :0.0.0.0 / 96 ( ::ffff: 0 :0:0 / 96 ) für die IPv4/IPv6-Übersetzung in Betracht gezogen, [ 39 ] aber es ist nicht mehr reserviert. [ 40 ] [ 30 ]

Unicast-Adressen

Nicht angegebene Adresse

  • :: / 128  – Die Adresse mit lauter Nullen wird alsnicht spezifizierte Adresse(entspricht 0.0.0.0 / 32 in IPv4). Diese Adresse darf niemals einer Schnittstelle zugewiesen werden und darf nur in Software verwendet werden, bevor die Anwendung die für die anstehende Verbindung geeignete Quelladresse des Hosts ermittelt hat. Router dürfen keine Pakete mit der nicht spezifizierten Adresse weiterleiten.

Anwendungen können auf einer oder mehreren spezifischen Schnittstellen auf eingehende Verbindungen warten. Diese werden in Listen aktiver Internetverbindungen durch eine bestimmte IP-Adresse (und eine durch einen Doppelpunkt getrennte Portnummer) angezeigt. Wird eine nicht spezifizierte Adresse angezeigt, bedeutet dies, dass die Anwendung auf allen verfügbaren Schnittstellen auf eingehende Verbindungen wartet.

Bei der Konfiguration einer Routingtabelle kann die nicht spezifizierte Adresse verwendet werden, um die Standardroutenadresse (entsprechend 0.0.0.0 / 0 in IPv4) für Zieladressen (Unicast, Multicast und andere) darzustellen, die an anderer Stelle in einer Routingtabelle nicht angegeben sind.

Lokale Adressen

  • :: 1/128  – Die Loopback -Adresse ist eine Unicast-Localhost-Adresse. Diese Adresse entspricht 127.0.0.1/8 in IPv4. Wenn eine Anwendung auf einem Host Pakete an diese Adresse sendet, leitet der IPv6 - Stack diese Pakete über dieselbe virtuelle Schnittstelle zurück.
  • fe80:: / 10  – Adressen im Link-Local-Präfix sind nur im lokalen Subnetz gültig und eindeutig. Dieser Adressbereich ist vergleichbar mit den Auto-Konfigurationsadressen 169.254.0.0/16 von IPv4.Innerhalb dieses Präfixes ist nur ein / 64 - Subnetz reserviert (54 Bits sind Nullen), was das effektive Format fe80:: / 64 ergibt . Die 64 niedrigstwertigen Bits wurden zuvor als Hardwareadresse der Schnittstelle immodifizierten EUI-64-Format verwendet, sind nun aber aus Datenschutzgründen pseudozufällige Werte. Jede IPv6-fähige Schnittstelle benötigt eineLink-Local-Adresse, und Anwendungen können auch ohne IPv6-Routing auf deren Vorhandensein angewiesen sein.

Einzigartige lokale Adressen

  • fc00:: / 7 –Unique Local Addresses ( ULAs) sind für dielokale Kommunikation vorgesehen [ 38 ] (vergleichbar mitdenprivaten IPv4-Adressen 10.0.0.0/8 , 172.16.0.0/12 und 192.168.0.0/16 ) .Sie sind nur innerhalb einer Gruppe kooperierender Standorte routingfähig. Der Block ist in zwei Hälften unterteilt. Die untere Hälfte ( fc00:: / 8 ) war für global zugewiesene Präfixe vorgesehen, jedoch ist die Zuweisungsmethode noch nicht definiert. Die obere Hälfte ( fd00 :: / 8 ) wird für probabilistisch eindeutigeverwendet,bei denen das / 8- Präfix mit einer lokal generierten 40-Bit-Pseudozufallszahl kombiniert wird,umeinprivates / 48- Präfix zu erhalten. Das Verfahren zur Auswahl einer 40-Bit-Zahl führt dazu, dass die Wahrscheinlichkeit, dass zwei Standorte, die fusionieren oder kommunizieren möchten, auf Adresskollisionen stoßen, aber dasselbe / 48- Präfix verwenden können, vernachlässigbar gering ist. [ 38 ]

Übergang von IPv4

  • ::ffff:0:0 / 96 – Dieses Präfix wird für IPv6-Übergangsmechanismenverwendetund alsIPv4-zugeordnete IPv6-Adresse.Mit wenigen Ausnahmen ermöglicht dieser Adresstyp die transparente Nutzung derTransportprotokolleüber IPv4 mithilfe der IPv6-Programmierschnittstelle (API). In dieserDual-Stack-Konfiguration müssen Serveranwendungen nur einen einzigen Listening-Socket, um Verbindungen von Clients mit IPv6- oder IPv4-Protokollen zu verarbeiten. IPv6-Clients werden standardmäßig nativ behandelt, und IPv4-Clients erscheinen unter ihrer IPv4-zugeordneten IPv6-Adresse als IPv6-Clients. Die Übertragung erfolgt analog: Ausgeführte Sockets können zur Übertragung von IPv4- oder IPv6-Datagrammen, je nachdem, ob sie an eine IPv6-Adresse oder eine IPv4-zugeordnete Adresse gebunden sind.
  • ::ffff:0:0:0 / 96 — Ein Präfix, das fürIPv4-übersetzte Adressen. Diese werden vomStateless IP/ICMP Translation (SIIT)-Protokoll verwendet. [ 40 ]
  • 64:ff9b:: / 96 — Dasbekannte Präfix. Adressen mit diesem Präfix werden für die automatische IPv4/IPv6-Übersetzung verwendet. [ 30 ]
  • 64:ff9b:1:: / 48 – Ein Präfix für lokal übersetzte IPv4/IPv6-Adressen. Adressen mit diesem Präfix können für verschiedene IPv4/IPv6-Übersetzungsmechanismen wieNAT64undSIIT. [ 31 ] Im Vergleich zu 64:ff9b:: / 96 enthalten diese Adressen ihre übersetzte IPv4-Adresse an den Positionen 48–63 und 72–87. [ 30 ] Das bedeutet, dass jedem Gerät für jede IPv4-Adresse ein / 88- IPv6-Präfix zugewiesen wird. Dies ermöglicht ähnliche Anwendungsfälle wie bei 6to4, wo eine einzelne öffentliche IPv4-Adresse in ein Präfix übersetzt wird. Dadurch ist nur eine NAT-Ebene erforderlich, und die Geräte müssen intern kein NAT66 durchführen, wenn sie zusätzliche Adressen benötigen, z. B. fürP2P-Schnittstellen oderDocker-Container.
  • 2002:: / 16 – Dieses Präfix wurde für die 6to4verwendet(das Präfix aus dem IPv4-Netzwerk, 192.88.99.0 / 24 , wurde ebenfalls verwendet).Das 6to4-Adressierungsschema ist veraltet. [ 41 ]

Adressen für spezielle Zwecke

Die IANA hat einen sogenannten Sub-TLA-ID- Adressblock für spezielle Zuweisungen [ 28 ] [ 42 ] des Bereichs 2001:: / 23 reserviert (aufgeteilt in den Bereich der 64 Netzwerkpräfixe 2001:0000:: / 29 bis 2001:01f8:: / 29 ). Folgende Zuweisungen aus diesem Block existieren derzeit: [ 29 ]

  • 2001:: / 32 — Wird fürTeredo-Tunneling, einemIPv6-Übergangsmechanismus.
  • 2001:1::1 / 128 — Port Control Protocol Anycast
  • 2001:1::2 / 128 — Traversal Using Relays around NAT Anycast
  • 2001:1::3 / 128 — DNS-SD-Dienstregistrierungsprotokoll Anycast
  • 2001:2:: / 48 – Wird fürBenchmarking. Entspricht 198.18.0.0 / 15 , das für IPv4-Benchmarking verwendet wurde. Zugewiesen an die Benchmarking Methodology Working Group (BMWG). [ 43 ]
  • 2001:3:: / 32 — Automatisches Multicast-Tunneling, Relay-Erkennung
  • 2001:20:: / 28 — Overlay Routable Cryptographic Hash Identifiers (ORCHIDv2). [ 34 ] Dies sind nicht geroutete IPv6-Adressen, die fürkryptografische Hashes.
  • 2001:30:: / 28 — Präfix für Entity Tags (DETs) des Drone Remote ID Protocol

Darüber hinaus hat die IANA die folgenden beiden IPv6-Präfixe für den AS112 -Nameserverbetrieb reserviert:

  • 2620:4f:8000:: / 48 — Blackhole-Server mit den traditionellen autoritativen Zonen konfiguriert
  • 2001:4:112:: / 48 — Blackhole-Server für den neuen Blackholing-Ansatz mit DNAME-Einträgen anempty.as112.arpa [ 44 ]

Dokumentation

  • 2001:db8:: / 32 — Dieses Präfix wird in der Dokumentation verwendet, [ 35 ] [ f ] überall dort, wo eine Beispiel-IPv6-Adresse angegeben oder Modellnetzwerkszenarien beschrieben werden.
  • 3fff:: / 20 — Dieses Dokumentationspräfix wurde 2024 vergeben, um der modernen, großflächigen Netzwerkmodellierung Rechnung zu tragen, die nicht durch ein einzelnes / 32- Präfix abgedeckt werden kann. [ 36 ]

Verwerfen

  • 100:: / 64 — Dieses Präfix wird zum Verwerfen von Datenverkehr verwendet. [ 32 ]

Veraltet und überholt

Siehe § Veraltete und überholte Adressen

Multicast-Adressen

Die Multicast-Adressen ff0x:: , wobei x ein beliebiger Hexadezimalwert ist, sind reserviert [ 1 ] und werden von der Internet Assigned Numbers Authority (IANA) verwaltet. [ 46 ]

Gängige IPv6-Multicast-Adressen
Adresse Beschreibung Verfügbare Zielfernrohre
ff0x::1Alle Knotenadressen, identifizieren die Gruppe aller IPv6-Knoten. Verfügbar in Bereich 1 (schnittstellenlokal) und 2 (verbindungslokal):
  • ff01::1 → Alle Knoten im Schnittstellenlokal
  • ff02::1 → Alle Knoten im Link-Local
ff0x::2Alle Router Verfügbar in den Bereichen 1 (schnittstellenlokal), 2 (verbindungslokal) und 5 (standortlokal):
  • ff01::2 → Alle Router im Interface-lokalen Netzwerk
  • ff02::2 → Alle Router im Link-Local-Netzwerk
  • ff05::2 → Alle Router im lokalen Netzwerk
ff02::5OSPFIGP2 (link-lokal)
ff02::6OSPFIGP designierte Router 2 (link-lokal)
ff02::9RIP Router 2 (link-lokal)
ff02::aEIGRP- Router 2 (link-lokal)
ff02::cDynamische Erkennung von Webdiensten2 (link-lokal)
ff02::dAlle PIM- Router 2 (link-lokal)
ff02::1aAlle RPL- Router 2 (link-lokal)
ff02::16Alle MLDv2 -fähigen Router 2 (link-lokal)
ff0x::fbmDNSv6In allen Zielfernrohren erhältlich
ff0x::101Alle NTP- Server In allen Zielfernrohren erhältlich
ff02::1:1Linkname 2 (link-lokal)
ff02::1:2Alle DHCPv6- Server und Relay-Agenten [ 47 ]2 (link-lokal)
ff02::1:3Link-lokale Multicast-Namensauflösung 2 (link-lokal)
ff05::1:3Ein Relay-Agent kann diese Adresse verwenden, um alle DHCPv6- Server im Standort zu erreichen. [ 47 ]5 (standortspezifisch)
ff02::1:ff00:0/104Angeforderte Multicast-Adresse des Knotens (siehe unten) 2 (link-lokal)
ff02::2:ff00:0/104Knoteninformationsabfragen 2 (link-lokal)

Angeforderte Multicast-Adresse des Knotens

Die 24 niedrigstwertigen Bits der Multicast-Adressgruppen -ID des angeforderten Knotens werden mit den 24 niedrigstwertigen Bits der Unicast- oder Anycast-Adresse der Schnittstelle belegt. Diese Adressen ermöglichen die Adressauflösung auf der Sicherungsschicht über das Neighbor Discovery Protocol (NDP), ohne alle Knoten im lokalen Netzwerk zu beeinträchtigen. Ein Host muss für jede seiner konfigurierten Unicast- oder Anycast-Adressen einer Multicast-Gruppe des angeforderten Knotens beitreten.

Stateless Address Autoconfiguration (SLAAC)

Beim Systemstart erstellt ein Knoten automatisch eine Link-Local-Adresse auf jeder IPv6-fähigen Schnittstelle, selbst wenn global routbare Adressen manuell konfiguriert oder über Konfigurationsprotokolle bezogen wurden (siehe unten). Dies geschieht selbstständig und ohne vorherige Konfiguration mittels zustandsloser Adressautokonfiguration ( SLAAC ) [ 48 ] unter Verwendung einer Komponente des Neighbor Discovery Protocol . Die Adresse wird mit dem Präfix fe80:: / 64 ausgewählt .

In IPv4 werden typischerweise DHCP oder PPP konfiguriert . Neuere IPv6-Hosts können so konfiguriert werden, dass sie das Neighbor Discovery Protocol (NDP) verwenden , um eine global routbare Unicast-Adresse zu erstellen: Der Host sendet Router-Anfragen, und ein IPv6 -Router antwortet mit einer Präfixzuweisung. [ 49 ] Alternativ kann ein DHCPv6- Server verwendet werden, entweder im zustandslosen Modus, in dem der Server die erforderlichen Netzwerkparameter bereitstellt, damit die Hosts ihre eigenen globalen Adressen generieren können, oder im zustandsbehafteten Modus, in dem der Server die globalen Adressen und weitere erforderliche Parameter zuweist.

Schnittstellenkennung

Die unteren 64 Bits der fe80:: / 64- Adresse enthalten eine 64-Bit-Schnittstellenkennung. Diese kann aus folgenden Quellen abgeleitet werden:

  • Wie der Name „Schnittstellenkennung“ bereits andeutet, kann es sich dabei um die 48-Bit -MAC-Adresse des Netzwerkadapters handeln , die garantiert eindeutig ist. Eine MAC-Adresse wie 00-0C-29-0C-47-D5 wird in eine modifizierte 64-Bit -EUI-64 -Adresse umgewandelt , indem zunächst FF-FE in die Mitte eingefügt wird: 00-0C-29- FF-FE -0C-47-D5 . Anschließend wird das Universal/Local- Bit invertiert, wodurch die Adresse 02-0C -29-FF-FE-0C-47-D5 (oder :020c:29ff:fe0c:47d5 in IPv6-Adressnotation) wird.
  • Die Verwendung der tatsächlichen MAC-Adresse des Adapters zur Ableitung der Schnittstellenadresse wird in Endgeräten nicht mehr empfohlen, da dadurch die MAC-Adresse im Internet offengelegt und die netzwerkübergreifende Verfolgung des Nutzers erleichtert wird. Daher wird heutzutage üblicherweise eine Pseudozufallsadresse verwendet . Zu den verfügbaren Optionen gehören die temporäre Adresse , die stabile Datenschutzadresse und die kryptografisch generierte Adresse . Dies ist zwar mit MAC-Spoofing verwandt, aber nicht identisch ; die Pseudozufalls-Schnittstellenkennung muss nicht mit der tatsächlichen oder gefälschten MAC-Adresse übereinstimmen.

Vorübergehende Adressen

Die global eindeutigen und statischen MAC-Adressen, die von der zustandslosen Adressautokonfiguration zur Erstellung von Schnittstellenkennungen verwendet werden, bieten die Möglichkeit, Benutzergeräte über die Zeit und trotz Änderungen des IPv6-Netzwerkpräfixes zu verfolgen. [ 50 ] Um zu verhindern, dass eine Benutzeridentität dauerhaft an einen IPv6-Adressbereich gebunden wird, kann ein Knoten temporäre Adressen mit Schnittstellenkennungen erstellen, die auf zeitlich variierenden Zufallsbitfolgen basieren [ 51 ] und relativ kurze Lebensdauern (Stunden bis Tage) aufweisen. Anschließend werden diese durch neue Adressen ersetzt.

Temporäre Adressen können als Quelladressen für ausgehende Verbindungen verwendet werden, während externe Hosts eine öffentliche Adresse durch Abfrage des Domain Name System (DNS) verwenden.

Netzwerkschnittstellen, die für IPv6 konfiguriert sind, verwenden in OS X Lion und späteren Apple-Systemen sowie in Windows Vista , Windows Server 2008 und späteren Microsoft-Systemen standardmäßig temporäre Adressen . [ 52 ]

Kryptografisch erzeugte Adressen

Zur Verbesserung der Sicherheit des Neighbor Discovery Protocol wurden im Jahr 2005 kryptografisch generierte Adressen (CGAs) als Teil des Secure Neighbor Discovery (SEND)-Protokolls eingeführt [ 53 ] .

Eine solche Adresse wird mithilfe zweier Hashfunktionen generiert , die mehrere Eingaben benötigen. Die erste Funktion verwendet einen öffentlichen Schlüssel und einen Zufallsmodifikator, der so lange inkrementiert wird, bis eine bestimmte Anzahl von Nullbits im resultierenden Hashwert erreicht ist. [ g ] Die zweite Hashfunktion verwendet das Netzwerkpräfix und den vorherigen Hashwert. Die niedrigstwertigen 64 Bits des zweiten Hashwerts werden an das 64-Bit-Netzwerkpräfix angehängt, um eine 128-Bit-Adresse zu bilden.

Mithilfe der Hash-Funktionen lässt sich auch überprüfen, ob eine bestimmte IPv6-Adresse die Anforderungen an eine gültige CGA erfüllt. Auf diese Weise kann die Kommunikation ausschließlich zwischen vertrauenswürdigen Adressen eingerichtet werden.

Stabile Datenschutzadressen

Die Verwendung des modifizierten EUI-64- Formats birgt erhebliche Sicherheits- und Datenschutzrisiken [ 54 ] , da die zugrundeliegende Hardwareadresse (meist die MAC-Adresse , die standardmäßig eine organisationsspezifische Kennung (OUI) enthält, welche den Hersteller des gesamten Geräts oder des Netzwerkadapters identifiziert) über das lokale Netzwerk hinaus offengelegt wird. Dies ermöglicht die Verfolgung von Benutzeraktivitäten, die Verknüpfung von Benutzerkonten mit anderen Informationen und die gezielte Ausrichtung von Sicherheitsangriffen auf den Gerätehersteller, sofern die OUI auf den Hersteller des gesamten Geräts verweist. Zudem verringert das modifizierte EUI-64-Format den Adressraum für die Suche nach Angriffszielen.

Um diese Mängel zu beheben, wurden stabile Datenschutzadressen eingeführt. Sie sind innerhalb eines bestimmten Netzwerks stabil, ändern sich jedoch beim Wechsel in ein anderes Netzwerk, um den Datenschutz zu verbessern. Sie werden deterministisch, aber zufällig im gesamten Adressraum des Netzwerks ausgewählt.

Die Generierung einer stabilen Datenschutzadresse basiert auf einer Hash-Funktion mit mehreren stabilen Parametern. Sie ist implementierungsspezifisch, es wird jedoch empfohlen, mindestens das Netzwerkpräfix, den Namen der Netzwerkschnittstelle, einen Zähler für doppelte Adressen und einen geheimen Schlüssel einzubeziehen. Der resultierende Hashwert dient zur Konstruktion der endgültigen Adresse: Typischerweise werden die 64 niedrigstwertigen Bits an das 64-Bit-Netzwerkpräfix angehängt, um eine 128-Bit-Adresse zu erhalten. Ist das Netzwerkpräfix kürzer als 64 Bit, werden mehr Bits des Hashwerts verwendet. Sofern die resultierende Adresse nicht mit bestehenden oder reservierten Adressen kollidiert, wird sie der Schnittstelle zugewiesen. Konflikte werden durch Anpassen des Zählers für doppelte Adressen behoben. [ 54 ]

Funktionsweise des Neighbor Discovery Protocol

Angeforderte Multicast-Adresse des Knotens

Jede Schnittstelle in SLAAC verfügt außerdem über eine angeforderte Multicast-Adresse , die aus dem Netzwerkpräfix ff02::1:ff00:0 / 104 und den 24 niedrigstwertigen Bits ihrer Unicast- oder Anycast-Adresse gebildet wird. Diese Multicast -Adresse wird in NDP verwendet, um doppelte Adressen zu erkennen und die Zuordnung zwischen IP-Adressen und Link-Layer-Adressen (MAC-Adressen) herzustellen.

Erkennung doppelter Adressen

Die Verwendung nicht hardwarebasierter Adressen birgt das Risiko von Adressduplikaten. Die Zuweisung einer Unicast -IPv6-Adresse zu einer Schnittstelle beinhaltet einen internen Test auf Eindeutigkeit dieser Adresse mittels Neighbor Solicitation und Neighbor Advertisement ( ICMPv6 Typ 135 und 136). Während dieses Tests befindet sich die Adresse in einem vorläufigen Zustand.

Der Knoten tritt der Multicast -Adresse des angeforderten Knotens für die vorläufige Adresse bei und sendet Nachbaranfragen, wobei die vorläufige Adresse als Zieladresse und die nicht spezifizierte Adresse ( :: / 128 ) als Quelladresse dient. Der Knoten tritt außerdem der Multicast-Adresse aller Hosts ff02::1 bei , um Nachbarinformationen empfangen zu können .

Empfängt ein Knoten eine Nachbaranfrage mit seiner eigenen vorläufigen Adresse als Zieladresse, weiß er, dass seine Adresse nicht eindeutig ist. Dasselbe gilt, wenn der Knoten eine Nachbarankündigung mit der vorläufigen Adresse als Absenderadresse empfängt. Erst nachdem die Eindeutigkeit einer Adresse erfolgreich nachgewiesen wurde, kann sie einer Schnittstelle zugewiesen und von ihr verwendet werden.

Wird einer Schnittstelle eine Anycast -Adresse zugewiesen (z. B. eine Subnetz-Router-Anycast-Adresse), wird aufgrund der inhärenten Nicht-Eindeutigkeit dieser Adressart keine Duplikaterkennung durchgeführt.

Routerbetrieb

Im NDP-Verfahren gibt der Router neben anderen Netzwerkparametern auch bekannt, auf welches /64-Präfix er im Internet Zugriff hat. Ein Knoten, der diese Informationen empfängt, kombiniert das Präfix mit seiner eigenen Schnittstellenkennung, um seine Unicast-Adresse im Internet zu erhalten. Hat ein Router beispielsweise Zugriff auf 2001:db8:1:2:: / 64 und verfügt der Rechner über die Schnittstellenkennung 02-0C-29-FF-FE-0C-47-D5(siehe obiges Beispiel), weist sich der Rechner selbst die Adresse 2001:db8:1:2: 020c :29ff:fe0c:47d5 zu .

DHCPv6 bleibt für andere Zwecke nützlich. Beispielsweise kann es vom Router des Internetdienstanbieters verwendet werden, um dem Router des Kunden ein Präfix der Größe /64 oder kürzer zu übergeben, ein Vorgang, der als Präfixdelegierung bezeichnet wird .

Adresslebensdauer

Jede an eine Schnittstelle gebundene IPv6-Adresse hat eine definierte Lebensdauer. Diese ist standardmäßig unbegrenzt, sofern sie nicht auf einen kürzeren Zeitraum konfiguriert wird. Es gibt zwei Lebensdauern, die den Zustand einer Adresse bestimmen: die bevorzugte Lebensdauer und die gültige Lebensdauer . [ 55 ] Lebensdauern können in Routern konfiguriert werden , die die für die automatische Konfiguration verwendeten Werte bereitstellen, oder bei der manuellen Konfiguration von Adressen auf Schnittstellen angegeben werden.

Wird einer Schnittstelle eine Adresse zugewiesen, erhält sie den Status „bevorzugt“ , den sie während ihrer Gültigkeitsdauer behält. Nach Ablauf dieser Gültigkeitsdauer wird der Status auf „veraltet“ gesetzt, und es dürfen keine neuen Verbindungen mehr über diese Adresse hergestellt werden. [ h ] Die Adresse wird ungültig , sobald auch ihre Gültigkeitsdauer abgelaufen ist; sie wird von der Schnittstelle entfernt und kann an anderer Stelle im Internet neu vergeben werden .

Auswahl der Standardadresse

IPv6-fähige Netzwerkschnittstellen verfügen üblicherweise über mehrere IPv6-Adressen, beispielsweise eine Link-Local- und eine globale Adresse. Sie können auch temporäre Adressen besitzen, die sich nach Ablauf einer bestimmten Gültigkeitsdauer ändern. IPv6 führt die Konzepte des Adressbereichs und der Adressauswahl ein und bietet somit mehrere Optionen für Quell- und Zieladressen bei der Kommunikation mit einem anderen Host.

Der Algorithmus zur Präferenzauswahl wählt die am besten geeignete Adresse für die Kommunikation mit einem bestimmten Ziel aus, einschließlich der Verwendung von IPv4-zugeordneten Adressen in Dual-Stack -Implementierungen. [ 56 ] Er verwendet eine konfigurierbare Präferenztabelle, die jedem Routing-Präfix eine Prioritätsstufe zuordnet. Die Standardtabelle hat folgenden Inhalt:

Präfix Vorrang Etikett Verwendung
::1/128 50 0 Localhost
::/0 40 1 Standard-Unicast
::ffff:0:0/96 35 4 IPv4-zugeordnete IPv6-Adresse
2002::/16 30 2 6to4
2001::/32 5 5 Teredo-Tunnelbau
fc00::/7 3 13 Einzigartige lokale Adresse
::/96 1 3 IPv4-kompatible Adressen (veraltet)
fec0::/10 1 11 Standortlokale Adresse (veraltet)
3ffe::/16 1 12 6bone (zurückgegeben)

Die Standardkonfiguration priorisiert die Nutzung von IPv6 und wählt Zieladressen im kleinstmöglichen Bereich aus, sodass lokale Verbindungen gegenüber global gerouteten Pfaden bevorzugt werden, sofern diese ansonsten gleichwertig sind. Die Präfixrichtlinientabelle ähnelt einer Routingtabelle, wobei der (inverse) Prioritätswert die Funktion der Verbindungskosten übernimmt; höhere Werte führen zu einer höheren Priorität. Quelladressen sollten vorzugsweise denselben Labelwert wie die Zieladresse aufweisen. Adressen werden Präfixen anhand der längsten übereinstimmenden Sequenz höchstwertiger Bits zugeordnet. Kandidaten für Quelladressen werden vom Betriebssystem bezogen , und Kandidaten für Zieladressen können über DNS abgefragt werden.

Um die Verbindungsherstellungszeit bei mehreren verfügbaren Adressen zu minimieren, wurde der Happy-Eyeballs -Algorithmus entwickelt. Er fragt den DNS-Server nach IPv6- und IPv4-Adressen des Zielhosts ab, sortiert die Kandidatenadressen anhand der Standard-Adressauswahltabelle und versucht, parallel Verbindungen herzustellen. Die erste erfolgreiche Verbindung bricht alle aktuellen und zukünftigen Verbindungsversuche zu anderen Adressen ab.

Domain Name System

Im Domain Name System (DNS ) werden Hostnamen mithilfe von AAAA- Ressourceneinträgen, sogenannten Quad-A- Einträgen , IPv6-Adressen zugeordnet . [ 57 ] Für die umgekehrte Namensauflösung reservierte die IETF die Domain ip6.arpa , deren Namensraum hierarchisch durch die einstellige hexadezimale Darstellung der Nibble- Einheiten (4 Bit) der IPv6-Adresse unterteilt ist.

Wie bei IPv4 wird jeder Host im DNS durch zwei DNS-Einträge repräsentiert: einen Adressdatensatz und einen Reverse-Mapping-Pointer-Datensatz. Beispielsweise hat ein Host-Computer namens derrick in der Zone example.com die eindeutige lokale Adresse fdda:5cc1:23:4::1f . Sein Quad-A-Adressdatensatz lautet: 

derrick.example.com. IN AAAA fdda:5cc1:23:4::1f

und sein IPv6-Zeigerdatensatz ist 

f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.3.2.0.0.1.cc5.addfip6.arpa. IN PTR derrick.example.com.

Dieser Zeigerdatensatz kann in einer Reihe von Zonen definiert werden, abhängig von der Delegierungskette der Autorität in der Zone dfip6.arpa.

Das DNS-Protokoll ist unabhängig von seinem Transportprotokoll . Anfragen und Antworten können über IPv6- oder IPv4-Transporte übertragen werden, unabhängig von der Adressfamilie der angeforderten Daten.

AAAA-Datensatzfelder
NAMEDomainname
TYPAAAA (28)
KLASSEInternet (1)
TTLZeit zum Leben, in Sekunden
RDLENGTHLänge des RDATA-Felds
RDATA128-Bit-IPv6-Adresse in Netzwerk-Byte-Reihenfolge

Historische Anmerkungen

Veraltete und überholte Adressen

  • Das standortspezifische Präfix fec0:: / 10 legt fest, dass die Adresse nur innerhalb des Standortnetzwerks einer Organisation gültig ist. Es war Teil der ursprünglichen Adressierungsarchitektur im Dezember 1995 [ 58 ] , wurde jedoch im September 2004 aufgrund einer uneindeutigen Definition des Begriffs „ Standort“ und der daraus resultierenden Verwirrung bei den Routing-Regeln als veraltet eingestuft. Neue Netzwerke dürfen diesen speziellen Adresstyp nicht unterstützen [ 59 ] . Im Oktober 2005 wurde dieser Adresstyp durch eine neue Spezifikation mit eindeutigen lokalen Adressen ersetzt [ 38 ] .
  • Der Adressblock 200:: / 7 wurde im August 1996 als OSI NSAP-zugeordneter Präfixsatz definiert, [ 60 ] [ 61 ] wurde aber im Dezember 2004 als veraltet erklärt. [ 62 ]
  • Das 96-Bit-Nullwertpräfix :: / 96 , ursprünglich als IPv4-kompatible Adresse bekannt , wurde 1995 erwähnt [ 58 ] , aber nie vollständig beschrieben. Dieser Adressbereich wurde verwendet, um IPv4- Adressen innerhalb einer IPv6-Übergangstechnologie darzustellen. Bei einer solchen IPv6-Adresse sind die ersten (höchstwertigen) 96 Bit auf Null gesetzt, während die letzten 32 Bit die eigentliche IPv4-Adresse darstellen. Im Februar 2006 erklärte die IETF die Verwendung von IPv4-kompatiblen Adressen für veraltet. [ 1 ] Die einzige verbleibende Verwendung dieses Adressformats besteht darin, eine IPv4-Adresse in einer Tabelle oder Datenbank mit festen Elementgrößen darzustellen, die auch eine IPv6-Adresse speichern können muss.
  • Der Adressblock 3ffe:: / 16 wurde im Dezember 1998 zu Testzwecken für das 6bone -Netzwerk reserviert. [ 63 ] Zuvor wurde der Adressblock 5f00:: / 8 für diesen Zweck verwendet. Beide Adressblöcke wurden im Juni 2006 wieder dem Adresspool zugeführt. [ 64 ]
  • Aufgrund von Betriebsproblemen mit 6to4 nimmt die Nutzung des Adressblocks 2002:: / 16 ab, da der 6to4-Mechanismus seit Mai 2015 veraltet ist . [ 41 ] Obwohl der IPv4-Adressblock 192.88.99.0/24 veraltet ist, gilt dies nicht für 2002:: / 16 .
  • Im April 2007 wurde der Adressblock 2001:10:: / 28 für Overlay Routable Cryptographic Hash Identifiers (ORCHID) zugewiesen. [ 65 ] Er war für experimentelle Zwecke vorgesehen. Im September 2014 wurde eine zweite Version von ORCHID spezifiziert [ 34 ] , und mit der Einführung des Blocks 2001:20:: / 28 wurde der ursprüngliche Block an die IANA zurückgegeben .

Verschiedenes

  • Für die umgekehrte DNS-Auflösung wurden IPv6-Adressen ursprünglich in der DNS-Zone ip6.int registriert , da man davon ausging, dass die Top-Level-Domain arpa eingestellt werden würde. Im Jahr 2000 revidierte das Internet Architecture Board (IAB) diese Absicht und entschied 2001, dass arpa seine ursprüngliche Funktion behalten sollte. Die Domains in ip6.int wurden nach ip6.arpa verschoben [ 66 ] , und die Zone ip6.int wurde am 6. Juni 2006 offiziell aufgelöst.
  • Im März 2011 präzisierte die IETF ihre Empfehlungen zur Zuweisung von Adressblöcken an Endnutzer. [ 23 ] Anstatt wie bisher / 48 , / 64 oder / 128 zuzuweisen (gemäß den Ansichten von IAB und IESG aus dem Jahr 2001), [ 67 ] sollten Internetdienstanbieter die Zuweisung kleinerer Blöcke (z. B. / 56 ) in Betracht ziehen. Die Richtlinien der regionalen Registrierungsstellen ARIN , RIPE und APNIC befürworten die Zuweisung von / 56- Blöcken, wo dies angebracht ist. [ 23 ]
  • Ursprünglich gab es zwei Vorschläge zur Übersetzung von Domainnamen in IPv6-Adressen: einen mit AAAA-Einträgen [ 68 ] und einen mit A6-Einträgen [ 69 ] . Die sich durchsetzende Methode mit AAAA-Einträgen ist vergleichbar mit den A-Einträgen für IPv4 und ermöglicht eine einfache Zuordnung von Hostnamen zu IPv6-Adressen. Die Methode mit A6-Einträgen verwendete ein hierarchisches Schema, bei dem die Zuordnung aufeinanderfolgender Gruppen von Adressbits durch zusätzliche A6-Einträge spezifiziert wurde. Dadurch war es möglich, alle Hosts in einem Netzwerk durch die Änderung eines einzigen A6-Eintrags neu zu nummerieren. Da die wahrgenommenen Vorteile des A6-Formats die wahrgenommenen Nachteile nicht aufwogen [ 70 ] [ 71 ] [ 72 ] [ 73 ], wurde die Methode 2002 in den experimentellen Status versetzt [ 71 ] und schließlich 2012 endgültig als veraltet eingestuft [ 73 ] .
  • Im Jahr 2009 wurde festgestellt, dass viele DNS-Resolver in Heimnetzwerk-NAT-Geräten und Routern AAAA-Einträge fehlerhaft verarbeiteten. [ 74 ] Einige dieser Resolver verwarfen DNS-Anfragen für solche Einträge einfach, anstatt die entsprechende negative DNS-Antwort zurückzugeben. Da die Anfrage verworfen wird, muss der sendende Host auf ein Timeout warten, was zu erhöhter Latenz beim Verbinden mit Dual-Stack-IPv6/IPv4-Hosts führt, da die Client-Software das Timeout für das Fehlschlagen der IPv6-Verbindung abwartet, bevor sie versucht, eine IPv4-Verbindung herzustellen. Happy Eyeballs bietet eine Lösung für dieses Problem.

Anmerkungen

  1. ^ Bitanzahl beginnend mit 0
  2. Eine 16-Bit- oder Zwei- Oktett- Größe wird manchmal auch als Hexett bezeichnet . [ 7 ] [ 8 ]
  3. ^ Unter der Annahme, dass eth2 der Zonennummer 3 entspricht. Dies ist üblicherweise der Fall, da die tatsächlichen Zonennummern bei 1 beginnen (0 ist die „Standardzone“).
  4. ^ Obwohl Windows die RFC 3493if_nametoindex()API zur Umwandlung eines Namens in eine Schnittstellennummer unterstützt, unterstützt es nicht die übliche Erweiterung "Name nach %".
  5. ^ Die inzwischen entfernten standortbezogenen Adressen von fec0::/10 benötigen ebenfalls einen Zonenindex. [ 12 ]
  6. ^ 192.0.2.0/24 , 198.51.100.0/24 und 203.0.113.0/24 werden für die Dokumentation in IPv4 verwendet . [ 45 ]
  7. ^ Vergleichbar mit dem „Proof-of-Work“-Bereich beim Bitcoin- Mining.
  8. In den meisten Fällen läuft die Gültigkeitsdauer nicht ab, da neue Router Advertisements (RAs) die Timer aktualisieren. Wenn jedoch keine RAs mehr vorhanden sind, läuft die bevorzugte Gültigkeitsdauer schließlich ab und die Adresse wird als veraltet markiert .

Referenzen

  1. ^ a b c d e f g h R. Hinden; S. Deering (Februar 2006). IP Version 6 Addressing Architecture . Network Working Group. doi : 10.17487/RFC4291 . RFC 4291 .Entwurf eines Standards. Ersetzt RFC  3513. Aktualisiert durch RFC  5952 , 6052 , 7136 , 7346 , 7371 und 8064 .
  2. ^ F. Gont; A. Cooper; D. Thaler; W. Liu (Februar 2017). Empfehlung zu stabilen IPv6-Schnittstellenkennungen . Internet Engineering Task Force . doi : 10.17487/RFC8064 . RFC 8064 .Vorgeschlagener Standard. Aktualisiert RFC  2464 , 2467 , 2470 , 2491 , 2492 , 2497 , 2590 , 3146 , 3572 , 4291 , 4338 , 4391 , 5072 und 5121 .
  3. ^ Silvia Hagen (Mai 2006). IPv6 Essentials (Zweite Ausgabe). O'Reilly. ISBN 978-0-596-10058-2Die
  4. ^ a b P. Savola; B. Haberman (November 2004). Einbettung der Rendezvous-Point-Adresse (RP-Adresse) in eine IPv6-Multicast-Adresse . Network Working Group. doi : 10.17487/RFC3956 . RFC 3956 .Vorgeschlagener Standard. Aktualisiert durch RFC  7371. Aktualisiert RFC  3306 .
  5. ^ a b B. Haberman; D. Thaler (August 2002). Unicast-Prefix–based IPv6 Multicast Addresses . Network Working Group. doi : 10.17487/RFC3306 . RFC 3306 .Vorgeschlagener Standard. Aktualisiert durch RFC  3956 , 4489 und 7371 .
  6. ^ JS. Park; MK. Shin; HJ. Kim (April 2006). Eine Methode zur Generierung von Link-Scoped IPv6 Multicast Addresses . Network Working Group. doi : 10.17487/RFC4489 . RFC 4489 .Vorgeschlagener Standard. Aktualisiert RFC  3306 .
  7. ^ Graziani, Rick (2012). IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6 . Cisco Press . S. 55. ISBN 978-0-13-303347-2Die
  8. ^ Coffeen, Tom (2014). IPv6 Address Planning: Designing an Address Plan for the Future . O'Reilly Media . S. 170. ISBN 978-1-4919-0326-1Die
  9. ^ S. Kawamura; M. Kawashima (August 2010). Eine Empfehlung zur Textdarstellung von IPv6-Adressen . Internet Engineering Task Force . doi : 10.17487/RFC5952 . ISSN 2070-1721 . RFC 5952 . Vorgeschlagener Standard. Aktualisiert RFC  4291 .
  10. ^ T. Berners-Lee ; R. Fielding ; L. Masinter (Januar 2005). Uniform Resource Identifier (URI): Generic Syntax . Network Working Group. doi : 10.17487/RFC3986 . STD 66. RFC 3986 .Internetstandard 66. Ersetzt RFC  2732 , 2396 und 1808. Aktualisiert durch RFC  6874 , 7320 und 8820. Aktualisiert RFC  1738 .
  11. ^ a b S. Deering ; B. Haberman; T. Jinmei; E. Nordmark; B. Zill (März 2005). IPv6 Scoped Address Architecture . Network Working Group. doi : 10.17487/RFC4007 . RFC 4007 .Vorgeschlagener Standard. Aktualisiert durch RFC  7346 .
  12. ^ a binet6(4)  –  FreeBSD Kernel Interfaces Manual „Die KAME-Implementierung unterstützt eine erweiterte numerische IPv6-Adressnotation für Link-Local-Adressen, wie z. B. „fe80::1%de0“ [...] draft-ietf-ipngwg-scopedaddr-format-02.txt“
  13. ^ B. Carpenter ; S. Cheshire ; R. Hinden (Februar 2013). Darstellung von IPv6-Zonenbezeichnern in Adressliteralen und Uniform Resource Identifiers . Internet Engineering Task Force . doi : 10.17487/RFC6874 . ISSN 2070-1721 . RFC 6874 . Vorgeschlagener Standard. Aktualisiert RFC  3986 .
  14. ^ "ipv6-literal.net Domain History" . who.is. Archiviert vom Original am 19. Januar 2025 . Abgerufen am 20. Oktober 2014 .
  15. ^ R. Droms (August 2014). IPv6 Multicast Address Scopes . Internet Engineering Task Force . doi : 10.17487/RFC7346 . ISSN 2070-1721 . RFC 7346 . Vorgeschlagener Standard. Aktualisiert RFC  4007 und 4291 .
  16. ^ Internet Architecture Board ; Internet Engineering Steering Group (Dezember 1995). IPv6 Address Allocation Management . Network Working Group. doi : 10.17487/RFC1881 . RFC 1881 .Informativ.
  17. ^ IPv6-Adressraum bei der IANA . Iana.org (29.10.2010). Abgerufen am 28.09.2011.
  18. ^ IPv6-Unicast-Adresszuweisungen , IANA
  19. ^ DE-TELEKOM-20050113 db.ripe.net. Abgerufen am 28.09.2011.
  20. ^ "ARIN Number Resource Policy Manual: Initial allocation to ISPs" .
  21. ^ „RIPE NCC IPv6-Adresszuweisungs- und -vergaberichtlinie: Mindestzuweisung“ .
  22. ^ zum Beispiel . Iana.org. Abgerufen am 28.09.2011.
  23. ^ a b c T. Narten; G. Huston; L. Roberts (März 2011). IPv6 Address Assignment to End Sites . Internet Engineering Task Force . doi : 10.17487/RFC6177 . ISSN 2070-1721 . BCP 157. RFC 6177 . Best Current Practice 157. Ersetzt RFC  3177 .
  24. ^ „IPv6-Adressierungspläne“ . ARIN IPv6 Wiki . Abgerufen am 15.07.2018 . Alle Kunden erhalten ein / 48- Subnetz, es sei denn, sie können nachweisen, dass sie mehr als 65.000 Subnetze benötigen. [...] Wenn Sie viele Privatkunden haben, sollten Sie / 56 -Subnetze für private Wohngebäude zuweisen .
  25. ^ „Was sind Bogons?“ . Abgerufen am 15.11.2021 .
  26. ^ „Vom RIPE NCC verwalteter Adressraum“ . Abgerufen am 22.05.2011 .
  27. ^ D. Johnson; S. Deering (März 1999). Reservierte IPv6-Subnetz-Anycast-Adressen . Network Working Group. doi : 10.17487/RFC2526 . RFC 2526 .Vorgeschlagener Standard.
  28. ^ a b M. Cotton; L. Vegoda; B. Haberman (April 2013). R. Bonica (Hrsg.). Special-Purpose IP Address Registries . Internet Engineering Task Force . doi : 10.17487/RFC6890 . ISSN 2070-1721 . BCP 153. RFC 6890 . Best Current Practice 153. Ersetzt RFC  4773 , 5156 , 5735 und 5736. Aktualisiert durch RFC  8190 .
  29. ^ a b „IPv6 Special-Purpose Address Space“ . www.iana.org . IANA . Abgerufen am 21.06.2026 .
  30. C. Bao ; C. Huitema ; M. Bagnulo; M. Boucadair; X. Li (Oktober 2010). IPv6 Addressing of IPv4/IPv6 Translators . Internet Engineering Task Force . doi : 10.17487/RFC6052 . ISSN 2070-1721 . RFC 6052 . Vorgeschlagener Standard. Aktualisiert RFC  4291 .
  31. ^ a b T. Anderson (August 2017). Local-Use IPv4/IPv6 Translation Prefix . Internet Engineering Task Force . doi : 10.17487/RFC8215 . RFC 8215 .Vorgeschlagener Standard.
  32. ^ a b N. Hilliard; D. Freedman (August 2012). Ein Discard-Präfix für IPv6 . Internet Engineering Task Force . doi : 10.17487/RFC6666 . ISSN 2070-1721 . RFC 6666 . Informativ.
  33. ^ S. Santesson (September 2006). TLS-Handshake-Nachricht für ergänzende Daten . Network Working Group. doi : 10.17487/RFC4680 . RFC 4680 .Vorgeschlagener Standard. Aktualisiert RFC  4346. Aktualisiert durch RFC  8447 und 8996 .
  34. ^ a b c J. Laganier; F. Dupont (September 2014). Ein IPv6-Präfix für Overlay-Routing-fähige kryptografische Hash-Identifikatoren Version 2 (ORCHIDv2) . Internet Engineering Task Force . doi : 10.17487/RFC7343 . ISSN 2070-1721 . RFC 7343 . Vorgeschlagener Standard. Ersetzt RFC  4843 .
  35. ^ a b G. Huston ; A. Lord; P. Smith (Juli 2004). IPv6 Address Prefix Reserved for Documentation . Network Working Group. doi : 10.17487/RFC3849 . RFC 3849 .Zur Information. Aktualisiert gemäß RFC  9637 .
  36. ^ a b G. Huston ; N. Buraglio (August 2024). Expanding the IPv6 Documentation Space . Internet Engineering Task Force . doi : 10.17487/RFC9637 . RFC 9637 .Informativ. Aktualisiert RFC  3849 .
  37. ^ S. Krishnan (Oktober 2024). Segment Routing over IPv6 (SRv6) Segment Identifiers in the IPv6 Addressing Architecture . Internet Engineering Task Force . doi : 10.17487/RFC9602 . RFC 9602 .Informativ.
  38. ^ a b c d R. Hinden; B. Haberman (Oktober 2005). Unique Local IPv6 Unicast Addresses . Network Working Group. doi : 10.17487/RFC4193 . RFC 4193 .Vorgeschlagener Standard.
  39. ^ E. Nordmark (Februar 2000). Stateless IP/ICMP Translation Algorithm (SIIT) . Network Working Group. doi : 10.17487/RFC2765 . RFC 2765 .Veraltet. Durch RFC  6145 ersetzt .
  40. ^ a b C. Bao; X. Li; F. Baker ; T. Anderson; F. Gont (Juni 2016). IP/ICMP-Übersetzungsalgorithmus . Internet Engineering Task Force . doi : 10.17487/RFC7915 . RFC 7915 .Vorgeschlagener Standard. Ersetzt RFC  6145 .
  41. ^ a b O. Troan (Mai 2015). B. Carpenter (Hrsg.). Abschaffung des Anycast-Präfixes für 6to4-Relay-Router . Internet Engineering Task Force . doi : 10.17487/RFC7526 . BCP 196. RFC 7526 .Best Current Practice 196. Ersetzt RFC  3068 und 6732 .
  42. ^ R. Hinden; S. Deering ; R. Fink; T. Hain (September 2000). Initial IPv6 Sub-TLA ID Assignments . Network Working Group. doi : 10.17487/RFC2928 . RFC 2928 .Informativ.
  43. ^ C. Popoviciu; A. Hamza; G. Van de Velde; D. Dugatkin (Mai 2008). IPv6 Benchmarking Methodology for Network Interconnect Devices . Network Working Group. doi : 10.17487/RFC5180 . RFC 5180 .Informativ.
  44. ^ J. Abley; B. Dickson; W. Kumari; G. Michaelson (Mai 2015). AS112-Umleitung mittels DNAME . Internet Engineering Task Force . doi : 10.17487/RFC7535 . ISSN 2070-1721 . RFC 7535 . Informativ.
  45. ^ J. Arkko; M. Cotton; L. Vegoda (Januar 2010). IPv4-Adressblöcke für Dokumentationszwecke reserviert . Internet Engineering Task Force . doi : 10.17487/RFC5737 . ISSN 2070-1721 . RFC 5737 . Informativ. Aktualisiert RFC  1166 .
  46. ^ „IPv6 Multicast Address Space Registry“ . Internet Assigned Numbers Authority .
  47. ^ a b T. Mrugalski; M. Siodelski; B. Volz; A. Yourtchenko; M. Richardson; S. Jiang; T. Lemon; T. Winters (November 2018). Dynamic Host Configuration Protocol for IPv6 (DHCPv6) . Internet Engineering Task Force . doi : 10.17487/RFC8415 . ISSN 2070-1721 . RFC 8415 . Vorgeschlagener Standard. Ersetzt RFC  3315 , 3633 , 3736 , 4242 , 7083 , 7283 und 7550 .
  48. ^ S. Thomson; T. Narten; T. Jinmei (September 2007). IPv6 Stateless Address Autoconfiguration . Network Working Group. doi : 10.17487/RFC4862 . RFC 4862 .Entwurf eines Standards. Ersetzt RFC  2462. Aktualisiert durch RFC  7527 .
  49. ^ T. Narten; E. Nordmark; W. Simpson; H. Holiman (September 2007). Neighbor Discovery for IP version 6 (IPv6) . Network Working Group. doi : 10.17487/RFC4861 . RFC 4861 .Entwurf eines Standards. Ersetzt RFC  2461. Aktualisiert durch RFC  5942 , 6980 , 7048 , 7527 , 7559 , 8028 , 8319 , 8425 und 9131 .
  50. ^ Die Auswirkungen der zustandslosen IPv6-Adressierung auf den Datenschutz . Portal.acm.org (21.04.2010). Abgerufen am 28.09.2011.
  51. ^ F. Gont; S. Krishnan; T. Narten; R. Draves (Februar 2021). Temporäre Adresserweiterungen für die zustandslose Adressautokonfiguration in IPv6 . Internet Engineering Task Force . doi : 10.17487/RFC8981 . ISSN 2070-1721 . RFC 8981 . Vorgeschlagener Standard. Ersetzt RFC  4941 .
  52. ^ „IPv6 unter Windows“ . Abgerufen am 25.03.2024 .
  53. ^ T. Aura (März 2005). Kryptografisch generierte Adressen (CGA) . Network Working Group. doi : 10.17487/RFC3972 . RFC 3972 .Vorgeschlagener Standard. Aktualisiert durch RFC  4581 und 4982 .
  54. ^ a b F. Gont (April 2014). Eine Methode zur Generierung semantisch undurchsichtiger Schnittstellenkennungen mit zustandsloser IPv6-Adressautokonfiguration (SLAAC) . Internet Engineering Task Force . doi : 10.17487/RFC7217 . ISSN 2070-1721 . RFC 7217 . Vorgeschlagener Standard.
  55. ^ Iljitsch van Beijnum (2006). „IPv6-Interna“ . Das Internet Protocol Journal . Bd. 9, nein. 3. S.  16–29 .
  56. ^ D. Thaler; R. Draves; A. Matsumoto; T. Chown (September 2012). D. Thaler (Hrsg.). Standardadressauswahl für Internetprotokoll Version 6 (IPv6) . Internet Engineering Task Force . doi : 10.17487/RFC6724 . ISSN 2070-1721 . RFC 6724 . Vorgeschlagener Standard. Ersetzt RFC  3484 .
  57. ^ S. Thomson; C. Huitema ; V. Ksinant; M. Souissi (Oktober 2003). DNS-Erweiterungen zur Unterstützung von IP Version 6. Network Working Group. doi : 10.17487/RFC3596 . STD 88. RFC 3596 .Internetstandard 88. Ersetzt RFC  3152 und 1886 .
  58. ^ a b R. Hinden; S. Deering (Dezember 1995). IP Version 6 Addressing Architecture . Network Working Group. doi : 10.17487/RFC1884 . RFC 1884 .Veraltet. Durch RFC  2373 überholt .
  59. ^ C. Huitema ; B. Carpenter (September 2004). Deprecating Site Local Addresses . Network Working Group. doi : 10.17487/RFC3879 . RFC 3879 .Vorgeschlagener Standard.
  60. ^ G. Houston (Aug. 2005). Vorgeschlagene Änderungen am Format der IANA IPv6 Registry . Network Working Group. doi : 10.17487/RFC4147 . RFC 4147 .Informativ.
  61. ^ J. Bound; B. Carpenter ; D. Harrington; J. Houldsworth; A. Lloyd (August 1996). OSI NSAPs and IPv6 . Network Working Group. doi : 10.17487/RFC1888 . RFC 1888 .Veraltet. Ersetzt durch RFC  4048. Aktualisiert durch RFC 4548 . 
  62. ^ B. Carpenter (Apr 2005). RFC 1888 ist überholt . IETF . doi : 10.17487/RFC4048 . RFC 4048 .Zur Information. Aktualisiert gemäß RFC  4548 .
  63. ^ R. Hinden; R. Fink; J. Postel (Dezember 1998). IPv6 Testing Address Allocation . Network Working Group. doi : 10.17487/RFC2471 . RFC 2471 .Veraltet. Ersetzt durch RFC  3701. Ersetzt RFC  1897 .
  64. ^ R. Fink; R. Hinden (März 2004). 6bone (IPv6 Testing Address Allocation) Phaseout . Network Working Group. doi : 10.17487/RFC3701 . RFC 3701 .Informativ. Ersetzt RFC  2471 .
  65. ^ P. Nikander; J. Laganier; F. Dupont (April 2007). Ein IPv6-Präfix für Overlay-Routing-fähige kryptografische Hash-Identifikatoren (ORCHID) . Network Working Group. doi : 10.17487/RFC4843 . RFC 4843 .Veraltet. Durch RFC  7343 ersetzt .
  66. ^ R. Bush (August 2001). Delegation von IP6.ARPA . Network Working Group. doi : 10.17487/RFC3152 . BCP 49. RFC 3152 .Veraltet. Ersetzt durch RFC  3596. Aktualisiert RFC  1886 , 2553 , 2766 , 2772 und 2874.
  67. ^ IAB ; IESG (September 2001). IAB/IESG-Empfehlungen zur IPv6-Adresszuweisung an Standorte . Network Working Group. doi : 10.17487/RFC3177 . RFC 3177 .Veraltet. Durch RFC  6177 ersetzt .
  68. ^ S. Thomson; C. Huitema (Dezember 1995). DNS-Erweiterungen zur Unterstützung von IP Version 6. Network Working Group. doi : 10.17487/RFC1886 . RFC 1886 .Veraltet. Ersetzt durch RFC 3596. Aktualisiert durch RFC  2874 und 3152 . 
  69. ^ M. Crawford; C. Huitema (Juli 2000). DNS-Erweiterungen zur Unterstützung der IPv6-Adressaggregation und -umnummerierung . Network Working Group. doi : 10.17487/RFC2874 . RFC 2874 .Historisch. Aktualisiert durch RFC  3152 , 3226 , 3363 und 3364. Aktualisiert RFC  1886 .
  70. ^ Vergleich von AAAA und A6 (brauchen wir A6 wirklich?) , Jun-ichiro Itojun Hagino, (Juli 2001)
  71. ^ a b R. Bush; A. Durand; B. Fink; O. Gudmundsson; T. Hain, Hrsg. (August 2002). Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) . Network Working Group. doi : 10.17487/RFC3363 . RFC 3363 .Informativ. Aktualisiert RFC  2673 und 2874 .
  72. ^ R. Austein (August 2002). Abwägungen bei der Unterstützung des Domain Name Systems (DNS) für das Internetprotokoll Version 6 (IPv6) . Network Working Group. doi : 10.17487/RFC3364 . RFC 3364 .Informativ. Aktualisiert RFC  2673 und 2874 .
  73. ^ a b A. Bierman; M. Bjorklund (März 2012). Network Configuration Protocol (NETCONF) Access Control Model . Internet Engineering Task Force . doi : 10.17487/RFC6536 . RFC 6536 .Veraltet. Durch RFC  8341 ersetzt .
  74. ^ Y. Morishita; T. Jinmei (Mai 2005). Häufiges Fehlverhalten bei DNS-Anfragen für IPv6-Adressen . IETF . doi : 10.17487/RFC4074 . RFC 4074 .Informativ.

Weiterführende Literatur

  • Beijnum, van, Iljitsch (2005). Ausführen von IPv6 . ISBN 978-1-59059-527-5Die