!!Achtung noch ungetestet!!
Erklärung
Mit clatd können den Clients in den Hoods ganz normal Dualstack (IPv4 und IPv6) angeboten werden. In der Freifunk Backbone muss aber nur noch IPv6 geroutet werden. Dazu werden am Gateway die IPv4 Pakete mit xlat464 ins IPv6 übersetzt und auf einen NAT64 Server im Freifunkbackbone (davon gibt es mittlerweile mehrere) wieder in IPv4 übersetzt. Somit ist für die Clients eine ganz normale IPv4 Kommunikation möglich, es gibt für die Clients keinen Unterschied zu normalen Dualstack wie es bisher genutzt wird.
Einrichtung
Zuerst benötigen wir eine weitere ULA IPv6 Adresse. Diese Adresse darf an kein Interface gebunden sein, muss aber ins Babel announced werden. Dies können wir mit einer route in der fff table erledigen:
ip -6 ro replace fd43:5602:29bd:ffff::deine_res_ip/128 dev lo proto static table fff
Für diese IP müssen wir zwingend in die main table gucken da dort später clatd eine route ablegt (priority kann angepasst werden, die rule sollte aber sehr bald greifen!):
ip -6 ru add from all to fd43:5602:29bd:ffff::deine_res_ip/128 lookup main priority 10
Danach installieren wir clatd nach Anleitung https://github.com/toreanderson/clatd:
cd ~ git clone https://github.com/toreanderson/clatd sudo make -C clatd install installdeps
Wir müssen die config ein klein wenig erweitern:
/etc/clatd.conf
dns64-servers=fd43:5602:29bd:ffff:1:1:1:64 v4-conncheck-enable=no clat-v6-addr=fd43:5602:29bd:ffff::deine_res_ip
In der ersten Zeile wird der DNS64 Server für das 64:ff9b::/96 Subnetz angegeben (nur nötig wenn dieser DNS Server nicht am Gateway eingetragen werden kann, alternativ kann dieser DNS Server auch direkt am Gateway genutzt werden). In der 2. Zeile wird der IPv4 Check deaktiviert (das Gateway hat in den meisten Fällen eine IPv4 Adresse, so das dieser Check sonst den Abbruch bedeutet) und in der 3. Zeile wird die IP Adresse angegeben die wir oben bereits entsprechend geroutet haben.
Danach kann man clatd starten:
systemctl restart clatd
Den Status ob alles geklappt hat mit
systemctl status clatd
angucken, es sollte etwa so aussehen:
● clatd.service - 464XLAT CLAT daemon
Loaded: loaded (/etc/systemd/system/clatd.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2021-01-19 14:56:27 CET; 13min ago
Docs: man:clatd(8)
Main PID: 11764 (clatd)
Tasks: 2 (limit: 2359)
Memory: 18.5M
CGroup: /system.slice/clatd.service
├─11764 /usr/bin/perl -w /usr/sbin/clatd
└─11780 tayga --config /tmp/Tm3kPlgTzD --nodetach
Jan 19 14:56:27 uranus clatd[11764]: Creating and configuring up CLAT device 'clat'
Jan 19 14:56:27 uranus clatd[11764]: Created persistent tun device clat
Jan 19 14:56:27 uranus clatd[11764]: Adding IPv4 default route via the CLAT
Jan 19 14:56:27 uranus clatd[11764]: Starting up TAYGA, using config file '/tmp/Tm3kPlgTzD'
Jan 19 14:56:27 uranus tayga[11780]: starting TAYGA 0.9.2
Jan 19 14:56:27 uranus tayga[11780]: Using tun device clat with MTU 1500
Jan 19 14:56:27 uranus tayga[11780]: TAYGA's IPv4 address: 192.0.0.2
Jan 19 14:56:27 uranus tayga[11780]: TAYGA's IPv6 address: 64:ff9b::c000:2
Jan 19 14:56:27 uranus tayga[11780]: NAT64 prefix: 64:ff9b::/96
Jan 19 14:56:27 uranus tayga[11780]: Note: traffic between IPv6 hosts and private IPv4 addresses (i.e. to/from 64:ff9b::10.0.0.0/104, 64:ff9b::192.168.0.0/112, etc) will be dropped. Use a translation prefix within your organization's IPv6
Danach müssen noch die Freifunk Netze auf das clat Interface geroutet und genNATet werden:
ip ro replace default dev clat table fff iptables -t nat -A POSTROUTING -o clat -j SNAT --to-source 192.0.0.1
Es können somit in den Hoods auch IPv4 Adressen verwendet werden, die nicht im Freifunk reserviert sind, z.b. aus dem 192.168.0.0/16 Netz (z.b. für jede Hood ein /23 aus diesem Netz)
Nacharbeiten
Wenn man kein IPv4 mehr routen möchte kann im babeld IPv4 komplett deaktivieren und auf den Gateway alle IPv4 Adressen auf allen peering Interfaces verwerfen. Dies sollte zum aktuellen Zeitpunkt (!!)noch nicht gemacht(!!) werden!
Nachteil
Babelpeers die von einem Abhängig sind, können kein IPv4 mehr über einen routen und sind von der IPv4 Welt abgeschnitten
Lösungsmöglichkeiten
Da 64:ff9b::/96 private IPv4 Adressen nicht umgesetzt werden (siehe letzte Meldung im clatd status) kann ein anderes /96 Netz verwendet werden. Damit werden auch private IPv4 Adressen umgesetzt und man könnte allen peers nur noch eine default route anbieten .
Ergebnis
Eventuell vorhandene Nebeneffekte sind noch nicht wirklich bedacht, zum aktuellen Zeitpunkt sollte daher erstmal IPv4 weiter geroutet werden. Es kann aber durchaus für eigene Hoods bereits xlat464 umgesetzt werden so das man zumindest für eigene Clients kein IPv4 Netz mehr benötigt.
