Re: ipv6 prefix maintenance

On 7/5/25 12:18 AM, Mike Fischer wrote:

Am 04.07.2025 um 22:08 schrieb Geoff Steckel <gwes@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"
I may subvert/block port 53 like some ISPs do.
I set the "managed" bit in advertisements and run a DHCP6 server
which works for some hosts.

  BTW: The correct prefix for ULA is fc00::/7 (RFC 4193, RFC 8190).  

Setting the "L" bit (RFC 4193 section 3) -> fd00::8

The servers then have at least two addresses.
They have to be configured to use the globally routeable source address
when communicating outside.
I'm not sure how route(8) priority interacts with IPv6 source address choice.

  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?

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.
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
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.


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.

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.
The router/firewall is OpenBSD so pf works.

    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    

Thanks again
  Geoff Steckel