<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hallo <br>
</p>
<p>da auch ich viel mit NAT64 experiementiert habe (und auch hin und
wieder noch tue), hier mal Erfahrungen von mir:<br>
</p>
<p>Ich selbst war lange und oft sowohl mit Linux PC als auch mit
Android Handy damit unterwegs. Im großen und ganzen hat damit
alles sehr gut funktioniert. Es gab allerdings leider paar
Ausnahmen, immer mal einzelne Seiten die extrem langsam geladen
haben oder auch Downloads die von einer v4 Quelle enorm langsam
waren. Wir reden hier von deutlich <100kbyte/s, man hat das bei
Webseiten mit Bildern schon gemerkt das was nicht stimmt, die
haben sich tlw. wie bei einem Modem aufgebaut. Hat man direkt per
v4 über Freifunk drauf zugegriffen war alles normal. Es ist nur
ein Bruchteil an Webseiten die betroffen waren, leider hab ich
kein Beispiel mehr zur Hand, es waren meist Seiten die man sehr
selten verwendet, daher hab ich mich da nie großartig drum
gekümmert. Nach einigen Monaten war ich davon aber so genervt, das
ich mittlerweile wieder auf normalen Dualstack umgeschwenkt habe.
Sowohl ich selbst als auch bei meinen Freifunkstandorte habe ich
nach und nach die DNS64 Server wieder raus genommen. Das ganze ist
wirklich nur aufgefallen wenn man es selbst lange intensiv genutzt
hat, manchmal hatte ich wochenlang keine Seite erwischt die
Probleme gemacht hat und dann gabs doch wieder eine oder zwei die
nicht so richtig wollten.<br>
</p>
<p>Die Idee ist ansich sehr gut aber irgendwie war das doch immer
bisschen hakelig und am Ende einen kleinen Tick zu nervig. Einfach
bei v4 nochn NAT mehr rein werfen, dann kann man die v4 Netze
wieder groß genug machen und alles ist super ;) (naja... * )<br>
</p>
<p>Zusammengefasst: Es geht gut genug das man es nutzen kann aber
wenn man einfach nur Internet will das geht, stolpert man doch hin
und wieder über irgendwas nerviges (vllt. auch irgendein altes
Windows das es noch nicht frisst wenn es keine v4 mehr mit bekommt
oder so...) und dann ist mMn der Vorteil zu gering als das ich das
behalten will oder auch anderen antun will. Das v4NAT dazwischen
funktioniert einfach deutlich besser und macht weniger Ärger.</p>
<p>Was ich mir noch vorstellen kann, am "Übergabepunkt zu Babel"
(also v2 Gateways oder Layer 3 Router) xlat464 machen. Dann haben
die Clients normales Dualstack und machen keinen Ärger aber im
babel muss man nur noch v6 routen. Ob da mein
Geschwindigkeitsproblem von oben wieder auftritt müsste man testen
aber dafür fehlt mir aktuell einfach die Zeit für solche
Experiemente und ich bleibe jetzt erstmal bei meinen v4NAT das tut
einfach zu gut ;)</p>
<p>Interessanterweise treten diese Probleme anscheinend nicht bei
Telekom Mobilfunk mit NAT64 auf, zumindest ist es mir dort noch
nie aufgefallen (außer als es mal ne zeitlang sehr kaputt war, da
hats die Telekom auf Nachfrage wieder gefixt ;)). Ich will daher
auch nicht ganz ausschließen das es ein config Problem auf meinen
NAT64 Gateways war oder ist.<br>
</p>
<p>Gruß</p>
<p>Christian</p>
<p>P.S. & * Ihr Webseitenbetreiber da draußen, macht doch
einfach mehr v6 dann brauchen wir uns um diesen scheiß nicht mehr
kümmern ;)<br>
</p>
<div class="moz-cite-prefix">Am 01.04.22 um 13:10 schrieb Martin
Jahn:<br>
</div>
<blockquote type="cite"
cite="mid:bc01b148-a873-f0bd-375b-1a74966dcb3a@nixxda.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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>
</blockquote>
</body>
</html>