Re: we should enable RFC7217 by default
Date: Tue, 27 Jan 2026 20:09:49 UTC
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:
> > > > On Tue, Jan 27, 2026 at 03:35:16AM +0330, Pouria Mousavizadeh Tehrani wrote:
> > > > > Hi everyone,
> > > > >
> > > > > With `net.inet6.ip6.use_stableaddr` now available, I believe we should
> > > > > enable it by default in CURRENT at least.
> > > > > As you may already know, we currently use the EUI64 method for generating
> > > > > stable IPv6 addresses, which has serious privacy issues.
> > > > >
> > > > > IMHO, trying to maintain backward compatibility defeats the purpose of a
> > > > > privacy RFC.
> > > > >
> > > > > To be clear, we don't want to change the ip addresses of existing servers.
> > > > > However, it's reasonable for users to expect changes during a major upgrade
> > > > > (15 -> 16), a fresh install of a new major release, or living on CURRENT.
> > > > > So, for obvious reasons, changing the default value would not be MFCed.
> > > > >
> > > > > What do you think?
> > > >
> > > > I think this would be a good step for FreeBSD. In HardenedBSD, we set
> > > > net.inet6.ip6.{prefer,use}_tempaddr to 1, which creates completely
> > > > random IPv6 addresses (scoped to the prefix, of course).
> > > >
> > > > 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)
>
> - 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 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. ;-)
Thanks,
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Signal Username: shawn_webb.74
Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc