Support ipprefix via argument

[the-nic]

Allow an extra argument ipprefix for both ipv4 and ipv6 to pass a separate prefix, like often for IPv6 connections where one gets a main ipv6 for the router and a subnet for the internal network.

Passing the ipprefix will also override the default netmask from the config.

Fixes #353

[ThomasWaldmann]

Is that ipprefix parameter supported by any dyndns service and any dyndns client already?

[the-nic]

to be honest, not that I know of. I used dynv6 before, but they are down now, and they had their own - but similar API.
https://www.do.de/wiki/flexdns-ipv6/ seems to have something like that, too.

For me at least, I wanted that because passing the iplanprefix as myip is not working, unfortunately. So it does solve a practical problem - at least when using a fritzbox

[the-nic]

If you want I can adjust the behavior or rename the parameter. The advantage of the extra parameter is that it keeps the api still compatible, as the calls still work without it as before.

[the-nic]

Any consideration? Or alternative suggestion? I mean, this is a real-world problem :)

[ThomasWaldmann]

I didn't do any related investigations yet, but at least I started working on the software and site again - primarily due to #505 (which is already half-done on the prod system).

For this PR it would be great if you could rebase it on current master branch, so that the github actions based tests will run (travis-ci is defunct here since long).

[the-nic]

rebased on master

[PhrozenByte]

Any updates on this @ThomasWaldmann?

I can confirm that this is a real-life issue: Deutsche Telekom assigns customers both a /64 and a /56 prefix by default (two totally different subnets indeed, i.e. the /64 subnet is not within the /56 subnet). AVM Fritz!Box routers will then use the given /64 prefix just for the router and use a randomly chosen /64 subnet within the given /56 subnet for all clients in the network. That's why we can't derive the IPv6 addresses of related hosts using the routers IPv6 address - they are in different subnets. It just took me some time to notice that the prefixes don't match 🙈

By googling for "ip6lanprefix" (as in how AVM calls it) one finds multiple other dynamic DNS services (e.g. dynv6.com, dnshome.de, strato.com, do.de) with similar API parameters, however, they are all named differently. Calling it "ipprefix" makes sense IMO considering it works for both IPv4 and IPv6 (even though I doubt than one would ever use it for IPv4...).

Would be great if we can get this to prod ❤️

[the-nic]

Happy second birthday 🎉

[ThomasWaldmann]

Update:

Since 0.13.0, the service supports:

• giving a network (a prefix) via, for example, ?myip=1.2.3.0/24 or ?myip=1:2:3:4::/64. the given netmask will be just stripped and ignored (it will use the configured netmasks from the host record in the database)
• if the received address ANDed with the netmask gives an all-zero host, no DNS A or AAAA will be created for the main host, but related hosts can be used to create host records in that network (v4 or v6)
• giving multiple ip addrs or networks via ?myip=<v4>,<v6>

So, considering that, can we close this?

[PhrozenByte]

Works like a charm, thank you Thomas! 🚀 🎉

However, there's a minor practical difference to this PR: This PR allows to configure the prefix for related hosts specifically. This PR thus allows one to use both the primary host and related hosts, whereas the new ?myip= parameter allows one to either use the primary host, or related hosts, but not both at the same time when the router's address is in a different subnet.

Just to emphasise: My personal use case has been fixed. I don't need IPv6 access to the router specifically, but rather just want to use related hosts, so the ?myip= solution is perfectly fine for me. So, in any case, a huge thank you Thomas! ❤️

---

About the limitation:

I'm with Deutsche Telekom again (wasn't for quite a while, but they enabled FTTH for me literally just yesterday 😅) and I'm still using an AVM Fritz!Box router. They have assigned 2003:f6:97ff:4fbb::/64 to the router specifically (variable <ip6addr>, the router then chose address 2003:f6:97ff:4fbb:422:cbeb:128a:47e8), and 2003:f6:974f:6a00::/56 as the network prefix (variable <ip6lanprefix>; note that this subnet doesn't include the router's address). My primary host is dyn.example.com with a configured /56 prefix length, and there's also a related host vpn.dyn.example.com with IPv6 interface ID ::2.

With the update URL https://ipv6.nsupdate.info/nic/update?myip=<ip6lanprefix> nsupdate.info will set the IPv6 of related host vpn.dyn.example.com to 2003:f6:974f:6a00::2 - exactly as expected. However, the IPv6 of primary host dyn.example.com will be unset (as you also noted).

With the update URL https://ipv6.nsupdate.info/nic/update?myip=<ip6addr> (same as just https://ipv6.nsupdate.info/nic/update) nsupdate.info will set the IPv6 of primary host dyn.example.com to 2003:f6:97ff:4fbb:422:cbeb:128a:47e8 - exactly as expected. However, the IPv6 of the related host vpn.dyn.example.com will be 2003:f6:97ff:4f00::2 - which is just wrong.

With an update URL like https://ipv6.nsupdate.info/nic/update?myip=<ip6addr>,<ip6lanprefix> nsupdate.info will always just choose the IPv6 address given last.

Suggestion: nsupdate.info could either additionally support the ?ipprefix= parameter as suggested in this PR, or the meaning of the ?myip= parameter could be changed so that e.g. the first IPv6 address is used for the primary host, and a second IPv6 for related hosts; if just one IPv6 is given, it is used for both. Same for IPv4 of course (i.e., ?myip=<ipaddr>,<ip6addr>,<ip6lanprefix> would choose <ipaddr> for both the primary host's IPv4 and the IPv4 of related hosts, <ip6addr> for the primary host's IPv6, and <ip6lanprefix for the IPv6 of related hosts).

[PhrozenByte]

Looks like my assessment was a bit premature 😒

Depending on the ISP and the DynDNS2 client (i.e., the router) ?myip=<ip6lanprefix> might not work, because routers fail to verify the primary host's AAAA RR, which causes them to send the same IPv6 subnet again until nsupdate.info automatically flags such host as abuse after a few days (also the reason why I noticed this just yesterday).

?myip=<ip6lanprefix> works with neither Deutsche Telekom nor Vodafone with AVM Fritz!Box routers out-of-the-box. However, there are (different) workarounds for both ISPs. So, it still works for me (thanks Thomas! ❤️), but there might be scenarios in which neither workaround works - and I kinda doubt that many users will find these workarounds 🙈

The solution is unchanged: nsupdate.info could support something like the suggested ?ipprefix= parameter, or syntax like ?myip=<ip6addr>,<ip6lanprefix>.

---

More details:

The issue is the following: To meet the DynDNS2 protocol requirement of only sending IP address updates when the IP address has changed, some DynDNS2 clients like AVM Fritz!Box routers query the DNS regularly to check whether the client's current IP address matches the published one. If the IP addresses differ or if the check fails (possibly after some retries), the router will send another update. To perform this check the router will use the primary host. However, with ?myip=<ip6lanprefix> the router doesn't actually send an IPv6 address, but a subnet, causing nsupdate.info to delete the primary host's AAAA RR. Consequently, the router's DNS check of the primary host fails and the router sends the same ?myip=<ip6lanprefix> again… which naturally still won't create an AAAA RR… thus the router's DNS check still fails and it tries again after some time… and again… and again… until nsupdate.info automatically flags the host as abuse because it has received the same addresses over and over again.

I'm not just with Deutsche Telekom, but also with Vodafone. It works with neither out-of-the-box, but there are workarounds for both:

• Deutsche Telekom uses Dual Stack, i.e., they delegate a native IPv4 address and two IPv6 subnets (/64 for the router and /56 for LAN clients). The IPv4 address works just fine, the A RR will be set and done. However, sending ?myip=<ip6lanprefix> causes the primary host's AAAA RR to be unset, causing the router to send IPv6 updates over and over again, ultimately causing nsupdate.info to flag the host as abuse.

  What saves the day here is v0.13.0 and an implementation detail of AVM Fritz!Box routers: If one does not use separate update URLs for IPv4 and IPv6, but a single ?myip=<ipaddr>,<ip6lanprefix> update URL (thanks to v0.13.0 👏), the router will be happy with just the matching A RR and won't try again.

• Vodafone uses DS-Lite, i.e., they delegate a /56 IPv6 subnet only (no native IPv4, just a CG NAT). Since there's no IPv4 address there will be no A RR. With ?myip=<ip6lanprefix> the primary host's AAAA RR will also be unset. Consequently, the router assumes that something went wrong and sends the same IPv6 subnet over and over again until nsupdate.info flags the host.

  Again, coincidence saves the day: Even though Vodafone delegates a /56 subnet, AVM Fritz!Box routers will always use the first /64 subnet for the router and the second /64 subnet for LAN clients. This allows one to abstain from using ?myip=<ip6lanprefix>: one can use ?myip=<ip6addr> or just ipv6.nsupdate.info instead and calculate related host addresses with interface IDs like ::1:0:0:0:2. This way the primary host's AAAA RR will be set and the router won't send repeated updates.