Arbeitsgruppe IPv6 im Mesh: Unterschied zwischen den Versionen
(Beschreibung der Ausgangssituation) |
(6to4 basics) |
||
| Zeile 11: | Zeile 11: | ||
* Die Routingtabelle für jedes Protokoll extra zu berechnen macht nicht wirklich viel Sinn | * Die Routingtabelle für jedes Protokoll extra zu berechnen macht nicht wirklich viel Sinn | ||
* Bei Verwendung einer klassischen Tunnellösung geht interner traffic vom Mesh zu einem zentralen Server und wieder zurück ins Mesh. Das ist nicht schön. | * Bei Verwendung einer klassischen Tunnellösung geht interner traffic vom Mesh zu einem zentralen Server und wieder zurück ins Mesh. Das ist nicht schön. | ||
| + | |||
| + | ==Lösungsvorschläge== | ||
| + | ===6to4 Tunnel=== | ||
| + | Bei IPv6 gibt es einen eigenen Prefix (2002:/16) unter dem jeder IP4 Adresse ein (ziemlich großes) IP6 Subnetz zugeornet ist. Diese Adressen sind zum Übergang zwischen IPv4 und IPv6 gedacht. | ||
| + | |||
| + | ====Vorteile==== | ||
| + | * Es muss kein eigener IP6 Adressblock registriert/verwaltet werden | ||
| + | * Die Infrastruktur von IPv4 kann mitbenutzt werden | ||
| + | * Pakete zwischen Mesh Nodes gehen über den natürlichen Weg im Mesh | ||
| + | * Es funktioniert mit allen relevanten Firmwares | ||
| + | |||
| + | ====Nachteile==== | ||
| + | * Eigene IP6 Blöcke können nicht im Internat angekündigt werden | ||
| + | * Ein 6to4 anycast server in unserer Nähe wäre fein | ||
| + | |||
| + | ====Funktionsweise beim Routen eines Pakets==== | ||
| + | Wenn wir ein IP6 Route haben: Wir benutzen diese | ||
| + | |||
| + | Die Zieladdresse ist eine 6to4 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die IP4 Adresse des zuständigen Gateways. | ||
| + | |||
| + | Die Zieladdresse ist eine andere IP6 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die 6to4 anycast Adresse (192.88.99.1). | ||
==Was wir schon haben== | ==Was wir schon haben== | ||
Version vom 16. August 2008, 04:40 Uhr
Achtung dies ist ein WoW (Maintainer: siehe Changelog)
und wenn dieses blöde Mediawiki nicht gerade meine Arbeite gefressen hätte, dann wäre hier auch schon ur viel zu lesen. *grml*
Inhaltsverzeichnis
IPv6 im Mesh
Es gibt ca. 2 Mrd. öffentliche IPv4 Adressen. Davon sind ca 74% unter der Kontrolle der USA, vom Rest hab' ich allein 5 bei Funkfeuer registriert und muss trotzdem NAT verwenden. Da dies eher unbefriedigend ist, wurde IPv6 entwickelt, das aber bisher noch nicht wirklich große Verbreitung gefunden hat. Was liegt also näher als diese neue Technologie in einem experiementellen Netz wie Funkfeuer auszuprobieren?
Probleme
- Mittelfristig werden nicht alle Router IP6 Forwarding unterstützen
- Die Routingtabelle für jedes Protokoll extra zu berechnen macht nicht wirklich viel Sinn
- Bei Verwendung einer klassischen Tunnellösung geht interner traffic vom Mesh zu einem zentralen Server und wieder zurück ins Mesh. Das ist nicht schön.
Lösungsvorschläge
6to4 Tunnel
Bei IPv6 gibt es einen eigenen Prefix (2002:/16) unter dem jeder IP4 Adresse ein (ziemlich großes) IP6 Subnetz zugeornet ist. Diese Adressen sind zum Übergang zwischen IPv4 und IPv6 gedacht.
Vorteile
- Es muss kein eigener IP6 Adressblock registriert/verwaltet werden
- Die Infrastruktur von IPv4 kann mitbenutzt werden
- Pakete zwischen Mesh Nodes gehen über den natürlichen Weg im Mesh
- Es funktioniert mit allen relevanten Firmwares
Nachteile
- Eigene IP6 Blöcke können nicht im Internat angekündigt werden
- Ein 6to4 anycast server in unserer Nähe wäre fein
Funktionsweise beim Routen eines Pakets
Wenn wir ein IP6 Route haben: Wir benutzen diese
Die Zieladdresse ist eine 6to4 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die IP4 Adresse des zuständigen Gateways.
Die Zieladdresse ist eine andere IP6 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die 6to4 anycast Adresse (192.88.99.1).
Was wir schon haben
- Einen großen Block IP6 Adressen
- natives IP6 im housing
- öffentliche IP4 Adressen auf allen Routern
