Fritzbox und IPv6 Prefix Update Probleme

So, da ihr das Problem anscheinend nicht nachvollziehen könnt, einmal nochmal mit Bildern.
Und ich habe auch eine Vermutung, woran es genau liegt.

Es geht nur um IPv6. Hier habt ihr die Daten aus der Fritte. Nehme ich jetzt von Anleitungs-Seite die Update-URL für ‘Mit AVM Fritzbox IPv6-Prefixe Updaten’ werden meine Records wie folgt geschrieben:

Man sieht, der AAAA-Record steht auf der Fritzbox, die NAS wäre auch mit ‘Portweiterleitung’ nicht erreichbar. (Es ist ja keine Weiterleitung, sondern ein Öffnen der Firewall)

Ich trage also den Host-Teil der IPv6 der NAS ein und mit dem zuvor gespeicherten IPv6-Prefix ergibt sich dann das Bild mit (Prefix)Host. Lasse ich jetzt aber die Update-URL so, wie sie oben in der Anleitung beschrieben ist, erhalte ich nach dem reconnect genau das Problem: Der AAAA-Record wird mit der vollständigen IPv6 der Fritte überschrieben und es wird eben nicht NUR der Prefix aktualisiert.

Wie ich aber grade festgestellt habe geht es mit der URL von der Anleitung, wenn man 2x den AAAA-Record setzt. Einmal Fritte, einmal auf die NAS mit (Prefix)Host.
Dann wird tatsächlich die IP der NAS nicht komplett überschirben, sodern so wie gewünscht der Prefix aktualisiert.

Aber: Ich will meine Fritte nicht erreichbar haben, also lösche ich den AAAA-Record entsprechend.

Ich konkretisiere daher meine Aussage: Der Link ist nicht unbedingt falsch, aber die Erklärung im Video ab Minute 8 (Masterlösung) fängt diesen Fall nicht ab. Es müsste dann der Satz dabei stehen, dass von oben nach unten aktualisiert wird und zuerst der AAAA-Record der Fritzbox dort stehen muss.
Andernfalls hätte man auch einfach nur die Variablen + Logik zur Verfügung stellen können und dann kann jeder gucken, wo er bleibt. Wer ‘Das ist die Lösung’ drauf schreibt muss sich nicht wundern, wenn Leute denken ‘das ist die Lösung’.
Und ja, das mag für euch total logisch und sinnig sein. Für mich war es das nicht. Und soo offensichtlich ist das Verhalten nicht, wenn man sich nur die URL ansieht.

Habe ich das jetzt ausreichend erläutert? Könnt ihr das ggf. reproduzieren?

Ich hoffe die Bilder sind groß genug. Als Neuling darf nur 2 Bilder posten.

Du hast mich ja bisher gar nichts gefragt außer der URL und erstmal rumgepöbelt, das ich ja keine Ahnung hätte.

Ja, Bilder sind hilfreich. Aber nur weil jemand seine Situation noch etwas beschreibt, ist das kein Roman.

Ja, lösche einfach die 2. Zeile mit dem AAAA-Record deiner Domain.
Lass dann aber auch das &ip6=<ip6addr> in der Update-URL sonst legt die m.W. Dennis wieder an.

1 Like

Prügelt doch nicht immer gleich so auf die neuen Anfänger ein das bringt das Forum schnell in einen schlechten Ruf. Alle haben mal klein angefangen. Zumal meiner Meinung nach ipv6 nicht trivial und das auch der Grund ist, weshalb es sich noch nicht durchgesetzt hat. Auch wenn es immer mehr wird.

1 Like

Wenn man die Anfänger mind. drei mal nach der VOLLSTÄNDIGEN Update-URL als „Vorformatierten Text“ fragt und immer nur Fragmente dieser zu sehen bekommt, weil das als Fließtext hier nicht sendbar ist. dann ist irgendwann auch mal Schluss mit lustig.

Sich hier mal die verschieden Optionen zur Textformatierung anzusehen und diese dann zu nutzen, erfordert kein IT-Spezialwissen und kann auch IT-Laien zugemutet werden. Word/Excel können die ja in der Regel alle bedienen, somit mit minimalem Einsatz von Gehirnschmalz auch diesen Editor hier,

Stimmt. Aber der Ton macht trotzdem die Musik. Off Topic aber eigene Erfahrung als Linux-Anfänger von mir:

Der Ton auf manche Fragen kann einem schnell den Spaß verderben. Umkehrschluss es verwundert nicht dass Linux in seiner Aussenwahrnehmung “ein System für freaks” bleibt.

Genauso ist es hier, wir sollten froh sein dass die Leute sich trauen und sie fördern nicht den Spaß nehmen. Sonst bleibt ipv6 in der Niesche.

1 Like

Ich frage mich ja, warum ein Forum, welches warscheinlich in jedem 3. Post irgendwelche Formatierungszeichen aus html und co enthält ausgerechnet so designed sein muss, das beim directen copy’n’paste der Text vermurkst wird… Aber Schwamm drüber. Jetzt hab ichs ja.

Ich hab dir dieses Bild hier gegeben (zugegeben kein Text):Screenshot 2026-03-02 141750

Wenn du zu faul bist, das abzutippen oder nicht in der Lage bist, eine andere vorhandene URL entsprechend abzuwandeln… Komm mal von deinem hohen Ross runter! Keiner zwingt dich hier zu antworten.

Wie ich schon geschrieben habe: Wenn man sich an Dennis Anleitung und hält Video hält, führt das nicht zum gewünschten Erfolg. Jedenfalls nicht bei mir. Du magst jetzt denken, ich bin ein d**mer Anfänger. Da sge ich nur: Ich befolge strikt die Anleitung, die einem überall so präsentiert wird: lehne dich zurück, wir machen das schon. Steht sogar in dem Ton bei den Anleitungen. Und wenn es dann hakt.. Ich hab ja wie zu Anfang geschrieben schon viele andere Dinge/URLs ausprobiert, stundenlang gegoogelt usw. Ich bin durchaus technisch versiert und ambitioniert, denke aber nicht, dass ich mich für mein Hilfegesuch rechtfertigen oder beschimpfen lassen muss. Fragst du nie nach Hilfe, wenn du an einer Stelle nicht weiter kommst?

Woher soll ich denn die Variablen für die Update-URLs von ipv64.net kennen? Nirgendwo wird “=auto&” erwähnt. Die Syntax kann man sich ja erschließen. Nützt einem nur nichts, wenn man nicht weiß, was man dann verbinden soll.

So. Genug “Romane” geschrieben. Das Thema ist durch und ich werde hier nichts mehr posten. Nicht nur in diesem Thread, sondern generell nicht mehr. Auf Typen wie dich kann ich verzichten.

Vielen Dank geht raus an @markusonwheels und @Benares !

Jetzt sei nicht so sauer, das bringt doch nichts.
Hast du schon gesehen, dass man bestimmte Updates in der ipv64.net-Oberfläche auch einfach verbieten kann?


Aber ich denke, dein eigentliches Problem ist ja inzwischen gelöst, oder?

Auch wenn der TS (@NilsS) das folgende vermutlich weder lesen wird noch will, ist die von ihm in Beitrag 5 präsentierte Lösung falsch.

Warum ist diese Lösung falsch? Sehen wir uns folgendes Bildschirmfoto an:


Wir sehen dort die aktuell verwendeten IPv6-Präfixe einer FritzBox. Relevant sind hier die IPv6-Präfixe für

  • Heimnetz = 2a02:3100:7c03:1400::/64
  • WAN = 2a02:3100:7206:70ef::/64

Nun sehen wir uns an, was ein DynDNS-Update bei ipv64 mit der vom TS als Lösung präsentierten update-URL = https://ipv64.net/update.php?key=abcdefghijklmnopqrstuvwxyz0123456789&ip=<ipaddr>&ip6lanprefix=auto&<ip6lanprefix> bewirkt:


Wie wir sehen sorgt diese dafür, dass im Feld unterhalb von IPv6 Prefix (DynDNS Prefix) der Wert 2a02:3100:7206:70ef::/64 als Ergebnis der Aktualisierung des IPv6-Präfixes eingetragen wurde. Das ist aber eindeutig der IPv6-Präfixe des WAN’s der Fritte und daher unbrauchbar für Server die im LAN der Fritte per IPv6 erreichbar gemacht werden sollen.

Die Lösung des TS ist somit falsch.

Kommen wir nun zur korrekten Lösung. Für diese benötigeh wir eine andere Update-URL, nämlich folgende: https://ipv64.net/update.php?key=abcdefghijklmnopqrstuvwxyz0123456789&ip=<ipaddr>&ip6lanprefix=<ip6lanprefix>. Erst mit dieser wird das gewünschte Ergebnis erreicht. Siehe:


Wie wir sehen sorgt diese nun dafür, dass im Feld unterhalb von IPv6 Prefix (DynDNS Prefix) der Wert 2a02:3100:7c03:1400::/64 als Ergebnis der Aktualisierung des IPv6-Präfixes eingetragen wurde. Das ist nun eindeutig der IPv6-Präfixe des Heimnetz (LAN’s) der Fritte und nur mit diesem Präfix können Server im LAN der Fritte per IPv6 erreichbar gemacht werden.

Aber Hauptsache der TS konnte hier ordentlich herum mosern, Update-URL’s, die richtig sind, als falsch diffamieren und seine falsche Update-URL als Lösung verbrämen.

1 Like