Ipv6 Präfix wird nicht aktualisiert

Das ist auch genau das was deine verwendete Update URL machen soll. Du verwendest eine dreiteilige Update URL. Diese aktualsisert:

  1. Die IPv4-Adresse (A Record)
  2. Die IPv6-Adresse (AAAA Record)
  3. den IPv6-Ürefix des LAN’s

Genau das passiert auch bei ipv64 und es werden korrekt die Einträge dazu erzeugt / aktualisiert. Auch der IPv6-Prefix wurde ja aktualisiert. Im ersten Bild von deiner Domain bei IPv64 sieht mann dass der Prefix auf b00:/64 endet. Im zweiten auf c800:/64. Also alles so wie du es mit der von dir gewählten URL beauftragt hast. Es ist kein Fehler seitens ipv64 sondern ein Denkfehler bei dir, der dir aber nicht bewusst ist.

Wenn ich mir da erstere Bild ansehe, dann denke ich du willst ausschließlich einen AAAA-Record im Format: „Interface-ID“ (ex. ::6743:12::f9aa::44a1) oder Format: „EUI-64 MAC“ (ex. 3C:49:37:12:26:B3) haben, der auf den Prefix verweist. Dann aber darfst du auch nur den Prefix per Update-URL aktualisieren, sonst nix. Dann sollte auch das Ergebnis stimmen.

Verwende also diese Update URL:

https://ipv64.net/nic/update?key=meinDomainupdatekey&ip6lanprefix=<ip6lanprefix>

oder

https://ipv64.net/nic/update?key=meinDomainupdateKey&domain=meineDomain.home64.de&ip6lanprefix=<ip6lanprefix>

nachdem du bei ipv64 alles wieder so zurückgesetzt hast wie auf dem Bild mit dem Prefix der auf b00:/64 endet.

Hier ergänzend eine generelle „Bastelanleitung“ für Update URL’s für Fritten:

WAN IPv4- & IPv6-Adresse updaten:

https://ipv64.net/nic/update?key=1234567890abcdefgh&ip=<ipaddr>&ip6=<ip6addr>

WAN IPv4- & IPv6-Adresse & IPv6-LAN-Prefix updaten:

https://ipv64.net/nic/update?key=1234567890abcdefgh&ip=<ipaddr>&ip6=<ip6addr>&ip6lanprefix=<ip6lanprefix>

WAN IPv6-Adresse & IPv6-LAN-Prefix updaten:

https://ipv64.net/nic/update?key=1234567890abcdefgh&ip6=<ip6addr>&ip6lanprefix=<ip6lanprefix>

WAN IPv4-Adresse & IPv6-LAN-Prefix updaten:

https://ipv64.net/nic/update?key=1234567890abcdefgh&ip=<ipaddr>&ip6lanprefix=<ip6lanprefix>

genau dieses

du willst ausschließlich einen AAAA-Record im Format: „Interface-ID“ (ex. ::6743:12::f9aa::44a1) oder Format: „EUI-64 MAC“ (ex. 3C:49:37:12:26:B3) haben, der auf den Prefix verweist

in der Nacht habe ich mir nochmal alles durch den Kopf gehen lassen,
der Logik-Fährte gefolgt

Fritzbox macht alles richtig, sendet was ihr aufgetragen wurde (Update-URL)

ipv64 macht alles richtig, verarbeitet die gesendeten Parameter

also ist ein (in diesem Fall &ip6=<ip6addr>) Parameter zuviel in der Update-URL

in einem Blog zu genau dieser Thematik hatte ich noch etwas gefunden

aus dem Blog :
bei Tests klappte die Übermittlung nur, wenn wir in der Update-URL zwingend den Platzhalter <ip6addr> verwendet wird

an der Update-URL einfach noch "&trash=<ip6addr>" anhängen,

ausprobiert, geht aber nicht, dieses unterstützt ipv64 nicht

dann heute Morgen einfach ausprobiert , Update-URL ohne &ip6=<ip6addr> Parameter,

geht !! alles funktioniert wie es soll !!

obwohl die Fritzbox bei der Übermittlung ohne &ip6=<ip6addr> angeblich Zicken macht
(ist vieleich bei einem FritzOS Update gefixt worden)

deshalb, und auch weil in der Anleitung zum Prefix-Update

der Parameter „&ip6=<ip6addr>“ mit aufgeführt wird, hatte ich diesen Parameter in der Update-URL immer mit angegeben

vieleicht sollte man die Anleitung diesbezüglich anpassen/erweitern
(z.b. "nur Prefix übermitteln , &ip6=<ip6addr> weg lassen)

Fazit

ohne &ip6=<ip6addr> in der Update-URL klappts auch mit „nur Prefix beziehen/updaten“

Naja, in den weitaus meisten Konstellationen werden die Nutzer von ipv64 und einer Fritte IPv6-Adresse und Ipv6-Prefix updaten wollen. Wer auf der Fritte z.B. Wireguard laufen hat braucht dafür, soll oder muss IPv6 genutzt werden (Stichwort: DS-Lite, CG-NAT), auch die IPv6-Adresse des WAN’s der Fritte. Denn da lauscht ja Wireguard dann.

Im Normalfall, also das was 95% machen würden, nimmt man für den IPv6-Prefix dann auch einen (oder auch mehrere) Domain-Präfixe, also z.B. www.Domain.ipv64.net, cloud.Domain.ipv64.net, etc., während die WAN-IPv6 auf Domain.ipv64.net zeigt und dort dann der Wireguard-Port der Fritte lauscht.

Ohne Verwendung des Domain-Präfix kannst so wie du das jetzt machst ja pro Port (wie bei IPv4) nur einen Server erreichbar machen oder musst wieder eine nginx-Proxy nutzen. Der Vorteil von IPv6 ist doch aber gerade, dass alle internen Server auch eine eigene öffentlich erreichbare IPv6-Adresse haben und ich somit mehrere Server direkt per IPv6 erreichbar machen kann, die z.B. https (tcp 443) nutzen, ohne Proxy und andere Verrenkungen.

1 „Gefällt mir“

Ja, noch läuft bei mir alles über einen nginx-Proxy ,

und genau für den brauche ich noch das WAN-Prefix .

nun kann ich in Ruhe alles auf ipv6 umstellen .

über die Einrichtung der (sub)Domain-Prefixe werde ich mich noch belesen ,

einige sub-Domains einer 2ten anderen Domain laufen über eine pfsense und

werden auch über die pfsense geupdatet .

aber der Anfang (Umstellung auf ipv6) ist schon mal gemacht. :slightly_smiling_face:

Die WAN-IPv6 brauchst du nur, wenn du die Fritte selbst von aussen erreichen möchtest. Für alle anderen Geräte hinterlege deren Interface Identifier als AAAA-Record. Der Prefix kommt dann durch das Prefix-Update mit hinzu. Schau aber, dass du den richtigen Interface Identifier erwischst, also keinen, der durch die Privacy Extension zusätzlich vergeben wird.

genau so läuft es ja

und was ist nun das Problem?

Problem und Lösung steht einige posts höher

einfach durchlesen