<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,<br>
</p>
<div class="moz-cite-prefix">Am 31.03.2022 um 23:49 schrieb Felix
Schymura:<br>
</div>
<blockquote type="cite"
cite="mid:d7e80a8b-6971-7829-941d-438f6a23f79c@funkolive.de">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p>Hallo zusammen,</p>
<p>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.</p>
</blockquote>
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.<br>
<br>
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.<br>
<br>
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)<br>
<blockquote type="cite"
cite="mid:d7e80a8b-6971-7829-941d-438f6a23f79c@funkolive.de">
<p>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.</p>
<p>Einige Router bevorzugen aus irgendeinem Grund in Bamberg
generell das Backup-Gateway <span aria-labelledby="value"><span
class="objectBox objectBox-string">"fff-nue2-gw6.fff.community"</span></span>,
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.<br>
</p>
<p>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.</p>
</blockquote>
<p>Die Definition von Gateways als "Main" und "Backup" ist in diesem
Kontext irreführend.</p>
<p>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.</p>
<p>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.<br>
</p>
<p>An einer Hood sind also immer beide Gateways aktiv beteiligt, man
kann aber z.B. durch babel-Metriken usw. die Ressourcennutzung
etwas verschieben.</p>
Gruß,<br>
nixxda
<p><br>
</p>
<blockquote type="cite"
cite="mid:d7e80a8b-6971-7829-941d-438f6a23f79c@funkolive.de">
<p>Ich bitte da mal SebaBe (in CC) darum nachzusehen, was es mit
dem NAT64 auf <span aria-labelledby="value"><span
class="objectBox objectBox-string">fff-nue2-gw6 auf </span></span>sich
hat und das für die Bamberg-Hood auf den gewöhnlichen Weg
umzustellen.</p>
<p>Grüße<br>
Felix<br>
</p>
<div class="moz-signature">-- <br>
<p><span dir="ltr" style="margin-top: 0; margin-bottom: 0;"><small>Felix
Schymura</small></span><br>
<span dir="ltr" style="margin-top: 0; margin-bottom: 0;"><small>Fachinformatiker
für Systemintegration</small></span><br>
<br>
<span dir="ltr" style="margin-top: 0; margin-bottom: 0;"><small>📞</small><small> +49
951 16096907</small></span><br>
<span dir="ltr" style="margin-top: 0; margin-bottom: 0;"><small>📮</small><small> Postfach
2411, 96015 Bamberg</small></span><br>
<span dir="ltr" style="margin-top: 0; margin-bottom: 0;"><small><a
href="http://de.linkedin.com/in/felix-schymura"
moz-do-not-send="true">LinkedIn</a></small><small> | </small><small><a
href="https://orcid.org/0000-0002-0338-3938"
moz-do-not-send="true">ORCID</a></small><small> | </small><small><a
href="https://twitter.com/funkolive"
moz-do-not-send="true">Twitter</a></small><small> | </small><small><a
href="http://funkolive.de/" moz-do-not-send="true">Website</a></small><small> | </small><small><a
href="http://www.youtube.com/user/myFunkoLive"
moz-do-not-send="true">YouTube</a></small></span> <br>
</p>
</div>
</blockquote>
</body>
</html>