as a workaround i guess you could send the updates from a machine in the local network.

Sure, but that feels like a rather clumsy way to cure the symptoms, not the cause … and, besides, doesn’t answer my questions. ;-)

I’m trying to understand the principles, and find a good way for more than just one machine or service. Which should also allow me to explain it to others, without ending up in lots of machines to support for friends … or even having to CNAME "MyFRITZ" ugly names on my real servers for them.

I was hoping for nsupdate.info, which I use and recommend for a long time, since it’s robust and keeps improving all the time.

Somehow I feel this might be an issue where router and dynamic DNS vendors need to work together, maybe using more modern update protocols?

As a temporary workaround, I think it might be feasible to force the router’s DHCPv6 to hand out addresses based on provider prefix + EUI-64 (as per RFC2373) and then use one host inside the LAN to update nsupdate.info’s record with its own global (non-temporary) dynamic IPv6 address, so nsupdate.info can in turn update the related host addresses. The router’s own WAN IPv6 would be lost with this scheme, though. Quite a flakey scheme, but it could save installing ddns update daemons on many machines, what do you think?

the dyndns protocol can only transfer 1 ip address (as a url argument).
if it is omitted, the sender ip address is used (http REMOTE_ADDR).

nsupdate.info will use whatever ip you send to it and it is the job of the client to determine the "correct" one.

as long as your client ip v6 addrs can be computed as prefix + id, it is enough to send 1 update with the correct prefix and have the related hosts table provide hostnames and ids for all your clients.

I don't know about AVM, but other DDNS clients, allow you to choose the Interface from which the update requests are to be sent out. I had to get used to send IPv4 update request from the WAN interface (as usual) but send IPv6 update requests from the LAN interface instead. This is how it works on pfSense and OpenWRT/Lede/Turris.

Fritz!Boxes always use ther WAN i/f address with the built-in DDNS client. So the best bet would really be to use a machine inside the LAN.

Crazy enough, AVM offer their own DDNS service, called "MyFRITZ", that correctly handles all this and even creates A+AAAA records for hosts that have "port forwarding" (with IPv6, actually only a firewall rule to open a port). Proprietary protocol between their routers and service, of course. Sigh. And it generates really ugly long domain names … and we have no CNAME for IPv6, so that’s no option either.

Guess I’ll further experiment with a host inside the LAN, and nsupdate.info, of course. Strongly believe in FOSS.

I’m conferring with AVM, regarding extra variables, or even a suggested extension of the dyndns2 protocol. I reckon open source services like nsupdate.info could pick it up, since it wouldn’t break existing clients.

Here’s a short snippet from one of my mails (sorry, German, translation follows):

Hallo Herr …,

hier im Nachgang noch ein paar Infos/Tipps:

Mittlerweile habe ich für den ddns type "userdefined" noch folgenden URL string probiert (mit gleichem Ergebnis):

https://ipv4.nsupdate.info/nic/update?hostname=<domain>&myip=<ipaddr> https://ipv6.nsupdate.info/nic/update?hostname=<domain>&myip=<ip6addr>

Falls es die Variable nicht vielleicht intern schon gibt, wäre es hilfreich, einfach ein (besser zwei) weitere einzuführen:

• <ip6addr-local> oder <ip6addr-lan> – sollte die IPv6-Adresse der Fritz!Box auf der lokalen (LAN-)Seite enthalten. Daraus könnten Prefix und mit Verwendung der EUI-64 auch korrekte lokale Hostadressen gebildet werden.
• <ip6addr-prefix> – könnte den zugeteilten IPv6-Prefix enthalten, etwa "2xxx:xx:xxxx:xxxx::/56". Damit wäre es für einen DDNS-Anbieter auch einfacher, die Netmask zu ermitteln. Derzeit muss man das noch manuell dort vorgeben (bspw. bei nsupdate.info).

Die vorgeschlagene Lösung hätte mehrere Vorteile:

• »doesn’t break existing applications«
• Ein geneigter Expertenbenutzer könnte (auf eigenes Risko und Wissen) z.B. das bestehende dyndns2-Protokoll »missbrauchen«, um statt der WAN-seitigen Fritz!Box-Adresse die interne (also eine aus dem zugeteilten Prefix) zu übermitteln und so derzeit bestehende DDNS-Dienste nutzen, um auf weitere interne Hosts zu referenzieren.
• Open-Source-Anbieter von DDNS-Diensten würden sich sicher schnell darauf einschießen, vielleicht gelänge es auf Dauer sogar, ein neues DDNS-Protokoll zu etablieren (dyndns3?), das bspw. IPv4- und IPv6-Adresse sowie den zugeteilten Prefix mit Netmask in einer Anfrage übermitteln könnte, bspw. in der Form:
  /nic/update?hostname=<domain>&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG&myip=<ipaddr>&myip6=<ip6addr>&myip6prefix=<ip6addr-prefix>

Nun, schauen wir einmal. Vielleicht mögen Sie das ja mal an die Entwicklung weiterleiten?

Wie immer mit besten Grüßen
…

In essence, I ask for the (possible) use of two more variables in DDNS updates: Apart from the router’s IPv6 WAN address <ip6addr> the additional use of either the router’s internal (local) IPv6 address (<ip6addr-local>) and/or a variable that returns the provider-assigned IPv6 prefix/netmask (<ip6addr-prefix>).

This could be helpful in bringing up a new "extended" (maybe "dyndns3"?) protocol which of course open source DDNS providers like nsupdate.info could easily integrate. And it’s about time for such, too.

News from AVM: Their R&D are having a look into the issue.

Let’s hope for the best. I strongly feel there should be an open and transparent way to handle this, apart from having each local IPv6 host run their own ddns clients (not just their "MyFritz" service which handles it correctly but in a proprietary way).

Did AVM ever reply with a solution to this problem?

https://service.avm.de/help/de/FRITZ-Box-7590/018/hilfe_dyndns
Firmware: 7.12
The help pages says that besides ipaddr and ip6addr that there is a third parameter called ip6lanprefix.

ip6lanprefix does not work in my Fritzbox with v7.21. I am currently trying to convince the first level support, that this actually is a bug on their side and not in my software, as I am hosting my own dyndns service. I have no problems with ip6addr though. If I leave ip6addr out and only trying to use ip6lanprefix I get Illegal INADDR on my webserver. If I have both ip6 statements inserted the Fritzbox is not even making a request.

Update: Problem fixed. I was not aware enough that ipv4 and ipv6 needed two seperate update calls, seperated by a space. Also AVM did not recognize this even though they had my logs. After changing this I can see ipv6 address and the ipv6 subnet being transfered correctly with v7.2.1

as found out by petric, the ip6lanprefix placeholder of the fritz box sends something like 1111:2222:3333:4444::/64, which is not accepted by nsupdate.info, because it is not a (pure) v6 addr. maybe we could just strip the /64 netmask part or even use it somehow.

using this is needed it the v6 prefix of the router is different from the v6 prefix of the internal LAN.

Hi there,

i just discovered a very similar problem. If have created an AWS lambda function to see the .
The prefix actually is displayed like this xxxx:xxxx:xxxx:xxxx::/56 in the FrotzBox ui. But is send as to my service.

I have filed a ticked at AVM now.

Regards

Tim