Re: we should enable RFC7217 by default

Shawn Webb <[email protected]> Tue, 27 Jan 2026 19:17:18 +0000
Newsgroups	gmane.os.freebsd.current
Message-ID	<n7aw5afsi5nclf5z4p4txyh2ixrsik2ludwcbrhmszce2ohzlf@ngx6ukw2il7t>
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?

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
signature.asc (application/pgp-signature, 833 B)