Architektur-Babel

Hinweis: Dieser Artikel beschreibt nicht das Freifunk-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 :-).

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.

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

Ziele und Anforderungen

Wesentlich Bestandteil sind:

• (Vanilla) OpenWRT (stable) (https://openwrt.org)
• Babel (https://www.irif.univ-paris-diderot.fr/~jch/software/babel/)
• batman advanced (https://www.open-mesh.org/projects/batman-adv/wiki)

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 soll bis zu einer Größe von 65000 Nodes 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.