> Am 05.07.2025 um 08:56 schrieb Geoff Steckel <g...@oat.com>: > > On 7/5/25 12:18 AM, Mike Fischer wrote: >>> Am 04.07.2025 um 22:08 schrieb Geoff Steckel <g...@oat.com>: >>> >>> Can anyone point me at a reference/discussion for ipv6 server addressing? >>> >>> rad(8) & slaacd(8) work well for clients. >>> >>> I have OpenBSD servers with IPv4 addresses including local DNS for them. >>> I would like to allow naive clients to connect to them using IPv6. >>> What addressing scheme might work well given ISP prefix changes? >>> >>> thanks >>> Geoff Steckel >>> >>> I see three ways to do this. All have problems. >>> 1) assign a fd00::/8 subnet for server access >>> >> This would work if you only need to access the server from other devices on >> your LAN. > Thank you very much for your thoughts. > That's the desired case. >> You would probably need to set up a local DNS to resolve names to the ULA >> address > There is one. >> and get all relevant clients to use that DNS for resolving names. >> > That's harder - there's a battle between "use my DNS" > and "your DNS is bad - I'll go to the root servers myself"
You could configure your local DNS in a way that it will serve a local domain itself, while forwarding all other requests to your current resolver. Or in the case of Unbound, have it resolve all other requests itself by using the root servers (which you would need for DNSSEC validation anyway if you don’t want to trust some other resolver). Or you could define hostnames in a subdomain of your public domain (if you have one) and have them resolve to your ULA addresses. (Though I seem to remember that doing this in a similar case with RFC 1918 IPv4 addresses was not recommended.) > I may subvert/block port 53 like some ISPs do. Sounds complicated and potentially dangerous. And you might miss DoH requests. > I set the "managed" bit in advertisements and run a DHCP6 server > which works for some hosts. I think you would need DHCPv4 to announce your DNS as well. You don’t know which type of IP the client resolver will use to access your DNS. And manually configured (non-DHCP) clients would also need to be touched. [snip] > >>> This would amount to a static Interface Identifier (IID) combined with the >>> dynamic public IPv6 prefix, correct? > Yes >> >> The only way I was able to solve this was by using `inet6 autoconf >> -temporary -soii` which effectively generates an EUI-64 IID while still >> reacting to changes of the prefix. >> >> I have found no way to specify an arbitrary (manual) static IID in >> combination with a dynamic prefix. (But if someone knows how to do this, I’d >> be interested.) >> > slaacd conflates two functions which I believe should be separate: > 1) generating the interface id initially > 2) maintaining the prefix > In its current form it works very well for clients/hosts. I’m not sure the two functions need to be separate. It would be sufficient if the IID generation could be made more configurable. > For servers, changing it to notice that an interface has an > all zero prefix and a nonzero IID so leave the IID alone could work. > ifconfig <ifc> inet6 -autoconf > ifconfig <ifc> inet6 <whatever> delete > ifconfig <ifc> inet6 0000::<something>/64 > ifconfig <ifc> inet6 autoconf I agree that a syntax for manually specifying an IID would be helpful. Its use would need to imply -temporary and -soii. So either `::<iid>`, `::<iid>/64` or `iid <iid>` might work. I have not researched how all this (ifconfig, slaacd, interface drivers, autoconf) works internally. So I don’t have an opinion on where or how any changes might be implemented. > It is a significant change and probably not acceptable. > Splitting it into two programs is also troublesome. >> The second issue you might need to solve is updating DNS records when the >> public prefix changes. DDNS can generally handle the DNS side but you need >> to figure out when to trigger the update. Apart from polling to check if the >> prefix/address has changed, Florian Obser had a suggestion for this in [1]. >> >> [1] https://marc.info/?l=openbsd-misc&m=172537841313091&w=2 >> > Alternatively, there's a rad(8)-like program which can execute > a program when it announces a prefix change. > I forget whether it's from KAME or one of the other BSDs. I haven’t found something like this on OpenBSD yet. rad(8) does not seem to have a provision for such a hook. > Either could trigger a little awk/perl/sh/sed/etc massaging > and signal unbound(8). >> The third potential issue might be to also reconfigure services running on >> the server to LISTEN on the current IPv6 address after the prefix has >> changed. Sometimes this is solved by specifying `*` as the LISTEN address. >> But if a specific IPv6 address is specified then the config must be updated >> and the service reloaded when the prefix change > Not currently an issue - * works; external servers are hosted elsewhere. Fine. This would be more likely to be an issue when using public IPv6 addresses, especially if different services on the same host need to use different IPv6 addresses (i.e. different IIDs). >> The fourth potential issue depends on your Internet routeIt needs to allow >> packets addressed to the public IPv6 address of your service to reach the >> host on the LAN. The solution is highly dependent on the software running on >> your router. >> > > The machines don't normally service requests from outside. Right. Then this part of the discussion is irrelevant for your use-case. In my case I do host some services locally that I may want reach from the Internet. > The router/firewall is OpenBSD so pf works. Ok, so you have a highly configurable place to centrally detect changes of the public IPv6 prefix. That is a better starting point than many commercial home routers. [snip] >> > Thanks again > Geoff Steckel Mike
