[Berlin-wireless] IPv6 Routing-Konzepte fuer Freifunk

[Daniel Paufler]

Hallo Alina, et.al

Nun ein paar Kommentare von mir.

Alina Friedrichsen wrote:
> 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.
Meine Recherchen haben leider keine Software zu Tage gefördert, mit
welcher wir unseren eigen Tunnel-Broker-Server betreiben und unseren
eigenen IPv6 Block verteilen können. Deshalb halte ich das nicht
wirklich für praktikabel, da ich nicht auf externe Broker für die
Mesh-Kommunikation setzen will.

> 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.
Ist imo sinvoll - auch parallel zu 4to6.

> 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.
Das ist imo die Zuknunft. Meine Recherchen haben mich vor ca. 1.5 Jahren
dahin gebracht - damals noch SIIT genannt und von den Russen
implementiert. Siehe auch
http://download.berlin.freifunk.net/pdf/vortrag/6mesh/freifunk-ipv6-mesh-siit-praesentation.pdf

Wie lynxis schon schreibt - das ist einfach zu implementieren und kann
ggfs. auch über dual-stack gefahren werden, damit das IPv4 routing nicht
_komplett_ und _auf einmal_ abgeschaltet werden muss. Aber: Anreize
schaffen und Funktionalität sicherstellen.

Imo ist Stufe 1 das parallele betreiben von IPv4 und IPv6. Dann sollten
einige Knoten nur noch IPv6 sprechen und die Border-Teile SIIT/NIIT/was
auch immer/ machen und IPv4 über IPv6 Tunneln. Wenn das geht, können wir
nach und nach das alte IPv4 mesh-routing abschalten - da IPv6 und
encapsulation/tunnel funktionieren.

Das wir das ohne NAT machen sollten ist ja klar ;)

Grüße

Daniel


-- 
Dipl. Inf. (FH) Daniel Paufler
Angewandte Informatik - Computer Aided Facility Management

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 261 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20091128/42d9ce4b/attachment.pgp>