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