topic - Beschreibung

Beschreibung

IPv6-Adressen werden mit Subnetzmasken in einen Netz- und einen Host-Teil unterteilt

subnet masks
wie bei IPv4

Bei IPv4 hat sich gezeigt, dass es manchmal von Nutzen wäre, einem Interface mehr als eine IP-Adresse zuweisen zu können, je nach Bedarf und Zweck (aliases, multicast etc.). Um in Zukunft flexibler bleiben zu können, geht man bei IPv6 weiter und erlaubt pro Interface mehr als eine zugewiesene IP-Adresse. Derzeit sind durch die RFCs kein Limit gesetzt, wohl aber in der Implementierung des IPv6 Stacks (um DoS Attacken vorzubeugen).

Neben der großen Bit-Anzahl für Adressen definiert IPv6 basierend auf einigen vorangestellten Bits verschiedene Adress-Typen. Diese werden hoffentlich in der Zukunft niemals aufgehoben (zum Unterschied zu IPv4 heute und die Entwicklung der class A, B und C Netze).

Zur Unterstützung einer automatischen Konfiguration wird die Bitanzahl in einen Netzwerk-Teil (vordere 64 Bits) und einen Hostteil (hintere 64 Bit).

Adress-Typ	Beschreibung
Adressen ohne speziellen Präfix
Netzteil der Adresse (Präfix)
Adress-Typen (Host-Teil)
Präfixlängen für das Routing

IPv6 Präfixe

Bezeichnung	Präfix	Verwendung
Link Local Unicast	`fe80::/10`	Rechner im eigenen Subnetz
Site Local Unicast	fec0 - feff	Standortlokale Adressen
Unique Local Unicast	fc00 - fdff	Private Adressen
Multicast	ff00	Für mehrere Clients
Global Unicast	2000 - 3fff	Weltweite eindeutige Adressen
	`2001`	An Provider vergeben, die weiterverteilen.
	`2002`	Tunnelmechanismus 6to4
NAT64	`64:ff9b::/96`	Übersetzungsmechanismus NAT64

Adressen ohne speziellen Präfix

Adress-Typ	Beschreibung
Localhost Adresse
Unspezifische Adresse
IPv6 Adressen mit eingebetteter IPv4 Adresse

Localhost Adresse

Dies ist eine spezielle Adresse für das Loopback Interface, vergleichbar zur ”127.0.0.1” bei IPv4. Bei IPv6 lautet die localhost Adresse

bzw. komprimiert:

Pakete mit dieser Quell- bzw. Ziel-Adresse sollten niemals den sendenden Host verlassen.

Unspezifische Adresse

Dies ist eine spezielle Adresse vergleichbar mit ”any” oder ”0.0.0.0” bei IPv4. In IPv6 lautet sie

oder:

Diese Adresse wird meistens in Routing-Tabellen und beim ”socket binding” (zu jeder IPv6 Adresse) angewandt bzw. gesehen.

Beachten: Die Unspezifizierte Adresse kann nicht als Ziel-Adresse verwendet werden.

IPv6 Adressen mit eingebetteter IPv4 Adresse

Es gibt zwei Adressen-Typen, die IPv4 Adressen enthalten können.

IPv4 Adressen in IPv6 Format

IPv4-only IPv6-kompatible Adressen kommen manchmal bei IPv6 kompatiblen Daemon zur Anwendung, die allerdings ausschließlich an IPv4 Adressen gebunden sind.

Diese Adressen sind mit einer speziellen Präfixlänge von 96 definiert (a.b.c.d. ist die IPv4 Adresse):

oder in komprimiertem Format:

Die IPv4 Adresse 1.2.3.4. z.B. sieht wie folgt aus:

IPv4 kompatible IPv6 Adressen

Dieser Adress-Typ wurde für das automatische Tunneln (RFC 2893 / Transition Mechanisms for IPv6 Hosts and Routers) verwendet, welches aber durch das 6to4 tunneling ersetzt wurde.

oder in komprimierter Form:

Netzteil der Adresse (Präfix)

Es wurden einige Adress-Typen definiert und zugleich blieb für zukünftige Anforderungen ausreichend Raum für weitere Definitionen. In RFC 4291 / IP Version 6 Addressing Architecture wird das aktuelle Adress-Schema definiert.

Lassen Sie uns nun einen Blick auf die verschiedenen Präfixe (und somit auf die Adress-Arten) werfen

Adress-Typ	Beschreibung
Link-lokaler Adress-Typ
Site-lokaler Adress-Typ
Unique Local IPv6 Unicast Adressen
Globaler Adress-Typ ("Aggregatable global unicast")
Multicast-Addressen
Anycast-Adressen

Link-lokaler Adress-Typ

Link-lokale Unicast-Adressen

Adressbereich fe80::/10 sind, wie weiter oben schon erwähnt, nur zur Kommunikation innerhalb desselben Netzwerksegments gedacht.
Routing ist mit diesen Adressen nicht möglich.

Es handelt sich um spezielle Adressen, die ausschließlich auf einem Link eines Interfaces gültig sind. Wird diese Adresse als Zieladresse verwendet, so kann das Paket niemals einen Router passieren. Die Adresse wird bei der Link-Kommunikation eingesetzt, z.B.:

Ist noch jemand anderer auf diesem Link?
Ist jemand mit einer speziellen Adresse hier (z.B. Suche nach einem Router)?

Die Adresse beginnt mit (wobei ”x” für ein hexadezimales Zeichen steht, im Normalfall ”0”)

Eine Adresse mit diesem Präfix gibt es an jedem IPv6 fähigen Interface nach einer stateless automatischen Konfiguration (dies ist der Regelfall).

Site-lokaler Adress-Typ

Diese Adressen sind vergleichbar zu den RFC 1918 / Address Allocation for Private Internets im heutigen IPv4. Eine Neuerung und Vorteil hierbei ist, vergleichbar zum 10.0.0.0/8 im IPv4, die Nutzbarkeit von 16 bits bzw. ein Maximum von 65536 Subnetzen.

Ein weiterer Vorteil: Da man bei IPv6 mehr als eine Adresse an ein Interface binden kann, ist auch die Zuweisung einer site-local Adresse zusätzlich zu einer globalen Adresse möglich.

Die Adresse beginnt mit:

(”x” ist ein hexadezimales Zeichen, normalerweise ”0”)

Dieser Adresstyp ist nun abgekündigt RFC 3879 / Deprecating Site Local Addresses und sollte nicht mehr verwendet werden. Für Tests im Labor sind solche Adressen meineserachtens aber immer noch eine gute Wahl.

Unique Local Unicast Adressen

Adressbereich fc00: :/7 entsprechen den privaten Adressen des IPv4-Protokolls.

Sie lösen die inzwischen veralteten sitelokalen Unicast-Adressen ab und werden im Internet nicht geroutet.

Weil die schon früh definierten site-local Adressen nicht eindeutig sind, kann dies zu großen Problemen führen, wenn z.B. einst unabhängige Netzwerke später zusammengeschlossen werden (Überlappung von Subnetzen). Aufgrund dessen und anderer Gründe wurde ein neuer Adresstyp definiert, genant RFC 4193 / Unique Local IPv6 Unicast Addresses.

Die Adresse beginnt mit:

Ein Teil des Präfix (40 Bits) werden pseudozufällig generiert. Es ist sehr unwahrscheinlich, daß zwei generierte Präfixe identisch sind.

Ein Beispiel für einen Präfix (generiert mit Hilfe des web-basierten Werkzeugs: Goebel Consult / createLULA):

Globaler Adress-Typ ("Aggregatable global unicast")

Globale Unicast-Adressen

Hier sind mehrere Adressbereiche in Gebrauch.
Die endgültigen Bereiche scheinen noch nicht ganz festzustehen, sind für die LPI-Prüfung aber auch nicht von Belang
Der globale Bereich ist jedenfalls für die Kommunikation im Internet zuständig
Da diese Adressen bei den meisten Internet Service Providern noch nicht nativ zu bekommen sind, empfehle ich zum Experimentieren die Verwendung eines Tunnelbrokers

Heute gibt es ist per Definition eine globale Adress-Art (Das erste Design, ''Provider based'' genannt, wurde bereits vor einigen Jahren wieder aufgegeben RFC 1884 / IP Version 6 Addressing Architecture [obsolete]. Einige Überbleibsel hiervon sind in älteren Linux Kernelquellen noch zu finden.

Die Adresse beginnt mit (x sind hexadezimale Zeichen)

Hinweis: Der Zusatz ”aggregatable” im Namen wird in aktuellen Drafts abgelegt. Es sind weitere Subarten definiert:

6bone Test-Adressen

Diese globalen Adressen waren die Ersten definierten und auch benutzen Adressen. Sie alle beginnen mit:

Beispiel:

Eine spezielle 6bone Test-Adresse, die niemals weltweit einmalig ist, beginnt mit

und wird zumeist in alten Beispielen benutzt, um zu vermeiden, dass Anwender diese mit Copy & Paste in Ihre Konfigurationen übernehmen können. Auf diese Weise können Duplikate weltweit einmaliger Adressen aus Versehen bzw. Unachtsamkeit vermieden werden. Es würde für den Original-Host ernste Probleme bedeuten (z.B. Antwortpakete für niemals gesendete Anfragen bekommen...). Aufgrund dessen, daß IPv6 nun produktiv ist, wird dieser Präfix nicht mehr länger delegiert und nach dem 6.6.2006 vom Routing ausgenommen (mehr unter RFC 3701 / 6bone Phaseout ).

6to4 Adressen

Diese Adressen werden für einen speziellen Tunnelmechanismus verwendet [RFC 3056 / Connection of IPv6 Domains via IPv4 Clouds und RFC 2893 / Transition Mechanisms for IPv6 Hosts and Routers]. Sie kodieren eine gegebene IPv4 Adresse, ein eventuelles Subnetz und beginnen mit

z.B. wird 192.168.1.1/5 repräsentiert durch:

Ein kleines Shell-Kommando kann aus einer IPv4 eine 6to4 Adresse erstellen:

Siehe auch tunneling using 6to4 und information about 6to4 relay routers.

Durch einen Provider zugewiesene Adressen für ein hierarchisches Routing

Diese Adressen werden an Internet Service Provider (ISP) delegiert und beginnen mit:

Präfixe für große ISPs (mit eigenem Backbone) werden durch local registries vergeben. Zurzeit wird ein Präfix mit der Länge 32 zugeteilt.

Grosse ISPs delegieren ihrerseits an kleinere ISPs ein Präfix mit der Länge 48.

Für Beispiele und Dokumentationen reservierte Adressen

Momentan sind zwei Adressbereiche für Beispiele und Dokumentationen RFC 3849 / IPv6 Address Prefix Reserved for Documentation reserviert:

Diese Adressbereiche sollten nicht geroutet werden und am Übergangsrouter zum Internet (basierend auf Absendeadressen) gefiltert werden.

Multicast-Addressen

Multicast-Adressen werden für entsprechende Dienste verwendet.

Sie beginnen immer mit (xx ist hierbei der Wert der Reichweite)

Die Adressen werden in Reichweiten und Typen unterteilt:

Multicast-Bereiche

Die Multicast Reichweite ist ein Parameter, mit dem die maximale Distanz angegeben werden kann, die ein Multicast Paket sich von der versendenden Einheit entfernen kann.

Zurzeit sind folgende Regionen (reichweiten) definiert:

ffx1: Node-lokal, Pakete verlassen niemals den Knoten
ffx2: Link-lokal, Pakete werden niemals von Routers weitergeleitet, der angegebene Link wird nie verlassen.
ffx5: Site-lokal, Pakete verlassen niemals den Standort (Site)
ffx8: organisationsweit, Pakete verlassen niemals eine Organisation (nicht einfach zu implementieren, dies muss durch das Routing Protokoll abgedeckt werden)
ffxe: Globale Reichweite
Sonstige sind reserviert

Multicast-Typen

Es sind bereits viele Typen definiert bzw. reserviert (siehe RFC 4291 / IP Version 6 Addressing Architecture für weitere Details), einige Beispiele:

All Nodes Adresse: ID = 1h, alle Hosts am lokalen Node (ff01:0:0:0:0:0:0:1) oder am angeschlossenen Link (ff02:0:0:0:0:0:0:1) werden adressiert.
All Routers Adresse: ID = 2h, alle Router am lokalen Node (ff01:0:0:0:0:0:0:2), am angeschlossenen Link (ff02:0:0:0:0:0:0:2) oder am lokalen Standort werden adressiert.

Erforderliche node link-local Multicast Adresse

Diese spezielle Multicast Adresse wird als Zieladresse bei der Erkundung des Nahbereichs verwendet, da es ARP bei IPv6 im Gegensatz zu IPv4 nicht mehr gibt.

Ein Beispiel für diese Adresse könnte sein:

Das benutzte Präfix zeigt, dass es sich um eine link-lokale Multicast Adresse handelt. Dass Suffix wird aus der Zieladresse erstellt. In diesem Beispiel soll ein Paket zur Adresse “fe80::1234” gesendet werden, aber die Netzwerk-Schicht hat keine Kenntnis der aktuellen Schicht 2 MAC Adresse. Die oberen 104 bits werde mit “ff02:0:0:0:01:ff00::/104” ersetzt und die unteres 24 bits bleiben unverändert. Diese Adresse wird nun ”am Link” verwendet, um den entsprechenden Node zu finden, der wiederum seine Schicht 2 MAC Adresse als Antwort zurücksendet.

Anycast-Adressen

Anycast Adressen sind spezielle Adressen und werden verwendet, um besondere Bereiche wie den nächstgelegenen DNS-Server, den nächstliegenden DHCP Server und vergleichbare dynamische Gruppen abzudecken. Die Adressen werden dem Pool des Unicast Adressraums (global-aggregierbar oder Site-lokal zurzeit) entnommen. Der Anycast-Mechanismus (client view) wird von dynamischen Routing-Protokollen gehandhabt.

Hinweis: Anycast Adressen können nicht als Quelladresse verwendet werden, sondern ausschließlich als Zieladressen.

Subnet-Router Anycast-Adresse

Die Subnet-Router Anycast Adresse ist ein einfaches Beispiel für eine Anycast Adresse. Angenommen, der Knoten hat folgende global zugewiesene IPv6 Adresse:

Die Subnet-Router Anycast Adresse wird durch komplette Streichung des Suffixes (die letzten gültigen 64 bits) erstellt:

Adress-Typen (Host-Teil)

In Hinblick auf Auto-Konfigurations- und Mobilitätsfragen wurde entschieden, die niedrigeren 64 bits als Host-Bestandteil zu nutzen. Jedes einzelne Subnetz kann deshalb eine große Anzahl an Adressen enthalten.

Der Host-Teil kann aus unterschiedlichen Blickwinkeln betrachtet werden:

Adress-Typ	Beschreibung
Automatisch erstellte Adressen
Manuell festgelegte Adressen

Automatisch erstellte Adressen

Automatisch erstellte Adressen (auch unter dem Namen stateless bekannt)

Bei der Auto-Konfiguration wird der Hostteil der Adresse durch die Konvertierung der MAC-Adresse eines Interfaces (falls vorhanden) zu einer einmaligen IPv6 Adresse (mittels EUI-64 Methode) generiert. Falls keine MAC-Adresse verfügbar ist (z.B. bei virtuellen Interfaces), wird anstelle dessen etwas anderes herangezogen (wie z.B. die IPv4 Adresse oder die MAC-Adresse eines physikalischen Interfaces).

Als Beispiel hat hier ein NIC folgende MAC-Adresse (48 bit):

Diese wird gemäß demIEEE-Tutorial EUI-64 Design für EUI-48 Identifiers zum 64 bit Interface Identifier erweitert:

Mit einem gegebenen Präfix wird daraus die schon oben gezeigte IPv6-Adresse:

Datenschutzproblem

Datenschutzproblem mit automatisch erstellten Adressen sowie eine Lösung

Der "automatisch generierte" Hostteil ist weltweit einmalig (mit Ausnahme, wenn der Hersteller einer NIC die gleiche MAC-Adresse bei mehr als einer NIC einsetzt). Die Client-Verfolgung am Host wird dadurch möglich, solange kein Proxy verwendet wird.

Dies ist ein bekanntes Problem und eine Lösung wurde dafür definiert: Datenschutz-Erweiterung, definiert in RFC 3041 / Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (es gibt bereits ein neueres Draft: draft-ietf-ipv6-privacy-addrs-v2-*). Es wird von Zeit zu Zeit mittels eines statischen und eines Zufallswertes ein neues Suffix erstellt. Hinweis: Dies ist nur für ausgehende Client-Verbindungen sinnvoll und bei bekannten Servern nicht wirklich sinnvoll.

Manuell festgelegte Adressen

Bei Servern ist es wahrscheinlich leichter, sich einfachere Adressen zu merken. Dies kann z.B. mit der Zuweisung einer zusätzlichen IPv6 Adresse an ein Interface geschehen.

Für das manuelle Suffix, wie ”::1” im obigen Beispiel, muss das siebte höchstwertige Bit auf 0 gesetzt sein (das universale/local Bit des automatisch generierten Identifiers). Es sind auch noch andere (ansonsten nichtausgewählte) Bit-Kombinationen für Anycast-Adressen reserviert.

Präfixlängen für das Routing

IPv6/Subnetting

Anhang

Siehe auch

ICMPv6/Typen

Links

Weblinks

TMP

Adress-Typen

Unicast-Adressen

Kommunikation eines Netzknotens mit genau einem anderen Netzknoten

Unicast-Adressen sind providerbasierte Adressen und gelten Weltweit

Sie sind durch die ersten 3 Bit 010 gekennzeichnet.
Anschließend folgen 5 Bit Registry-ID, die das Organ bezeichnen, das diese Adresse an den Provider vergeben hat, auf die wiederum eine Provider-ID folgt.
Anschließend folgt die Subscriber-Id, die die Einrichtung bezeichnet, die von dem Provider die Adresse bezieht

Subscriber kann sein Netz wiederum in verschiedene Unternetze gliedern

die durch eine entsprechende ID gekennzeichnet sind
Die letzten 48 Bit bilden schließlich die Interface-ID
Da dies genau der Größe einer MAC-Adresse enstpricht, können sich damit Stationen im LAN automatisch konfigurieren, indem sie einfach ihre MAC-Adresse als Interface-ID verwenden

Weitere Adressbereiche

die den heutigen lokalen Adressbereichen entsprechen, und die nicht von einem Router geroutet werden
Es sind dies verbindungsspezifische und standortspezifische lokale Adressen

Link-Local-Adressen

Sind nur innerhalb abgeschlossener Netzwerksegmente (link) gültig

Netzwerksegment ist ein lokales Netz, gebildet mit Switches oder Hubs, bis zum ersten Router
Link-Local-Adressen sind mit APIPA-Adressen im Netz 169.254.0.0/16 vergleichbar.

Formatpräfix lautet fe80::/10

10 Bit 54 Bit 64 Bit
1111111010 0 Interface ID

Verwendung

Adressierung von Nodes in abgeschlossenen Netzwerksegmenten
Autokonfiguration
Neighbour-Discovery

Vorteile

In einem Netzwerksegment muss keinen DHCP-Server zur Adressvergabe konfigurieren werden

Zone ID

Soll ein Gerät mittels einer dieser Adressen kommunizieren, so muss die Zone ID mit angegeben werden
eine Link-Lokale-Adresse kann auf einem Gerät mehrfach vorhanden sein

Beispiele

fe80::7645:6de2:ff:1%1
fe80::7645:6de2:ff:1%eth0

Site Local Unicast (veraltet)

fec0::/10

fec0… bis feff…

Standortlokale Adressen (site local addresses)

Nachfolger der privaten IP-Adressen (beispielsweise 192.168.x.x)
Durften nur innerhalb der gleichen Organisation geroutet werden
Die Wahl des verwendeten Adressraums innerhalb von fec0::/10 war beliebig

Überschneidungen der Adressräume

Es konnte zu Überschneidungen der Adressräume an unterschiedlichen Standorten kommen
- Bei der Zusammenlegung von ehemals getrennten Organisationen
- wenn eine VPN-Verbindung zwischen eigentlich getrennten mit Site Local Addresses nummerierten Netzwerken hergestellt wurde

Deprecated (RFC 3879)

Aus diesem und weiteren Gründen sind Site Local Addresses nach RFC 3879 veraltet
- werden aus zukünftigen Standards verschwinden
Neue Implementierungen müssen diesen Adressbereich als Global-Unicast-Adressen behandeln

Nachfolger sind Unique Local Addresses

Unique Local Unicast (ULA)

fc00::/7 (fc00… bis fdff…)

Für private Adressen gibt es die Unique Local Addresses (ULA)

beschrieben in RFC 4193

Präfix fd

Derzeit ist nur das Präfix fd für lokal generierte ULA vorgesehen

Präfix fc

ist für global zugewiesene, eindeutige ULA reserviert

Site-ID

Auf das Präfix folgen 40 Bit, als eindeutige Site-ID

Eindeutigkeit

Diese Site-ID ist bei den ULA mit dem Präfix fd zufällig zu generieren und somit sehr wahrscheinlich eindeutig
Bei global vergebenen ULA jedoch auf jeden Fall eindeutig
- RFC 4193 gibt jedoch keine konkrete Implementierung der Zuweisung von global eindeutigen Site-IDs an

Subnet-ID

Nach der Site-ID folgt eine 16-Bit-Subnet-ID, welche ein Netz innerhalb der Site angibt

Beispiel

fd9e:21a7:a92c:2323::1

Hierbei ist

fd das Präfix für lokal generierte ULAs
9e:21a7:a92c ein einmalig zufällig erzeugter 40-Bit-Wert
2323 eine willkürlich gewählte Subnet-ID
::1 die Host-ID

Vorteil der Verwendung von wahrscheinlich eindeutigen Site-IDs

Beim Einrichten eines Tunnels zwischen getrennt voneinander konfigurierten Netzwerken sind Adresskollisionen sehr unwahrscheinlich
Pakete, die an eine nicht erreichbare Site gesendet werden, laufen mit großer Wahrscheinlichkeit ins Leere, statt an einen lokalen Host gesendet zu werden, der zufällig die gleiche Adresse hat

ULA-Central

Es existiert ein proposed standard, welcher Richtlinien für Registrare (IANA, RIR) beschreibt, konkret deren Betrieb sowie die Adressvergabe-Regeln
Allerdings ist eine derartige „ULA-Central“ bisher nicht gegründet
Sowohl der RFC 4193 als auch der proposed standard sind identisch in Bezug auf das Adressformat und den Generierungs-Algorithmus

Global Unicast

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

::/96 (96 0-Bit)

Stand für IPv4-Kompatibilitätsadressen

welche in den letzten 32 Bit die IPv4-Adresse enthielten
dies galt nur für globale IPv4 Unicast-Adressen
Diese waren für den Übergang definiert
In RFC 4291 vom Februar 2006 als veraltet (engl. deprecated) gekennzeichnet

0:0:0:0:0:ffff::/96 (80 0-Bit, gefolgt von 16 1-Bit)

Steht für IPv4 mapped (abgebildete) IPv6 Adressen

Die letzten 32 Bit enthalten die IPv4-Adresse
Ein geeigneter Router kann diese Pakete zwischen IPv4 und IPv6 konvertieren
- und so die neue mit der alten Welt verbinden

2000::/3 (2000… bis 3fff…; was dem binären Präfix 001 entspricht)

Stehen für die von der IANA vergebenen globalen Unicast-Adressen
Routbare und weltweit einzigartige Adressen

Bildung einer Globalen Unicast Adresse

Unterteilung des Adressraumes in öffentlichen (TLA, NLA, SLA) und lokalen Bereich (64 Bit + 64 Bit)

Routing im öffentl. Bereich effizient durch hierarchische Netz-topologische Orientierung
Routing im lokalen Bereich effizient durch festen „public-“ Teil der Adresse (64 Bit)

Nur Top-Level Aggregation ID muss zentral verwaltet werden

Adressvergabe erfolgt blockweise hierarchisch von oben nach unten

Option	Beschreibung
TLA	Top Level Aggregation (z.B. Super-Provider,Exchange)
NLA	Next Level Aggregation (z.B. ISP)
SLA	Site Level Aggregation (z.B. Firma)

Global Unicast Adressen

Option	Beschreibung
2001 2003, 240, 260, 261, 262, 280, 2a0, 2b0	werden an Provider vergeben und 2c0 die diese an ihre Kunden weiterverteilen werden von Regional Internet Registries (RIRs) vergeben
2001::/32	sind ihnen noch vollständig zugeteilt beginnend mit 2001:0: anders als 2001::/16 Tunnelmechanismus Teredo 3ffe::/16
2001:db8::/32	Testnetzwerk 6Bone Dokumentationszwecke wurden gemäß RFC 3701 an die IANA keine tatsächlichen Netzteilnehmer zurückgegeben
2002 64:ff9b::/96	Adressen des Tunnelmechanismus 6to4 Übersetzungsmechanismus NAT64 gemäß RFC 6146

Multicast-Adressen

Multicast-Adressen sprechen eine ganze Gruppe von Rechnern an

Das ist zum Beispiel für Video on Demand oder Fernunterricht nützlich und spart Bandbreite, da es bereits auf der IP-Schicht ausgewertet wird und mehrfache Übertragung von Paketen verhindert.
Auch mehrere NTP-Server können einer Multicast-Gruppe angehören.

Multicast-Adressen beginnen alle mit der Bitfolge 1111 1111

Darauf folgen dei Felder Flag und Scope.
Bisher ist allerdings nur das Flag T definiert, mit den Werten 1 für dauerhaft und 0 für temporär.

Einer-zu-vielen-Kommunikation wird durch Multicast-Adressen abgebildet

Typ: 0000 ... fest definiert (ANA), 0001 ... Adresse wurde „frei“ vergeben

Scope: Gültigkeitsbereich 0001 nur lokales Endgerät

Wert	Scope
0010	Link lokal
0101	Site lokal
1000	Organisations-lokal
1110	Global

Regel

FF02::1:FF00:0/104 zzgl. letzte 24 Bit der Unicast Adresse
Link-Lokale MC Adresse des Endsystems (für Neighbor Discovery)

Beispiele für Multicast-Adressen

FFO1::1 alle lokalen Interfaces FF02::1 alle Link-lokalen Interfaces
FF05::2 alle Site-Ilokalen Router FF0x::202 Sun RPC

Präfix ff00::/8 (ff…)

stehen für Multicast-Adressen

Nach dem Multicast-Präfix folgen

4 Bit für Flags
4 Bit für den Gültigkeitsbereich (Scope)

Flags sind zurzeit in folgenden Kombinationen gültig

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

Gültigkeitsbereiche

Die restlichen Bereiche sind nicht zugewiesen

dürfen von Administratoren benutzt werden, um weitere Multicast-Regionen zu definieren.

Wert	Scope	Beschreibung
1	interfacelokal	diese Pakete verlassen die Schnittstelle nie. (Loopback)
2	link-lokal	werden von Routern grundsätzlich nie weitergeleitet und können deshalb das Teilnetz nicht verlassen.
4	adminlokal	der kleinste Bereich, dessen Abgrenzung in den Routern speziell administriert werden muss.
5	sitelokal	dürfen zwar geroutet werden, jedoch nicht von Border-Routern
8	organisationslokal	die Pakete dürfen auch von Border-Routern weitergeleitet werden, bleiben jedoch „im Unternehmen“ (hierzu müssen seitens des Routing-Protokolls entsprechende Vorkehrungen getroffen werden).
e	globaler Multicast	darf überallhin geroutet werden
0, 3, f	reservierte Bereiche

Beispiele für wohlbekannte Multicast-Adressen

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

Anycast Adressen

Verschiedene Endgeräte sind unter einer (Anycast-) Adresse erreichbar

Auslieferung des Paketes normalerweise an das Interface des Endgerätes, welches (Netztopologie) Routing-mäßig das nächstliegende ist
Unterscheidet sich nicht von normaler Unicast-Adresse 4 Anycast Funktionalität ist durch die Router und durch Konfiguration des Endgerätes zu realisieren
Derzeit nur für Router oder Server zulässig (Änderung jedoch absehbar)

Anwendungsbeispiele

Dienste unter global gleicher Adresse effizient verfügbar (Routing zum PoP)
Load Balancing
erhöhte Stabilität durch mehrere Router gleicher Adresse
Mobile IPv6 Home Agents Anycast (Anycast Id. 126 oder 7E)

Mit Anycast-Adressen erreicht man genau einen aus einer Gruppe von Rechnern

die die selbe Anycast-Adresse haben
- Zum Beispiel einen aus einer Gruppe von Nameservern, oder von Routern bei einem Provider