On 1/27/26 21:09, Shawn Webb wrote:
On Tue, Jan 27, 2026 at 09:01:53PM +0100, Guido Falsi wrote:
On 1/27/26 20:17, Shawn Webb wrote:
On Tue, Jan 27, 2026 at 07:27:28PM +0100, Guido Falsi wrote:
On 1/27/26 19:17, Shawn Webb wrote:
[...]
The one thing I would hope is that support for completely random IPv6
addresses via SLAAC does not go the way of the dodo.
(If net.inet6.ip6.use_stableaddr becomes the default, we will likely
keep it at 0 in favor of the other aforementioned sysctl nodes.)
Those are two orthogonal things.
stableaddress enabled replaces the current algorithm for deriving the main
interface address, that stays attached to the interface indefinitely.
tempaddr creates additional addresses for the interface that are used (and
preferred if the prefer flag is enabled) for outgoing connections, and are
generated again periodically, with old ones remaining attached to the
interface, since old connections could still use them, till reboot.
The two can live together, there is no reason to disable one of them.
BTW while developing my patch, in one of the first iterations, I did break
the tempaddr mechanism, so I can assure you I took special care for them to
not interfere with each other.
Seems I was indeed a bit confused. Thank you for the explanation.
So looking at one of my current SLAAC systems, I see:
==== BEGIN LOG ====
bridge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric
0 mtu 1500
options=10<VLAN_HWTAGGING>
ether 58:9c:fc:10:d7:7e
inet 192.168.1.251 netmask 0xfffff000 broadcast 192.168.15.255
inet6 fe80::5a9c:fcff:fe10:d77e%bridge0 prefixlen 64 scopeid 0x3
inet6 2001:470:4001:1:5a9c:fcff:fe10:d77e prefixlen 64 autoconf
pltime 14400 vltime 86400
inet6 2001:470:4001:1:c001:f868:c587:cdd7 prefixlen 64 deprecated
autoconf temporary pltime 0 vltime 44033
inet6 2001:470:4001:1:c139:85be:79b3:e3ec prefixlen 64 autoconf
temporary pltime 12610 vltime 86400
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
bridge flags=0<>
==== END LOG ====
From what I understand now, the only thing that would change is the
2001:470:4001:1:5a9c:fcff:fe10:d77e address. Instead of incorporating
the MAC address in that IP address, it would be the stableaddr
address.
Amy I understanding that correctly?
You are correct.
AFAIK the relevant RFCs implemented here were studied to be compatible with
one another.
To give some details:
The net.inet6.ip6.use_stableaddr sysctl changes the algorithm that
incorporates the MAC address in the IPv6 address with one deriving the IPv6
address with an hash (sha256 HMAC) of the concatenation of various sources,
as described in RFC 7217, specifically:
- the network prefix
- MAC address, interface name or interface id (configurable via
net.inet6.ip6.stableaddr_netifsource, default uses MAC address)
Made a mistake here, default is interface name, as it is suggested in
the RFC with higher priority than MAC address. the preference there is
"interface index" but we do not have stable indexes, so it is a poor
choice on FreeBSD.
Anyway the default can be changed if deemed better, but using the mac
address would cause the IPv6 address to change even for simple hardware
replacement, which looks undesirable, and against the RFC intention.
- hostid (this is a UUID, constant on the machine)
- a counter, usually 0, incremented if there are DAD conflicts (another host
with same address is detected on the network, counter incremented and a new
address is checked, by default for 3 times, configurable via
net.inet6.ip6.use_stableaddr)
- we use an additional counter to cater for the very rare case the algorithm
should generate an invalid address, in such a case the counter is
incremented and another address generated and verified.
Way cool! For when there might be a conflict: is any jitter applied to
the new address generation? If we made it to this point (where the
counters actually matter), if the conflicting systems don't apply a
random jitter, there could be a chance of counter exhaustion.
I'm not completely sure, and should check the code, but I think I
remember the DAD checks already have some random time delay embedded
that would cause jitter in the retries.
I would highly doubt that would happen in practice. I suspect the
stars would have to align and we would have already learned how to
speak fluent Dog with our furry friends. ;-)
As you say, the chances are very low, unless both hosts have the same
exact values for the hash, and generate the new addresses with the same
exact delays. As soon as one host "beats" the other to an address it
will keep it and the other host will calculate a new one.
The worst thing is, with no intervention, those two hosts would be in a
permanent race conditions and switching IPs randomly when rebooted, not
optimal, but chances are really low.
The only situation where the issue could be noticeable is cloning a
bunch of VMs from the same image without changing the hostid (which
would be an error anyway) and running them simultaneously in the same
subnet. This can be easily avoided in two ways:
- change hostid (easily done by removing /etc/hostid before creating the
image or using something like cloud-init)
- configure the base image to use MAC address for stableaddr
(or both...)
--
Guido Falsi <[email protected]>
