[Berlin-wireless] IPv6 Routing-Konzepte fuer Freifunk

[Alexander Couzens]

> Also, im Grunde gibt es 3 grundsaetzliche Konzepte um IPv6 und IPv4
> parallel ueber ein Computer-Netz bzw. Mesh zu routen, je nach dem wie
> stark auf die Abwaertskompatibilitaet zur alten IPv4-Infrastruktur
> Ruecksicht genommen werden soll.
> 
> * 6to4-Tunnel
> * Dual Stack
> * und 4to6-Tunnel (fuer die es noch kein RFC gibt, Alex' Entwicklung,
> die er aus Gesichtswahrungsgruenden "NIIT" nennt.)

nee. der name war meine Kreation.
ich hab es sinngemaes niit nach der niete genannt :). 

> 6to4-Tunnel: Das erste Konzept, die 6to4-Tunnel, hatte ich
> urspruenglich fuer Berlin vorgeschlagen weil es am kompatibelsten zu
> den festgefahrenen IPv4-Strukturen hier ist. Bei diesen Konzept
> muessen naemlich nur Sender- und Empfaenger-Node IPv6 sprechen alle
> anderen Nodes auf der Strecke brauchen auch weiterhin nur IPv4. Bei
> 6to4-Tunneln wird das IPv6-Paket in ein IPv4-Paket gepackt und an
> eine IPv4 Empfaenger-Adresse gesandt, die sich aus der IPv6-Adresse
> ergibt. Die IPv4-Adresse zu der es soll, ist in der IPv6-Adresse
> kodiert. Beim Empfaenger wird das IPv6-Paket dann wieder ausgepackt
> und lokal weiter geroutet.

> Dual Stack: Die Dual Stack Variante waere das zweit
> abwaertskompatibelste Konzept. Fuer das IPv6-Routing muessten dabei
> alle Nodes auf der Strecke auch IPv6 sprechen, aber das IPv4-Routing
> wuerde ebenfalls so erhalten bleiben, wie es jetzt ist. Damit das
> funktioniert muessen die Nodes das Routing-Protokoll fuer beide
> IP-Versionen parallel laufen lassen. Momentan muss dazu der olsrd
> zwei mal gestartet werden, dass das auch mit einer Instanz laeuft ist
> von den EntwicklerInnen in Zukunft geplant.

ich bin gegen dualstack. da es meiner Meinung die Entwicklung nur
behindert. Siehe die amd64 arch. das legacy stoert nur.

> 4to6-Tunnel: Das dritte Konzept waere eher etwas fuer ein zukuenftiges
> IPv6-only Mesh, ueber das dann dennoch IPv4-Pakete geroutet werden
> sollen. Das komplette IPv4-Routing wuerde erstmal eingerissen, was
> Verwaltungsaufwand sparen wuerde. Also nur noch IPv6. Um dann dennoch
> IPv4-Pakete ueber das Mesh routen zu koennen, kaeme ein Tunnel
> aehnlich den oben beschriebenen 6to4-Tunnel zu Einsatz, blos anders
> herum. Also das die IPv4-Pakete in IPv6-Paketen verpackt werden. Die
> IPv6-Adresse an die das Paket soll errechnet sich dabei wiederum aus
> der IPv4-Adresse. Die in IPv6 umgerechnete IPv4-Adresse muss der
> Empfaenger dabei als HNA ankuendigen, wo das IPv4 Paket dann wieder
> entpackt und lokal in die IPv4-Welt weiter geroutet wird.

Ich halte 4to6 die bessere Moeglichkeit, da es erstmal schneller zu
realisieren ist. 6to4 macht mehrere Probleme und loest ausserdem nicht
das ip vergabe Problem.

Es gibt btw. noch ein paar Probleme, wenn wir weiter denken in Richtung
ipv6 only. Da kommt dann das nat Problem z.B. zum Tragen. Wir sollten
(!) freifunk ohne NAT basteln. 

Wir haben ein Mesh mit vielen Nodes.
Es gibt mehrere Nodes die als Gateway konfiguriert sind.
jetzt schauen wir uns 2 Nodes davon an;
- node GW ist gateway und hat dsl per ipv6
- node CL ist client.

node GW : macht ein hna6 200/3
node CL : moechte jetzt ins Internet und waehlt mit olsr die
node GW aus. Nun braucht die node CL das ipv6 prefix vom DSL anschluss
der node GW. Wie wird das kommuniziert ? Da gibt es jetzt mehrere
Ansaetze. Meiner Meinung muesste das ganze stateful gemacht werden.
Vielleicht dann per IPIP Tunnel (ipv6 natuerlich)

Ich hoffe es finden sich ein paar leute auf der c-base heute abend ein
zur Diskussion.


gru:c lynxis