Re: we should enable RFC7217 by default

On 1/27/26 21:55, Patrick M. Hausen wrote:
> HI all,
> 
> Am 27.01.2026 um 21:46 schrieb Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>:
> 
>> To narrow the impact, I suggest switching to the MAC address as the default key source instead of the interface name.
> 
> If I read the relevant RFC correctly the main argument for stable addresses in contrast to
> traditional EUI-64 is the narrowing of the search space in sweep scan attacks.
> Because the OUIs which make up half of the order of magnitude are well known.
> 
> Isn't that the case, too, if we start with the MAC address and the hash algorithm
> by which the final address is generated is public?
> 

All this has already been discussed in the code review.

My intent while implementing this was to adhere to the RFC letter and 
intent. Looks like some suggestions are based on the idea that personal 
preference has priority over RFC conformance.

The RFC has a relatively strict description of the algorithm.

Anyway the point against using MAC addresses, and preferring other 
options, is clearly stated in the RFC in appendix A.

The MAC address is suggested as a third option (the first was not really 
viable in FreeBSD since interface indexes are not stable, so I used the 
second as the main one), and the paragraph talking about MAC addresses 
clearly states it is not a good choice [1].

I'd also add that my understanding of the RFC is that the compromise 
between privacy and address stableness in this one is more towards 
stableness of the address, which is also what I was after. There are 
other more recent RFCs addressing the privacy issues more aggressively 
(for example RFC 8981). If privacy is the primary concern these options 
should be investigated.

I don't see how cloned hosts should be a problem. it is quite easy to 
force a machine to regenerate its hostid.

Anyway I will not scream against changing the default for sysctl 
net.inet6.ip6.stableaddr_netifsource, but my opinion is against changing 
it, for all the reasons I have already stated in the review and here, 
and will not perform such a change myself.


[1]  https://www.rfc-editor.org/rfc/rfc7217#appendix-A.3

-- 
Guido Falsi <madpilot@FreeBSD.org>