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.2bis10.130.255.254
- Die anycast IP der Knoten. Zum Beispiel:
- 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.