From nobody Tue Jan 27 18:27:28 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 4f0v5Z66ZNz6QDmT for ; Tue, 27 Jan 2026 18:27:30 +0000 (UTC) (envelope-from madpilot@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 4f0v5Z5b5Mz3k8Q for ; Tue, 27 Jan 2026 18:27:30 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769538450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=3VB68o1Toi76qAbqq62UupZQJVMzuAkmq98Gzcjtx+Y=; b=Bdwi2b/rsxtgrk+Dk1PYJBuItI5C5j01odkW8nl++qh++wf9m8TL/e8dJRuq8SaLB3PkAg O7gHAYJ359TFgu7ZpGh82kH0asYBudxEpSQK8mZYhIfX/DoUHZerZW2dywDw89L53bNrnW x6yjGG7d9aU0WSMN01Dd0HHrwlcBM3Do6xzi+p4GSePTbIcUvZNErgNoF2W71UPMtXGs6Y LfcMLzb/azx6ShoPGdmzGsPQ9ByXnX8k/qcGuLxbHSk5Op/2VQ9F2QjEH7QvKlOhBfFd90 /RqGgQQOePVPncQpNEVIERM60jY/FLhvx0/EMZniDhmyfFzgxNqOg9OnB+iQAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769538450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=3VB68o1Toi76qAbqq62UupZQJVMzuAkmq98Gzcjtx+Y=; b=tZs7VKvHQAJkQa4p/SRZ6JL9K8h04/vmV+w88hpYyJXw4AY3E9Iczn2CXhAgYu/146JnzR KRr3AbbBN98lOxGnKL4ErMmVQwMCVbq7Jri/bJcK6mUXmll/Oum/R0po72eEmrtSvrqQbq JrTsHRNWvuyz6Di5ZLSCv3m8yUiMdyvWwA1VPX8n1biZLRMd2AKMi7aG/+jtpczRFCXRYT W1qFRm9gTGaOkeAhexgbMpN5+S4MrxzAI9zEEAtxeGGBDe6v2N8cJEBxuZv8m98/ln4dAA a3OT6LaKBu7i8kV3ljCL5ctzSzkOt5yB4dUrzUakeZHumiKDIO9UyZLHrDeIxQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769538450; a=rsa-sha256; cv=none; b=Ofh+zoBO/dvQs4Gen9izJ+AJgaxdLPK9izoz/gcHtS+9ud91vucl5ygfFfqqEEo4lQr/wZ oHbUPK60krEYTAC9RmQXVxl88ec7AMWTCk3FdbQQqlXiGAKBz+8Z5uypMyuNtYk7ZNC8y3 8Nr+4xshW4TOSSiU687ZKqZga6WkVlvCDaXaRdpAQ0T9QXiwUgEhuovSaGKhdU1WbCz6TX lC0XULRPwS3rKC0moSFGgsin8FywPF+plOVNwTHj8t2Jna3Il7NFIC2ox3msHFMUteo19k zVW+XHX0xA3DTHEuw+vhzo3lqDlnYxiiz9IXc2YNeoyetpTX2p17qezQmZiDvQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2a01:e11:2002:4280:ab9b:8bf1:ec36:413a] (unknown [IPv6:2a01:e11:2002:4280:ab9b:8bf1:ec36:413a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f0v5Z39KgzHhY for ; Tue, 27 Jan 2026 18:27:30 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <0f5fcd3d-b189-49f5-ac81-d4fb48d90a77@FreeBSD.org> Date: Tue, 27 Jan 2026 19:27:28 +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 From: Guido Falsi Subject: Re: we should enable RFC7217 by default To: freebsd-current@freebsd.org References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> Content-Language: en-US Autocrypt: addr=madpilot@FreeBSD.org; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNIkd1aWRvIEZhbHNpIDxtYWRwaWxvdEBGcmVlQlNELm9yZz7CwHgEEwECACIFAk+G+3MC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEBrmhg5Wy9KT2uIIAIrawQ89TnqEhi2C OEQAhx3uqWZuNoS6NyiSgsRCmtSnT2GOgH4Ucbr/I37SkV1B3K6HkoL6lwN8Gjf5KOgLqmTi E1W3RTwS7l8PSvdnjM9i7g351R4mTijtxawB/JcQf/Kge3Yqr1V4g6H+wQXHUStmHThbupuN trzRphvR/e5ekT0FTyVfPmpcbm68i2bwZnKUex/TNIECBykYh8b+SYMLhENf2ayRjCIWS2Ad 7tnTKhMtnS5jtW6qjBy4RoTpQD6oR1xIgkTRlQ49roVCUfdHb+Y/kh+U9G1IcoNy4vkg9IfP dwpSfnP+a8j0AZ1hMnOLZ1fYoQrs+4gVLy8Fs7TOwU0EUxB7QQEQAKFhrDceoPdK/IHDSmoj 6SQYisvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef +WE75M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ube T3XwQO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr 8OEQfOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB 2i6A/xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45 qfyhMiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0 xpNiUilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWA dlKCNTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanC YrAg+8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNR gow3kSuArUp6zSmJABEBAAHCwF8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCk X/qwEVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7F jfrV+dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxA lZ/7i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+ lQMZ9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8 LkQdrQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncg== In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. -- Guido Falsi