6to4
IPv6-Übergangsmechanismen | |
---|---|
4in6 | Tunneling von IPv4 in IPv6 |
6in4 | Tunneling von IPv6 in IPv4 |
6over4 | Transport von IPv6-Datenpaketen zwischen Dual-Stack Knoten über ein IPv4-Netzwerk |
6to4 | Transport von IPv6-Datenpaketen über ein IPv4-Netzwerk (veraltet) |
AYIYA | Anything In Anything |
Dual-Stack | Netzknoten mit IPv4 und IPv6 im Parallelbetrieb |
Dual-Stack Lite (DS-Lite) | Wie Dual-Stack, jedoch mit globaler IPv6 und Carrier-NAT IPv4 |
6rd | IPv6 rapid deployment |
ISATAP | Intra-Site Automatic Tunnel Addressing Protocol (veraltet) |
Teredo | Kapselung von IPv6-Datenpaketen in IPv4-UDP-Datenpaketen |
NAT64 | Übersetzung von IPv4-Adressen in IPv6-Adressen |
464XLAT | Übersetzung von IPv4- in IPv6- in IPv4-Adressen |
SIIT | Stateless IP/ICMP Translation |
6to4 (auch STF oder 6 to 4 genannt) war ein IPv6-Übergangsmechanismus. Hierbei wurden Tunnel im Internet aufgebaut, um IPv6-Pakete über IPv4 transportieren zu können.
Funktionsweise
Bei 6to4 wurde auf jede IPv4-Adresse ein /48 großes IPv6-Netz abgebildet. Das IPv6-Präfix setzte sich aus dem Präfix 2002 und der hexadezimal notierten IPv4-Adresse zusammen. Der lokale Host oder Router mit öffentlicher IPv4-Adresse schachtelte ein IPv6-Paket in ein IPv4-Paket. Sollte das Paket ein natives IPv6 Netz erreichen, wurde es an ein 6to4-Relay geschickt. Dort wurde das IPv6-Paket wieder ausgepackt und ans Ziel geschickt. Sendete der entfernte Host etwas zum lokalen Host zurück, wurde das Paket nicht zwingend wieder über dasselbe 6to4-Relay geleitet, sondern konnte über jedes beliebige 6to4-Relay geroutet werden.
Pakete, die an IPv6-Adressen aus diesem Netz gesendet wurden, konnten eindeutig zugeordnet werden. Aufgrund des Präfix 2002 wurden sie an ein 6to4-Relay geleitet und von dort aus wurde anhand der IPv4-Adresse, die aus der IPv6-Adresse abgeleitet werden konnte, das Paket wieder zum lokalen Host und gegebenenfalls von dort aus zu einem Host im dahinter liegenden IPv6-Netz geleitet.
Öffentliche 6to4-Relays stellten einfache Zugänge ins IPv6-Netz dar, die keiner Anmeldung bedurften und von allen genutzt werden konnten.
Zur weiteren Vereinfachung musste der Benutzer nicht explizit die IPv4-Adresse eines 6to4-Relays ermitteln, sondern konnte über die Anycast-Adresse 192.88.99.1 (bzw. 2002:c058:6301::) das nächste öffentliche 6to4-Relay[1] erreichen.
Reverse DNS
Über ein Webinterface bei der Number Resource Organization gab es die Möglichkeit, die passende reverse Domäne für den 48-Bit-Präfix unter 2.0.0.2.ip6.arpa auf einen eigenen Nameserver zu delegieren.[2] Dies war jedoch nur sinnvoll, wenn man eine permanent zugewiesene IPv4-Adresse nutzte und keine dynamische IPv4-Adresse von einem Provider zugewiesen bekam.
Sicherheitsaspekte
Bei der Verwendung von 6to4 waren einige Sicherheitsaspekte zu beachten. Aufgrund der offenen Architektur musste ein 6to4-Host beziehungsweise -Router gekapselte Pakete von allen IPv4-Adressen empfangen und verarbeiten. Dadurch war beispielsweise ein IP-Spoofing einfach zu bewerkstelligen.
Sicherheitshinweise zum Betrieb eines 6to4-Hosts, -Routers oder -Relays sind in RFC 3964 beschrieben.
Datenschutzaspekte
IP-Adressen gelten nach höchstrichterlicher Rechtsprechung als personenbezogene Daten, da mit ihnen ein Personenbezug (zumindest zum Anschlussinhaber) hergestellt werden kann. Bei der Verarbeitung von IP-Adressen dürfen daher, nach Ansicht des Düsseldorfer Kreises, nur gekürzte Adressen verwendet werden, das heißt, dass beispielsweise das letzte Oktett einer IPv4-Adresse ausgenullt wird, so dass kein Personenbezug mehr herstellbar ist, andere IP-adress-basierte Dienste, wie beispielsweise Geolokation, aber weiterhin möglich bleiben.
Bei IPv6-Adressen wird ein Kürzen auf maximal 40 Bit empfohlen.[3] Es blieben somit nach dem 16-Bit-Präfix 2002 noch die obersten 24 Bit der IPv4-Adresse des Anschlussinhabers übrig, womit kein Personenbezug mehr herstellbar sein soll.
Probleme für den Benutzer
Aufgrund der Fehlerrate der 6to4-Umsetzung durch Verwendung des Anycasts schienen diverse Inhalte über IPv6 schlecht erreichbar. Eine scheinbare Lösung für den Endbenutzer bestand dann darin, IPv6 zu deaktivieren, wodurch die weitere Verbreitung von IPv6 behindert wurde. Im technischen Dokument RFC 7526 wird daher empfohlen, 6to4 Anycast nicht mehr zu verwenden. Abhilfe bei der Verwendung von 6to4 bot der "Happy-Eyeballs"-Algorithmus, der in RFC 6555 beschrieben ist und von mehreren Browsern eingesetzt wird. Dabei wird eine Website sowohl über IPv4 als auch IPv6 adressiert und die erste Antwort verwendet.
Alternativen
Andere Mechanismen, mit denen sich IPv6-Pakete in IPv4 tunneln lassen, sind unter anderem
- Teredo,
- ISATAP und
- Tunnelbroker.
Ein Vergleich der Tunnelmechanismen findet sich unter IPv6#Tunnelmechanismen.
Aktuelle VPN-Software kann ebenfalls zum Tunneln von IPv6 über IPv4 und umgekehrt eingesetzt werden, z. B. Cisco AnyConnect oder OpenVPN.
Literatur
- 6to4, Kapitel in Understanding IPv6 (S. 295–316) von Joseph Davies. Microsoft Press, 2. Auflage, Redmond 2008. (englisch)
Einzelnachweise
- ↑ RFC 7526, Anycast Server historisch
- ↑ http://6to4.nro.net/
- ↑ 84. Konferenz vom 7./ 8. November 2012 - Einführung von IPv6 - Hinweise für Provider im Privatkundengeschäft und Hersteller (Memento vom 11. Dezember 2013 im Internet Archive), abgerufen am 13. Juni 2018
Weblinks
- http://www.feyrer.de/IPv6/ueberreuter-6to4.html
- http://wiki.debian.org/DebianIPv6 Konfigurationshinweise für die Linux-Distribution Debian
- Definition von 6to4 Adressen: RFC 3056
- Sicherheitshinweise: RFC 3964
- 6to4 Anycast Adressen: RFC 3068
- Public 6to4 Gateway Services + Linux shellscript
- 6to4 bei Debian/Ubuntu einrichten http://pastebin.com/9W5PPRBd
- JavaScript 6to4-Adressumrechner