From nobody Mon Feb 9 21:48:50 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 4f8yxv0kJLz6QbFV for ; Mon, 09 Feb 2026 21:48:51 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f8yxt6wT1z3lYJ; Mon, 09 Feb 2026 21:48:50 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770673731; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UKBm0Fzb3IlUIYT5rIWqUZ3vdVcvFAUwNe+l1Uyfp7Q=; b=QolPGAsoYo8TvwtKa+XVa1YuKhLDqG31dAB31rjP7X7kpDVDtoqKubWbR9fVBH8n0t4HvT NbwteTti1NhKoUMBeu+N/gEG6fN6jgWvkAnTtp9wWgPe61lf2s2DxKIAoiUZ9Ire85qoVl JPSECOPqqFEDGZmjlQ32vRt2chdJpL7mBqoyG+/21QAYac3//8FEy2L7pns8/WbP42cAXD 4+NK8eQki7WxDgYheYAt7VmrhUYTAKb7rH+If992L29PoLJmlEzDev800p9CxvYYJvVkJR hKglokdnm6v1Jd68R1glfVg3aicEyQmQ+950qEC/PyOorv0x9v36chNRB83j4Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1770673731; a=rsa-sha256; cv=none; b=R2pzq3c3pbKpUmF2OYnp98DgfO7b9TXbOaQd6IW9NU+ucTy3bfQqFdCLcWu7/sUQ3kq8S4 ieCfsnDwZszJe+E/8A6j8BPDqwLRf4uGodWLtv/qVKHj0T3LWPsplxAIsn+Ag+2sDlacVV nI2OOytfdtrss4bYWDkFxJULJjod+3sMPUcz9CEumzorumwE1FqpjjM131WROVlfw5vEhQ ms4ulfm/2bFNQmoSsBy0wmFcyNa6fzy/NstPU6zsz8nKf4okKQYcorIkxXmWn8IJvD+CDX 8pFRzxDHCbGE7L/LMTG3WdmJm1bjbDSwPo4dWPgzI4NdM4906OWeSdOOLQEY8g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1770673731; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UKBm0Fzb3IlUIYT5rIWqUZ3vdVcvFAUwNe+l1Uyfp7Q=; b=W+QZBtz/2tyfVkl4/dH6EQx3AmQg6g8284KjlLZJ/k3sjqGjqZoEu1xtLobz/t6w/i/wCJ MIk2VChXjRJw9uLhLl918f1/cKnoBa0xHGKd0narAykBg44nSSA/xWEpPQSsOH5I4YcYkQ ZWc0uNVsVLZvOcZwd9aLpMSp6YNowoPToyBM1Qbb6piBqnfNvnE12flj+dsuHb4i/eo4Qn WyUH6p+1jlou6Y21CNgP8m7pLrIBET0R8sM5+Kr/SkPRe/XyM0+jZx3ZL/kbfWvE9eFsXt 1IWUcEO/mQJoXn9PmXzQt43WwgsBIhuAUglXwU/as9IR0Oq9PTDaJsomYQ9+1g== Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 did not present a certificate) (Authenticated sender: brooks/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f8yxt61p1z5mg; Mon, 09 Feb 2026 21:48:50 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 131BB3C01A1; Mon, 09 Feb 2026 21:48:50 +0000 (UTC) Date: Mon, 9 Feb 2026 21:48:50 +0000 From: Brooks Davis To: Guido Falsi Cc: Pouria Mousavizadeh Tehrani , freebsd-current@freebsd.org Subject: Re: we should enable RFC7217 by default Message-ID: References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> <7521210e-1348-40b8-85ed-8e7a0d3b290a@FreeBSD.org> <2593e290-77ec-41d1-801a-79a6eff3dc93@FreeBSD.org> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2593e290-77ec-41d1-801a-79a6eff3dc93@FreeBSD.org> On Mon, Feb 09, 2026 at 10:09:04PM +0100, Guido Falsi wrote: > On 2/9/26 21:49, Guido Falsi wrote: > > On 1/28/26 11:00, Brooks Davis 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 wonder if we should ship an update to 15 (landing in 15.1) explicitly > > > adding net.inet6.ip6.use_stableaddr=1 and a suitable comment to > > > /etc/sysctl.conf so people who later upgrade to 16 aren't painfully > > > surprised when their server disappears.?? New installs of 16 would get > > > the new default, but upgrades would keep the old default.?? The downside > > > would be that people who have edited sysctl.conf would have a merge > > > conflict to resolve, but that's a fairly normal thing. > > > > > > -- Brooks > > > > > > > > > Hi all, I just committed the change in the default (thanks to zlei for > > approving it, and all the reviewers). [1] > > > > > > I'll also send an heads up to current@ and net@ just in case. > > > > > > I am replying t this specific message in the thread because I do like > > brooks' idea on how to introduce this on stable. > > > > Once I get the MFC approved and committed [2], I could send a further PR > > implementing such a change on stable/15 sysctl.conf. > > While writing my heads up message I just noticed this plan cannot work, > unluckily. > > Due to the nature of the sysctl, enabling it via /etc/sysctl.conf would cause > the change to only affect interfaces created after sourcing the file. This > means that for most machines the default interface would be unaffected and > keep the default to the in kernel one. > > To achieve the effect Brooks suggests would require the "soft switch" to > happen via loader.conf. Not sure if this is a good idea though. I think all my reasoning still applies to loader.conf. IMO, people are going to be really upset if they miss a release note that causes their system to be inaccessable via IP. Even with proper remote access, it's super annoying to fix (having done this to myself many times by many means). -- Brooks