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"
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 triggera 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
