NUT server listens on the wrong IPv6 address

[fencepost-error]

With the following example upsd.conf:

LISTEN upsserver.lan 3493

the server listens on the IPv6 address that was current when it was started but never updates when the address changes, so after awhile it ends up listening on an address that will never get any connections:

> dig upsserver.lan AAAA
;; ANSWER SECTION:
upsserver.lan.         0       IN      AAAA    2403:de00:2200:f06:xxxx:xxxx:xxxx:5678

However the NUT server is still listening on whatever IPv6 address was current at the time it started (...1234), not the one that's in use now (...5678):

> ifconfig | grep 5678
    inet6 2403:de00:2200:f06:xxxx:xxxx:xxxx:5678/64 scope global temporary dynamic
> ifconfig | grep 1234
    inet6 2403:de00:2200:f06:xxxx:xxxx:xxxx:1234/64 scope global temporary deprecated dynamic

Perhaps the NUT server could warn about, or report an error with, using hostnames in the LISTEN entry in the presence of IPv6 addresses, or update the code to do whatever sshd, httpds, etc do to keep current with interface addresses.

[jimklimov]

Fair point, PR welcome.

[jimklimov]

BTW, the other servers you've mentioned - did you bind them also to the hostname, or to "ANY" address (e.g. all-zeroes)?

[fencepost-error]

Yes, I worked around it with LISTEN :: which bypasses the issue, with the original form I was just trying to be a bit more specific about where and what I accepted connections from/on.

The server it's on, out-of-the-box Ubuntu 22.04 LTS, isn't assigning any permanent IPv6 addresses, just temporary dynamic and a handful of expired temporary deprecated dynamic still hanging around. Let me do some reading on it to see how this is addressed at the code level, sshd and lighttpd on the same box switch over to the current (non-expired) address so presumably there's some mechanism to deal with listening on non-permanent addresses.

[fencepost-error]

It looks like there's no way to address this in code. RFC 5014 (from 2007) defines a inet6_is_srcaddr() where you can check whether a temporary address is in use and warn about it, but nothing seems to implement this except z/OS. Even then, if someone did implement it, it would only tell you it's a temporary address, not that it's a deprecated address.

So it looks like it's more of a design decision, what's the appropriate action to take if someone specifies a hostname, rather than ::, that resolves to an IPv6 address which may only be usable for a few hours?

[jimklimov]

I'd dare say that addresses flipping so quickly are unacceptable for a server :D

Clients caching the older DNS name would also have troubles once every few minutes/hours as the server migrated to another address but they still poke the old one. Persistent clients like upsmon that essentially establish a session and run with it would also have troubles (although specifically upsmon I think should be able to reconnect).

Other than that, maybe the server should re-resolve the name and close a listener and start a new one if address(es) behind it changed. The question is how frequently: we use the system resolver which is same for /etc/hosts, DNS, LDAP or whatever you put in nsswitch.conf, so I am not sure there is at that level any concept for TTL of the name.

On related note, upsd also listens on the first IP address seen even if several were resolved by the name (DNS aliases, etc.)

[fencepost-error]

Yeah, it came as a bit of a surprise because previously I'd been connecting over IPv4 (which was stable), and then the initial IPv6 connect was fine as well, it was only after a few days had passed and the client reconnected that the problem cropped up.

In case this is useful for anyone else hitting this problem, I've had a look at how other things that report use of temporary addresses handle this. ip opens a netlink socket to NETLINK_ROUTE and reads what looks like a giant blob of JSON over the link, ifconfig reads /proc/net/if_inet6 and parses it, and FreeBSD, OpenBSD, and OS X use the SIOCGIFAFLAG_IN6 ioctl and check for the IN6_IFF_TEMPORARY flag, this seems to be a BSD thing given that they all support it.

Admittedly this isn't notably useful except to confirm that there's no regular way to do it.