Architektur-Babel

Hinweis: Dieser Artikel beschreibt nicht das aktuelle KBU-Netz aus konzeptioneller Sicht und erklärt viele, tiefe Details. Um einfach mitzumachen musst Du nicht alles davon verstehen - wenn Du Interesse hast, lese einfach weiter :-).

Dieser Artikel beschreibt eine vom KBU-Netze abweichende, mögliche Konfiguration. Sie ist ISP (d.h. VPN-Provider) unabhängig und verzichtet auf eine Node-Hierachie (Node, Supernode).

Hierbei schildert die Einleitung zunächst verschiedene Probleme des aktuellen KBU-Netzes und Ideen für eine Verbesserung. Aus diesen Punkten werden Ziele und Anforderungen hergeleitet, die zu denen Umsetzungen vorgeschlagen werden.

Kurzzusammenfassung

• ISP / VPN-Provider unabhängig.
• Routing via Babel (Backbone + Adhoc)
• Roaming über batman-adv

Einleitung

Stand 04/2016 verwendet das KBU-Netz batman-adv auf allen links (auch VPN). Server erfüllen die Aufgabe der Supernodes. Broadcasts belasten das Netz dort.

Einschränkungen

Ein paar Dinge sind im batman-adv-Netz (Stand: Q1/2016) unschön

Hohe Last durch batman-adv über VPN-Links

batman-adv ist nicht dafür gedacht auf in VPNs verwendet zu werden. Algorithmus und Metrik ermitteln fortlaufend die Verbindungsqualität und belasten die VPN-Verbindung. Das Qualität ändert sich aber kaum (keine Funkstörung, VPN ist eingeschaltet oder aus), so dass viel Overhead entsteht. IP-Router (häufig Server in RZ) werden hierdurch enorm belastet

Viel broadcast-Traffic durch Roaming über Hoods

batman-adv-Metadaten werden im ganzen Stadtgebiet verteilt und erlauben ein Roaming innerhalb einer Hood. Der Aufwand ist aber unnnötig. Kaum jemand wird bspw. von Lindweiler nach Porz roamen. Es gibt noch nicht einmal eine durchgehende Funkverbindung. Dabei belegen die Metadaten viel Wifi-Kapazität (d.h. airtime).

Einstiegshürde

Neue Freifunk-Communities (bspw. Troisdorf, Hennef) müssen am Anfang recht viel Know-How ohne Freifunk-Bezug mitbringen (Konfiguration von Server, Supernodes). Besser wäre, die Einstiegshürde niedrig zu halten. Eine Hand voll OpenWRT-Router sollte ausreichen, um ein Freifunk-Netz aufzubauen.
Neue Freifunk-Communities sollten nicht vor der Herausforderung stehen, dass sie Server für den Betrieb auftreiben oder einen eigenen Verein gründen müssen. Werden wichtige Server von Einzelpersonen betrieben, besteht immer das Risiko, dass Sie weniger Zeit haben oder aussteigen und das gesamte Netz beeinträchtigt wird.

Neue Communities sind für die Dezentralität extrem wichtig. Um so mehr Communties sich finden und ihre Netze bauen, desto dezentraler wird Freifunk. Alle Netze existieren unabhängig voneinander.

Abhängigkeit von Servern, Personen, ISPs

Das Freifunk-Netz sollte von niemanden einfach abgeschaltet werden können:

• Aktuell betreiben 1-2 Personen fast alle Supernodes in den Hoods - mehrere hundert nodes sind von ihnen abhängig
• Das Netz sollte auch nicht einem einzelnen ISP- oder Verein abhängen, der den Abuse-Desk betreibt. Ein passender abuse-Desk ist zwar wichtig - andernfalls erreichen Abmahnungen den Node-Aufsteller - aber das Netz sollte nicht auf einen Provider festgelegt sein. Bspw. sollte ein Node hide.me und ein anderer den Freifunk Rheinland e.V. nutzen können.

Konzeptionelle Sicht

Es gibt bereits einige Ansätze wie lokale Supernodes auf Futro-Hardware, die einige Nachteile adressieren. Viele Einschränkungen und Kompromissen entstehen durch die Konzeptionierung des Freifunk-Netzes. Für die vorgestellten Einschränkungen sind u.a. folgende Punkte wichtig:

Verschiedene Nodes nacheinander nutzen (Roaming)

Es ist hilfreich in einem bestimmten Gebiet (z.B. ein Gebäude) roamen zu können. Dabei kann sich ein Client mit verschiedenen Nodes verbinden, ohne dass Netzwerkverbindungen abreißen. Damit ein Client roamen kann, müssen Daten zwischen in Frage kommenden Nodes ausgetauscht werden. Der Bereich sollte nicht zu groß gewählt werden, damit nicht unnötig viele Daten übertragen werden müssen.

Verschiedene IPv6-Adressen im Netz (Multihoming)

Wenn mehrere ISPs verwenden werden, gibt es viele IPv6-Netze die sich zum Teil dynamisch ändern.

Nutzt ein Client eine IPv6-Verbindung in das Internet, so benötigt er eine IPv6-Adresse. Weiterhin muss er einen Router verwenden, der diese Adresse routen kann. Hier ist offen, welche Art von Adresse der Client verwenden soll (Public oder ULA) und wie Router nur passende Absenderadressen routen. Ein Router kann nicht jede beliebige Absenderaddresse in einem VPN-Tunnel verwenden (IP-Spoofing). Damit muss er die Adressen entweder ersetzen (Nat66) oder an den Router mit passendem VPN-Tunnel weiterleiten (Source Sepecific Routing).

Freifunk-Routing

Clients und Nodes sollten direkte Ende-zu-Ende Verbindung aufbauen können. Jeder client soll seine eindeutige IP-Adresse haben können. Direkte Verbindungen in andere Communities sollen auch möglich sein. Das Intercity-VPN ist eine Verbindung aller Freifunk-Communities. Wie kommunizieren Clients im Freifunk-Netz untereinander? Welche Adressen verwenden genutzt und direkte Verbindungen aufbauen zu können? Wo werden Verbindungen zum ICVPN aufgebaut und wie wird DNS verwendet?

Ziele und Anforderungen

Designziele

Das Netz soll die folgenden Eigenschaften bieten:

1. ISP-Unabhängigkeit: Es können verschiedene VPN-Provider verwendet werden. Das Netz ist nicht abhängig von einem ISP (bspw. Freifunk-Rheinland).
2. Roaming: Zwischen Nodes, die direkten Funkontakt haben, soll Roaming möglich sein.
3. Skalierbarkeit: Das Netz einer Community soll bis zu einer Größe von 65000 Nodes (zzgl. clients) skalieren können.
4. IPv4 und IPv6: Beides wird verwendet
5. Dezentralität: Die Komponenten des Netzes werden nicht zentral verwaltet.
6. Geringe Hardware-Anforderungen: Auch Geräte mit wenig Ressourcen können verwendet werden.
7. Wiederverwendbarkeit: Andere Communities sollen analog Netze gestalten können. Die Netze existieren unabhängig.

Keine Designziele

Folgende Punkte werden nicht berücksichtigt. Technische gesehen sind sie aber grundsätzlich umsetzbar.

1. Internet-Performance: Ein hoch performanter Zugriff auf das Internet soll nicht sichergestellt sein.
2. Netzwerk-Management: Es muss nicht sichergestellt sein, dass eine einzelne Person möglichst viele Router effizient verwalten kann.
3. Stabilität: Die Verfügbarkeit einzelner Komponenten wird nicht sichergestellt.

Umsetzung

Modifizierte: Routing über das VPN, bridging zwischen batman-adv und Infrastruktur-Strategie

• Nodes verbinden zu einem ISP (z.B. FFRL e.V, hide.me) und erhalten Routbare IPs, sofern sie an das Internet angebunden sind.
• Jedem Node wird ein eindeutiges private IPv4 (/24) und ULA IPv6 Netz (/64) zugewiesen.
• Jeder Node betreibt einen DHCP und einen radvd auf dem Infrastruktur-Netz.
• Im ad-hoc-Netz werden babel und batman-adv verwendet.
  • batman-adv nur für Roaming. Broadcast wird komplett gefiltert. Jeder Node ist batman-adv Gateway
  • babel zur IP-Kommunikation zwischen den Nodes genutzt.
• Verfügt der Node über öffentliche IPv6-Prefixes, dann schaltet er DHCPv6-Prefix Delegation auf dem ad-hoc Interface (nicht batman-adv) ein. Benachbarte Nodes können darüber Prefixes erhalten.

Erreichte Anforderungen

• Das Netz ist Provider-Unabhängig, da jeder ISP genutzt werden kann. Traffic kann grundsätzlich auch ohne VPN in das Internet geleitet werden.
• Roaming ist über batman-adv möglich. Annahme: Clients benötigen nach einem Zellenwechsel keinen Broadcast: IPv6-ND ist nicht mehr nötig üb eine Layer-2 Adresse aufzulösen. ND-Table Einträge müssen langlebig sein.
• Das Netz skaliert bis theoretisch zu 65000 Knoten, da es ~ 65000 /24-Netze im Bereich 10.0.0.0/8 gibt. Annahme: Babel skaliert passend in zusammenhängenden Mesh-Segmenten.
• Dezentralität: Es gibt nicht notwendiger Weise Server in Rechenzentren.
• Geringe Hardware-Anforderungen: Auch TP-Link WR841n Geräte können verwendet werden.
• Wiederverwendbarkeit - Netze verschiedener Communities beeinflussen sich nicht, sofern sie nicht direkt mit Babel verbunden sind. Über das ICVPN können die ULA-Netze routed werden.