Der IPv6-Adressraum

Der Adressraum von IPv6 teilt sich in mehrere große Blöcke auf, die ihrerseits wieder unterteilt sein können. Alle Adressen unterhalb der hierarchischen Adressebene eines Blockes weisen einen identischen Präfix auf. Dadurch wird das Routing entschieden vereinfacht., da die Router einen großen Teil der Entscheidungen schon anhand dieses Präfix treffen können.

Die alten IPv4-Adressen werden dabei mit dem Präfix 0 in den IP6-Raum eingeblendet.

Durch die neue Struktur stehen nicht nur eine Menge neuer Adressen, sondern auch einige neue Adressierungsarten zur Verfügung. Pakete werden je nach Adressierung an genau eine Station gesendet (Unicast), an eine Gruppe von Stationen ( Multicast) oder an die schnellste aus einer Gruppe von Stationen (Anycast)

Unicast-Adressen

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.  Anschlie0end folgt die  Subscriber-Id, die die Einrichtung bezeichnet, die von dem Provider die Adresse bezieht.

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

Neben den providerbasierten Adressen gibt es noch zwei weitere Adressbereiche, die den heutigen lokalen Adressbereichen entsprechen, und die nicht von einem Router geroutet werden. Es sind dies verbindungsspezifische und standortspezifische lokale Adressen.

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.

 Anycast-Adressen

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.

Der IPv6-Adressraum unterteilt sich also wie folgt

Präfix Verwendung
0000 0000 Reserviert und IPv4
0000 0001 Nicht zugewiesen
0000 0010 OSI-NSAP-Adressen
0000 010 Netware IPX-Adressen
0000 011 Nicht zugewiesen
0000 1 Nicht zugewiesen
0001 Nicht zugewiesen
001 Nicht zugewiesen
010 Adressen für Service Provider
011 Nicht zugewiesen
100 Adressen für geographische Bereiche
101 Nicht zugewiesen
110 Nicht zugewiesen
1110 Nicht zugewiesen
1111 10 Nicht zugewiesen
1111 110 Nicht zugewiesen
1111 1110 Nicht zugewiesen
1111 1110 0 Nicht zugewiesen
1111 1110 10 verbindungsspezifische lokale Adressen
1111 1110 11 Standortspezifische lokale Adressen
1111 1111 Multicast

Lokale Adressen haben wie die reservierten Adressgruppen in IPv4 keine globale Bedeutung und können gut in Unternehmen eingesetzt werden, die sich vor dem Internet durch einen Firewall abschirmen wollen.

Für die Notation von 16-Byte Adressen gelten folgende Regeln:

  • 16 Byte Adressen werden als 8 Gruppen von je 4 hexadezimalen Ziffern geschrieben und die Gruppen werden durch Doppelpunkte getrennt. Beispiel:

    8000:0000:0000:0000:0123:4567:89AB:CDEF

  • Aufeinanderfolgende Gruppen die nur aus 0-en bestehen, können durch zwei aufeinaderfolgende Doppelpunkte ersetzt werden. Beispiel:

    8000::0123:4567:89AB:CDEF

  • Führende Nullen in einer Gruppe können weggelassen werden. Beispiel:

    8000::123:4567:89AB:CDEF

  • IPv4-Adressen können als zwei Doppelpunkte mit einer alten gepunkteten Dezimalzahl geschrieben werden. Beispiel:

    ::192.168.32.1

Die folgenden Felder wurden weggelassen:

  • Das IHL wurde weggelassen, weil der IPv6Header eine feste Länge hat.
  • Das Protocol-Feld wurde herausgenommen, weil das Feld Next-Header angibt welches Protokoll auf der Transportschicht verwendet wird.
  • Alle Felder in Bezug auf Fragmentierung wurden weggelassen, weil IPv6 Fragmentierung anders handhabt. IPv6-Router fragmentieren keine Pakete, sondern schicken der Quelle eine Nachricht gefälligst kleinere Pakete zu schicken.
  • Das Feld Checksum ist verschwunden, weil die Berechnung der Prüfsumme bei jedem Hop sich negativ auf die Performance auswirkte, und auf den Schichten über und unter der Vermittlungsschicht schon genug Prüfsummen berechnet werden.

IPv6-Erweiterungsheader

Einige der großzügig gestrichenen Felder sind manchmal doch noch notwendig, und für diese Fälle sind derzeit 6 Erweiterungsheader definiert, die benutzt werden um zusätzliche Informationen zu kodieren. Alle Erweiterungsheader sind optional. Werden mehrere benutzt müssen sie direkt nach dem Hauptheader erscheinen.

Erweiterungs-Header Zweck
Optionen für Teilstrecken Dieser Header wird für Informationen benutzt die alle Router auf der Strecke prüfen müssen. Bisher ist eine Option definiert, die Unterstützung von Jumbogrammen, also Paketen die größer als 64 kByte sind.
Routing Mit diesem Header kann eine Route vollständig oder teilweise spezifiziert werden.
Fragmentierung Dieser Header enthält Optionen für die Fragmentierung von Paketen. Nanu, hatten wir nicht eben gesagt IPv6 fragmentiert nicht? Im Prinzip ja. Der Quellhost darf Pakete immer noch fragmentieren. Nur die Router auf der Strecke sind nicht mehr dazu berechtigt.
Authentifikation Der Authentifizierungsheader bietet einen Mechanismus, durch den der Empfänger sicher sein kann, das der in der Adresse angebene Sender auch tatsächlich der ist, der er behauptet zu sein.
Verschlüsselte Sicherheistdaten Dieser Header enthält Informationen über das verwendete Verschlüsselungsverfahren.
Optionen für Ziele Dieser Header ist für Optionen vorgesehen, die nur vom Zielhost interpretiert werden müssen. Er wird derzeit nicht benutzt.