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.

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 vpn-links 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 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.
• 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.

Es gibt bereits einige Ansätze wie lokale Supernodes auf Futro-Hardware, die einige Nachteile adressieren. Viele konzeptionelle Fragen sind jedoch noch offen

• Wie sollen Roaming-Bereiche zugeschnitten werden? Wie wird das Roaming umgesetzt?
  • In welchen Gebieten soll Roaming möglich sein?
  • Über welche Technik wird Roaming erreicht?
  • In welchen Kompoenten werden Meta-Daten zum Roaming propagiert?
• IPv6-Multihoming - verschiedene IPv6-Adressbereiche durch verschiedene ISPs:
  • IPv6-Adressierungsstrategie: Nat66 ja / nein? Verteilung der Prefixe (PD / DHCP vs. radvd).
  • Externes-Routing: Wie nutzt ein Client den zur IPv6-Absenderadresse passenden Internet-Uplink?
  • Internes-Routing: Welche Eindeutige Adresse kann ein Client netzintern verwenden und ist überall erreichbar?

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.