© Sculpies, 123RF

IPv4 hat noch lange nicht ausgedient – gleichzeitig gewinnt IPv6 speziell im asiatischen Raum an Einfluss. Um auch in Zukunft die volle Konnektivität im Betrieb gewährleisten zu können, muss sich der Admin etwas einfallen lassen. Die Lösung heißt Dualstack.

Einem Teil der Administratoren bleibt in den nächsten Jahren das Thema IPv6 noch erspart. Sie verfügen über genug IPv4-Adressen, um den Zugang ihrer Netze mit Hilfe der Network Address Translation zum Internet-4 zu gewährleisten. Ein Zugang zum Internet-6 ist nicht erforderlich, da hier bislang noch keine unternehmenskritischen Dienstleistungen bereitstehen.

Dies trifft jedoch nicht auf alle Admins und Netze zu. Es existieren inzwischen einige Einsatzszenarien, die eine Beschäftigung und Einführung von IPv6 doch ratsam erscheinen lassen. Vorweg sollte allerdings jedem Admin klar sein, dass eine komplette Umstellung von IPv4 auf IPv6 in den nächsten zehn Jahren sehr unwahrscheinlich ist.

Welche Gründe gibt es aktuell für die partielle Einführung von IPv6? Eine Firma arbeitet zum Beispiel mit Kunden oder Partnern in Fernost zusammen. Die sind oft bereits seit einigen Jahren über doppeltes NAT ans Internet angebunden. Denn viele Provider im asiatischen Raum vergeben seit geraumer Zeit aus Adressenknappheit nur private IP-Adressen an ihre Kunden und maskieren diese. Die Kunden verwenden ebenfalls Router, die die intern verwendeten privaten IP-Adressen umwandeln. Das führt vor allem mit VPN und VoIP oft zu Schwierigkeiten und stellt viele Admins vor Probleme.

Keep it simple

Mit IPv6 verfügen die Kunden über globale Adressen für jedes System, was deren Konnektivität gewährleistet. Darum steht zu erwarten, dass viele asiatische Internetnutzer relativ schnell auf native IPv6-Zugänge wechseln werden. Wer mit ihnen in Kontakt treten will, muss zumindest seinen Router umrüsten auf den so genannten Dualstack.

Die bisher nur über IPv4 erreichbaren Systeme muss der Admin zusätzlich mit IPv6-Adressen ausstatten. Hier stellt sich ihm die Frage, woher er diese erhält. Als üblicher Ansprechpartner gilt der aktuelle Provider, der auch die IPv4-Adressen bereitstellt. Allerdings bieten derzeit nur wenige in Mitteleuropa einen nativen IPv6-Zugang an. Hier gilt es aktuell, Tunnel zu nutzen. Diese baut der Admin mit IPv4 zu einem IPv6-Tunnelbroker auf, der über den Tunnel den Zugang zum Internet-6 bereitstellen. Auch bieten sie IPv6-Adressen (meist als /48-Präfix) und routen diese durch den Tunnel.

Das professionelle Umfeld bedienen vor allem die Unternehmen Sixxs [1] und Hurricane Electric [2]. Nach der Registrierung stellen sie, aktuell noch kostenlos, Tunnel und IPv6-Adressen bereit. Diese tragen sie in ihren Whois-Servern ein, sodass für Dritte die Weitergabe der Adressen nachvollziehbar bleibt.

Für den Aufbau der Tunnel gibt es unterschiedliche Methoden. Sie unterscheiden sich im Wesentlichen dadurch, ob der Tunnel-Endpunkt bei dem Kunden über eine statische globale, dynamische oder über eine private maskierte IPv4-Adresse verfügt. Im ersten Fall genügt es unter Debian, ein zusätzliches Tunnel-Device mit dem folgenden Eintrag in der »/etc/network/interfaces« anzulegen:

iface ipv6tunnel inet6 v4tunnel
endpoint BrokerIPv4Adresse
local LokaleIPv4Adresse
address LokaleIPv6Adresse
netmask 64
mtu 1480
gateway BrokerIPv6Adresse
ttl 255

Das ermöglicht es dem System, durch den Tunnel auf das Internet-6 zugreifen. Routet der Tunnelbroker ein IPv6-Präfix durch den Tunnel, verteilt der Admin dies mit einem Router-Advertisement-Daemon oder DHCPv6 in seinem Netz. Optional stattet er die Systeme auch mit festen IPv6-Adressen aus. Da die Hosts nun sowohl über eine IPv4- als auch eine IPv6-Konnektivität verfügen, heißt diese Lösung auch Dualstack-Betrieb.

Dualstack-Lite oder NAT64?

Trotz der IPv4-Adressenknappheit sollen die Verfahren Dualstack-Lite und NAT64 den Zugang der Kunden in das Internet-4 gewährleisten. Bei beiden weist der Provider dem Kunden eine globale IPv6-Adresse für den Router und ein Präfix für die hinter dem Router befindlichen Systeme zu.

Über diese globalen IPv6-Adressen kommunizieren sowohl der Router als auch die weiteren Systeme mit Servern via IPv6. Die beiden Verfahren unterscheiden sich darin, wie sie dem Kunden zur Verfügung stehen. Beim Dualstack-Lite (Abbildung 1) weist der Provider dem Router des Kunden zusätzlich eine private IPv4-Adresse zu.

Abbildung 1: Bei Dualstack-Lite spart der Provider globale IPv4-Adressen, indem er selbst das NAT von privaten IPv4- auf globale IPv4-Adressen (NAT44) übernimmt.

Der Router verteilt seinerseits private IPv4-Adressen per DHCP im internen System. Diese besitzen nun eine globale IPv6- und eine private IPv4-Adresse, jeweils mit Default-Gateways, die auf den Router zeigen. Ruft nun ein Anwender eine Webseite auf, führt das System zunächst eine Namensauflösung durch. Enthält die Antwort nur eine IPv6-Adresse, greift der Host über seine globale IPv6-Adresse auf das Zielsystem zu. Enthält die DNS-Antwort sowohl eine IPv4- als auch eine IPv6-Adresse, bevorzugen aktuelle Betriebssysteme IPv6 und greifen ebenfalls damit auf das Zielsystem zu. Nur bei reinen IPv4-Zielen kommt Dualstack-Lite zum Einsatz.

Der Client verschickt ein IPv4-Paket mit seiner privaten Absenderadresse, die der Router zunächst maskiert und mit seiner eigenen private Absenderadresse maskiert. Anschließend kapselt der Router das Paket in einem IPv6-Paket und schickt es damit an ein spezielles System beim Provider. Dieses System extrahiert das IPv4-Paket wieder und nattet (NAT44) es auf eine globale IPv4-Adresse. Dazu setzt der Provider besonders leistungsstarke Carrier-Grade-NAT-Komponenten (CGN) ein.

Einige Hersteller bezeichnen dieses System auch als Address Family Transition Router (AFTR). Einen derartigen AFTR kann der Admin des Providers auch mit Linux und dem AFTR-Softwarepaket des Internet Software Consortium [3] realisieren. Da der Router des Kunden keine globale IPv4-Adresse mehr besitzt, kann er auch keine Dienste wie Dyn DNS oder Portforwarding nutzen. Das geschieht jetzt nur noch, dafür aber auch besser, über IPv6.

Bei der zweiten Variante, dem NAT64, nutzt der Provider einen anderen Ansatz, um dem Kunden den Zugriff auf das Internet-4 zu ermöglichen. Er erhält nur globale IPv6-Adressen für seinen Router und die dahinter befindlichen Systeme.

IPv4 nur im Notfall

Wichtig ist, dass diese Systeme für ihre Namensauflösung nur den DNS-Server des Providers nutzen. Dafür gibt es drei Möglichkeiten:

• Die Namensauflösung liefert nur eine IPv6-Adresse: Die Clients greifen über ihre globale IPv6-Adresse auf das Zielsystem zu.
• Die Namensauflösung liefert sowohl eine IPv4- als auch eine IPv6-Adresse: Die Clients bevorzugen die IPv6-Adresse und greifen auf das Ziel zu.
• Die Namensauflösung liefert nur eine IPv4-Adresse: Hier reagiert der DNS-Server des Providers und fälscht in seiner Antwort an den Client zusätzlich eine IPv6-Adresse und fügt diese seiner Antwort hinzu.

Dafür hängt er die hexadezimale Repräsentation der IPv4-Adresse an ein vorher definiertes IPv6-Präfix an. Hierbei wählt der Admin des DNS-Servers das hierzu optional reservierte Präfix 64:FF9B::/96 oder auch einen freien Bereich aus seinem Fundus der IPv6-Adressen. Der Client erhält nun in der DNS-Antwort wieder sowohl eine IPv4- als auch eine IPv6-Adresse und bevorzugt die IPv6-Adresse. Das entsprechende Paket sendet er an das Default Gateway bei seinem Provider.

Dort erkennt der Router die gefälschte IPv6-Adresse an dem verwendeten Präfix. Das System extrahiert die eingebettete IPv4-Adresse und führt eine Network Address Translation und Protocol Translation von IPv6 auf Ipv4 durch. Dieses Verfahren bezeichnen die Entwickler als NAT64 (Abbildung 2). Das erforderliche DNS Application Layer Gateway nennen sie DNS64.

Abbildung 2: Bei NAT64 fälscht der Provider eine IPv6-Adresse, um später diese Zugriffe auf IPv4 zu maskieren.

Für Linux gibt es dafür mehrere Implementierungen. So erlaubt Bind in seiner neuesten Version bereits den Einsatz als DNS64-Server. Für die NAT64-Komponente existieren sowohl die Userspace-Applikation Tayga [4] als auch eine Kernelkomponente Ecdysis [5].

Ein vermeintliches Problem beim Einsatz von NAT64 stellt die zunehmende Verbreitung von DNSSEC dar, das Veränderungen und damit ein technisches Fälschen der DNS-Antworten erkennt und entsprechende Antworten ignoriert.

NAT-PT

Das RFC 2766 beschrieb bereits im Jahr 2000 einen Network Address Translator/Protocol Translator namens NAT-PT, der im Gegensatz zu NAT64 zusätzlich auch ein NAT46 anbietet. Damit sollen nicht nur IPv6-Systeme auf beliebige IPv4-Ziele, sondern umgekehrt IPv4-Systeme auch auf beliebige IPv6-Ziele zugreifen. Da sich IPv4-Adressen problemlos in eine gefälschte IPv6-Adresse einbetten lassen, ist ein NAT64 recht einfach implementierbar. Der umgekehrte Weg erweist sich als deutlich komplizierter.

Der IPv4-Adressraum bietet zu wenig Platz, um beliebige IPv6-Adressen in gefälschte IPv4-Adressen einzubetten. Das verhindert, dass DNS46 und NAT46 unabhängig voneinander agieren, denn sie müssen ständig die Informationen untereinander austauschen. Obwohl einige funktionsfähige Implementierungen existieren, wurde 2007 aufgrund vielfältiger Probleme das RFC 2766 für NAT-PT in den historischen und unerwünschten Status versetzt (RFC 4966).

Für ein reines IPv4-System gibt es daher gegenwärtig keine Lösung für einen Zugriff auf Hosts, die nur über IPv6 erreichbar sind. Abhilfe schafft an dieser Stelle lediglich ein Dualstack-Proxy. Mit diesem verbinden sich die Clients dann per IPv4, um das IPv6-Zielsystem zu erreichen. Allerdings unterstützt diese Technik nur Protokolle, die das Nutzen von derartigen Application Layer Gateways erlauben. Dazu zählen DNS, SMTP, HTTP oder HTTPS.

Ausblick

Da nur sehr wenige aktuelle DSL-Router IPv6 unterstützen, müssen die Provider vor der flächendeckenden Einführung von IPv6 die Endgeräte bei den Kunden austauschen. Das ist mit Kosten verbunden, die der Endkunde nicht zu tragen bereit sein wird. Daher werden die Provider diesen Austausch möglichst lange hinauszögern.

Dies führt dazu, dass viele ISPs den administrativen Aufwand scheuen, ihre Dienste zusätzlich über IPv6 anzubieten. Trotz des erfolgreichen IPv6-Day im Juni, an dem viele Anbieter ihren Service für einen Tag zusätzlich über IPv6 anboten, stellten prominente Teilnehmer wie Facebook, Google und Youtube ihren Dualstack-Betrieb aktuell wieder ein.

Fazit

So lange die großen Dienstleister ihr Angebot nicht per IPv6 ins Netz stellen, ist dieses Protokoll relativ uninteressant. Bis sich das ändert, werden die DSL-Provider wahrscheinlich auch hierzulande beginnen private IPv4-Adressen zu verteilen. E-Plus und Base bedienen sich dieser Praxis bereits seit Jahren für ihre GPRS- und UMTS-Zugänge.