Brainstorming: Eine neue Art IPv4 im Freifunk zu routen

Hier versuche ich ein neues Konzept zum Umgang mit IPv4 in Freifunknetzen aufzuschreiben. Es ist Work-in-Progress. Ich werde diesen Beitrag öfters editieren und vielleicht auch völlig ändern. Bitte beachtet das, falls ihr Kommentare hierzu schreibt.

Annahmen

  • ① Dieses Konzept betrachtet nur Clients, die direkt per WLAN mit einem Knoten verbunden sind. Das Routing für die LAN-Ports muss (und kann!) anders gelöst werden und ist nicht Teil dieses Konzeptes.
  • ② WLAN Clients müssen immer DHCP machen. Es gibt keine statisch am Client konfigurierten IPs.
  • ③ Eine spezielle Software läuft auf allen Knoten, die mit Clients kommunizieren sollen.
  • ④ Es gibt ein funktionierendes IPv6 Mesh zwischen den Knoten.
  • ⑤ Knoten könnten IPv6 Routen (und sei es nur per ripng über batman-adv) austauschen.

Abgrenzung

  • Keine LAN-Ports. Da brauchen wir ein anderes Konzept (ist aber recht einfach).
  • Nur IPv4, kein IPv6 (wird nachgereicht, ist ähnlich und etwas einfacher).

Konzept

Aus ① und ② folgt direkt, dass dem Netz immer bekannt sein kann, mit welchen Knoten ein bestimmter Client verbunden ist und welche IPv4 dieser hat. Wir bilden daraus der 3-Tupel (ClientMAC, Knoten, IPv4). Ein Knoten selbst wird dabei unter anderem durch seine IPv6 im Mesh gekennzeichnet. Der Knoten ist also für andere Knoten über das Mesh erreichbar. Desweiteren ist es bei IPv4 in Freifunknetzen oft so, dass mehrere Gateways den Zugang zum IPv4 Internet bereitstellen. Damit sich die externe IPv4 eines Clients nicht ändert, sollte der gewählte Gateway möglichst konstant bleiben. Darum erweitern wir das Tupel noch um ein Element: (ClientMAC, Knoten, IPv4, StickyGateway). Der StickyGateway ist dabei der vom Client bevorzugte Gateway zum Internet. Dieser kann beim ersten verbinden des Clients vom Netz gesetzt werden. In der Praxis will man das Tupel wahrscheinlich noch um so etwas wie Timeouts und Leasetimes ergänzen.

Die Liste dieser Tupel wird „irgendwie“ zwischen den Knoten ausgetauscht bzw. repliziert. Vor der praktischen Umsetzung sollten wir diesen Bereich noch optimieren.

Grundlagen

  • Jeder Knoten ist anycast Gateway aller Clients (ähnlich next-node in Gluon).
  • ggf. ist der Knoten anycast DNS, ansonsten wird DNS ganz normal geroutet.
  • Das gesamte IPv4 Internet wird in ein IPv6 /96 eingebettet und darüber geroutet.
  • Für die Clients wird ein eigenes IPv4 Subnetz verwenden in dem es zwei Klassen von IPs gibt:
    • Die anycast IP der Knoten. Zum Beispiel: 10.130.128.1/17
    • IPs, die Clients zugeteilt werden. Zum Beispiel: 10.130.128.2 bis 10.130.255.254
  • Gateway (Supernode) IPs, DNS, usw. befinden sich in anderen Subnetzen. Dazwischen wird geroutet.
  • Alle Knoten, die Clients bedienen oder erreichen wollen, treten einer IPv6 Multicastgruppe bei. Nennen wir sie Client-Multicast-Gruppe (CMG). Multicastoptimierungen im Mesh würden die Effizienz dieses Konzeptes steigern.

Traffickapselung zwischen den Knoten

Zunächst wird das gesamte IPv4 Internet in ein IPv6 /96 gemappt. Nehmen wir als Beispiel 2001:db8:4444::/96. Unser Clientnetz darin wäre also 2001:db8:4444::10.130.128.0/113.

Pakete von Clients müssen zunächst nicht gesondert gekapsel werden. Es reicht aus Absender und Empfänger IPv4 in das entsprechende IPv6 Äquivalent umzuformen. Die Pakete können danach von den Knoten direkt über das Layer3 Routing zum Empfänger geleitet werden.

Empfang von Paketen

Pakete, die an einen Client gerichtet sind, müssen über den entsprechenden Knoten aus der Tupelliste geroutet werden. Das Routing auf allen Knoten (und Gateways, die Clients erreichen wollen) muss also Pakete an das Clientnetz (2001:db8:4444::10.130.128.0/113 in diesem Beispiel) abfangen und z.B. über ein tap-Device routen, das vom einem Daemon bereitgestellt wird.

Dieser Daemon wird die Pakete nehmen und diese an den entsprechenden Knoten senden (z.B. verpackt als UDP Paket). Auf dem Knoten wird (ggf. der gleiche Daemon) diese Pakete entgegen nehmen, sie auspacken und an den entsprechenden Client senden.

Was so im Netz passieren könnte

Ein neuer Client verbindet sich

Der Client macht DHCP. Der Knoten antwortet direkt und gibt ihm eine IPv4. Dem Knoten ist nun MAC und IPv4 des Clients bekannt. Zudem wählt er noch einen geeigneten Internetgateway (ggf. mit Hilfe von batman-adv) aus und füllt das oben angesprochene 4-Tupel aus. Dieses Tupel teilt er dem Netz mit. Das ist in etwa O(|CMG|) und kann durch Multicastoptimierungen verbessert werden.

Jetzt können:

  • Alle Knoten die IPv4 des Clients erreichen (ohne ARP Broadcasts!)
  • Der Client kann seinen anycast Gateway erreichen und darüber den Rest des Internets.

Ein Client wechselt zu einen anderen Knoten

Der Knoten bekommt direkt mit (lasst mal iw event auf einem Knoten laufen), dass der Client nun bei ihm ist. Die Liste mit den Tupeln ist ihm bekannt und er sieht, dass der Client dort geführt wird. Er aktualisiert das Tupel und informiert alle Knoten über die Änderung. Auch das ist O(|CMG|).

Zudem informiert er gesondert den Knoten, an dem der Client zuletzt gemeldet war um sicher zu stellen, das sämtlicher Clienttraffic jetzt bei ihm ankommt.

Ein Client sendet ein Paket

über Gateway

Ein Client wird alle Pakete an Empfänger außerhalb des Clientsubnetzes immer über den Gateway schicken. Die Pakete müssen nicht speziell gekapselt werden. Es reicht aus, diese in IPv6 zu mappen (NAT64/SIIT) und als Absender IP die des Clients einzusetzen.

an einen anderen Client

Möchte ein Client ein Paket an einen anderen Client senden, wird er ARP versuchen. Der Knoten wird in diesem Fall ARP Proxy spielen und so wieder zum Gateway werden. Ab dann: Gleiche Spiel wie vorhin.

Diesen Fall will man durch Clientisolation noch etwas strenger erzwingen.

Ein Client hat also später nur mit zwei MAC Adressen zu tun: Der anycast MAC des Knotens und seiner eigenen.

9 Likes

Bin ich nicht für. Dann hab ich keine statische IP mehr

Die können doch auch von DHCP vergeben werden. Würde sogar Sinn machen damit diese nicht doppelt vergeben sind.

1 Like

die frage ist wie viel last so tap Tunnel macht auf einen bisher schwachen Router die ja bisher nur wlan machen … (nicht die Router die Fastd machen)

Warum ist das die Frage? Das könnte man auch im Kernel machen und den entsprechenden Headroom direkt reservieren um umkopieren zu vermeiden.

Was genau soll eigentlich erreicht, bzw. verbessert werden?

Die einzige Stelle, die ich gesehen habe, die Verbesserungen anspricht, sind die wegfallenden ARP Broadcasts. Geht es darum das Hintergrundrauschen zu verringern?

Es geht um das Skalierungsproblem. batman-adv funktioniert ohne Tricks nicht mit mehr als 20 bis 30 Knoten. Wir mussten schon den OGM Interval von 300ms auf 5s erhöhen und damit fast jede Flexibelität bei der Meshstruktur aufgeben (sich langsam bewegende Knoten wären aktuell nicht meshfähig). Broadcast und Multicast zwischen den Clients wird zum aller größten Teil auch bereits gefiltert.

Daher ist ein Ziel die Behandlung von Clients aus batman-adv herausziehen, so dass Roaming unabhängig vom Meshprotokoll funktioniert. Nebenbei fällt der gesamte Broadcasttraffic zwischen den Clients weg. Danach können wir mit anderen Meshprotokollen experimentieren und beim Clientroaming mit anderen Protokollen kompatibel bleiben.

Irgendwie müssen wir ja so langsam Meshes mit tausenden Knoten hinbekommen.

Einen ähnlichen Entwurf für IPv6 werde ich demnächst aufschreiben, ebenso einen für die Anbindung der LAN-Ports.

3 Likes

Ich verstehe technisch leider nichts davon, finde es aber total klasse, dass ihr euch damit beschäftigt! Danke schon alleine für den Versuch es zu verbessern. Dann will ich Mal nicht weiter stören. Wenn was getestet werden muss, einfach melden. Haben hier immer so viele Router rumfliegen, da geht bestimmt was.