> 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. You would probably need to set up a local DNS to resolve names to the ULA address and get all relevant clients to use that DNS for resolving names. BTW: The correct prefix for ULA is fc00::/7 (RFC 4193, RFC 8190). > or > 2) use the single (dynamic) global prefix everywhere This would amount to a static Interface Identifier (IID) combined with the dynamic public IPv6 prefix, correct? 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.) 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 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 changes. The fourth potential issue depends on your Internet router. It 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. > or > 3) advertise link-layer addresses for servers See (1). > and > 4) zeroconf isn't applicable and confuses things Again, it would only allow local access. HTH Mike
