On 1/27/26 21:55, Patrick M. Hausen wrote:
HI all,
Am 27.01.2026 um 21:46 schrieb Marek Zarychta <[email protected]>:
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 <[email protected]>
