Benutzer:Christof/Gluon-Babel

Motivation

Derzeit arbeiten viele Communities mit Batman als mesh-Protokoll. Das funktioniert gut, skaliert allerdings nicht beliebig. Mit der zunehmenden Popularität von Freifunk besteht der Bedarf an Lösungen, bei denen insbesondere auch Skalierung im Vordergrund steht.

Die Ursache für die Begrenzung der Skalierungsfähigkeit von Batman-basierten Netzen liegt in der Struktur. Bei Batman erfolgt Meshing auf OSI-Ebene 2, sodass sich das gesamte Netz wie ein großer Netzwerkswitch verhält. Jeder Client sieht jeden beliebigen anderen Client im Netz und Broadcasts gehen an alle. Der dadurch entstehende Traffic beschränkt letztlich die Anzahl der Teilnehmer im Netz.

Setzt man Babel als Mesh-Protokoll ein, ergeben sich andere Voraussetzungen für das Netzwerk:

1. Der Broadcast/Multicast-Traffic ist deutlich reduziert, bei dem folgenden Netzentwurf ohne zusätzliche Maßnahmen nur zwischen Client und dem unmittelbar verbundenen Node möglich. Dadurch skaliert das Netzwerk besser.
2. Roaming funktioniert nicht ohne zusätzliche Maßnahmen.

Zusätzliches Material

• Nils hat den Master-Plan in seinem Blog [1] zusammengefasst.

Allgemeines

Die offenen Punkte und Aufgaben stehen in [2]

Begriffe

• Node: Ein Freifunk-Router (kann ggf Zugang zum Internet herstellen)
• Gateway: Ein Server im Freifunk-Netz der es mit Hilfe von VPN-Technologie (meist fastd oder L2TP) ermöglicht, dass mehrere Nodes ein gemeinsames Netz bilden obwohl sie keine direkte Wifi-Konnektivität haben. Gateways können auch Zugang zum Internet herstellen
• Client: Ein Netzteilnehmer

Topologie

Das Freifunk-Mesh liegt mit dem Einsatz von Babel auf OSI-Ebene 3. Die Nodes und Gateways können sich einen Netzbereich teilen, die Client können in einem eigenen Subnetz liegen. Auf jedem Node/Gateway läuft l3roamd und babel. Auf jedem Node läuft ein radvd, der n (mit n irgendwas < 8, vielleicht auch nur 4) präfixe announcen kann. Die Clients erhalten ihre Router Advertisements ohne aktives On-Link-Bit. Dadurch lassen sich auf den Nodes die wesentlichen Routingentscheidungen treffen. l3roamd findet bei Bedarf neue IP-Adressen per Neighbor Discovery heraus. Damit findet l3roamd neue Routen und gibt die an Babel weiter. Babel verteilt und optimiert die Routen. Durch die Kombination von l3roamd und babel wird roaming möglich.

Im Unterschied zu batman-basierten Netzen wird der Nutztraffic im Mesh nicht durch das Meshing-Protokoll gekapselt. Stattdessen liegt Verwaltungstraffic und Nutztraffic im Mesh nebeneinander.

Man kann ein Freifunk-Netz in drei Aufbaustufen sehen:

2 Robinson-Nodes

In diesem Modus wird von beiden Routern ausschließlich das selbe /64 ULA-prefix announced. Die angeschlossenen Clients greifen sich eine IP. Durch die Nutzung von babel und l3roamd können alle Clients über das announcete ULA-Netz miteinander kommunizieren.

2 Nodes mit Gateway

Zusätzlich zu dem vorherigen Szenario gibt es mehrere Möglichkeiten. NAT (dann hat man verschiedene Probleme und im Mesh nur das ULA-prefix) oder Verteilung öffentlicher ipv6-prefixe (präferierter Ansatz). Das Gateway gibt das prefix den verbundenen Nodes bekannt. Diese wählen aus allen möglichen prefixes die relevanten aus und announcen diese an die Clients. Welches Prefix vom Client genutzt wird, hängt vom Ziel und der Entscheidung des Clients ab. Der IPv6-Traffic wird über das Gateway geroutet, sofern er ins Internet geht. Netzintern werden vom Client die ULA-Adressen gewählt.

2 Nodes mit Gateway und jeweils Internetanschluss

Zusätzlich zum vorherigen Szenario kann nun traffic am Node direkt, teilweise direkt (Entscheidung für welche AS direkt ausgeleitet werden soll, Rest über VPN) oder alles über ein dediziertes VPN ausgeleitet werden. In diesem Beispiel haben wir nun 4 Prefixe: 1 ULA, eins vom Gateway und je Node noch eins. Die letzten drei prefixes sind public ipv6-prefixes. Die Funktionsweise ist wie im Szenario davor. Durch die Nutzung von Source-Routing (Einschränkung der Nutzung eines Gateways auf Clients mit IPs aus einem bestimmten Quell-Bereich) ist die Konnektivität auch mit mehreren Default-Routen bei kaputten Client-Implementierungen sichergestellt.

[3]

Features

• (hoffentlich) bessere Skalierung des Netzes
• Die Nodes werden auch innerhalb des Freifunk-Netzes als Router genutzt. Dadurch wird das Ausleiten von Traffic direkt ins Internet denkbar

IPv6

Zunächst wird das Netzwerk als reines IPv6-Netz aufgebaut. Es gibt drei Prefixes:

• Infrastruktur (Gateways, NTP, Updateserver) (Frankfurt: fddd:5d16:b5dd::/64) Jeder Gateway announced das identische prefix mit seiner spezifischen IPv6-IP im RA.
• Nodes (Frankfurt: fddd:5d16:b5dd:1::/64)
• Clients (Frankfurt: fddd:5d16:b5dd:2::/64)

Siehe auch [4]

Die Nodes und die Clients liegen in unterschiedlichen IPv6-ULA-Netzen Clients liegen weiterhin in dem unter prefix6 angegebenen Netz der site.conf Nodes liegen in babel_mesh.prefix der site.conf

Neben den privaten IPv6-Adressen können von den Nodes auch public IP-Adressen verteilt werden. Diese können von Node-Betreibern dem Freifunk "gespendet" werden. Diese prefixe werden im Config-Mode eingetragen und einem neuen daemon namens prefixd den umliegenden Nodes bekannt gemacht, welche diese prefixe announcen.

IPv4

IPv4 wird im Mesh über prefix4 ermöglicht. Weil die dhcp-Clientimplementierungen nicht einheitlich mit den dhcp-Optionen umgehen und insbesondere DHCP-OPTION 133 teilweise gar nicht zur Verfügung steht beziehungsweise erst manuell im Client aktiviert werden muss, kann die IPv4-Netzstruktur nicht analog zur IPv6-Struktur aufgebaut werden. Stattdessen verteilt ein verteilter dhcp-Server (ddhcp) IP-Adressen, die in prefix4 liegen. Damit ein babelbasiertes Freifunknetz funktioniert, muss das Ziel jedes Pakets auf dem Node getroffen werden. Für IPv6 wird das durch Host-Routen erreichet, für IPv4 ist das aufgrund der oben beschriebenen Problematik der DHCP-Optionen nicht ohne einen weiteren Dienst (arpproxyd) möglich, der dafür sorgt, dass Clients, obwohl Netzmasken mit weniger als 32 Bit genutzt werden, der Traffic zunächst zum Node geschickt und dann von dort aus über die hinterlegten Routen weiter verteilt werden kann.

Broadcasts

• Wie bekommt man avahi und bittorrent neighbor discovery zum laufen?
• Müssen die an einem Node hängenden Clients voneinander isoliert werden? (besser wäre mMn wenn es gelänge diese in ein L2-Netz zu legen, sodass diese ungehindert lokal kommunizieren können)

Komponenten

prefixd

Das IPv6-Konzept sieht vor, dass Betreiber ein IPv6-Prefix zur Nutzung im Freifunk-Netz freigeben können. Der Betreiber kann im Konfigurationsmodus diesen Prefix einstellen. Dieser wird dem prefixd mitgeteilt. Der prefixd verteilt dieses prefix an andere prefixd auf andere im mesh befindliche Nodes. Dabei werden nur die besten n (n irgendwo zwischen 4 und 8?) prefixe weitergegeben. Auf dem jeweiligen Node wird durch den prefixd die radvd-Konfiguration angepasst (Konfigurationssocket?), sodass diese prefixe announced werden.

l3roamd

l3roamd hat die Aufgabe Routen zu erkennen. Dafür muss eine Tabelle aller Nodes und der dahin zeigenden Routen vorgehalten werden. Die Routen sind je Node verschieden, aber jeder Node hat einen Eintrag. Die Routen werden per babel im Mesh verteilt und durch babel optimiert.

Damit Clients miteinander kommunizieren können, ist es erforderlich, dass neben der Routen der Nodes auch die der Clients mit Hilfe von l3roamd ausfindig gemacht werden können. Diese können ebenfalls durch babel im gesamten Netz verteilt werden.

Ideen

• Um die Skalierbarkeit zu verbessern, werden die Client-Host-Routen direkt an den l3roamd des anfragenden Nodes zurückgemeldet. Der würde daraufhin einen unidirektionalen Tunnel zu dem Knoten mit dem Client aufbauen und die Pakete darüber schicken.
• keine Abschottung von Clients an einem Node voneinander, bridgen von AP-Wifi und lan-ports

babel

• müssen die mac-adressen an die /128 Routen angehängt werden?