From nobody Tue Jan 27 22:00:45 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4f0zqw26XWz6QTqv for ; Tue, 27 Jan 2026 22:01:00 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT TLS ECC 1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f0zqv6Fhjz3rkx for ; Tue, 27 Jan 2026 22:00:59 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.2/8.17.2) with ESMTPSA id 60RM0jLj063488 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 27 Jan 2026 23:00:46 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1769551246; bh=ybGGTWcncQkGZ+ZdqlOZ3ezAvfcos2sxBq3hTMNIyKo=; h=Date:Subject:To:References:From:In-Reply-To; b=K2KN+73p+uzQLaVnL6T3a5ixAFD/usxd0nDkIv7wASWALP6Owb+QvtRuOU1rHd+SI X5UMK2alRYEvktgI1sAcO1a3V5ETexEZoPpsBolaQCi3TkF77dFFKSVXoC6LSZr9Jw zCpcvvjynakL/ra845+WREIKXtAUoVVYQxbXQsrwMFwTTmLnZKV69w/61lIfbCHW3o 4nU50AUHITfGEEhFHsxoWBfhQpL03Yx7rdUiTMG2jnjDaabBlSpAZEKQn+CwYbLgU9 LceY/wXSj7D3TTXbjf//Os46HSRFQRKQI6N+lE/fbaTlGLnJlL8JoZ0MVdQoaZIaBk j5Tdyv0q85LFg== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Message-ID: Date: Tue, 27 Jan 2026 23:00:45 +0100 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: we should enable RFC7217 by default To: Guido Falsi , freebsd-current@freebsd.org References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> <0f5fcd3d-b189-49f5-ac81-d4fb48d90a77@FreeBSD.org> <39a63487-ee9a-4792-a787-d476ae6f6a0c@plan-b.pwste.edu.pl> <240ec1f1-ca30-44b9-b654-1a114c71d6f3@FreeBSD.org> Content-Language: en-US From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNN01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD7CwHcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgc7ATQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V4= In-Reply-To: <240ec1f1-ca30-44b9-b654-1a114c71d6f3@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4f0zqv6Fhjz3rkx W dniu 27.01.2026 o 22:28, Guido Falsi pisze: > On 1/27/26 21:55, Patrick M. Hausen wrote: >> HI all, >> >> Am 27.01.2026 um 21:46 schrieb Marek Zarychta >> : >> >>> 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 > Hi Guido, I am not here to object, but to support your change, although my perspective is different - probably spoiled by having seen too many improperly cloned systems. In one of the messages in this thread, you mentioned consensus, there will never be full consensus, which is perfectly fine, but the discussion has certainly raised interest in this subject. FreeBSD was likely last actively developed operating system without stable privacy (RFC 7217) implemented, so Guido, many thanks for your work on this. I believe that once enabled, this feature will be highly appreciated, perhaps even cherished, by the community. Thank you also for defending the choice of the interface name as the correct key for generating these interface IDs. We discussed this in the past, but list subscribers were not following that review on the Phabricator. The method should not be a point of contention when making stable addresses the default. I keep my fingers crossed that stable privacy (RFC 7217) will become the default in main, and that it will be MFCed to stable/15. I would also like to thank Pouria for bringing this topic up. Cheers -- Marek Zarychta