Stellungnahme Hood Bamberg

Martin Jahn fff at nixxda.net
Fr Apr 1 13:10:44 CEST 2022


Hi,

Am 31.03.2022 um 23:49 schrieb Felix Schymura:
>
> Hallo zusammen,
>
> ich hab mir heute die Zeit genommen das Problem genauer zu erfassen. 
> Grundsätzlich ist es so: Alles was IPv6 kann funktioniert generell 
> einwandfrei und ohne jegliche Störung. Alles was nur IPv4 kann 
> funktioniert teilweise, da NAT64 zum Einsatz kommt.
>
Ein Client, der nur IPv4-fähig ist, bekommt von einem ggf. vorhandenen 
NAT64 garnichts mit, da dieser normalerweise in DNS-Anfragen nur 
A-records abfragen wird und keine AAAA-records. Ein DNS-Server mit 
aktiviertem DNS64 verändert keine Antworten auf angefragte A-records, 
verhält sich dort also genauso wie ein "normaler" DNS-Server. Es werden 
lediglich zusätzliche AAAA-records generiert für Ziele, die nur einen 
A-record (und keine AAAA-records) besitzen.

Dieser zusätzliche AAAA-record wird gebildet aus der IP-Adresse des 
zugehörigen A-records und einem davor gestellten translator-prefix, z. 
B. wird aus der IPv4-Adresse 131.188.0.10 und dem prefix 64:ff9b::/96 
die Adresse 64:ff9b::83bc:a. Das gibt einem Client mit IPv6-Adresse die 
Möglichkeit über diese spezielle Adresse und einem translator (also 
einer NAT64-Instanz irgendwo im Netz) ein IPv4-Ziel direkt zu erreichen. 
Dadurch ist es möglich, dass Clients mit ihrer IPv6-Adresse nicht nur 
Ziele erreichen können, die bereits IPv6 unterstützen, sondern auch alle 
anderen, die das noch nicht tun.

Der Vorteil besteht darin, dass Clients somit nicht mehr zwingend eine 
IPv4-Adresse benötigen, um alle Ziele erreichen zu können. Die meisten 
Betriebssysteme unterstützen diese Verfahren, allerdings gibt es noch 
einige Anwendungen, die in reinen IPv6-Netzen nicht sauber 
funktionieren. Deshalb gibt es im Normalfall bei uns trotzdem noch 
DHCP-Server, um auch native IPv4-Unterstützung zu bieten. Sollten bei 
diesem allerdings mal die leases ausgehen oder der Service gestört sein, 
können IPv6/NAT64-fähige Clients und Anwendungen weiterhin 
funktionieren. (Apple's iOS bspw. funktioniert uneingeschränkt in Netzen 
mit reinem IPv6, solange auch NAT64 angeboten wird)
>
> Auf meinem Gateway "fff-gw-geo.freifunk-geo.de" ist kein NAT64 aktiv. 
> Sofern man das Hoodfile so manipuliert, dass nur mein Gateway genutzt 
> wird funktioniert es auch. Deshalb gibt es auch in anderen Hoods die 
> bei mir laufen keine Probleme.
>
> Einige Router bevorzugen aus irgendeinem Grund in Bamberg generell das 
> Backup-Gateway "fff-nue2-gw6.fff.community", welches wohl NAT64 
> einsetzt, was wohl nicht alle Geräte zu verstehen wissen. Daher kommt 
> es auch zustande, dass neben den Problemmeldungen sehr viele "Es geht 
> doch" Meldungen kamen. Je nachdem wie die Geräte konfiguriert sind 
> funktioniert entweder alles oder es kommt zu Problemen.
>
> Ein Quickfix wäre also das Hoodfile auf den Routern anzupassen, 
> welches nur das gewollte Gateway enthält. Zielführend ist das jedoch 
> nicht, weshalb ich davon abrate. Warum manche Router trotz der bei 
> fff-gw-geo "höheren" Announcements das Backup-Gateway bevorzugen 
> erschließt sich mir nicht.
>
Die Definition von Gateways als "Main" und "Backup" ist in diesem 
Kontext irreführend.

Gemeint ist damit wohl die BATMAN-Gatewayselection. Hier kann man zwar 
verschiedene Bandbreiten angeben und damit erreichen, dass Nodes 
vermeintlich ein anderes Gateway bevorzugen. Das stimmt aber leider nur 
sehr eingeschränkt. Die Gatewayselection hat als einzige Funktion das 
Filtern von DHCP-requests für bestimmte Gateways. Damit kann man nur 
beeinflussen, welches Gateway von einem DHCP-request erreicht wird und 
diesen dann (idealerweise) beantwortet. Das kann man z.B. nutzen, um die 
Auslastung der vorhandenen DHCP-Pools etwas zu steuern. Der 
entscheidende Punkt ist aber, dass man damit nur den IPv4-Traffic vom 
Client zum Gateway steuern kann, allen anderen Traffic nicht. Der Weg 
des Traffics aus unserem Backbone-Netz bis zum Client wird über babel 
und die kürzeste Route dort definiert, hängt also davon ab, wie das 
jeweilige Gateway an unser Netz angebunden ist.

Ein weiterer wichtiger Punkt: die Gatewayselection beeinflusst keine 
IPv6 Router Advertisements. Dort kommen normalerweise alle 
Advertisements von allen Gateways beim Client an und dieser kann dann 
selbst entscheiden, welcher Router bevorzugt wird. Das ist dann abhängig 
von der jeweiligen Implementierung und den Parametern in den Router 
Advertisements.

An einer Hood sind also immer beide Gateways aktiv beteiligt, man kann 
aber z.B. durch babel-Metriken usw. die Ressourcennutzung etwas verschieben.

Gruß,
nixxda


> Ich bitte da mal SebaBe (in CC) darum nachzusehen, was es mit dem 
> NAT64 auf fff-nue2-gw6 auf sich hat und das für die Bamberg-Hood auf 
> den gewöhnlichen Weg umzustellen.
>
> Grüße
> Felix
>
> -- 
>
> Felix Schymura
> Fachinformatiker für Systemintegration
>
> 📞 +49 951 16096907
> 📮 Postfach 2411, 96015 Bamberg
> LinkedIn <http://de.linkedin.com/in/felix-schymura> | ORCID 
> <https://orcid.org/0000-0002-0338-3938> | Twitter 
> <https://twitter.com/funkolive> | Website <http://funkolive.de/> | 
> YouTube <http://www.youtube.com/user/myFunkoLive>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://lists.freifunk.net/pipermail/franken-freifunk.net/attachments/20220401/431969bf/attachment.htm>


Mehr Informationen über die Mailingliste franken