Stellungnahme Hood Bamberg

Fr Apr 1 19:01:51 CEST 2022

Hallo

da auch ich viel mit NAT64 experiementiert habe (und auch hin und wieder 
noch tue), hier mal Erfahrungen von mir:

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.

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... * )

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.

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 ;)

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.

Gruß

Christian

P.S. & * Ihr Webseitenbetreiber da draußen, macht doch einfach mehr v6 
dann brauchen wir uns um diesen scheiß nicht mehr kümmern ;)

Am 01.04.22 um 13:10 schrieb Martin Jahn:
>
> 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/0f2edf14/attachment-0001.htm>