Re: we should enable RFC7217 by default
- Reply: Shawn Webb : "Re: we should enable RFC7217 by default"
- In reply to: Shawn Webb : "Re: we should enable RFC7217 by default"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 27 Jan 2026 18:27:28 UTC
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.
--
Guido Falsi <madpilot@FreeBSD.org>