From nobody Tue Jan 27 20:46:37 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 4f0yBc0xrbz6QQ11 for ; Tue, 27 Jan 2026 20:47:04 +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 4f0yBZ2lKfz3cn1 for ; Tue, 27 Jan 2026 20:47:02 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=vhO2caBk; dmarc=pass (policy=quarantine) header.from=plan-b.pwste.edu.pl; spf=pass (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl designates 2001:678:618::40 as permitted sender) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl 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 60RKkcIF063093 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 27 Jan 2026 21:46:49 +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=1769546809; bh=WEw2jDXzHiKtWlhhoqD7uUHkVzSqwptKlC5n0JsnKWg=; h=Date:Subject:To:References:From:In-Reply-To; b=vhO2caBktzSqJObUrICzPveTxUKYVrjsX+/cc75JxDN8Zfdj0+00KF0Lll03vvqXr CTGmU3tGSWb0Xtrnfvj2d/Wu5L1+bu/Hml4WLg8XfAZ9ZJI4DyKgSKk1DsTESe/rJd dkzTQ6L2ZGtbDqBz7UNICPPRab6D7hTwoqt8TcmLcBRj8/NvKRODpxSEyC3a1K5nmp skAs5a4v8X6lvXEi+iM4W6n3+hkBarjPNpFZhL2ZdzYWd3WbqlyCkjEqtU4fqrOZ1l 3/kfLMfLxpakj8pViLvsbvVXfvZ9BZkk9kqfWA55I7mLJpFgZWZdX17AsMn2h3tKHl pUYhrdTRH+mMg== 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: <39a63487-ee9a-4792-a787-d476ae6f6a0c@plan-b.pwste.edu.pl> Date: Tue, 27 Jan 2026 21:46:37 +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: freebsd-current@freebsd.org References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> <0f5fcd3d-b189-49f5-ac81-d4fb48d90a77@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: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.78 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.980]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_HAS_DN(0.00)[]; HAS_XAW(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+] X-Rspamd-Queue-Id: 4f0yBZ2lKfz3cn1 W dniu 27.01.2026 o 21:09, Shawn Webb pisze: > On Tue, Jan 27, 2026 at 09:01:53PM +0100, Guido Falsi wrote: >> On 1/27/26 20:17, Shawn Webb wrote: >>> 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 metric 0 mtu 1500 >>> options=10 >>> 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? >> You are correct. >> >> AFAIK the relevant RFCs implemented here were studied to be compatible with >> one another. >> >> >> >> To give some details: >> >> The net.inet6.ip6.use_stableaddr sysctl changes the algorithm that >> incorporates the MAC address in the IPv6 address with one deriving the IPv6 >> address with an hash (sha256 HMAC) of the concatenation of various sources, >> as described in RFC 7217, specifically: >> >> - the network prefix >> >> - MAC address, interface name or interface id (configurable via >> net.inet6.ip6.stableaddr_netifsource, default uses MAC address) >> >> - hostid (this is a UUID, constant on the machine) >> >> - a counter, usually 0, incremented if there are DAD conflicts (another host >> with same address is detected on the network, counter incremented and a new >> address is checked, by default for 3 times, configurable via >> net.inet6.ip6.use_stableaddr) >> >> - we use an additional counter to cater for the very rare case the algorithm >> should generate an invalid address, in such a case the counter is >> incremented and another address generated and verified. > Way cool! For when there might be a conflict: is any jitter applied to > the new address generation? If we made it to this point (where the > counters actually matter), if the conflicting systems don't apply a > random jitter, there could be a chance of counter exhaustion. The interface ID in a stable privacy address has to remain the same within the same network (the same prefix). Applying jitter will not fix it. This patch was tested and works fine. Making it the default is a good step, as well as doing an MFC of stable privacy to stable/15 (without making it default there). The only possible clash between systems could happen when a lazy admin clones a system, uses the same interface name, and does not regenerate the host UUID. To narrow the impact, I suggest switching to the MAC address as the default key source instead of the interface name. Sometimes MAC addresses are cloned as well, but that usually depends more on the virtualizing host than on the sysadmin who clones the system. -- Marek Zarychta > > I would highly doubt that would happen in practice. I suspect the > stars would have to align and we would have already learned how to > speak fluent Dog with our furry friends. ;-) > > Thanks, >