[Berlin-wireless] IPv6-Internet in Freifunk

Alina Friedrichsen x-alina
Mi Nov 25 22:30:41 CET 2009


Um IPv6-Internet ins Freifunk-Mesh zu bringen, gibt es wiederum 3
verschiedene Moeglichkeiten, die alle ihre technischen und *politischen*
Vor- und Nachteile haben. Es geht vor allem darum das vom Provider nur
ein fester zusammenhoengender IP-Adressbereich dem/der KundIn nach Hause
geroutet wird. Die Bundeswehr hat dieses Problem nicht, da sie ihren
grossen Adressbereich selbst aufteilen koennen, und nicht auf ihren
Provider hoffen muessen.

* NAT bzw. IP-Masquerading
* Zentrale(r) VPN-Server
* und IP-Renumbering

NAT bzw. IP-Masquerading: Das ist in IPv4 die gaengige Methode. Dabei
werden alle ausgehenden Verbindungen auf eine einzige oeffentliche
Absender IP-Adresse gemappt. Dies ist aber mit relativ grossen Aufwand
(Conntrack) verbunden und geht auch nicht ohne Probleme. Erstens ist der
so ans Internet angebundene Rechner nicht uebers Internet erreichbar.
D.h. ausgehende Verbindungen, aber keine eingehenden Verbindungen
moeglich. Und zweitens muss fuer jedes komplexere Protokoll, das mit
mehreren Verbindungen arbeitet, extra ein Hack geschrieben werden, damit
es durch NAT funktioniert. Das ist z.B. der Grund dafuer, wieso
SIP-Telefone oft nicht ohne weiteres funktionieren. Ein Grund wieso IPv6
Entworfen wurde ist eigentlich um diese Probleme endlich abzuschaffen.
NAT waere technisch gesehen, also weniger schoen.

http://en.wikipedia.org/wiki/Network_address_translation

Zentrale(r) VPN-Server: Damit haetten wir die oben genannten Probleme
nicht. Wir wuerden einfach einen IP-Adressbereich, der gross genug ist,
das alle sich eine IP-Adresse daraus raus picken koennen, an den
Gateways in unser Mesh tunneln. Technisch waere problematisch, wenn
dieser eine oder wenige VPN-Server ausfallen, das gesamte Freifunk-Netz
vom Internet abgeschnitten waere. Politisch waere problematisch, wenn
das bewusst geschieht, z.B. bei einer Beschlagnahme, weil irgendjemand
Mist damit gebaut hat, oder PolitikerInnen sich entschlossen haben
Freifunk fuer "boese" zu halten. Des weiteren liesse sich mit einer
solch zentralisierten Struktur auch allen Traffic ins Internet an einen
oder wenigen Punkten abhoeren. Also vor allem politische Probleme, die
mir da Bauchschmerzen bereiten.

IP-Renumbering: Bei IPv6 ist es normal das sich eine IP-Adresse waehrend
des Betriebes aendern kann. Siehe z.B. die Privacy Extensions, die bei
Windows defaultmaessig aktiviert sind.
Nun ist die Idee, wenn der Adressbereich, den der Provider zum Gateway
routet gross genug ist, das eine IP-Adresse davon zu den anderen Nodes,
die kein Internet haben, z.B. getunnelt werden kann. So wuerde sich der
Node einfach eine oeffentliche IP-Adresse und eventuell ein Subnetz aus
den Adressbereich das Internet-Gateways ziehen koennen.
Bei einen Gateway-Wechsel muesste dann ein zweiter Tunnel aufgebaut
werden und sich eine weitere IP-Adresse ziehen.
In Kombination mit Policy Routing liesse sich damit sogar ein
schmerzfreier Wechsel der Gateways erreichen. Pakete mit einer
Absender-Adresse im Bereich des alten Gateways liessen sich in dieses
routet, Pakete mit einer Absender-Adresse im Bereich des neuen Gateways
liessen sich das neue routen. So das es keine Verbindungsbrueche gebe,
wenn das alte Gateway nicht komplett tot ist.
So koennte der Node sich ein Buendel von oeffentlichen IPs zu legen, mit
denen er im Normalfall immer im Internet erreichbar ist.
Und wenn schon IPv6 ueber einen End-to-End Tunnel ins Internet geroutet
wird, liesse sich das natuerlich auch mit IPv4 machen.
In einen weiteren Schritt liessen sich beide Tunnel auch mit IPSec
verschluesseln.
Als Kritikpunkt an dem Konzept wird angemerkt, das eventuell
08/15-Provider in der Zukunft aus politischen Gruenden nicht ausreichend
IPv6-Adressen routen werden.
Dann liessen sich welche von einen der vielen kostenlosen Tunnel-Broker
besorgen.
Sven-Ola meinte pessimistisch, das er glaube das diese ihr Angebot
einstellen werden, sobald IPv6 ausreichend Verbreitung findet. FunkFeuer
hat sich ein ganzes Buendel IPv6-Adressen gesichert, die wir im Notfall
benutzen koennten. Und als letzten Fallback liesse sich natuerlich auch
hierbei NAT verwenden. *wuerg*
Die Endscheidung, was verwendet wird liege hierbei bei dem/der
Uplink-BetreiberIn und waere nicht Mesh-weit festgelegt. Das halte ich
fuer ein sehr wichtiges Feature.

In der naechsten E-Mail werde ich Moeglichkeiten zur Autokonfiguration
der Nodes behandeln. Kurz: Mensch kann es sich einfach machen oder
schwer.

Alina






Mehr Informationen über die Mailingliste Berlin