Eine kleine Einführung in wichtige Unterschiede zwischen IPv6 und IPv4

Für ein Hobbyprojekt habe ich mich letztens mit IPv6 befasst. IPv6 weist ein paar wichtige Unterschiede zu IPv4 auf, die man meines Erachtens direkt am Anfang kennen sollte, um nicht mit einem IPv4-Denken an IPv6 heranzugehen. In diesem Artikel möchte ich kurz die für mich wichtigen Unterschiede erklären, die mir beim Verständnis von IPv6 etwas Schwierigkeiten gemacht haben.

Schauen wir uns zunächste einmal den grundlegenden Aufbau einer IPv6-Adresse an. Ich werde mich hier erst einmal auf Unicast beschränken, also die Kommunikation von Host zu Host. Insgsesamt besteht eine IPv6-Adresse aus 128 Bits, wovon 48 bis 64 Bit das Routing Prefix bilden, 16 bis 0 Bit die Subnet ID und exakt 64 Bit den Interface Identifier.

 2001:0db8:85a3  :    0000   : 0000:8a2e:0370:7334     (Beispiel)

[ Routing Prefix | Subnet ID | Interface Identifier ]  (Format)
 \              / \         / \                    /
  --------------   ---------   --------------------
    48-64 Bit       0-16 Bit          64 Bit

Die vollständige Notation einer IPv6-Adresse sieht dann folgendermaßen aus: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Führende Nullen innerhalb von Blöcken darf man weglassen, sodass man dieselbe IPv6-Adresse auch als 2001:db8:85a3:0:0:8a2e:370:7334 schreiben kann. Außerdem dürfen an einer Stelle mehrere Blöcke von Nullen komplett entfernt und durch einen doppelten Doppelpunkt markiert werden: 2001:db8:85a3::8a2e:370:7334.

Diese Aufteilung ist extrem wichtig, vor allem die letzten 64-Bit sind meiner bisherigen Recherche nach immer der Interface Identifier und werden niemals für Subnetze verwendet. Man kann also im Gegensatz zu IPv4 nicht entscheiden, dass man ein Subnetz für 256 Hosts mit acht frei zuweisbaren Bits haben will. Bei IPv4 wäre das ein ganz klassischer Fall, z.B. mit 10.0.0.0/24. Eine solch kleine Unterteilung von Subnetzen ist in IPv6 nicht vorgesehen, die letzten 64 Bit gehören immer zum Interface Identifier.

Zuweisung von Subnetzen an Kunden

Hier kommen wir schon zum ersten wichtigen Unterschied zwischen IPv4 und IPv6. Bei IPv4 erhalten wir von unserem Provider in der Regel genau eine IP-Adresse für einen Zugang oder Server. Haben wir hinter diesem Zugang weitere Geräte oder virtuelle Server, müssen wir entweder manuell weitere IPv4-Adressen beim Provider beantragen oder mit lokalen IP-Adressen und NAT arbeiten.

Bei IPv6 erhalten wir (meinem Verständnis nach) vom Provider immer erzwungenermaßen mindestens ein komplettes /64 Subnetz, bei manchen Anbietern sogar ein /48 Subnetz. Das heißt wir können problemlos auf einem bestehenden Server weitere VMs anlegen, die ebenfalls eine öffentliche IP-Adresse erhalten können.

Beispielsweise könnte ich von meinem Provider folgendes Subnetz für einen Server erhalten: 2001:db8:85a3::/64. Das bedeutet, dass mein Server das 64-Bit-Präfix 2001:db8:85a3:0 für alle Adressen verwenden muss, und ich die restlichen 64 Bit frei verwenden kann. Mein Hauptserver könnte damit beispielsweise die IP-Adresse 2001:db8:85a3::1 erhalten, also der erste Host im Subnetz sein. Für die VMs könnte ich dann (wenn ich DHCP zur Zuweisung verwende, aber dazu später mehr) die Hostnummern 100 bis 999 (0x64 bis 0x3e7) vorsehen, sodass sich IP-Adressen 2001:db8:85a3::64 bis 2001:db8:85a3::3e7 für die VMs ergeben würden.

Da mein Provider meinem Server ein komplettes 64-Bit-Subnetz zugewiesen hat und hoffentlich sein Routing auch richtig für das ganze Subnetz eingerichtet hat, kann ich dieVMs nach Zuweisung der IP-Adressen sofort aus dem öffentlichen Internet erreichen. Ich muss nicht vorher beim Provider um neue IP-Adressen betteln.

NAT vermeiden!

Das bringt uns zu einem weiteren wichtigen Punkt: NAT ist bei IPv6 in der Regel ganz schlechter Stil und sollte vermieden werden, wann immer möglich. Es gibt ausreichend IPv6-Adressen, damit jedes Gerät eine eigene öffentliche IPv6-Adresse erhalten kann. Das heißt aber gleichzeitig auch, dass man sich nicht mehr auf NAT als “Firewall” verlassen sollte, sondern saubere Firewalls einrichten muss. Denn sobald ein Gerät eine globale IPv6-Adresse hat, ist es theoretisch auch global im Routing erreichbar.

Praktisch wird noch die Frage sein, ob zum Beispiel bei VMs am Hauptserver Forwarding aktiviert oder deaktiviert ist, aber im Prinzip sollte man immer davon ausgehen, dass ein Server öffentlich erreichbar ist und saubere Firewall-Regeln einrichten.

Mehrere IPv6-Adressen pro Interface

Ein weiterer Punkt, der für mich überraschend und neu war: Bei IPv6 ist es normal, dass ein Interface mehrere IPv6-Adressen zugewiesen hat. Standardmäßig hat ein Gerät immer schon eine Link-local-IPv6-Adresse, die nur innerhalb eines Netzwerks verwendet werden kann. Diese startet mit fe80::/10. Daneben kann ein Interface noch weitere IPv6 erhalten.

Zur Zuweisung von IPv6-Adressen an Geräte habe ich bisher zwei Methoden benutzt: Stateless Autoconfiguration (SLAAC) und Zuweisung per DHCPv6. Da ein Interface mehrere Adressen haben kann, können auch beide gleichzeitig eingesetzt werden. Darüberhinaus gibt es wohl auch noch die zufällige Zuweisung (die vermutlich bei den Privacy Extensions Anwendung findet) und natürlich die statische Definition.

Bei Stateless Autoconfiguration wird vom Router eine Router-Advertisment-Nachricht mit dem Prefix gesendet. Der Empfänger der Nachricht kann dann dieses Prefix verwenden, mit einem aus der MAC-Adresse erzeugten Interface Identifier konkatenieren und hat somit eine vollständige (im Normalfall global eindeutige) IPv6-Adresse. Zur Kollissionsvermeidung kann noch eine Duplicate Address Detection durchgeführt werden. Da MAC-Adressen allerdings ebenfalls eindeutig sein sollten, sollte es im Normalfall nicht zu Kollissionen kommen.

Unique Local Addresses

Unique Local Addresses (ULA) sind Adressen in IPv6, die nicht global geroutet werden. Man sollte sie aber auf keinen Fall mit privaten IPv4-Adressen vergleichen, da man sonst Gefahr laufen könnte, NAT in das IPv6-Setup einzubauen. Wie oben geschrieben ist das zu vermeiden. Eine Unique Local Address ist, wie der Name schon sagt, eine lokale Adresse, die aber global eindeutig sein sollte. Hierzu erzeugt man sich zunächst eine zufällige Global ID von 40-Bit Länge. Dies kann beispielsweise mit einem Generator erfolgen, der eine MAC-Adresse und die aktuelle Uhrzeit verwendet. Man könnte aber ebenso 40 bit aus /dev/urandom lesen.

Zusammen mit dem ULA-Präfix 0xfd (8 Bit) ergibt die Global ID dann das Routing Prefix von 48 Bit Länge. Man kann dann selbst weiters 16 Bit für verschiedene Subnetze verwenden. Hat man nur ein Subnetz kann man diese 16 Bit einfach auf 0 setzen. Damit verbleiben dann wie im Schaubild oben wieder 64 Bit für den Interface Identifier, der wie zuvor aus der MAC erzeugt oder per DHCPv6 zugewiesen werden kann.

Diese so erzeugte Unique Local Address kann man nun ebenfalls dem Interface zuweisen. Ein und dasselbe Interface kann also nun folgende IPv6-Adressen haben:

• eine link-local Adresse
• eine oder mehrere globale IPv6-Adressen, z.B. aus MAC generiert und per DHCPv6 zugewiesen
• eine oder mehrere ULA-IPv6-Adressen, z.B. aus MAC generiert und per DHCPv6

Ich persönlich verwende ULA derzeit für einen Anwendungsfall, wo ich mehrere VMs zu einem VPN verbinden will. Jede VM erhält eine globale IPv6-Adresse, damit sie z.B. für System-Updates auf Paket-Server zugreifen kann. In einem klassischen IPv4-Setup hätte man vermutlich keine globale IPv4-Adresse zugewiesen und den Zugriff über ein NAT-Gateway gelöst, aber wir erinnern uns, wir wollen NAT vermeiden bei IPv6. Neben der globalen IPv6-Adresse erhält jeder Host noch eine ULA für das VPN. Die anderen Hosts kann er dann über deren ULA durch das VPN erreichen.

Fazit

Insgesamt gefällt mir IPv6 bisher sehr gut, insbesondere natürlich die Tatsache, dass ich VMs eine öffentliche IP-Adresse zuweisen kann, ohne für eine weitere IP-Adresse bezahlen oder mich rechtfertigen zu müssen. Leider muss man aber immer noch davon ausgehen, dass manche Nutzer nur IPv4 zur Verfügung haben (z.B. der österreichische Anbieter A1 hat die Einführung von IPv6 im Festnetz-Internet meines Wissens immer noch nicht vollständig durchgeführt), sodass man um einen Parallelbetrieb von IPv4 und IPv6 von öffentlichen Diensten leider nicht herumkommen wird.