From nobody Mon Jan 26 09:00:25 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 4f02Ym2tqjz6Pxm5; Mon, 26 Jan 2026 09:00:28 +0000 (UTC) (envelope-from glebius@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 4f02Ym289Tz3DQQ; Mon, 26 Jan 2026 09:00:28 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769418028; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=o5tWqP0lWqyPecWI9/ff2YXL45nU7lZe2DAQXZvF3Mo=; b=mhYuNlzHdaGN9UNtYeSLLIaHrBD67gseYQglLOZLKM9c1DAiwTdzA21zG80SETzWRu3zZa MDtH8FPHDWKOY4JXxGgB26kq0nn7QxexXYMKfTs5qiGNPDAfdF3YHiOiDHEx7FiEdte6mw 5s2mIoGF2SUq0xZdVn4Id8aisFm+jHlXlrr6/EExwHNZm/4UeqNLLCMZS03BRrdqp1tC35 d0uu9QbaRSJmfmNr+OiJLdDhmh7mG165oZm8aYtmigIZY71n1mJXkMDIj/a49fytBVrY3R RheatOv8UXP5/YC/eDu/NaB+q+tFgNmXZUShC/wDLgHL9h1prLKSgdtjAAtz3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769418028; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=o5tWqP0lWqyPecWI9/ff2YXL45nU7lZe2DAQXZvF3Mo=; b=OPO6sdirRLy8qMKWoGasEkrzDacq2HlFrpwc4fmMaxK5acK6vOwkqVNYSH47+5yzkpSJOL Z/UE63g1JdVbfGJYQWQaLkMbouDqINMhTc7iw81Eta0skk/j7XrQbXBk2FMCMizLpafHa/ hOP3v0nSuZfmHCPwjhCr4kMno7NDKMv3yvyhZJF2BAs8koxQ1JzGsOV48bvJq4IDdHIwHx Qq5mLrJkg1TwsxOTteCFbgxJxxb+8Czr81K0PUROQ2oAHxiqBY7ALhmsRMxAgCWr5e7UNV HuVmszda0g3PPzTfqW4doopgQTbJuY1SDzTUfDI+mfgp3CfuH8O61XLhJc/I+w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769418028; a=rsa-sha256; cv=none; b=ujSHbZBca5MIpq8WFa+AFAHewT73PowYx2QQzRVdmxIClLjQ8DzIrEwVhudO9YaAgGL26V 4hH0f/wkHTdFJvOjnkZdeN3lsf5ujwTTE8j/inURLufs6VQqsqKaE/UcWAO+cmfjMXfFwn SQXEc63hKWpQAWy/LN+bfnFgIo9q26UhnXJLviGgdgW/tSBtm7HdZs7F5gJrQ5K70uIgGo /mXQnRvxUIbZWG06WfLpnxGiweIoG5R2kp+tdCHgGIHGTV6UGfgQwyjs/ksGPTc4WqkgBB tJ7HieH5TqoHSQ2Mu3Ih2ABV/tX7ua6LA9MU/q0JAgu++t0yvWlk0LxKf06eKw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f02Yl6dhPz12gm; Mon, 26 Jan 2026 09:00:27 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 26 Jan 2026 01:00:25 -0800 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: January 2026 stabilization week Message-ID: 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 Hi FreeBSD/main users & developers: This is an automated email to inform you that the January 2026 stabilization week started with FreeBSD/main at main-n283376-8ef8c6abfadf, which was tagged as main-stabweek-2026-Jan. Those who want to participate in the stabilization week are encouraged to update to the above revision/tag and test their systems. The tag main-stabweek-2026-Jan has been published at Gleb Smirnoff's github repo. To connect this repo as an additional remote you need to run: git remote add glebius https://github.com/glebius/FreeBSD Once remote is configured, to checkout the tag run: git fetch glebius --tags git checkout main-stabweek-2026-Jan If you want to use only the official FreeBSD repo, then update to the revision: git pull git checkout 8ef8c6abfadf Developers are encouraged to avoid pushing new features to FreeBSD/main during the stabilization week, but focus on bugfixes instead. The stabilization week runs up to Friday 18:00 UTC, but if there is consensus that any regressions discovered by participants have been fixed, it will end early. Once that happens, the advisory freeze of FreeBSD/main branch is thawed. -- Gleb Smirnoff From nobody Mon Jan 26 14:30:41 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 4f09tw4ygNz6QLf8; Mon, 26 Jan 2026 14:30:48 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4f09tw2qHKz3qTY; Mon, 26 Jan 2026 14:30:48 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 813A6D7893; Mon, 26 Jan 2026 14:30:41 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 60QEUfiG002745; Mon, 26 Jan 2026 14:30:41 GMT (envelope-from phk) Message-Id: <202601261430.60QEUfiG002745@critter.freebsd.dk> To: Gleb Smirnoff cc: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: January 2026 stabilization week In-reply-to: From: "Poul-Henning Kamp" References: 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-ID: <2743.1769437841.1@critter.freebsd.dk> Date: Mon, 26 Jan 2026 14:30:41 +0000 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4f09tw2qHKz3qTY -------- Gleb Smirnoff writes: > started with FreeBSD/main at main-n283376-8ef8c6abfadf Live on T14s Gen2, so far nothing to note. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Mon Jan 26 16:38:02 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 4f0Dk10Mrjz6QVDp for ; Mon, 26 Jan 2026 16:38:17 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f0Dk02rH2z3GCD for ; Mon, 26 Jan 2026 16:38:16 +0000 (UTC) (envelope-from fernando.apesteguia@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of fernando.apesteguia@gmail.com designates 209.85.167.177 as permitted sender) smtp.mailfrom=fernando.apesteguia@gmail.com Received: by mail-oi1-f177.google.com with SMTP id 5614622812f47-45c719bb855so2716175b6e.1 for ; Mon, 26 Jan 2026 08:38:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769445495; x=1770050295; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5k7Xya44GhaouFWzZf0Epp147hjhBO58tfu6jo+xPKs=; b=Gl4pH1TJ96WPlTh+Q5I933Ep19rU0cXXoiXCmjzsfP4DtbRQulnYtNIpoQikr8S48i 1XqNyWaDrpND6ZnnxpTbMyqc8kTxa8B6iYEp7dQdWkf3bcdf63Xr/YaZ/7WShQ4eaVzC ufcRId1PG7xBLH6+HjxAGOhauGI7hZOR8udMuF9cX+TN9UG3QH+skVJpy4ZkQK9e+EWa mzJ8qU9fN4VVNidKfPtyfI0MfPH2+pbg5x85Yd0DllUnIHZZvKfnkQzLwot7MPgu8tHi PRUj5ksAFuCaTQoofrBWYef8MPdRscHeiiYlLF5EWGWb8IJ6yIsE+kdn23wRIQQL8QKz 4nWA== X-Gm-Message-State: AOJu0YxjZZuIpi7lcAXRgh19kauZeR/a26zhUflBgkNG5BNyzh8+Msg0 3A1S7LwNUd1L1J4mVzyq6eZtPfVLaeCSf7VMjqlZC95gNF/O/nAQ8+nGiN0NGg== X-Gm-Gg: AZuq6aKnsmeC28SHAAJFxwVO8eUeMf459wARgvaEj1dup2RQV7mSt5vCABfBKzdmI20 8aj2RbgcUqSo4nvcf8UUFifF2Yw2o2TbWvKQliwY/z21dPtjyYQ9IuaQUheXY6uy+KQ4IX/x4cW DmgGoMvzefaNWsCYOOD5Z2Z2F+CaLWvLdBNOSDSNII/FHMZ8khFmU++tq4f0oqHRtvnbp7t5q+p 76Pd/G4Ft4IrWMdgA+IBLrFp2In+svarY1Q6U0rYwZjkQLaDPaqLeTYsJe+SglIZhCZPXnJbvx0 VmIg50xRTqWxc9kBIpb0L2t5ElMv3mSLPqsUlgYWpKtL56/fmELZd4hm7VFY0xH84FWgOH5wuHN HjByPls6o5gCBcRm8kc/TGNHeIkVMdfhCMA3XWwFfTw9qp8G34ET/juwlIiqxf8yBKO+5yjn9My 4DEee2gxl7b/Sao/T3BlgrC/prOwb/NN/qWVlJfMsi6k3uZ6Q= X-Received: by 2002:a05:6808:1707:b0:45e:e21f:bb9f with SMTP id 5614622812f47-45ee21fbd7cmr1331303b6e.24.1769445494984; Mon, 26 Jan 2026 08:38:14 -0800 (PST) Received: from mail-oo1-f42.google.com (mail-oo1-f42.google.com. [209.85.161.42]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-408afc03891sm7581146fac.15.2026.01.26.08.38.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 08:38:14 -0800 (PST) Received: by mail-oo1-f42.google.com with SMTP id 006d021491bc7-6610c5b014cso2346475eaf.0 for ; Mon, 26 Jan 2026 08:38:14 -0800 (PST) X-Received: by 2002:a05:6820:1609:b0:662:c8a5:66b6 with SMTP id 006d021491bc7-662e044efd2mr2427813eaf.51.1769445494475; Mon, 26 Jan 2026 08:38:14 -0800 (PST) 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 From: =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= Date: Mon, 26 Jan 2026 17:38:02 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_QgPw96XSLPfGF_bJyX1LoyrXWk7lZenyDMBJ7JB3L2_CmU4vtnuPeShEn8 Message-ID: Subject: Error building kernel To: freebsd-current Content-Type: multipart/alternative; boundary="00000000000025d26c06494d22d3" X-Spamd-Bar: / X-Spamd-Result: default: False [-0.07 / 15.00]; NEURAL_HAM_LONG(-0.86)[-0.863]; R_MIXED_CHARSET(0.83)[subject]; NEURAL_HAM_MEDIUM(-0.49)[-0.490]; NEURAL_SPAM_SHORT(0.35)[0.350]; FORGED_SENDER(0.30)[fernape@freebsd.org,fernandoapesteguia@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[fernape@freebsd.org,fernandoapesteguia@gmail.com]; MISSING_XM_UA(0.00)[]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.177:from]; TO_DOM_EQ_FROM_DOM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.177:from,209.85.161.42:received] X-Rspamd-Queue-Id: 4f0Dk02rH2z3GCD --00000000000025d26c06494d22d3 Content-Type: text/plain; charset="UTF-8" Hi all, I'm trying to update one of my systems to latest current. Buildworld is fine, but building the kernel fails with this error. Any ideas why? --- all_subdir_sfxge --- ctfconvert -L VERSION -g sfxge.o --- sfxge.ko.full --- ld -m elf_x86_64_fbsd -warn-common --build-id=sha1 -T /usr/home/fernape/FreeBSD-repos/src/sys/conf/ldscript.kmod.amd64 -r -o sfxge.ko.full sfxge.o sfxge_dma.o sfxge_ev.o sfxge_intr.o sfxge_mcdi.o sfxge_nvram.o sfxge_port.o sfxge_rx.o sfxge_tx.o efx_bootcfg.o efx_crc32.o efx_ev.o efx_intr.o efx_lic.o efx_mac.o efx_mcdi.o efx_mon.o efx_nic.o efx_nvram.o efx_phy.o efx_port.o efx_rx.o efx_sram.o efx_tunnel.o efx_tx.o efx_vpd.o efx_filter.o efx_hash.o mcdi_mon.o siena_mac.o siena_mcdi.o siena_nic.o siena_nvram.o siena_phy.o siena_sram.o siena_vpd.o ef10_ev.o ef10_filter.o ef10_image.o ef10_intr.o ef10_mac.o ef10_mcdi.o ef10_nic.o ef10_nvram.o ef10_phy.o ef10_rx.o ef10_tx.o ef10_vpd.o hunt_nic.o medford_nic.o medford2_nic.o ld: error: efx_rx.o: invalid sh_type for string table section [index 1]: expected SHT_STRTAB, but got SHT_NULL *** [sfxge.ko.full] Error code 1 make[4]: stopped making "all" in /usr/home/fernape/FreeBSD-repos/src/sys/modules/sfxge make[4]: 1 error make[4]: stopped making "all" in /usr/home/fernape/FreeBSD-repos/src/sys/modules/sfxge make[3]: stopped making "all" in /usr/home/fernape/FreeBSD-repos/src/sys/modules --- all_subdir_rtw89 --- ctfconvert -L VERSION -g rtw8922a_rfk.o --- rtw8922a.o --- ctfconvert -L VERSION -g rtw8922a.o --- all_subdir_sge --- ctfconvert -L VERSION -g if_sge.o make[3]: stopped making "all" in /usr/home/fernape/FreeBSD-repos/src/sys/modules --- all_subdir_rtw89 --- make[3]: stopped making "all" in /usr/home/fernape/FreeBSD-repos/src/sys/modules make[2]: stopped making "all" in /usr/obj/usr/home/fernape/FreeBSD-repos/src/amd64.amd64/sys/GENERIC 1062.82 real 3851.16 user 168.32 sys make[1]: stopped making "buildkernel" in /usr/home/fernape/FreeBSD-repos/src make: stopped making "kernel" in /usr/home/fernape/FreeBSD-repos/src --00000000000025d26c06494d22d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I'm trying to up= date one of my systems to latest current. Buildworld is fine, but building = the kernel fails with this error.

Any ideas why?

--- all_subdir_sfxge ---
ctfconvert -L VERSION= -g sfxge.o
--- sfxge.ko.full ---
ld -m elf_x86_64_fbsd -warn-common = --build-id=3Dsha1 -T /usr/home/fernape/FreeBSD-repos/src/sys/conf/ldscript.= kmod.amd64 -r =C2=A0-o sfxge.ko.full sfxge.o sfxge_dma.o sfxge_ev.o sfxge_i= ntr.o sfxge_mcdi.o sfxge_nvram.o sfxge_port.o sfxge_rx.o sfxge_tx.o efx_boo= tcfg.o efx_crc32.o efx_ev.o efx_intr.o efx_lic.o efx_mac.o efx_mcdi.o efx_m= on.o efx_nic.o efx_nvram.o efx_phy.o efx_port.o efx_rx.o efx_sram.o efx_tun= nel.o efx_tx.o efx_vpd.o efx_filter.o efx_hash.o mcdi_mon.o siena_mac.o sie= na_mcdi.o siena_nic.o siena_nvram.o siena_phy.o siena_sram.o siena_vpd.o ef= 10_ev.o ef10_filter.o ef10_image.o ef10_intr.o ef10_mac.o ef10_mcdi.o ef10_= nic.o ef10_nvram.o ef10_phy.o ef10_rx.o ef10_tx.o ef10_vpd.o hunt_nic.o med= ford_nic.o medford2_nic.o
ld: error: efx_rx.o: invalid sh_type for stri= ng table section [index 1]: expected SHT_STRTAB, but got SHT_NULL
*** [s= fxge.ko.full] Error code 1

make[4]: stopped making "all" i= n /usr/home/fernape/FreeBSD-repos/src/sys/modules/sfxge
make[4]: 1 error=

make[4]: stopped making "all" in /usr/home/fernape/FreeBS= D-repos/src/sys/modules/sfxge

make[3]: stopped making "all"= ; in /usr/home/fernape/FreeBSD-repos/src/sys/modules
--- all_subdir_rtw8= 9 ---
ctfconvert -L VERSION -g rtw8922a_rfk.o
--- rtw8922a.o ---
c= tfconvert -L VERSION -g rtw8922a.o
--- all_subdir_sge ---
ctfconvert = -L VERSION -g if_sge.o

make[3]: stopped making "all" in /u= sr/home/fernape/FreeBSD-repos/src/sys/modules
--- all_subdir_rtw89 ---
make[3]: stopped making "all" in /usr/home/fernape/FreeBSD-= repos/src/sys/modules

make[2]: stopped making "all" in /us= r/obj/usr/home/fernape/FreeBSD-repos/src/amd64.amd64/sys/GENERIC
=C2=A0 = =C2=A0 =C2=A01062.82 real =C2=A0 =C2=A0 =C2=A03851.16 user =C2=A0 =C2=A0 = =C2=A0 168.32 sys

make[1]: stopped making "buildkernel" in= /usr/home/fernape/FreeBSD-repos/src

make: stopped making "kern= el" in /usr/home/fernape/FreeBSD-repos/src


=
--00000000000025d26c06494d22d3-- From nobody Mon Jan 26 19:08:31 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 4f0J316jnDz6PSlk for ; Mon, 26 Jan 2026 19:08:13 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Received: from mail.tarsnap.com (mail.tarsnap.com [54.86.246.204]) by mx1.freebsd.org (Postfix) with SMTP id 4f0J30316jz3m4D for ; Mon, 26 Jan 2026 19:08:12 +0000 (UTC) (envelope-from gperciva@tarsnap.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=tarsnap.com; spf=pass (mx1.freebsd.org: domain of gperciva@tarsnap.com designates 54.86.246.204 as permitted sender) smtp.mailfrom=gperciva@tarsnap.com Received: (qmail 27140 invoked from network); 26 Jan 2026 19:08:11 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by mail.tarsnap.com with SMTP; 26 Jan 2026 19:08:11 -0000 Date: Mon, 26 Jan 2026 11:08:31 -0800 From: Graham Percival To: freebsd-current@freebsd.org, freebsd-git-weekly@tarsnap.com Cc: Colin Percival Subject: FreeBSD Git Weekly 2026-01-19 to 2026-01-25 Message-ID: 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 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.56 / 15.00]; NEURAL_HAM_SHORT(-0.98)[-0.983]; NEURAL_HAM_LONG(-0.97)[-0.975]; NEURAL_HAM_MEDIUM(-0.90)[-0.903]; DMARC_POLICY_ALLOW(-0.50)[tarsnap.com,none]; R_SPF_ALLOW(-0.20)[+ip4:54.86.246.204/32]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[54.86.246.204:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4f0J30316jz3m4D Hi all, I'm happy to announce FreeBSD git weekly for 2026-01-19 -- 2026-01-25: https://freebsd-git-weekly.tarsnap.net/2026-01-19.html It's a list of the 134 commits in that week, split into categories. No highlighted commits this week. To see all reports: https://freebsd-git-weekly.tarsnap.net/ This work is funded by cperciva@ and Tarsnap Backup Inc. Cheers, - Graham Percival From nobody Mon Jan 26 20:33:26 2026 X-Original-To: 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 4f0Kxd0Vvyz6PZSC for ; Mon, 26 Jan 2026 20:33:41 +0000 (UTC) (envelope-from jonlooney@gmail.com) Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f0Kxc1h6zz41xQ for ; Mon, 26 Jan 2026 20:33:40 +0000 (UTC) (envelope-from jonlooney@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of jonlooney@gmail.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=jonlooney@gmail.com Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-6505cac9879so7651284a12.1 for ; Mon, 26 Jan 2026 12:33:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769459618; x=1770064418; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dEPM4Sf3gZgKZ+Z18tNl6UV9xnlpSBnxmtWe/KNRfig=; b=vJJ68EzFra2AhGb8DWjcJdnt422B5ElNKpotCbAiC+kPPpPuVoRztx1Dy/NueIQ+7T y2G0w3OAyvudMetxL+TYH7G6OAdBFgx4LHOL4aBxWbaqLgxv4yueGxgI2RO23JFMQY/W 9bcWgtRQGvK6GXQRSEfnJvTF30xD6o4fvslBajGIl2crmmC0mxxWUWDXIxbQOVNyfmNj qXNcsK7Jpl2fk9yY+b/B5UF/PRbHvn1qzykTp3w4OfIh0pyza833/bKhZQ4fvaaWKzlD CX/3Hc/fXXdMRh28d4x/5qBEv8wN22CQrniqDB19JzBe1xyoY21aXuBIrNcVKUgMmJIP cO8g== X-Gm-Message-State: AOJu0YwxoAiejX6PyhlKaLNvDvet9ZS5KKSI9NbpA7GbzK99gURd+EJC 8AwnCtERlXwWLdFk5JHzo0cOCXDW17SxoFaTK3GtaXLD96EChwC0h5X7QV3Jt8on X-Gm-Gg: AZuq6aKgBN4pjYZowtUad7ctveQgI5svYpJe8gV3/aNLKsg0A2NqmKtuifwVOvOd/M+ Oy28dQHuNM8yZyncWBOg8FPtuKcv8n0f8fQ0/NcZgkAiwnik503XiVbZxSy7gAzghHvqDRKu78m E5HXBdI4Mn+T0aCO2gepg6isaQ7rtZ04tuXaEiTXjZbp3cOYcPzjAi/VT5XTNUfchcVsKB8simX rMKfj0kASNv8JcFTHleRJVpzd0WEKL/eEIlJY9gE89UPb2RFBLsLT+SWgzbg2vM07hBasYWswlU 5xmnF6CEOLldQRWsgdNL/o6fk6PhL1HwU94jB2ib9rIScuh3U022pfp2XYj20BcVrq4PXxke5ly aum3WfE//PoRzZornpUCtRblXx8pPiJ9AtL2KJ/pBc1b8gb3y/oB1pza3FCSgvBEkDYavgGBS8o EbGZQ0f+hHM3TmR24qMfxlegiWGCdFux7miJMiJmTM7qZZB1SeaVHK/Ra9bVaMnHAQ6g9ss4Gj0 A== X-Received: by 2002:a17:907:94cc:b0:b87:2eb8:2b78 with SMTP id a640c23a62f3a-b8d20b30a5amr421860166b.18.1769459617970; Mon, 26 Jan 2026 12:33:37 -0800 (PST) Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com. [209.85.218.49]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b885b6ff080sm659304866b.38.2026.01.26.12.33.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jan 2026 12:33:37 -0800 (PST) Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-b885e8c6700so596673566b.0 for ; Mon, 26 Jan 2026 12:33:37 -0800 (PST) X-Received: by 2002:a17:907:9484:b0:b87:9b53:b67c with SMTP id a640c23a62f3a-b8d20d704b2mr425029566b.26.1769459617687; Mon, 26 Jan 2026 12:33:37 -0800 (PST) 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 From: "Jonathan T. Looney" Date: Mon, 26 Jan 2026 15:33:26 -0500 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_QjdFQjQ-i7gLVBDlGLNjsnart8HpgHOGpyTTq_MqWYxIFHQOYyMkqSBeB4 Message-ID: Subject: Heads up: New WITNESS output To: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000f4ef360649506b70" X-Spamd-Bar: - X-Spamd-Result: default: False [-1.89 / 15.00]; NEURAL_HAM_LONG(-0.93)[-0.925]; NEURAL_HAM_SHORT(-0.59)[-0.590]; NEURAL_HAM_MEDIUM(-0.48)[-0.479]; FORGED_SENDER(0.30)[jtl@freebsd.org,jonlooney@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[current@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[jtl@freebsd.org,jonlooney@gmail.com]; MISSING_XM_UA(0.00)[]; R_DKIM_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.53:from]; TO_DOM_EQ_FROM_DOM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.53:from,209.85.218.49:received] X-Rspamd-Queue-Id: 4f0Kxc1h6zz41xQ --000000000000f4ef360649506b70 Content-Type: text/plain; charset="UTF-8" Hi Folks, As a heads-up, I just committed a change to the WITNESS output. It will now print more detailed information when a lock ordering was established through a chain of locks (e.g. lock1 is locked before lock2, lock2 is locked before lock3; therefore, locking lock3 before lock1 is a LOR). An example of the new output is in the review request ( https://reviews.freebsd.org/D54785). If you want to restore the old behavior, you can set the debug.witness.trace sysctl/tunable to 1. In the meantime, please let me know if you run into any trouble with the new functionality. Jonathan --000000000000f4ef360649506b70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Folks,

As a heads-up, I just committ= ed a change to the WITNESS output. It will now print more detailed informat= ion when a lock ordering was established through a chain of locks (e.g. loc= k1 is locked before lock2, lock2 is locked before lock3; therefore, locking= lock3 before lock1 is a LOR).

An example of the n= ew output is in the review request (https://reviews.freebsd.org/D54785).

I= f you want to restore the old behavior, you can set the=C2=A0debug.witness.= trace sysctl/tunable to 1.

In the meantime, please= let me know if you run into any trouble with the new functionality.
<= div>
Jonathan
--000000000000f4ef360649506b70-- From nobody Mon Jan 26 20:54:05 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 4f0LPD6SG9z6PbpH; Mon, 26 Jan 2026 20:54:08 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4f0LPD5z5Gz4531; Mon, 26 Jan 2026 20:54:08 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769460848; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yEccVAq+Q3mFpHwPQN8YUNyjMWrQRTAe4GXkxV8fLCM=; b=vLzXRtN7GsUXmbeuOdIjvd0xezPlX0Z9Z2IDV5mHqcQd091rBnxjXznv1y9MZ3kaY41+Vt GIF2mAiOlf0EAOOmA7dBoOqTMovb/dnGi3QROMWho1KTnnsXU2GGFW2v1BwBNd1efzuVU/ DuduXkTeMaVKBMTRD2KfcVtfA96H/Eg5JL7sbK8a0Uq6k5EQREhjPUV6nNql04np/3sXZQ hHvAfNgroVe43SFt0rciuj6u2Xt53GR9OTY6LHSd6RnPSYqa1YF9vkY3eWq/e2y+tHdlB4 Umb8Afsus2sz3TTNc3qVCxaZ7pDLkbg1ozY/d0f29Ibk2wv5UMFF8D2dqBR2ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769460848; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yEccVAq+Q3mFpHwPQN8YUNyjMWrQRTAe4GXkxV8fLCM=; b=pk1XYC6/ujZZE7I1/vuAHFUcIBjEsmW2EC9d6HepdKXGTypZnOQ74UvHJDM6TgtFrraFOF BzhOTmhWeBAQWjsfEaPe/ci8A1DUIrjlk7sifoDc9gqERzvH7L6zSenJplSVI3JKfwJHfn eEaQFND8n5/BYQaUdOeJczhwAsqUK96M/LzoIYf+kJIqFPk22UzsGjRiLO0qtROghpttiy QwkKt7k3LB0TsxIkR10wIvIw1aJMC9IQZFKA12wIWl6ychT2fz1ptEIAXVA04J3f119rgv G4KgM4t++kqisJJxA8zFmkwUoy7PUeXAiPVPFaAy9ujSL2nT3YcEywymXCx61g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769460848; a=rsa-sha256; cv=none; b=T0vlDu5/AxqVT0Aw/JPqFmBnYEE/hLQ/8gVME7bN2KChLMj7Q4ZVew/OdSvze0FhvCjQ1S R3SyTtgLrZFxvh2lrvSq57WCBX+DV80lhrxsAqPwisXOfjZgslFlAwLsSfIxvx9xKQP6oV vpzm+taVgeRtD9PcZ0LIrpj8p97OGnHH4m8WiBmy2hZGWwslAHiMEKinyd/xgZYlDjve/+ +4ukFstchDkoY9OlmHQG+zBXZBjyi23KGdd1R5sXBYE9uPpdFeILyKHqAFtIkeD8pQ2lLa Xy0/0pwnj9HtM0Tc+AO4Y51Y4piFRMz4bIQkp6DFyNgqUj2qIzikLhSGZBcTEw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f0LPD2wlvz1JD4; Mon, 26 Jan 2026 20:54:08 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 26 Jan 2026 12:54:05 -0800 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: January 2026 stabilization week Message-ID: References: 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: On Mon, Jan 26, 2026 at 01:00:25AM -0800, Gleb Smirnoff wrote: T> This is an automated email to inform you that the January 2026 stabilization week T> started with FreeBSD/main at main-n283376-8ef8c6abfadf, which was tagged as T> main-stabweek-2026-Jan. I have a regression with ipfw dynamic rules. Patch do be put on review today. -- Gleb Smirnoff From nobody Mon Jan 26 23:13:31 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 4f0PV64v3Rz6PmlH; Mon, 26 Jan 2026 23:13:34 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4f0PV61gnkz3Srw; Mon, 26 Jan 2026 23:13:34 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769469214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Xk1zs4YJA3jOtE0fjei+Whk0eDSmruQz03y1HKiHqVE=; b=T4dk9a/NyJJMvbar9Hz2Gn2OffgUoDT6UIEK85if6EZWZV4RZT+8Z+PiakHUhTt0Zl2NcP dxQGP8rsyik5zRy1uhuUazfPQ+yNpyiKBUHbTr7WlcC+m86BUPDGmL565vzt6plYEtVtic 6vegRkWLctr21mm6IpXeckiFf87PwjHvtyeFrP+b/5YxUXODqrRdnenE6sewRQ05RaoG+M FFKD1BRxagav6c312arF4ensgP6OrZBYBxCHMYumPWDHi11TkH60JWqgPr9jaVsrZqqm8Y tr7d3jdO1JtB45L14j1RmaHtf2VFMp4Dy0LgHOHXLdTTtB1t6FjBzv3ANNIofA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769469214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Xk1zs4YJA3jOtE0fjei+Whk0eDSmruQz03y1HKiHqVE=; b=qw8DexT8Ic/ehnbnAaI46aViu3voGhNVGjE6FPxBsQCmZGiPe6GtMmuErVQpWzt5wFO0Pu iH5GzeeMdKe+PuqRH5pGOGds43wLRaWaJYWAVOAmvLwRsFjlXnBXjVfJ34KwL3vOP8cTLw J6FF4PoFlP3nXDQg6PfheQd8zu4P/WbOWALLLQbo5RQX6NJQPzHbPmBFXohLOu0LZmmOxa qs8N61Fpj3x+GebNAqPHQN51DV4D50QUPAqf/07M8nrdJAAz+lV26A+2glEmq60517YitE qiYcjh/Up8cdZyB72Dowp5ftPCaER2gzgmU2uLLCLpyPEo4H9FWXmCnumOHTAw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769469214; a=rsa-sha256; cv=none; b=yG3URqmpqO8H5M7dMwGd8JC+2EWcKDMbO6U4hSLR2bZ4oucdCx5mhzD42cFQ4qiPpCYtSu L50fJ4ldRWmqc7KMGP7EDYTds8FF1n+33iWytZQHO4N7gaK9gxgEhVlxTDHcqXGdw5DKmV +Hi5b+onkAeruuzRwGcl2NZoIDpDhMA3m1J9TRluiLxNv4vo13ZfDaFtN3+pLqQKedRlR8 0ryE//2IVxDX7JGNCWCs2fp/7Vy2Df+q3dTgGJKesJWfnKn0NPFuXr5cU2c9yCN/aF/khC ngKTu1mrzVOKhR/qE31gu3iVv3xeR1PBQrsLc+7fNKGEp9jzEN8hTxxjR/ByNQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f0PV55Pxqz1LfV; Mon, 26 Jan 2026 23:13:33 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Mon, 26 Jan 2026 15:13:31 -0800 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: January 2026 stabilization week Message-ID: References: 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: On Mon, Jan 26, 2026 at 12:54:05PM -0800, Gleb Smirnoff wrote: T> On Mon, Jan 26, 2026 at 01:00:25AM -0800, Gleb Smirnoff wrote: T> T> This is an automated email to inform you that the January 2026 stabilization week T> T> started with FreeBSD/main at main-n283376-8ef8c6abfadf, which was tagged as T> T> main-stabweek-2026-Jan. T> T> I have a regression with ipfw dynamic rules. Patch do be put on review today. Should be fixed by d1a8f1a62f31. -- Gleb Smirnoff From nobody Tue Jan 27 00:05:16 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 4f0QfJ4gscz6PqYv for ; Tue, 27 Jan 2026 00:05:44 +0000 (UTC) (envelope-from pouria@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4f0QfJ3nMbz3YHG; Tue, 27 Jan 2026 00:05:44 +0000 (UTC) (envelope-from pouria@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769472344; 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; bh=IL+xdPhSCTpGH4FxycbPnbesMzKEwiZSz7Hz2JhBjtY=; b=kvMlTtk3gLCzbfGQimJZxJBEl+Kwy7oMyUC7s5VzgClIBI74GvIlGEiExDKEHvypWZ5RKT W3jOf/LbJaPNp0sQBrk2QDxiv7q/VqJ8tMVoG2enAuuAisoAAh4rWNACDjrqcqfX3eisqC aswz7YUKdGVGjNeuEW2a4Tu32ceLy0Zh82X+m975tCIiAu8RPlBXN8+9vB+U3kg68glDIs I3hz5itib4FFOZVl8fUGNXPk0W+iik3WW4zcWbzxjIlgFVNrwq1juzv0sU8DPnWnUWEgbq TDMPYeftkMuJsupvHLbvXtlXGiHcWoPudJ9nyWDTTMHTqsSYRepA+wQxmBBteQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769472344; 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; bh=IL+xdPhSCTpGH4FxycbPnbesMzKEwiZSz7Hz2JhBjtY=; b=qLSvPeCCn+1nz45KllRSSluxK6SFdIY/iy6ywUwOEgGPiXZeIzvpNYDKquwU2Z9GlgR59H B4UKcGK/AH1/E9Ef7XGIh3uwlyE+ICk8u101haDOzrQ5GIIhf4qkYJQS1Tk+NznYwLl9C8 pvCrauQIqiBSbotMwOpvUKkULKYJcwWQ8Yaw8HOPdpdCYtZK73zQ6RxfI1xClB+C6+433y w280WPeX8GWIZLsPbISdYR09U7Xy4UUMHT2Dh7bvVarxK+4T4udlLl311yoviUpDw84RU5 Y5gUO2Wxrj43zsIYhDikgNnf3l8LgAMB7xbp0edCeklM0qKa9fWkafIuE1Uuxg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769472344; a=rsa-sha256; cv=none; b=pc5Q6WI7HAZzzOV+qzIIAmanHUwhWf8XpzYEIYXvFwLNdLYBAYk/MxLgKjEichmmTGMqXU Cotwd8c66My0AUzQjYNCD24l+Q2zFi8nrZAzF8knM1viWoGWkWI9XXgWddtQln3CtZN79r WtxDdQouBY97H6+bKd/ZN5G0QkJJJXpypIZ3Fb2wBXhUFOmmdiOTcJNUQ+i7MrqBQGBA2J 0En8ktXZQVeYCazQNZLJhXEHnj7OXGvNNAhTaOqRjHuOoFNuc78ttzbcTGDHowo3JY7d9c pcWYIyHdFNYkaniJAVIkgtNqeSyRrWy1VG0lr0BubXFHBVfi1cfMaGigx7OxKQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from nl.mail.spmzt.net (mail.spmzt.net [193.148.248.214]) (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: pouria) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f0QfJ0kl4z1MBV; Tue, 27 Jan 2026 00:05:44 +0000 (UTC) (envelope-from pouria@FreeBSD.org) Received: by nl.mail.spmzt.net (OpenSMTPD) with ESMTPSA id 5ff54f86 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 27 Jan 2026 03:35:34 +0330 (+0330) Message-ID: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> Date: Tue, 27 Jan 2026 03:35:16 +0330 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 Content-Language: en-US, fa-IR To: freebsd-current@freebsd.org From: Pouria Mousavizadeh Tehrani Subject: we should enable RFC7217 by default Cc: madpilot@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------1bMdn74YtxT1LhbsopkrcsA2" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------1bMdn74YtxT1LhbsopkrcsA2 Content-Type: multipart/mixed; boundary="------------hdnCiYAQngVaclRqS0h3LWtc"; protected-headers="v1" Message-ID: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> Date: Tue, 27 Jan 2026 03:35:16 +0330 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US, fa-IR To: freebsd-current@freebsd.org From: Pouria Mousavizadeh Tehrani Subject: we should enable RFC7217 by default Cc: madpilot@freebsd.org --------------hdnCiYAQngVaclRqS0h3LWtc Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkgZXZlcnlvbmUsDQoNCldpdGggYG5ldC5pbmV0Ni5pcDYudXNlX3N0YWJsZWFkZHJgIG5v dyBhdmFpbGFibGUsIEkgYmVsaWV2ZSB3ZSBzaG91bGQgDQplbmFibGUgaXQgYnkgZGVmYXVs dCBpbiBDVVJSRU5UIGF0IGxlYXN0Lg0KQXMgeW91IG1heSBhbHJlYWR5IGtub3csIHdlIGN1 cnJlbnRseSB1c2UgdGhlIEVVSTY0IG1ldGhvZCBmb3IgDQpnZW5lcmF0aW5nIHN0YWJsZSBJ UHY2IGFkZHJlc3Nlcywgd2hpY2ggaGFzIHNlcmlvdXMgcHJpdmFjeSBpc3N1ZXMuDQoNCklN SE8sIHRyeWluZyB0byBtYWludGFpbiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGRlZmVhdHMg dGhlIHB1cnBvc2Ugb2YgYSANCnByaXZhY3kgUkZDLg0KDQpUbyBiZSBjbGVhciwgd2UgZG9u J3Qgd2FudCB0byBjaGFuZ2UgdGhlIGlwIGFkZHJlc3NlcyBvZiBleGlzdGluZyANCnNlcnZl cnMuIEhvd2V2ZXIsIGl0J3MgcmVhc29uYWJsZSBmb3IgdXNlcnMgdG8gZXhwZWN0IGNoYW5n ZXMgZHVyaW5nIGEgDQptYWpvciB1cGdyYWRlICgxNSAtPiAxNiksIGEgZnJlc2ggaW5zdGFs bCBvZiBhIG5ldyBtYWpvciByZWxlYXNlLCBvciANCmxpdmluZyBvbiBDVVJSRU5ULg0KU28s IGZvciBvYnZpb3VzIHJlYXNvbnMsIGNoYW5naW5nIHRoZSBkZWZhdWx0IHZhbHVlIHdvdWxk IG5vdCBiZSBNRkNlZC4NCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCi0tIA0KUG91cmlhDQo= --------------hdnCiYAQngVaclRqS0h3LWtc-- --------------1bMdn74YtxT1LhbsopkrcsA2 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQSqt7cppfvJ816gj0lUwVnUeMwagAUCaXgBPAAKCRBUwVnUeMwa gO3cAQCmPFVgeH6Lr30eAIKm9JQoHVChI0Zz1XfTHIKTd3g3TgEA4r/1vVEKzhsI jsv/ZTema4guHxxNKLSPQPuHSF4wwQg= =ck7i -----END PGP SIGNATURE----- --------------1bMdn74YtxT1LhbsopkrcsA2-- From nobody Tue Jan 27 03:39:26 2026 X-Original-To: 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 4f0WP16tJyz6Q7T3 for ; Tue, 27 Jan 2026 03:39:33 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4f0WP1600dz3xg8; Tue, 27 Jan 2026 03:39:33 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769485173; 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=JDKZwUkKbO2yNbLaicm9I8RmfGxepgBvMBe8/MINYaM=; b=w8hwArvsVBzgmX+/ttJi59ZRvcjgqomzNL9z+HF3X2yv3MNhEQDXNk75rOaqQXUhhaWiAJ noRrAcAPWYqO3dC/v9FbPu7pK8Eo8Ybjnm2UUsDgaa0WBEAxCNZghkvtDQy8zFe4+3ANhZ fD8AFwCvfW5hPe1KGKX9Awqbo95C8KO6QwE1dJQFiZ0vks0YNdWXFVj7TMuaGxFN9lvi3E FjU2K4zRaJYBlUrKSZIt0YiGqvoRSg3JuvCbots4FXt7VqUG5aAufZgmdGZr7dqN/V6H00 a5KuCjSu86YXb8i2LfKJOl6eClWsXd64+S3VCe5L/yYG+1WNxvWmgUDSfTFxdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769485173; 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=JDKZwUkKbO2yNbLaicm9I8RmfGxepgBvMBe8/MINYaM=; b=jT7ZFTLorcozI9V3AT4tzTMWvKCbE6X/kbMEx9uPSkDp7pbXaNjZFitoXjKXwp6yS+z91e 8rFOyp/vabgwWoz0dscgIwXaSJCyQH5U7VzYoA8w4nrSKjv71VL8sfebRhkHtqMsu5U/j2 AG/AFYRyP0kEbXC3D5szTc3SPc9ksuB9hSjMZZeT1w48VpIAYMrel8RVyDs3i9me+SO+SQ 48/FEcU7BniCOfNR1p3Wvu/Xib2+BO6jBHPXIeNHKE/UpWNt+AoVZJetjCyCE+fGj7aE1f Y8bjrkKgS8ubtg8dGBZRiRAEzjbWqhtimXJIARkos+p91+UuhYSLwRGQZit2dA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769485173; a=rsa-sha256; cv=none; b=bv4v1ptAfiWVdChC8Sb5qc03URQIcPZkoKY0kv67Owt4iaFx92/Wb3lHHMg6au0YdHkds8 Lgw6rXPKpbDwK44mBSZkBtbYJ8p5vkTNlmmC9hk5gJj50jpdEroLEsq23W17VsDegCsBbt 32sRLxiOuFp6S93Ig1UF+IzkHFHXy+pKJ0XTVS6tMkLwyKy7cJol0hETIaMIExvJCQdURV FQHdux3Yq1HKFBCREmVjUX/cLwk0zpMy5HpdID1lLu4hHK2tRhg/g6Wz3z3KEZF73K1faO tp9Mupb9PmHpMZtwFinZ4LH3awhHUu2z5bpQRaXOyg2gzvQmVmjstzG0fnooVg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from smtpclient.apple (unknown [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f0WP06kx2z1QHq; Tue, 27 Jan 2026 03:39:32 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <93A15E94-C5FD-44B2-858E-595E9188A530@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_5892096E-2097-4403-975B-124F6878A8A7" 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 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: Heads up: New WITNESS output Date: Tue, 27 Jan 2026 11:39:26 +0800 In-Reply-To: Cc: FreeBSD Current To: "Jonathan T. Looney" References: X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_5892096E-2097-4403-975B-124F6878A8A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 27, 2026, at 4:33 AM, Jonathan T. Looney = wrote: >=20 > Hi Folks, >=20 > As a heads-up, I just committed a change to the WITNESS output. It = will now print more detailed information when a lock ordering was = established through a chain of locks (e.g. lock1 is locked before lock2, = lock2 is locked before lock3; therefore, locking lock3 before lock1 is a = LOR). >=20 > An example of the new output is in the review request = (https://reviews.freebsd.org/D54785 = ). >=20 > If you want to restore the old behavior, you can set the = debug.witness.trace sysctl/tunable to 1. >=20 > In the meantime, please let me know if you run into any trouble with = the new functionality. >=20 > Jonathan Hi Jonathan, That is a nice feature. I have been confused by the LOR report for many = times. Thanks for your work ! Best regards, Zhenlei --Apple-Mail=_5892096E-2097-4403-975B-124F6878A8A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Jan 27, 2026, at 4:33 AM, Jonathan T. Looney <jtl@freebsd.org> = wrote:

Hi Folks,

As a heads-up, I just committed a change to the WITNESS = output. It will now print more detailed information when a lock ordering = was established through a chain of locks (e.g. lock1 is locked before = lock2, lock2 is locked before lock3; therefore, locking lock3 before = lock1 is a LOR).

An example of the new output is in the review request (https://reviews.freebsd.org/D54785).

If you want to restore = the old behavior, you can set the debug.witness.trace = sysctl/tunable to 1.

In the meantime, please let me know if you run into any = trouble with the new functionality.

Jonathan

Hi Jonathan,

That is a nice feature. I have been confused by = the LOR report for many times. Thanks for your work = !

Best regards,
Zhenlei

= --Apple-Mail=_5892096E-2097-4403-975B-124F6878A8A7-- From nobody Tue Jan 27 08:15:22 2026 X-Original-To: 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 4f0dWL3LyVz6QQnQ for ; Tue, 27 Jan 2026 08:15:26 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4f0dWJ6FQwz4Q7S for ; Tue, 27 Jan 2026 08:15:24 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 26B31D7893 for ; Tue, 27 Jan 2026 08:15:23 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 60R8FMHK006897; Tue, 27 Jan 2026 08:15:22 GMT (envelope-from phk) Message-Id: <202601270815.60R8FMHK006897@critter.freebsd.dk> To: current@freebsd.org Subject: cam_da too noisy about SYNCHRONIZE CACHE From: Poul-Henning Kamp 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-ID: <6895.1769501722.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jan 2026 08:15:22 +0000 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.65 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.91)[-0.906]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; NEURAL_SPAM_SHORT(0.25)[0.254]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[phk]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[current@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_NA(0.00)[freebsd.dk]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4f0dWJ6FQwz4Q7S I have a Rpi3B which runs 15.0 on a Seagate USB-SATA gadget. Every few hours usually around XX:X0:30 it spits out: Jan 27 00:40:30 rpi3b kernel: (da0:umass-sim0:0:0:0): MODE SENSE for CACH= E page command failed. Jan 27 00:40:30 rpi3b kernel: (da0:umass-sim0:0:0:0): Mode page 8 missing= , disabling SYNCHRONIZE CACHE Jan 27 00:40:30 rpi3b kernel: (da0:umass-sim0:0:0:0): Devices already qui= rked for NO_SYNC_CACHE, maybe remove quirk table The relevant code in cam_da is: if (mark_bad) { bad: xpt_print(done_ccb->ccb_h.path, "Mode page 8 missing, disabling SYNCHRONIZE CACHE\n"); if (softc->quirks & DA_Q_NO_SYNC_CACHE) xpt_print(done_ccb->ccb_h.path, "Devices already quirked for NO_SYNC_CACHE, maybe remove quirk table\= n"); softc->quirks |=3D DA_Q_NO_SYNC_CACHE; softc->disk->d_flags &=3D ~DISKFLAG_CANFLUSHCACHE; } I can understand emitting the message the first time after a reboot, but that program logic makes absolutely no sense to me ? -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence= . From nobody Tue Jan 27 13:26:34 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 4f0mQZ2XKmz6Pq4m for ; Tue, 27 Jan 2026 13:26:46 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4f0mQZ1srZz3kjL for ; Tue, 27 Jan 2026 13:26:46 +0000 (UTC) (envelope-from olivier@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769520406; 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=vXKSjGFSSAqDankG9cHzcU9TAddUidum0x6nItnnhe0=; b=sov3cpwMHgValp1YKEMsBlpVZH9Vtz8jFr4moAtaqiv13f8hJCqHmpR6ws1iJChb89AB4e Nwn0vtlJ0iyqAc/7I7MigBVWZPKcgFSr/r9XImlN3dWoQ74WAUn0IL7oeACecUGyAOtwua yvVPG87JNMcbndhCb8byNAZv+3L3pSxmSxJ/87Qy3Gs8KtcgklBL+ma8+Sf3eSTwK2tKVf X9nYEjhSXL1LJ94YrFMMiKOrquf0qhHtc/mGWECZHFYyE0CXglACMKHBq3GBcT6kLQISIn HLeA5NeKC5HUXzLKLQQzvv7Y7neYajZBbl8N+QvWp25/We+Os4h+3J8NUGKDEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769520406; 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=vXKSjGFSSAqDankG9cHzcU9TAddUidum0x6nItnnhe0=; b=Zru90WfryLcrMrr1XVT+yk9ICPMwP7rISpDSjqZrYF+jzMLEz6ObiRwNj/QWfiiXux8RLX EXkgrQJb3qzDop2yCCi/J+pKzXtri2vvKR/2pL00TS5/1NT8T9LwTWWrMS9HoL9LOlRBoE 77Bhn0hih2b5vhnlZplAy3bJ6kqPJDirhqyX2t+m4X00CtmDcNr6DvPay/TA8RDFurJfAQ 7lYL57VJcowY/zhnvx5Jsp4jZBU2ntMCXSyJIzPxnM293mcGUwcSFQA/GCMDcYh4FJkeFS cX/JNjTlmmYDYUyIJLQbl7dObu3l/7KuGbUa/7Um5t8xn9G/Au8Nfa/GZvaRIA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769520406; a=rsa-sha256; cv=none; b=i7k3mhrgSHML48bgipstmntouMQwgaP04U3nQKNUif/4gBoYKNrOaipNaKsHk9xDXwTKOF hzW8Njjrm50Zs4cPK0kJZ+tBzwFRuVSNNN2vwuw2GTfpizaWIwl5QP8xRP+MVO9VE89kV5 np9Sc6rcgX6pabtuUsozrAarFUvtBiD7tLGKZlb/5rEXRz1PyqainqTeHidDrYxF1egsVv xxej2mcCz5TZqU2VMKVdvWLcFaHUjWITCocqXdZ/nzhu8tj61mZSXarOQkaBWIgZPsQWOI oQ39jyaOEP8CLwwCLbuRQlCR55v7NntI+CO7Uta1OdW4Fpqh8Blkxwx+B/OEEw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mail-oa1-f43.google.com (mail-oa1-f43.google.com [209.85.160.43]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f0mQZ0vRqzB7d for ; Tue, 27 Jan 2026 13:26:46 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-oa1-f43.google.com with SMTP id 586e51a60fabf-404263bd58fso3914668fac.1 for ; Tue, 27 Jan 2026 05:26:46 -0800 (PST) X-Gm-Message-State: AOJu0YwQpJ7rpBMJCwJ+PlOGqWeZpEgCmDog6eF9oj4Qoy+wS23a4FmK dknsm4opwBI0Ef/knokFmkAvoM2wqxhQi0k+DHTuvd3xubwh6d4Afo2jM5j8GEzeLfyt+sjsv+p Vg+4cI5LlPodr9HxCg3hPPo9s747LpNo= X-Received: by 2002:a05:6820:1904:b0:659:9a49:8ee4 with SMTP id 006d021491bc7-662f20c687amr952730eaf.24.1769520405282; Tue, 27 Jan 2026 05:26:45 -0800 (PST) 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 References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> In-Reply-To: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Tue, 27 Jan 2026 14:26:34 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_QjDLvQHpuxiPVmdSccD7SKgXjOIVwOqPIcZvcP3_xMiouGKWLVLJk5HuHQ Message-ID: Subject: Re: we should enable RFC7217 by default To: Pouria Mousavizadeh Tehrani Cc: freebsd-current@freebsd.org, madpilot@freebsd.org Content-Type: multipart/alternative; boundary="0000000000002e046d06495e9341" --0000000000002e046d06495e9341 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 27, 2026 at 1:05=E2=80=AFAM Pouria Mousavizadeh Tehrani < pouria@freebsd.org> wrote: > > What do you think? > > In a server environment, administrators typically assign static IPv6 addresses manually and do not use the EUI-64 method. Switching to RFC 7217 should impact mainly desktops and laptops (the main beneficiaries of this privacy feature). While some cloud setups use SLAAC, a major release (16.0) is the appropriate time for such a change to ensure we follow modern security standards by default. I support this change. Olivier --0000000000002e046d06495e9341 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On = Tue, Jan 27, 2026 at 1:05=E2=80=AFAM Pouria Mousavizadeh Tehrani <pouria@freebsd.org> wrote:

What do you think?



<= div class=3D"gmail_default" style=3D"font-family:"courier new",mo= nospace">In a server environment, administrators typically assign static IP= v6 addresses manually and do not use the EUI-64 method.
Switching to RFC= 7217 should impact mainly desktops and laptops (the main beneficiaries of = this privacy feature).
While some cloud setups use SLAAC, a = major release (16.0) is the appropriate time for such a change to ensure we= follow modern security standards by default.
I support this= change.

Olivier
--0000000000002e046d06495e9341-- From nobody Tue Jan 27 14:25: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 4f0nl53wC9z6PtZm; Tue, 27 Jan 2026 14:26:09 +0000 (UTC) (envelope-from olce@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4f0nl524l3z3w23; Tue, 27 Jan 2026 14:26:09 +0000 (UTC) (envelope-from olce@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769523969; 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=MvXSlLDjrSyc7ibYbPT98yM23Pyz1lNDrOiq3qJzrfU=; b=tsj9OC8q3Ec6vgs+uF+fLB+PgS3/nReLEHlo1MkB/MASVgf3XF9WRY715MjZcZTUuBT55L X/xE1zurGevSoqaJj5qxuIMACt31WT+2B2ec0bJLOevvSvWpTWipvCtW/ajVAkIrNM16nV sS1JkHqp8ZaNdd4mcQJIP3dlWRgeNOD0h8NfDl4+lxuxYNwAAICrXSobAwwHNPy+JJtOLe wofO8BqTF09sTtjRewOVAfSihk+Byblk7nenMcVx9g/h2WGgkFlQMdbcOC4IepSM1pv68V mQoKX3QfNqc8KCJjWhdNCVUczxqrtHUq9MAHaFRjhTr5+NvmlNDgLOjeIMO8LQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769523969; 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=MvXSlLDjrSyc7ibYbPT98yM23Pyz1lNDrOiq3qJzrfU=; b=xJYxTgxzeMXF8yBdVP4f9HWHQ7GnSvKRDVAgCWozq+JmifJcqxMbijAKzIwkqaZ8wdYofL fHEpMnpBDr3FOXWjkbbEvO4dewJyonmFD4JkneEIEr0U0iyMGeaBs+cu9b5MS/vUhaajBn 9jdFe85Xtp1wZj0srDgP1NMAPZlDqwvbXRuZuMio7E2sd3NEsNcqMmDLHDLeA/m4Bz13LO XtvysiR+JKm9fMjLsTngVr8eovxN4cYVU0ToTJA3zl6o/8A8Fy0FHSV656Gii7PjEOqjsO qFrv4cqkESSVaZSPasQjP22JfLVQjHYOK2U2rrKusbmzAqIkZ1wufcFVt9/WxQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769523969; a=rsa-sha256; cv=none; b=WSJIi2h50wkkzRqGq4UMDMOIKUZHoOPo1XSjdNxptHpKgIgpz6aQQMrV5JqmLaHTpBMLkR P6zTnVBhVJJzsr/WIPmYYONJh073v3wrvNx2MAhcFq478NnagBpW4yD+5wWIp6Ore3rIWi mOqD7z3Rl0yUsty56LXVwwGuVPRZLBwYIAtBz2lUmQspmPKYz9KQeSnaNw0pDIRU5ym4Br lTomxYjV5KOaZyHYEUs0JS3QuGzcNwDyvSdZD5BneO7msWJzAjxFruCDLjuznt6RBIHI+A Eyk682HemdsOusG7+7O6JxB7qaztg7eEi50Xu14gEfDs69a++qujPRx/BgGYlA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from ravel.localnet (aclermont-ferrand-653-1-222-123.w90-14.abo.wanadoo.fr [90.14.66.123]) (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: olce/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f0nl456qbzC8q; Tue, 27 Jan 2026 14:26:08 +0000 (UTC) (envelope-from olce@freebsd.org) From: Olivier Certner To: Gleb Smirnoff Cc: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: January 2026 stabilization week Date: Tue, 27 Jan 2026 15:25:50 +0100 Message-ID: <2506357.THHZn3L5Ee@ravel> In-Reply-To: References: 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: multipart/signed; boundary="nextPart4146898.kAAoriTUSa"; micalg="pgp-sha384"; protocol="application/pgp-signature" --nextPart4146898.kAAoriTUSa Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Olivier Certner To: Gleb Smirnoff Cc: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: January 2026 stabilization week Date: Tue, 27 Jan 2026 15:25:50 +0100 Message-ID: <2506357.THHZn3L5Ee@ravel> In-Reply-To: MIME-Version: 1.0 Hi, I'm still getting a panic at boot in IPFW code that is different than the panic I was getting before d1a8f1a62f31 (but after e3caa360d5d0a73a). I think it's at the moment of loading rules. Quick extract: panic: _sx_xlock_hard: recursed on non-recursive sx XXX @ sys/netpfil/ipfw/ip_fw_iface.c _sx_xlock_hard() sx_xlock() ipfw_iface_ref() ta_prepare_add_ifidx() add_table_entry() manage_table_ent_v1() ipfw_ctl3() sogetopt() ... Thanks and regards. -- Olivier Certner --nextPart4146898.kAAoriTUSa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCQAdFiEEmNCxHjkosai0LYIujKEwQJceJicFAml4yu4ACgkQjKEwQJce JiedKhAAqwMGOp4VPw1xchWmhbomgqK0b9tb+Vpo+9ptSXbsncH8+XvB/xHi5zaR VENSwEh4YI2VYmbRLq5CrqObIhDNWpi3fVoVk9bqN7ggWKnHurW9EgF9afmCczlL in1qZWcTVgLb5KdbVe2wYw0oN7dUnOLg3UccHzXJyFnzAx6yyXu0d58ISFCRngah MAnbVVzrITKpOrBiFax6XgGJCuFbzRayMuZZo0x18ASKiOzKl2uDkzoh2tjG1SZg iEKGiyAbxqJiYFQxc1JDJRjXTZgC5jKImboZLI+AH8Ol8xXCsZuQo7DUDhtpB7gM 2i/A8KBgXCMaDIONmOI78Zj4TcB1Witsi3uoIhjwlkdS6BSNV443ve0NY9xwSLgo 8QnH2DcrllWHE28ECn2mwjwuuv4Zir57+7RkNkB7WCKqIvZl8diBpa+tMHsP6LW6 YZOLa/5l1gHuf+Dx1J8+viXvnltwH0RnpnKpxDLOvFGfwDRf+75BZOYjR+t/m4Qu oaIw7fOqLsfL2AFyFEy595qnQphNBc3Qr0lKH8Nfw6/rv9OF2S3Zcnxt110jJ1EZ XfRNYHxuQCNbKpdG/etxJ3NWcsboBhWHBwVjWsxrGcWJWwIhmYidHYhin6LxdrIS GJ0q0AdRcLNiRKX4yUwR8Jd7GXPVKXmlnfoJc5b8PcP4rQuDT0c= =nvcr -----END PGP SIGNATURE----- --nextPart4146898.kAAoriTUSa-- From nobody Tue Jan 27 17:39:02 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 4f0t1j10nbz6Q9Wr; Tue, 27 Jan 2026 17:39:05 +0000 (UTC) (envelope-from glebius@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 4f0t1j0V3dz3VjQ; Tue, 27 Jan 2026 17:39:05 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769535545; 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=wlNReI9A0vpvs/J9XtCEZUJsnQMlccBHlhmUr1rTOYw=; b=JiYWQV2ikHFlKK7xoioPAAVnB2RzOmbwMtTthMgJ4XvoVKO0/Rv/+Hm9DzUKGQ9WNrSeCB 1IqMU4/680FqHasbs4Rx+noxv7fec+11G7WfDSeuz8z+EXlELFHOFyfoOC4yw3h6wwvZKn ZabIupTgn/T4k1PgIGJsl901xmW4EF/UESvebTL47zZajjEop4nWZn7AI2ZR01FGBvftyL gpWeD5NMoJMHGb88xkDaX+Rd7f/yB4jincEUEhEnobuYYVwZL+qt1m5XUE3tHFWv+rtxIN Uh3/4PIOOjhGkvsL7DlIdYR83goAMjRHxXn3LYvgds/MOuFXqLbTJ1V0oFi4JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769535545; 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=wlNReI9A0vpvs/J9XtCEZUJsnQMlccBHlhmUr1rTOYw=; b=O53NLf/HlIzQsNh3WSwtElzodf7CQ1ypFZCzDtQ1bmSxBpwFNrt0pE2+RIMYEn3HtgvbO3 ICCOxTEbEaY+802xErSXjeU615TWmdGBN3q2g99nFAfAeciST5a/HMPAB6dyzzitRAvM+X kslLJGgKmvgjK2Ufhj4ozP9JA4nN1Om7kw8uNbfYVF984/LgmlukUv23iR+NcjSMTKNky5 FuOM2ANBEwObw02sUhMZYrjSlom9qqrlCun0N5llY/lZ5EEaeaTO1BHoM54WL4SD9ikF5I xgMAG4V9NX31ddgk0jUclDbvKUhP9Pv5gnroaiU9dP1VBTYrK3W/8nLPMmvdEA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769535545; a=rsa-sha256; cv=none; b=EGRLUXB4NO2k3OuHV/H92pMifGph7/xd4k1jntuM0iM8Jpq3lh8W60WDgRMjK5DlG0UmpE lbE9CmvJL8ETa6VQbOwTrQV8D0zDDhHD2wBwhgAQVt2n45RUEaip3uFKlz0Joid+Z8IYl1 nSCmRkfimB6tDRSoLGSdkWOzlKjSkwV88q0o1Z8uRINgJpDD7TTZ5r8zqgSCIEcSebXnz2 eAxiDM/JH0OEa8MfZ1LNaJreOCoQD+AKhlSS20hFnqhPn0s284UrN8KuO5EdGrzgXL9hvJ XF3JgTzFK9c5aOW79q/ktSru+LL24KkVr9pKOgGoRNmup3Wg+/l4gTXxyByJsA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f0t1h3rdKzGhZ; Tue, 27 Jan 2026 17:39:04 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Tue, 27 Jan 2026 09:39:02 -0800 From: Gleb Smirnoff To: Olivier Certner Cc: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: January 2026 stabilization week Message-ID: References: <2506357.THHZn3L5Ee@ravel> 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: <2506357.THHZn3L5Ee@ravel> Olivier, On Tue, Jan 27, 2026 at 03:25:50PM +0100, Olivier Certner wrote: O> I'm still getting a panic at boot in IPFW code that is different than the panic I was getting before d1a8f1a62f31 (but after e3caa360d5d0a73a). I think it's at the moment of loading rules. Quick extract: O> panic: _sx_xlock_hard: recursed on non-recursive sx XXX @ sys/netpfil/ipfw/ip_fw_iface.c O> _sx_xlock_hard() O> sx_xlock() O> ipfw_iface_ref() O> ta_prepare_add_ifidx() O> add_table_entry() O> manage_table_ent_v1() O> ipfw_ctl3() O> sogetopt() O> ... O> O> Thanks and regards. Sorry for that! Should be fixed by d8a78048a246. -- Gleb Smirnoff From nobody Tue Jan 27 18:09:58 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 4f0tjN56q2z6QCTk for ; Tue, 27 Jan 2026 18:10:00 +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 4f0tjN4Qs4z3cWX; Tue, 27 Jan 2026 18:10:00 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769537400; 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=lyLaKN0bUO0KnjTnLoz6xJR5jMS/vXEMXWGZcoIzQwQ=; b=Zd1oPF/FJjCEJ05RHuAzsrxhZug2CxfxThQ39oyYkHV4AA+PhBQviLHU4AXrH1jy7WImBA vh0yp68JuAipiMDWzHrVWt1yDYprpM5Gkgq5TUNVATAIpnm/69R0/aARAbKqX3mhvx3fx1 y8AgxuIT/23IJoCAakTDDgosck2HgGlyQjm4ZpxfdN++W88Ml5rN6D+eJ6S0xUbYreMOQJ z4pyct3OZpwFzfB+ra/XXscmsoltFftVy+G3Hsc2AqhfrBRMYkzamUEw1dYMKuXCQMrFkE azZUNtzWsDvX2KatVfoLyCajOfXUzWmNQyQuYHBHSoEjrLo8nkLqRvSDajDfbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769537400; 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=lyLaKN0bUO0KnjTnLoz6xJR5jMS/vXEMXWGZcoIzQwQ=; b=ojEH3zgPjbBfUSCRwTnHLpLEtm+998BrRKIdIRuNP+GAhDEVd+LSTtH1Ruqu5umpaVj3BC BaT245ItyiwYqyg/YrQ3AMzgQ93sHhB1WSnuQUDs9Da45dEESu1pLpR/etyv61vmKUC6Nj RLy4CGGHML4Vt9XQGGZ70+wYIKB48qeaVhv4XYwwU8ojnePCvn1z0p6UEtoHk5NePjTYVv 70Em8EaLrj3kAtaBASGB8ojFAyi3tGBGJ0ujm9XQ9HX2MkXIgObuIewcaIUBNt9/ZIsu6q ejsYDDQEUe80zwoPpyE0tHeZSseNLQK12/J5BwED9cj2dXLfDjgGZi4ohapr8A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769537400; a=rsa-sha256; cv=none; b=ERzxsPXk7qhlM0YUi8zmInUf+y7HHk6bKJTfxkyWGpr4ZxN8Jbs9I5LdmCD5Tp7BabbGMk vHbZlfuVA/Ql4FiOWSdGDo5cEmVAddjCXbYlux82qDmHikr0Ig3QgaU8A9+sekFFwWFq9c wRdc9/dsov+wCNlNl1+W3rduVwfFknw+forNDqyqkDdDO30bLdyR7fhG9NSFpWzQ/iPQ/N RIuyr8vhX3zYjUefl0BScwwyRz4fXirrVrWM9wRT0vfAxuoTUy5ZBUGscKngA8yQwgjyT6 nh3vRMYSek0DQi++CrXwYSGmLyUQyV/2BDO+Cehxmq/pI/1NQuRbKG4g+PIe5Q== 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 4f0tjN0qCmzHNN; Tue, 27 Jan 2026 18:09:59 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <1c328ef9-0efe-4a80-8912-920ee4905e5f@FreeBSD.org> Date: Tue, 27 Jan 2026 19:09:58 +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: Pouria Mousavizadeh Tehrani , 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: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/27/26 01:05, Pouria Mousavizadeh Tehrani wrote: > Hi everyone, Hi! > > 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'm happy my contribution spurred this kind of interest. I would like to enable it by default on head, but I'd rather have a good consensus on this before actually doing it. it has already been noted that this shouldn't be a big problem for servers, which usually get manually assigned addresses for various reasons, so I would not worry much about that scenario. So I'm obviously in favor of this proposal. BTW I'm also proposing MFCing this to stable/15 [1]. But the feature would remain off by default there. If any source committer would feel like approving me committing this MFC it would really be appreciated. (I don't have a src commit bit, and, as far as I understand our rules, I need explicit approval to commit any change there) [1] https://reviews.freebsd.org/D54382 -- Guido Falsi From nobody Tue Jan 27 18:17:27 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 4f0tt72WCFz6QDN8 for ; Tue, 27 Jan 2026 18:17:35 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f0tt70FYSz3fqZ for ; Tue, 27 Jan 2026 18:17:35 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-oo1-xc2a.google.com with SMTP id 006d021491bc7-662f5c4665eso222267eaf.2 for ; Tue, 27 Jan 2026 10:17:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1769537849; x=1770142649; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=CWtXW3wE4IcJX1ftNeD8RX17ZSkI3TAKbILt3btxSB0=; b=QHaILVjqcxRpp5GQmvszS7q0Wl/KNxEEXu1969ZmlDjNUitksfvNJH7psOPnyoN+Ui hxGZL2p32+oIsB8UDP5u14ehzPN1NkyQLnUJcM1wt3JOBc09QVrLuT7J7NMBRPLpsLqd nDbKyN0ugJAIh0KgigEqXUFSVOO7qFvhju8h07BZApKOUDe7CvHriCPOunUdibHAYYEa 73NfSE2Y/2+i8PDuiPkgiL/nJ3bnlMU397dZ3pNuUOU9kru5dQxrAXDACUXDCq31xQT6 MLhUy6N2AmoKwiiMS9qvsU4kM/3Bt50/LnKNaVRR+MUO5x2GWu/lbRBpAEbQl1Tg5QBT 88lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769537849; x=1770142649; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CWtXW3wE4IcJX1ftNeD8RX17ZSkI3TAKbILt3btxSB0=; b=exq5pozpgkgqTVo9/4uXQqda2ZGgSPFi8518LhPVwUv//NwUFGrDnpHunP+e43uCXM s3qyvfgb4KSGpN4d5i/ycZEiGMBrCSEVmIj2+PJ8jK/jPLceoPYrwuUUwPcYIHzzK000 V1MAZOx6I88OxTjZxXQ2+gLaSMfn8g1DO3CSFKaKtUZLEV442hjY3M9wKoMg9qizUN7W HPfDsNCdTNSYO5rVf3aU60Zo95wJ8QAeT+jRZ0jEFvQgmAnZD15rg/2oFpONgJIGjlpA 16qwAJQsqmq6JiJVW7PPxACWIIlLcTUjb6yDT89XSS1Uix92tnSWSoNj0IyDD7y/sdOo PB7Q== X-Gm-Message-State: AOJu0YzQtMMXQPKc9zbbVJCuKS31urCJAs1a63/k2n4TJCF6k0i6Zfbh 1XwbwaYvADxyI+TUyvhKmZwx/EB5Yl3nQuDnDS94a4G13mRGf87u2hUiwQbvv07hcnSssZA0Fq9 aAzGDGV8= X-Gm-Gg: AZuq6aJc5XHDkyHrFdaGtGWu8Tm9pIRPTLa5hq2xZZ0Qpi7M9v5TSFHSFOrCShO2YXo e/KgETLYuSfblX8Q5E5T8lJ1m/kk3IqAR4Y/CTUS8Iv6/hVPl7HIONzZh8ZchM91o76RIn6XwGR QXoEQlpS3ngxU7Sl+i7+x4C3aVSQlvPw3ApNrJ5ls3/YmgEFPJjf2XAmmRD8Nug3e1apo3TyFI9 hcYi/CzcD1cSDtxj1vJcbwagH+qntudOiBXeB+Sx2ScLMMhWkbflfMY7WeljytqKcq7YT0tfxkm idKnU0j5vXyu7/urp+H9E1bVEtiKPVqCX8iVN8EpoSFORdK06tRwajebNHSzspGfeElTZ6pOs+j cOB2Z7iDBm+Mkky7deJP9+xo2gvc+3+mFQisUEk/QXktc7v2t8v9zmhid0Sw090QUppbY X-Received: by 2002:a05:6820:80c7:b0:662:bc9a:91c6 with SMTP id 006d021491bc7-662f20435acmr1538539eaf.22.1769537848554; Tue, 27 Jan 2026 10:17:28 -0800 (PST) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-4095749f298sm266817fac.12.2026.01.27.10.17.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jan 2026 10:17:28 -0800 (PST) Date: Tue, 27 Jan 2026 18:17:27 +0000 From: Shawn Webb To: Pouria Mousavizadeh Tehrani Cc: freebsd-current@freebsd.org, madpilot@freebsd.org Subject: Re: we should enable RFC7217 by default Message-ID: X-Operating-System: FreeBSD mutt-hbsd 14.3-STABLE-HBSD FreeBSD 14.3-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7ci6kqcufi7stpup" Content-Disposition: inline In-Reply-To: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4f0tt70FYSz3fqZ --7ci6kqcufi7stpup Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: we should enable RFC7217 by default MIME-Version: 1.0 On Tue, Jan 27, 2026 at 03:35:16AM +0330, Pouria Mousavizadeh Tehrani wrote: > Hi everyone, >=20 > 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. >=20 > IMHO, trying to maintain backward compatibility defeats the purpose of a > privacy RFC. >=20 > 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 upgra= de > (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. >=20 > 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.) Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --7ci6kqcufi7stpup Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAml5ASYACgkQ/y5nonf4 4foUFxAAjQwjT0ntjCjb+8u2lqpzr7E7XzNZEAf9Y+NWZD8ZXKHohpazkfKzhBuU pEPMvh24nJywlwN6BxF/csJPa+3yJISNsiySxP9O7jmGkIasO7Y9PC2m7v+i3+GI zbF41+k867WSH5GV06+2TeA4QJ7bIHEHHPlBvP98I/aCaMUTXHV3CVFCIuNsDovy 9caZPPIxGf93J0X7PnlxMJmTz//HTIiQeZbUPH7zHAKMmYkqqMbYenM8ifO/ZmBH EiPaBIMe9rVYcEzZ+pIawaC7YAIMJWgVVfNr3AFtDWEaktUgVEX8VNoI6HDmgz0G cUAkpH9M6uCH446P605dyoalqI4eagnwfjR7aDmTp5z9Afsl/+nVhvn8rdsXarcB ydBCBxfLuq81YiXlpWKouWwG8NZh96Ov+GfcRAzne9lm+LXzGbU1cRZFUuUciu+C 1nV0DxLmRM53XncydsiHTOXj0C2y/BFjjh8OoTDavSq5AoBFY/k6hJ4Bwf4Z2wHl 6gO1BGBb5JZPwYHsTh/CiVFFuuNTVUMyi6OXx40X5ehex7CAgci7M/y9UKkddsCQ +Ur68V2xRqilNJ6fT2odGZoVpJkK5jGWBDoFiCgJQGxry0i2vyUpLc5PiXXHAUCM ez3IQNZ/FDGBftzMouC9FiGTdJ81Kl2o7S8LCPSXkdxSAF/iue8= =JSIK -----END PGP SIGNATURE----- --7ci6kqcufi7stpup-- 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 From nobody Tue Jan 27 19:17:18 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 4f0wCB2gVWz6QJPR for ; Tue, 27 Jan 2026 19:17:26 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f0wC95XJrz3H8F for ; Tue, 27 Jan 2026 19:17:25 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-662f9aeb782so91591eaf.3 for ; Tue, 27 Jan 2026 11:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1769541439; x=1770146239; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7rxTKb7mXZ3XhmWrybV095HMYAb1dLWAFoU2AgoSrXQ=; b=G/kOTWfmFWozUuwyHB23ZroJi6iBy1GNdC3e/+uEGeApE1OMwSbQHrpYufogRhAh7M xNZsEr7lBJurvwl18f8AJCHIvBfy0jg1wGdeqqLxZRm/eZhdQ79yU7tm7Rl3TxQ9i3bq a2Jl7pEy192bFJoA5yfqc4b+3ryXNSvSvy6wjueDWuvk8yZQaLCzgUgyTekG6HblB5SJ l2OzIUqRJvy9OwEG8fztZ4O3smRBN1F7878EOoydQGd8SOWUf7qiRhNBOHH5GYwm0wVG Li3wbl4UZAIsIYwTq1PKqv1A8HjgC52LMhIv8VBP0mrbi3VvlnIlpFVHQxLOeZCgox0H cAQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769541439; x=1770146239; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7rxTKb7mXZ3XhmWrybV095HMYAb1dLWAFoU2AgoSrXQ=; b=kb6rLqGka7xYrK5oNBssw6hHR6hgm9UfzourowFK6CJZAusez12B8RA3ELOttQvP6N XWxlOs8FvjErOd89q7e9ZgB4oNCV4I/rAG3U9FaD8sPNm4C5j8TnTA2fVu8X3P3FIGl/ 8lHaat5LsZmimk3R7UgnnO94zaKpsjZvxEzU2DGw/goQWpBf2wA5Ukv+FbSfsHI11iAA ZH7Jpo0k/tOIwNgFfrVIE0POICxou6cjMVzinWEksPHm6xYm8foEfiGmPSm+y/o9nXUt NDpYVeG1ZR2Po1JsxCeX1hZWKOA4x3aL1blBS2+LBWd9zZS8OMkvLIL1NFHcpSNpW7Ci M2VQ== X-Gm-Message-State: AOJu0YxuwB4syDwZBPosXDW1e4rCv0/4Z2Bf2j3gyFjKI4KfIKIZKP/R 72D9HiNhXZtAvxgNU6tPAzbojCI/m071sYLBGV4s/34An481YP/z+ENKaQfAKqTO/hw= X-Gm-Gg: AZuq6aIvuJu0q8//Ej8EnJGetU+pPO1nymZ2rCBxdaezPPKcKIJwzLXVa/k/pfuYHkd MN0BAWZmxetjrUi5f4HfGpQ5ADHc5EQe1v9cEKMUA6tC/rs3Fs8l1XX1pd0xVSBmuH3hQP3pKCX 8KpNmbfQgfgyla2/AQt+2XgeWEGTnv4uuuYLceFopn2GLEVVMuOXNo9f40k+oPDcpcUPNVt6pwa VZiPElDAod25uZLQH+fznHSwFQilOzRB9vYdj+ywlWmMr0CKiLydbksby0tDK1rst6TX21eqdlj qtWq+ZCeGdtghnoV4+kGPld+eOC6UpUeE3Ko1tD3fC1j8Gv3nByCFftV6OfiZssxyRW2VAbugAI 2bWY0YJgh2oi3BZuM5KXo6HXPNB+iErIMXAUO1MNoyCKjEVCckoJUyDMWn3VwXFl4lcbF X-Received: by 2002:a05:6820:498c:b0:662:c3a3:2dc4 with SMTP id 006d021491bc7-662f20575b0mr1525074eaf.36.1769541439393; Tue, 27 Jan 2026 11:17:19 -0800 (PST) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-662f99447b5sm204653eaf.2.2026.01.27.11.17.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jan 2026 11:17:18 -0800 (PST) Date: Tue, 27 Jan 2026 19:17:18 +0000 From: Shawn Webb To: Guido Falsi Cc: freebsd-current@freebsd.org Subject: Re: we should enable RFC7217 by default Message-ID: X-Operating-System: FreeBSD mutt-hbsd 14.3-STABLE-HBSD FreeBSD 14.3-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> <0f5fcd3d-b189-49f5-ac81-d4fb48d90a77@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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oyz6roa7m34yy3ab" Content-Disposition: inline In-Reply-To: <0f5fcd3d-b189-49f5-ac81-d4fb48d90a77@FreeBSD.org> X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4f0wC95XJrz3H8F --oyz6roa7m34yy3ab Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: we should enable RFC7217 by default MIME-Version: 1.0 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 w= rote: > > > Hi everyone, > > >=20 > > > 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 genera= ting > > > stable IPv6 addresses, which has serious privacy issues. > > >=20 > > > IMHO, trying to maintain backward compatibility defeats the purpose o= f a > > > privacy RFC. > > >=20 > > > To be clear, we don't want to change the ip addresses of existing ser= vers. > > > However, it's reasonable for users to expect changes during a major u= pgrade > > > (15 -> 16), a fresh install of a new major release, or living on CURR= ENT. > > > So, for obvious reasons, changing the default value would not be MFCe= d. > > >=20 > > > What do you think? > >=20 > > 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). > >=20 > > The one thing I would hope is that support for completely random IPv6 > > addresses via SLAAC does not go the way of the dodo. > >=20 > > (If net.inet6.ip6.use_stableaddr becomes the default, we will likely > > keep it at 0 in favor of the other aforementioned sysctl nodes.) >=20 > Those are two orthogonal things. >=20 > stableaddress enabled replaces the current algorithm for deriving the main > interface address, that stays attached to the interface indefinitely. >=20 > 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. >=20 > The two can live together, there is no reason to disable one of them. >=20 >=20 > 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: =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D bridge0: flags=3D1008843 m= etric 0 mtu 1500 options=3D10 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 plt= ime 14400 vltime 86400 inet6 2001:470:4001:1:c001:f868:c587:cdd7 prefixlen 64 deprecated a= utoconf temporary pltime 0 vltime 44033 inet6 2001:470:4001:1:c139:85be:79b3:e3ec prefixlen 64 autoconf tem= porary 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=3D0<> =3D=3D=3D=3D END LOG =3D=3D=3D=3D =46rom 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? Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --oyz6roa7m34yy3ab Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAml5DzcACgkQ/y5nonf4 4frOnw/+Mz23x5L4cwWKgFFvG8vvI1wsPXRbBImUH8udnzClfB4sY9iCoFPy25tR ZcVEzKyrVwb0fQXiYHj8F9QuGry6U3uEzk2g8k6B2jcYkU8oE86Gy2z5B6kt3Nlk 3vmN/8MjK8b3VEoYKwoTi5ZP2H1l/r1sXio+LXWosjI1we5jb0r+JTGu+KE23Wc9 uAv0PXpvdUlV14cV26boD0eLYxEP62HoruBuwGX7AyRX7mlX4On+di/RKpnr1WlD NLDW+qGrvBq9jAISwHY3zJtBUn63T4SSI051ZW7micNy9AMMmBsf8R73UxQn1ZE/ jOXJiqbqZ9pwf07ruTcAAeyVjSQhK/k4T740b6vpfenv38oG0MdwDH+m3fj8psad xF8n9tH1o2A0hPukC8pAS/rQC555oCiJ9Qkwz/sFhv42Qs0KmoblXwuc/t5Wl6xI /3VXItOgRkzCyd5tSV75Qd0nH38DvYe9jMtP8V0A+7WJBws81EWzXkc5T5VlZM/v 2+xOMDR5KRAxpug5DhRKHXlucXzyyHcne9P2yVR6SZ8zQ+Erp/xYWj9QbysY00TB MhmiSujbUuwb3VSURNvrcwlAEBwrX3wbgN8zd/Mp52uchJ4ZxOlbH2WzrtHndET1 Y34QAXi3OzEgzoSyEmN2btRpq65o3lo+VkrQ5v8nTzMSy14zswQ= =FM5C -----END PGP SIGNATURE----- --oyz6roa7m34yy3ab-- From nobody Tue Jan 27 20:01:53 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 4f0xBX2n0dz6QLjJ for ; Tue, 27 Jan 2026 20:01:56 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4f0xBX29Jlz3Tp5; Tue, 27 Jan 2026 20:01:56 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769544116; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=voY6JN1SBJvZO6Of9gh5lSeWP2gOWRmaUAD3Iq29nqM=; b=J4twhWMYu0nNYlZDi8396NbyXctE0qR+q0LogA07SV7zrBS0bLUOMeu5fMglxe8/aNvrKl 0vwwceInAp6DsKtDgdcGgWFCeo9EpGWbkBlqznsU46St3TTUCNd8ywxXQOU6iYs0W27JXI HQ3Dxzo6I8b+cGRs5DI0J9crz0FjADoV4E/srETf2oG9cBTuZCZbDy4yiWrsgjKHewn9y+ xqmrEtEn2LgNqEcEsQT03YnzfOTGgM+PduLTX477XPgLsrOc3ow6Hk7xSQZw89P0skfXFp dkPYp2ES51HvGKyFTHbTwCJ/62hYRLLruh07eHufkDeCn/J8PqM0JyRWILjLiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769544116; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=voY6JN1SBJvZO6Of9gh5lSeWP2gOWRmaUAD3Iq29nqM=; b=xELhhyR/9bRJxoDMAoqUq6Xh9zmEOc0JQAA24ZVPg3IkpuMQkG6vBtt08t0W/Q5hNwJ9N2 1ZpG1fOLcTOHcXs6K8hQCA8p22YBEfrUgiC+iAwV4deZ2RPNLo378IOVMnoWHYI/iH+I9M K+LcXVstt0l+wbGKxxDzPrZIi7o53LmXEWi7QXtaCZHuqC4vd7ZKrHjyr21raalqhln45A oYl2pV0OCMJZgy6RoQMpsrfzAIDL+73cyJcqCKufogd5BD2yfE0V1EvVx8zrHGMoGXYuCl iYJe1lY9BcQGNBp3lFxkROgrItPD+DTKFA5uJvZGSnZAuiUC+IcE2FH4mkw2Lg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769544116; a=rsa-sha256; cv=none; b=lx2bJOi8H/le1nHEp9wa/dTnLXF8n6V1YAGHk+PIxfn9Pl7hfVkA+ANiprQD8ht7wun01W vWMX1C5z7VQTobsl9r8OLoEigu5hPF+5TxmYCYF/nZe4zMu+76B+E6QXTuMt8v+iSMwLHm ir9ou0W1jlih5VeJv3gtE9A5AxEDE5thH+eCbQCOuIgJ+5qUdybbG/nTxQ81BQOzh5pAoO 41LiN8tx9Xsux6YOim80r0EzaSQ1FlpzjqMvZ72WE+TnHTtcy02vvvZ11kvcN46faSuHv3 EtnaRwwQqRaolghlZyAhAY6YabRJiEVbAdvm8ZoihVMVZcCt5z4hAt44hwjtow== 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 4f0xBW6LknzK2R; Tue, 27 Jan 2026 20:01:55 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: Date: Tue, 27 Jan 2026 21:01:53 +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: Shawn Webb Cc: freebsd-current@freebsd.org References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> <0f5fcd3d-b189-49f5-ac81-d4fb48d90a77@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 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. -- Guido Falsi From nobody Tue Jan 27 20:09:49 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 4f0xMj2nN7z6QMYX for ; Tue, 27 Jan 2026 20:09:53 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f0xMj0x3tz3WQj for ; Tue, 27 Jan 2026 20:09:53 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-x335.google.com with SMTP id 46e09a7af769-7d15b8feca3so2293470a34.3 for ; Tue, 27 Jan 2026 12:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; t=1769544591; x=1770149391; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=458ECLQ6X7op13ggm4Zc9IzTNajaFKACgFhkgjsnjdY=; b=Tdniry0muswRu5ahpStto4uMCX7I/IQnm8XhITt4AcBm4rjR02D9UXihBea7isPU07 9fH4/Go6i2Yjocp2HwQZVhfFlc6fpw5wKYB1A0dXvWwryqx9GsMGHA8umDpXAHixPsna X25jGPtOLuDHwCIrLPezYV8/bvvUy/pxs87eccwAPXFCWLiHuQbZmksNUx139eq7LAqn D9tOUc50aLhePNdVfKVzPTUp1Oww7Jdu9TerJpuGITCO3Z6hz4l4hag9O2RPN01VNYon Y+vy5AFCclA+0ZUh7290vEuK/ey4SQY+ikIEljgEZNqRwRLWYAepSDwp4HH/JZ/w2L9X 6BEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769544591; x=1770149391; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=458ECLQ6X7op13ggm4Zc9IzTNajaFKACgFhkgjsnjdY=; b=UKHGe5+8v9VAdYme2oRm8yVokBGvyL6Ns0y22WJQNqiqFKLSVHxV+Y4h8zda72HNUy tt7wpePh9qp9FvIdRioBCAVYLtehbIWWCp5g/cWwxWrIGpcr6LU2cxE1hVJgKri/jxvH nYt/r2ASm+wzK6QEkOjU3Np7f4428VjZcS1Yrn0FiugAomq10edT0OKIwINVlSygW3vi JZpWIl1yhvEWnf379SvxqlcUGXo5xat7UPy03ho4FKcDXY+O0IsDPXcBfzYjboCTP+ir Jk9K1W8ItJJSvULKdISb7clUW+TinA56ZkjCR6d8Q3Zq9pEeR3hAdohzT/mHavfIOVPt whsg== X-Gm-Message-State: AOJu0YzhiuLTdaCxSEjQJBa0WkT5y8xaBJpkaQUoJ7FKte+4pHaI6JKH LUNEOJZEobJ+5wRkSfvsrZZwbEHp4+tE9iN3A6PVyeEnPrXQOLTLmiVpycq6M+0Zo0Q= X-Gm-Gg: AZuq6aLxx94IpoCfIIMbyTNRVTZlcgc8NW88CpyoSjszZbJSEaCtWe8WPocwYx6Dipi nC97aFkck/Mg0dtQLiF+btjLrlw+IulEkXjZ5zlSbBazskjQiZOLbILH63JhIY+pzQ8FjVHl8Fh Hl2rqNLWqHLVMVjboWRKONx7JUnDDjUH3esg/UmkNdFD6jcUnQ9s+RGxghmfxN4VemvZd93/tPa 7jvAx5PIwvmL3sEFlcPeM8UHKiAPmUqJAjMoC+wf7s685kiTpHxqkabfCdSHoQBGYQfic9mBVIj BOkwj9WLf0iVE3FmYaER/d/hf/3U3g1kJKj03vlhWzC51qK2grokeZ+xuQIcl4umAVLM8QZC4hA T9mX2XjX7ItbZvtEIqHEIcM5E4s4dQNe/AK0wH4H/UK9fevw2tx1dmBvNYWmCiHG/COer X-Received: by 2002:a05:6830:3c8c:b0:7c7:701:fb10 with SMTP id 46e09a7af769-7d184face16mr1856209a34.7.1769544591005; Tue, 27 Jan 2026 12:09:51 -0800 (PST) Received: from mutt-hbsd ([2001:470:4001:1::95]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7d18c825bfdsm409245a34.29.2026.01.27.12.09.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jan 2026 12:09:50 -0800 (PST) Date: Tue, 27 Jan 2026 20:09:49 +0000 From: Shawn Webb To: Guido Falsi Cc: freebsd-current@freebsd.org Subject: Re: we should enable RFC7217 by default Message-ID: X-Operating-System: FreeBSD mutt-hbsd 14.3-STABLE-HBSD FreeBSD 14.3-STABLE-HBSD HARDENEDBSD-14-STABLE amd64 X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> <0f5fcd3d-b189-49f5-ac81-d4fb48d90a77@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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mfl7u6qer26oglo4" Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4f0xMj0x3tz3WQj --mfl7u6qer26oglo4 Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: we should enable RFC7217 by default MIME-Version: 1.0 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 Tehra= ni wrote: > > > > > Hi everyone, > > > > >=20 > > > > > With `net.inet6.ip6.use_stableaddr` now available, I believe we s= hould > > > > > enable it by default in CURRENT at least. > > > > > As you may already know, we currently use the EUI64 method for ge= nerating > > > > > stable IPv6 addresses, which has serious privacy issues. > > > > >=20 > > > > > IMHO, trying to maintain backward compatibility defeats the purpo= se of a > > > > > privacy RFC. > > > > >=20 > > > > > 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 maj= or 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. > > > > >=20 > > > > > What do you think? > > > >=20 > > > > I think this would be a good step for FreeBSD. In HardenedBSD, we s= et > > > > net.inet6.ip6.{prefer,use}_tempaddr to 1, which creates completely > > > > random IPv6 addresses (scoped to the prefix, of course). > > > >=20 > > > > The one thing I would hope is that support for completely random IP= v6 > > > > addresses via SLAAC does not go the way of the dodo. > > > >=20 > > > > (If net.inet6.ip6.use_stableaddr becomes the default, we will likely > > > > keep it at 0 in favor of the other aforementioned sysctl nodes.) > > >=20 > > > Those are two orthogonal things. > > >=20 > > > stableaddress enabled replaces the current algorithm for deriving the= main > > > interface address, that stays attached to the interface indefinitely. > > >=20 > > > tempaddr creates additional addresses for the interface that are used= (and > > > preferred if the prefer flag is enabled) for outgoing connections, an= d are > > > generated again periodically, with old ones remaining attached to the > > > interface, since old connections could still use them, till reboot. > > >=20 > > > The two can live together, there is no reason to disable one of them. > > >=20 > > >=20 > > > 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 t= hem to > > > not interfere with each other. > >=20 > > Seems I was indeed a bit confused. Thank you for the explanation. > >=20 > > So looking at one of my current SLAAC systems, I see: > >=20 > > =3D=3D=3D=3D BEGIN LOG =3D=3D=3D=3D > > bridge0: flags=3D1008843 metric 0 mtu 1500 > > options=3D10 > > 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 0= x3 > > inet6 2001:470:4001:1:5a9c:fcff:fe10:d77e prefixlen 64 autocon= f pltime 14400 vltime 86400 > > inet6 2001:470:4001:1:c001:f868:c587:cdd7 prefixlen 64 depreca= ted autoconf temporary pltime 0 vltime 44033 > > inet6 2001:470:4001:1:c139:85be:79b3:e3ec prefixlen 64 autocon= f 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=3D0<> > > =3D=3D=3D=3D END LOG =3D=3D=3D=3D > >=20 > > 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. > >=20 > > Amy I understanding that correctly? >=20 > You are correct. >=20 > AFAIK the relevant RFCs implemented here were studied to be compatible w= ith > one another. >=20 >=20 >=20 > To give some details: >=20 > The net.inet6.ip6.use_stableaddr sysctl changes the algorithm that > incorporates the MAC address in the IPv6 address with one deriving the IP= v6 > address with an hash (sha256 HMAC) of the concatenation of various source= s, > as described in RFC 7217, specifically: >=20 > - the network prefix >=20 > - MAC address, interface name or interface id (configurable via > net.inet6.ip6.stableaddr_netifsource, default uses MAC address) >=20 > - hostid (this is a UUID, constant on the machine) >=20 > - a counter, usually 0, incremented if there are DAD conflicts (another h= ost > with same address is detected on the network, counter incremented and a n= ew > address is checked, by default for 3 times, configurable via > net.inet6.ip6.use_stableaddr) >=20 > - we use an additional counter to cater for the very rare case the algori= thm > 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. 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, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --mfl7u6qer26oglo4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAml5G4YACgkQ/y5nonf4 4fpnzhAAocU8vqmR0lW3b2CSLyqohHmJutOLXwZ2NNETqSDTMrLai5SXt2XS4PUH /sFKYOZ/in5ifOtluq1gMnSywoBUNczujT9pWGd9LEukvAColsC1w1OSi55H07cC eJQf2GzGnw/BaIpFYVGVSrHqFk94wwYCxuOsIA0fOrYIGcBoQUKmlD2aMMVlzDTR +qaoi9/vU3m6MA8cSQ4+Ds5nQpdHXH2POLqfcEHxvhia8GaC904DAqeDN8SSxs1p WYvGAoj2K47w5xdTlQN55I0tOibPY7Qvpipn6spi2g4/bV8WBGISrvj3+Cxe4l7k PzZws0yADL5ylSIhBxewJhjG9U3yN6yr8+89/ixgv/WFvbIIATm1Au3Z0+dIgT/W KR4n2t3jRcGCW316EEdLuEm15yy3t8slDvglFkCiiKIdL4ujIITX72AJNlM6aC80 ck9AJpjOwh4oE2VN3oDHdLPuepj8Vjbbb2x+3c61yjgCQKqjDVdWFBGLj1c6qYGU JrHlh5eosWHwd4YU1veYityvFAPqEfK3k17d5RzXWyid+o4doTgnLwSHVLN3xENd jr34Bn4y52MuJH6o00Ch9SMZv0xFVvebN4URfe/4r2kUsDSKKWjFolPojuOb0+TL rJdCtaj62K4COXIA7b1lmKu6wNBMWjpftgC0UsaVtBYenIBrV98= =PJwD -----END PGP SIGNATURE----- --mfl7u6qer26oglo4-- From nobody Tue Jan 27 20:29:55 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 4f0xq34GTTz6QNqH for ; Tue, 27 Jan 2026 20:30:07 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from vogon.madpilot.net (vogon.madpilot.net [159.69.1.99]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4f0xq207Fnz3ZLL for ; Tue, 27 Jan 2026 20:30:06 +0000 (UTC) (envelope-from mad@madpilot.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=cyq4qetkgngm header.b="b Tyeqfh"; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 159.69.1.99 as permitted sender) smtp.mailfrom=mad@madpilot.net Received: from localhost (mail [IPv6:fd5c:5351:d272::3]) by vogon.madpilot.net (Postfix) with ESMTP id 4f0xpt0kR3zLnJy for ; Tue, 27 Jan 2026 21:29:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject:date:date :message-id:received; s=cyq4qetkgngm; t=1769545795; x= 1771360196; bh=FkVj3vwkwcDaHPBKm6bmRSDEh4o9G7P2IRmAHSUOYl0=; b=b TyeqfhOTqS0QpNZx8TLUtjQ7+9oXm3/b+XrWwbmXygcJC6upx/vjAYvbd4FZHQtC /h3GlWtRYNgd3LjnwOKxpCojaDfGS9ouFiLSKtBLk3DJ6PmdEuIF36jd3EnSdyx4 HKCkVC33NjekxuRWBihSjpfXadR5tsnALOEV/p0TZ10bI8Vs90q5PLFKAaCqKR0d ZczBRveGs0c5JrrxjSnYPrAqD1wyov9OcWSnuIh83MbuYV3c6pT6O+xYQ74Xi2y8 KDdXUuQ0UDCr7eWbuvygoLN6mmxEzGGWKo8SDrNMqi+g4YRaWzFu4qUTaX1ICBeT 7HT2v9AgRQC1WtE+kqt8w== Received: from vogon.madpilot.net ([IPv6:fd5c:5351:d272::3]) by localhost (vogon.madpilot.net [IPv6:fd5c:5351:d272::3]) (amavis, port 10026) with ESMTP id D58tY2XczfEz for ; Tue, 27 Jan 2026 21:29:55 +0100 (CET) Message-ID: <1d39545e-a49b-43f6-b7e7-e6cf01b0f060@madpilot.net> Date: Tue, 27 Jan 2026 21:29:55 +0100 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: Guido Falsi Autocrypt: addr=mad@madpilot.net; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNHkd1aWRvIEZhbHNpIDxtYWRAbWFkcGlsb3QubmV0PsLAeQQTAQgAIwIbAwIeAQIXgAUL CQgHAwUVCgkICwQWAgMBBQJS79AgAhkBAAoJEBrmhg5Wy9KTc0kH/RO64ORBlTbTHaUaOj8F Je5O5NU2Pt9Cyt5ZWBRvxntr1zPTJGKRPS9ihlIfqT4ZvEngQGp57EUyFbCpI0UWasTerImM tt5WACnGmCzUTB39UXx8Oy4b1EgWeTJQ747e/F1mQLXTNa6ijRBE9fYlTb4gAkPN88/wVV9v 3PZozKLTg16ghBzHM/P7Lk8L7clPEZChX1FTa/6eSt3nvzfCuTMZbBPJF/ph+q1KyPqRgVfh tyhu5dvgMoPz/ni41IfeSrkJTD5RXzdyGR9q4Z1NYeBsLkRjC4LxKAP5KqUsvlOUjKvO1byj ApYdMarol+IGkaSk9e3zVYAJkWKjn/ni8XbOwU0EUxB7QQEQAKFhrDceoPdK/IHDSmoj6SQY isvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef+WE7 5M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ubeT3Xw QO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr8OEQ fOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB2i6A /xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45qfyh MiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0xpNi UilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWAdlKC NTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanCYrAg +8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNRgow3 kSuArUp6zSmJABEBAAHCwF8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCkX/qw EVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7FjfrV +dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxAlZ/7 i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+lQMZ 9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8LkQd rQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncg== In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: - X-Spamd-Result: default: False [-2.00 / 15.00]; MISSING_MIME_VERSION(2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=cyq4qetkgngm]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RECEIVED_HELO_LOCALHOST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+] X-Rspamd-Queue-Id: 4f0xq207Fnz3ZLL 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 On 1/27/26 21:09, Shawn Webb wrote: > 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: [...] >>>>> >>>>> 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) Made a mistake here, default is interface name, as it is suggested in the RFC with higher priority than MAC address. the preference there is "interface index" but we do not have stable indexes, so it is a poor choice on FreeBSD. Anyway the default can be changed if deemed better, but using the mac address would cause the IPv6 address to change even for simple hardware replacement, which looks undesirable, and against the RFC intention. >> >> - 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. I'm not completely sure, and should check the code, but I think I remember the DAD checks already have some random time delay embedded that would cause jitter in the retries. > > 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. ;-) As you say, the chances are very low, unless both hosts have the same exact values for the hash, and generate the new addresses with the same exact delays. As soon as one host "beats" the other to an address it will keep it and the other host will calculate a new one. The worst thing is, with no intervention, those two hosts would be in a permanent race conditions and switching IPs randomly when rebooted, not optimal, but chances are really low. The only situation where the issue could be noticeable is cloning a bunch of VMs from the same image without changing the hostid (which would be an error anyway) and running them simultaneously in the same subnet. This can be easily avoided in two ways: - change hostid (easily done by removing /etc/hostid before creating the image or using something like cloud-init) - configure the base image to use MAC address for stableaddr (or both...) -- Guido Falsi 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, > From nobody Tue Jan 27 20:55:07 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 4f0yNG00vkz6QQHq for ; Tue, 27 Jan 2026 20:55:25 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4f0yNF2YjMz3fKk for ; Tue, 27 Jan 2026 20:55:25 +0000 (UTC) (envelope-from pmh@hausen.com) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 1F19A8; Tue, 27 Jan 2026 21:55:18 +0100 Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3864.300.41.1.7\)) Subject: Re: we should enable RFC7217 by default From: "Patrick M. Hausen" In-Reply-To: <39a63487-ee9a-4792-a787-d476ae6f6a0c@plan-b.pwste.edu.pl> Date: Tue, 27 Jan 2026 21:55:07 +0100 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Marek Zarychta X-Mailer: Apple Mail (2.3864.300.41.1.7) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4f0yNF2YjMz3fKk 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? Kind regards, Patrick= From nobody Tue Jan 27 21:08:14 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 4f0ygH5cvZz6QQrJ for ; Tue, 27 Jan 2026 21:08:27 +0000 (UTC) (envelope-from pmh@hausen.com) Received: from mail2.pluspunkthosting.de (mail2.pluspunkthosting.de [217.29.33.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4f0ygG24ZSz3gxq for ; Tue, 27 Jan 2026 21:08:26 +0000 (UTC) (envelope-from pmh@hausen.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pmh@hausen.com designates 217.29.33.228 as permitted sender) smtp.mailfrom=pmh@hausen.com Received: from smtpclient.apple (87.138.185.145) by mail2.pluspunkthosting.de (Axigen) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA id 057F56; Tue, 27 Jan 2026 22:08:25 +0100 Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3864.300.41.1.7\)) Subject: Re: we should enable RFC7217 by default From: "Patrick M. Hausen" In-Reply-To: Date: Tue, 27 Jan 2026 22:08:14 +0100 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <45359118-7492-457D-A9A0-CFA37EBA125B@hausen.com> 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> To: Marek Zarychta X-Mailer: Apple Mail (2.3864.300.41.1.7) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.02 / 15.00]; NEURAL_HAM_SHORT(-0.95)[-0.948]; NEURAL_HAM_MEDIUM(-0.81)[-0.811]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.46)[-0.456]; R_SPF_ALLOW(-0.20)[+a:mail2.pluspunkthosting.de]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:16188, ipnet:217.29.32.0/20, country:DE]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[hausen.com]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4f0ygG24ZSz3gxq Hi! > Am 27.01.2026 um 21:55 schrieb Patrick M. Hausen : >=20 > HI all, >=20 > Am 27.01.2026 um 21:46 schrieb Marek Zarychta = : >=20 >> To narrow the impact, I suggest switching to the MAC address as the = default key source instead of the interface name. >=20 > 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. >=20 > 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? I was probably jumping to conclusions to quickly - interface names are = also quite predictable. So what kind of "real entropy" is intended to bring into = the hash? Host UUID probably? Kind regards, Patrick= From nobody Tue Jan 27 21:10:13 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 4f0yjl6j75z6QRDK for ; Tue, 27 Jan 2026 21:10:35 +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 4f0yjl1HgZz3hh5 for ; Tue, 27 Jan 2026 21:10:35 +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 60RLADVg063206 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 27 Jan 2026 22:10:27 +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=1769548228; bh=TkDUWdplN9tnKf2LQ9QDDnDba6I9kohXRJnBF5HGMjY=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=MRGCB930oC0nfG4/zV5rm5Ilc0ZGkrtNeDscNwXWdcAbKhj6UAbhQGeRQYyUp15Uo 8tVmEdGimZsBlWPMaxFEezOC/4Z0C8AePlJ+9KJA6DVVbdJhlX/jX0V1iO252SsYfG vqHMyFusH8JWATEq5demmK+6AB8VfGDAezLIWL2UUP39Nwr4i6iZbPb30r/CIjHa/j 9e2K29oc54UxrsWOGeMbp/DbIBfH3QUNpJ73WjR+ltltwYa6UfLvk4VdXzHOXyQK4W soYecFlgp0U255c/mR6trzOAZyXXpzW/VYPraLtiZwsrnf7QkRAaaya/PRk17cZGsr hEfy+NLu6iYwA== 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 22:10:13 +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: "Patrick M. Hausen" Cc: 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> 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 [-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: 4f0yjl1HgZz3hh5 W dniu 27.01.2026 o 21:55, Patrick M. Hausen pisze: > 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? > > Kind regards, > Patrick > As far as I know, this is not possible with current computing platforms, and it would probably require prolonged observation of the same host across different subnets. On the other hand, we still have EUI-64–based link-local addresses. Although they are not exposed to the Internet, they remain a concern. -- Marek Zarychta From nobody Tue Jan 27 21:15:47 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 4f0yrG1xvTz6QRT8 for ; Tue, 27 Jan 2026 21:16:14 +0000 (UTC) (envelope-from pouria@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4f0yrG1KDvz3kxX; Tue, 27 Jan 2026 21:16:14 +0000 (UTC) (envelope-from pouria@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769548574; 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=SioNl47LjsCgerFwV11u9Ie74HLewjWBSlrOsvZRhrw=; b=VfBZHW5pohibf5xMeU2auAiCA9Yv1Xf8YSSJPcjEeMOuHk134bvpQuepEn66y0+ubC2pWM Ph3LDjl//yqgfqKW3gg+Js/CJZSvJ8oQFdJsY11l6TTaAfjpmPJsIX2TJdqztuqVKHGS6U nlZxGyRC+u4dkMAPeC76kCQYrVvCxprC7JAaAqflli69hozSLCacgX8AisI3gUF/zVl6yr oIcnGht/ENNtOpdTTc6GYbPP2U8iIy7eU5tz+EJ2gfiHHDoABjKvMquwsxqCclQ+UcBcxQ 9XyS6Ui+tvnpbPnnvHSdiixxwOvJrv8+u8QDPZLvj4fcENk39JXuUM5rtX83Ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769548574; 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=SioNl47LjsCgerFwV11u9Ie74HLewjWBSlrOsvZRhrw=; b=EX5jBtbD8oTTmkEtYX8yIrkNDUtrI4Q2dNRsB1/7i130WCJi/V8UYlBXJyaU00ZMZBiwCo J4ou4aOUAMn06cBahifmnOWfjYid3MR8T0g/YsTsDFloB9M3KmBXNCq/qDpqdoVQ97B+ja Mf6+F7RpzXKBwFaqM/fSNscnTtHx7ZE9Afx3hH81kMJMXe8iOuVhT2GPeC+GfUoADjWzEK 0VUTYGv8yCiReu0yoAa3iEkarB0evk6EBH72Ce49d9rOZAtlaaQr/WDYYvW34bBYJYCgDf Nyrk5NIM69fql01yFoaz2GTdu86u/QaBXHpLWXZVWWyyXkRqqmtgGFs9ntKbMg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769548574; a=rsa-sha256; cv=none; b=wVNdOiciUK8DJxskvCIAPEmYDQb9mDEQg3figiXTEF6u0RcQlBdQoNU/NxPPiejxoW2itD qSv6CmheCqBeQAjBQjE+JHpZ/88N1NCUDIIMMuwH0Jv2xA0jNiLwAZHDRhWh6ZQ02VZ+SC m+tPQNJBaI9Iqny99eO/W2RRmEmPLRTprrCWyc1FtrH+OgAZN9AhnuoCC0JBYSEwvsBDqn ShumFUvN68GoqVfNwujhRlO6A4hrqSo4XV9b+wiY3wAn78tUrtQbRtjxF2edKvvOb6h9sD 1mSjwcFj/E0bq+2S/gDQwdaUW+haNTYUPVwMf8n7lCJSw3ZD3Bc/gGsm6Cuu7g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from nl.mail.spmzt.net (mail.spmzt.net [193.148.248.214]) (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: pouria) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f0yrF5K2zzLb1; Tue, 27 Jan 2026 21:16:13 +0000 (UTC) (envelope-from pouria@FreeBSD.org) Received: by nl.mail.spmzt.net (OpenSMTPD) with ESMTPSA id 96f30cf5 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 28 Jan 2026 00:46:04 +0330 (+0330) Message-ID: <4a83b581-1960-48b5-a589-ee47d85e8f18@FreeBSD.org> Date: Wed, 28 Jan 2026 00:45:47 +0330 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: =?UTF-8?Q?Olivier_Cochard-Labb=C3=A9?= Cc: freebsd-current@freebsd.org, madpilot@freebsd.org References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> Content-Language: en-US, fa-IR From: Pouria Mousavizadeh Tehrani In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------6BO10FY6rA5jzJlxqn3k311U" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------6BO10FY6rA5jzJlxqn3k311U Content-Type: multipart/mixed; boundary="------------WCY50cmdLKkf0BNXQVQU8j7t"; protected-headers="v1" Message-ID: <4a83b581-1960-48b5-a589-ee47d85e8f18@FreeBSD.org> Date: Wed, 28 Jan 2026 00:45:47 +0330 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: we should enable RFC7217 by default To: =?UTF-8?Q?Olivier_Cochard-Labb=C3=A9?= Cc: freebsd-current@freebsd.org, madpilot@freebsd.org References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> Content-Language: en-US, fa-IR From: Pouria Mousavizadeh Tehrani In-Reply-To: --------------WCY50cmdLKkf0BNXQVQU8j7t Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMS8yNy8yNiA0OjU2IFBNLCBPbGl2aWVyIENvY2hhcmQtTGFiYsOpIHdyb3RlOg0KPiBJ biBhIHNlcnZlciBlbnZpcm9ubWVudCwgYWRtaW5pc3RyYXRvcnMgdHlwaWNhbGx5IGFzc2ln biBzdGF0aWMgSVB2NiANCj4gYWRkcmVzc2VzIG1hbnVhbGx5IGFuZCBkbyBub3QgdXNlIHRo ZSBFVUktNjQgbWV0aG9kLg0KVG8gYWRkIGEgbm90ZSwgYWRtaW5pc3RyYXRvcnMgdXN1YWxs eSBhdm9pZCAqdXNpbmcqIEVVSS02NCBhZGRyZXNzZXMgZm9yIA0KcHJvZHVjdGlvbiwgZXNw ZWNpYWxseSBmb3IgdGhlaXIgRE5TIHJlY29yZHMuDQpIb3dldmVyLCB0aGV5IG9mdGVuIGhh dmUgYW4gRVVJLTY0IGFkZHJlc3MgYmVjYXVzZSBoYXZpbmcgZGVmYXVsdCByb3V0ZXMgDQph bmQgb3RoZXIgcGFyYW1ldGVycyBhdXRvbWF0aWNhbGx5IGNvbmZpZ3VyZWQgYnkgYWNjZXB0 X3J0YWR2IGlzIGNvbnZlbmllbnQuDQpUaGF0J3Mgd2h5IEkgYmVsaWV2ZSB0aGVyZSB3aWxs IGJlIGFuIGltcGFjdCBvbiBzZXJ2ZXJzLiBob3dldmVyLCBhcyB5b3UgDQpzYWlkLCBpdCdz IG5vdCBhbiBpc3N1ZSBoZXJlLg0KDQpBdCBsZWFzdCwgd2UgdXNlIGFjY2VwdF9ydGFkdiBp biBvdXIgcHJvZHVjdGlvbiBBTkQgcGVvcGxlIHR5cGljYWxseSANCmNvbmZpZ3VyZSB0aGVp ciBydGFkdmQgd2l0aCB0aGUgYXV0b25vbW91cyBiaXQuIFNvIHRoaXMgcmVzdWx0cyBpbiAN CmhhdmluZyBFVUktNjQgYWRkcmVzc2VzIG9uIHRoZSBzZXJ2ZXJzLCB3aGljaCBtYXkgYmUg dXNlZCBpbiBzb3VyY2UgDQpzZWxlY3Rpb24uDQoNCkkgd291bGQgbGlrZSB0byBraW5kbHkg cmVxdWVzdCBAbWFkcGlsb3QgdG8gY3JlYXRlIHRoaXMgcGF0Y2ggZm9yIA0KcmV2aWV3LCBp bmNsdWRpbmcgYSBub3RlIGluIHRoZSBVUERBVElORyBmaWxlLCBpZiBldmVyeW9uZSBpcyBp biBhZ3JlZW1lbnQuDQoNCi0tIA0KUG91cmlhDQoNCg== --------------WCY50cmdLKkf0BNXQVQU8j7t-- --------------6BO10FY6rA5jzJlxqn3k311U Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQSqt7cppfvJ816gj0lUwVnUeMwagAUCaXkrAwAKCRBUwVnUeMwa gNWtAQCKciMDxgTpUzzUegx877ZSklETCcuEACKKKsb84Mqh7QEA7JNHyn8AICBU GUn/AchR+HF01WuCHQO4ZlDAu+EsLAY= =0jPz -----END PGP SIGNATURE----- --------------6BO10FY6rA5jzJlxqn3k311U-- From nobody Tue Jan 27 21:28:13 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 4f0z681gTNz6QSPQ for ; Tue, 27 Jan 2026 21:28:16 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4f0z676C0dz3n2R for ; Tue, 27 Jan 2026 21:28:15 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769549295; 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=vsSNR1Ho4M2xQYjth2D15aClBhlS2ykScpPa5kkU3/Y=; b=r5nJCgerMr9Fb2q2lIz94dLR6atTLMw6fOExH4c3G9Z+OdnNGYhg+y2bObEvsUOeu5tyE4 AEMK0MUk+6f3ejitLSFnHlzjEdluGlLqtjn5kayHjJftVKE7WlE55VD9+ZuGHb0UY4JhYV Ymt/RfQw+gt33zu3odVMqsCF2KFzH3+ygjNtgQlAj5JjhXDVzAoAxgHmwwPLC+HE0pslAr 4Vd6ff0ZTLWq1JSAFwKt/aspo1HXVBv0AiEobbblbEBcf20LJPDsvKGpnGGuhp7wXwsxy2 Q10S+gpZxI9WskiOysB29Zomkf8b/61T8VGLP1MClZsEf9H2a6kSplSz94Qs+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769549295; 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=vsSNR1Ho4M2xQYjth2D15aClBhlS2ykScpPa5kkU3/Y=; b=OFOwT4oPyRDaCgU/RVFmXxXWFxhkmUNV1aXHB9nY8VnFnHoA9+Q7aQMu5W0Cuq9jRlOa/x 3VAzGbjQ4fgWW2h647le8Yr8nQSZJFa9ettTKYb04069VKQORigDYlqSWvoPvOlJl+sltQ ookZVeTXWM1evm65QV5r/WugKzaPOUWSOIUJhVIGtuoqEw1X3CPtda/Cny3IbCeNUFvQmS UeELb7DPCz6ZU2Bd+CRmIonEnfaLH/V9SKdyFGiZzIEPQzXlOucan4/d6rCHpyAwgFARL5 KNmObdawJYwDpBNqtu6RtFdErt4XDdhuKzDpYp2LRhsFhDnW4xty5XgQyZNPIg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769549295; a=rsa-sha256; cv=none; b=DTJqU2Ny6EvAfm53DuBrJA1g2bxrikeiCW2MgwBt5Sjtk2Ys/QVtcZqckskNQfxH0BS9tH W/9WIHQ4wpFOLCyfbqcgfZyA//M7D+plQKYaMsmwBBUfXEk9EfG8hYmrJgx6ZDKwXQjDKX jB6LjDuB8JurWu3UOGAVVLWmewXQPqH7YeoYYQ8TTVgLJAgn9NAeXH9cnetZMitZ/79ImN Qp3wA5CDSsVeUediaIAPIZKATlEiEV/HrDFEhCW0TLXQ88xemXvA+saZLU54XGfmOIlQ/s pWAO12FMRsSjvKvQIz0tfSbXgjG3wkPdhPAzKLOEoUtOG6GoKTgH4k6CI13k/g== 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 4f0z672FyTzLnD for ; Tue, 27 Jan 2026 21:28:15 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <240ec1f1-ca30-44b9-b654-1a114c71d6f3@FreeBSD.org> Date: Tue, 27 Jan 2026 22:28:13 +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> <0f5fcd3d-b189-49f5-ac81-d4fb48d90a77@FreeBSD.org> <39a63487-ee9a-4792-a787-d476ae6f6a0c@plan-b.pwste.edu.pl> 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 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 -- Guido Falsi 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 4f0zqv2C50z6QTYb for ; Tue, 27 Jan 2026 22:00:59 +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 4f0zqv0JbJz3rbs for ; Tue, 27 Jan 2026 22:00:58 +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 60RM0ZcM063487 (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: 4f0zqv0JbJz3rbs 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 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 From nobody Tue Jan 27 23:01:34 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 4f11B82lfjz6PcVK for ; Tue, 27 Jan 2026 23:01:52 +0000 (UTC) (envelope-from pouria@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4f11B821ZXz3M4w; Tue, 27 Jan 2026 23:01:52 +0000 (UTC) (envelope-from pouria@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769554912; 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=h591Tsfb9t8Chut/Wb1aSOz4euhJ4+tEfJfS4jlr1sE=; b=pbaMnmZ7wiGabRHAlnLjvlEYqE9jz+/HdPTIflhEP9P6OAmWLr1i2rdUC/ZhNt3YKw16UE PVQkUJeufQXVZiZAz4STCX59sK3nVgpY5aDsolTLbAr2Uprokw7IlRlHTOFa9TN8XJz8gh jBT3kOGGJkrqvkOOasDKfBRZyuoh1azFKV/6IjJ7lJCiyZhgCECaAOEXi69YD2uJgN5Og8 UbCLvKXW1ArXemDE3WTAcopT57pBBK0h2OAIA+u8JQV46fSxUqQiKfQtGODtX/8YM1W7VW sGj15zKACybc6FSLpJ9ne7//N4VEHj+j7oJkZGSfMaTNIROHkuDVYA6IYPaH6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769554912; 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=h591Tsfb9t8Chut/Wb1aSOz4euhJ4+tEfJfS4jlr1sE=; b=uxb/uyjQK5unO5CZzdmET0GVwsOwM85oh9dY5+0aEYLJVmWpL7J71hqvyq5ILDPFFFAfL3 hPoaue8Mp5S7r699M4FRc0KKlTqhRIlGaFMte542A7NnLPZGsjXKC4xyd+9HNi2oCRFfG+ 7+NO0H3DK83TUCyPqrOHdWlecAlWrnPO9tkY+IT/RzrEGyZ82rrcuKtHhAYqVWK1FL2fJY Q4akOMpRHVfts41ZxcK19RlWtJTktrJfITNwc5FMZQa9gwPMmAYmLMMafpJwGJgB333pNI l2yds9sbeVxFcW2S8JoLVH5ciny2Y15j4gMboAVxR62E7YVi+ARlBqTlI2DaFA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769554912; a=rsa-sha256; cv=none; b=lXoOnUJPeN5vh0FlQxVzlz1aF5IyT2j1rvoQ9994kPkjYamjk7UIqe7ooXskMl5fXaixrB TtBB4Cx09Yf/lMlwofvHM4xaT2AA0WByE0pu7tFa3noSzQd3lIcrX2UHfgtefvNkjzPbJA VmTAUf/BgsvsVz2YEBN5HW1RCz3P+TDiQaUJtUSiP/VS9HwCNpDsax7sCEFxDAJqBr42oe bKd80y7MmxMYvOgRrIIkcf1U0byEMZlZXeWGQ6JXmwofDe/y9zu4cB70ObN9ClgDRfXya/ 5v1RbJrb4fBgIOUPArZ2fAVLCvsoQFjvlmtmX/IcIYtYllZ3dSNY0Oi7pWGnjw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from nl.mail.spmzt.net (nl.mail.spmzt.net [IPv6:2a01:e140:12:1::25]) (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: pouria) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f11B76XpFzNKH; Tue, 27 Jan 2026 23:01:51 +0000 (UTC) (envelope-from pouria@FreeBSD.org) Received: by nl.mail.spmzt.net (OpenSMTPD) with ESMTPSA id df67df05 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 28 Jan 2026 02:31:50 +0330 (+0330) Message-ID: <4555a7b1-90c3-4184-ac3e-5ce45004dedc@FreeBSD.org> Date: Wed, 28 Jan 2026 02:31:34 +0330 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: Marek Zarychta 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, fa-IR Cc: freebsd-current@freebsd.org From: Pouria Mousavizadeh Tehrani In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------5Q1GCtktoW0NvsUSfvc6vMlK" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------5Q1GCtktoW0NvsUSfvc6vMlK Content-Type: multipart/mixed; boundary="------------v5YOVbKRWhT0kOwEVfq8oNtS"; protected-headers="v1" Message-ID: <4555a7b1-90c3-4184-ac3e-5ce45004dedc@FreeBSD.org> Date: Wed, 28 Jan 2026 02:31:34 +0330 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: we should enable RFC7217 by default To: Marek Zarychta 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, fa-IR Cc: freebsd-current@freebsd.org From: Pouria Mousavizadeh Tehrani In-Reply-To: --------------v5YOVbKRWhT0kOwEVfq8oNtS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMS8yOC8yNiAxOjMwIEFNLCBNYXJlayBaYXJ5Y2h0YSB3cm90ZToNCj4gSW4gb25lIG9m IHRoZSBtZXNzYWdlcyBpbiB0aGlzIHRocmVhZCwgeW91IA0KPiBtZW50aW9uZWQgY29uc2Vu c3VzLCB0aGVyZSB3aWxsIG5ldmVyIGJlIGZ1bGwgY29uc2Vuc3VzLCB3aGljaCBpcyANCj4g cGVyZmVjdGx5IGZpbmUsIGJ1dCB0aGUgZGlzY3Vzc2lvbiBoYXMgY2VydGFpbmx5IHJhaXNl ZCBpbnRlcmVzdCBpbiB0aGlzIA0KPiBzdWJqZWN0Lg0KRXhhY3RseS4NClRoZSBpZGVhbCBz aG91bGQgYmUgcm91Z2ggY29uc2Vuc3VzIChyZmM3MjgyKSwgd2hpY2ggaXMgc2xvdyBidXQg d29ya3MgDQpwZXJmZWN0bHkuDQoNCi0tIA0KUG91cmlhDQoNCg== --------------v5YOVbKRWhT0kOwEVfq8oNtS-- --------------5Q1GCtktoW0NvsUSfvc6vMlK Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQSqt7cppfvJ816gj0lUwVnUeMwagAUCaXlDzgAKCRBUwVnUeMwa gEMVAQCJoJcZHQeMF1JoMoFKtklvCvXI1gv3fP92CyU9Gi/hGgD/aGPj7AUDvlhl SkxrKvIYTX4OqRotoXMvHXo0dy7t4As= =tlrC -----END PGP SIGNATURE----- --------------5Q1GCtktoW0NvsUSfvc6vMlK-- From nobody Wed Jan 28 10:00:42 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 4f1HpM6VWsz6PbSh for ; Wed, 28 Jan 2026 10:00:43 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4f1HpM5m5Kz3ZvZ; Wed, 28 Jan 2026 10:00:43 +0000 (UTC) (envelope-from brooks@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769594443; 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=k7PjPDRNqC8DW6pR6CJRCqxpy7co/5p61Ps8oAkJTq4=; b=LHCU1jem2WSDx9mOOVGATInhLxiI5dN1VW0fFyPElbVcFwiRQmyi/O9T0Q2PshmhTLJbPY PBG1M8cO4Mn7KFbzfOqorrjvFq+PUtveAB6WNnCiPaGPM5BWhDCeSDXjVCPj1vyeXC6DMw fidos0ijNWkbkzHuf/4a1a5dhQvyKtVs7oyfN4zd4FERJnphPYgCUqJp5c+EnEHCyycZhZ Bg4eFvC+Rs/uFnEuT49CpO66uWBb/CpOgZmQJItwKRhIU3e9lizCDLR2l9ilz379tkgnUW 8BcfYlq4G28T59eSFOjjU1UkISQhgvroPQsDfU5DY5EMtL8qxGxcsu6xxFEwLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769594443; 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=k7PjPDRNqC8DW6pR6CJRCqxpy7co/5p61Ps8oAkJTq4=; b=G2ehkG8P3/cFII/UW4ve2K+o35P9mt3uzvZK2ugnNIANSfyGa6TF4YMGJ4LSquHM0xTPyr sO0NcnXoDRX9O9IrslBrrIVm1nYbPVCHZXESdu/T2CWswgpA4hZ3FiXnk4u9+FhXy3aOsl HlIKIoq+gEpvRENrnooN6F038wc1xDL1Xry0kMRh8CqG3eA0rtUNbJNoh/bl6SUdyz4q9q 0oU+bxF5WjL21uQen+YNdttEMNN4nrxmOLFfeSWXJAwQilvFImUbp79DcQt0iCZYTIPqh9 zojHI2VMIRXR6t2U+eq7MEemMkyCYUG2Grnyr4QRIgJSloQvWeiTnMNGO7AwlA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769594443; a=rsa-sha256; cv=none; b=aRPmGsrY8lWvYibiozU1+Oglxj+waL5ozkoKlS37hdLtctgPRhrJXEyOKoY6W2zfvV3WbQ PXqk2hu7rKHX2WUcOtZ2Xl1+2TkcDgROJz9Hj3Vj8qgGTbiZHMIOD8PD7ehZVjRBt7Qx5F Z2jaBj8sFTnCSZ8BSEroiRxUDmy4UA+z98s7kpWMa2R8uvV4XtNOe2jCOjPy7HgiKXRsSf k0Ax1AXyLXTm44ZK9ipMRlJFbGoaEzgkrsp0dCy1j4ZBTc45WfEo4rZeecXfUUskqxFjB/ dy9GUTVbJ6IOO2XPGRaEhWwcJVz8uhR/2sqJH22h0AdQ6TtdOnST+1XlmCI5qw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4f1HpM4zY8zrxr; Wed, 28 Jan 2026 10:00:43 +0000 (UTC) (envelope-from brooks@freebsd.org) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id C5A1F3C01A0; Wed, 28 Jan 2026 10:00:42 +0000 (UTC) Date: Wed, 28 Jan 2026 10:00:42 +0000 From: Brooks Davis To: Pouria Mousavizadeh Tehrani Cc: freebsd-current@freebsd.org, madpilot@freebsd.org Subject: Re: we should enable RFC7217 by default Message-ID: References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@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: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> 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 From nobody Wed Jan 28 11:38:02 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 4f1KzL0HB7z6Pn0j for ; Wed, 28 Jan 2026 11:38:38 +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 4f1KzK5cklz3pl9 for ; Wed, 28 Jan 2026 11:38:37 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; none Received: from [IPV6:2001:678:618:402f:3a4b:2b64:b53f:e6a9] ([IPv6:2001:678:618:402f:3a4b:2b64:b53f:e6a9]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.2/8.17.2) with ESMTPSA id 60SBcDBN067704 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 28 Jan 2026 12:38:22 +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=1769600304; bh=Pe9cteaKuMiLHqWa4CYwFNwT3ugyRwZ+kQIuNhQDVPM=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=yCZ0QN3MetL+t3w+mUvAdOIb0NfyTQtA5hFhc4x9zFcKJjkshfY1B930RZSR8W5DU RnSZ0ot8rVkrIGMCODOJi8Ub5gjhlL6Twc2DWDzMvPS0xOmt0/mGh4nBbyIYfmHmkn VohQQ+irc8ngaza3mNxBNF/JHmNJLhqPnGhpj6icf2DibBkx+WQ1WzDcgpRKl6UCwc AGypRI6zyWsr69hOHzi10AHDsht50b10ZUH+qAFcbYezyGYzAnpdRED2Icji83yxpJ gvU7GbLHtfDByQ30wiUoYgTYlMgqYI3X2x27dwigbdThVPAySBUsrZzeG5TyayLoC8 ycHIiBNj/dwdA== Message-ID: Date: Wed, 28 Jan 2026 12:38:02 +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: Brooks Davis Cc: freebsd-current@freebsd.org References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> Content-Language: en-US From: Marek Zarychta In-Reply-To: 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: 4f1KzK5cklz3pl9 W dniu 28.01.2026 o 11:00, Brooks Davis pisze: > 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 > Unfortunately, support for stable privacy (RFC 7217) is not implemented in stable/15, therefore any discussion about introducing this change into 15.1-RELEASE is pointless at the moment. The MFC of stable privacy (RFC 7217) support to stable/15 is under review on the Phabricator. If you support this initiative, please comment on review D54382. Cheers -- Marek Zarychta From nobody Wed Jan 28 11:56:02 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 4f1LMd23rfz6Ppqp for ; Wed, 28 Jan 2026 11:56:13 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4f1LMb0Snkz3rh8; Wed, 28 Jan 2026 11:56:10 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=sGyHlRe9; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 87.255.56.188 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws Received: from smtp-relay-int-backup.realworks.nl (crmpreview3.colo2.realworks.nl [10.2.52.33]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4f1LMQ4z8NzBG; Wed, 28 Jan 2026 12:56:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1769601362; 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=kntlzzzQpjCxWY4v75SaU4bxpMB9Z4h4dMzGJttrr2k=; b=sGyHlRe9okwR5U6od880LhfMyHFnwxfPg4Yjo/cu17xCvIMmMON5GWqyba/nZ4yHMtWs4r 7c5VQIpmHPLBanvcsIJq5WZEvM32gkmkZcrWG2boiDKMIqGC7HKbEPO2NKShfK3tU/lk46 xYNIS6VoiJFK0yWVJVNk0d8jbU+IqSlzMmlWc+i+28sA+36TO2E7+vF9G+mhzaq+VwPmCI lTON66LB0HD/sjrrQbkR22OWTJ2F+50tWSSi9B4uwmoZN73eWwGUU+93nuyUxP4zx93Cw0 +MUonK6mytQY8ZprhUxuru6tXl6hPlyLK4rUxOWTxQl23hgJ9FU6WTYCn9MgFw== Received: from crmpreview3.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview3.colo2.realworks.nl (Postfix) with ESMTP id A58B2140163; Wed, 28 Jan 2026 12:56:02 +0100 (CET) Date: Wed, 28 Jan 2026 12:56:02 +0100 (CET) From: Ronald Klop To: Pouria Mousavizadeh Tehrani Cc: freebsd-current@freebsd.org, madpilot@freebsd.org Message-ID: <1160596598.791.1769601362263@localhost> In-Reply-To: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> Subject: Re: we should enable RFC7217 by default 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: multipart/alternative; boundary="----=_Part_790_1097856801.1769601362202" X-Mailer: Realworks (780.44) X-Originating-Host: from (89-20-164-210.static.ef-service.nl [89.20.164.210]) by crmpreview3.colo2.realworks.nl [10.2.52.33] with HTTP; Wed, 28 Jan 2026 12:56:02 +0100 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:147.0) Gecko/20100101 Firefox/147.0 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; R_SPF_ALLOW(-0.20)[+ip4:87.255.56.128/26]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[klop.ws:+] X-Rspamd-Queue-Id: 4f1LMb0Snkz3rh8 ------=_Part_790_1097856801.1769601362202 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Pouria Mousavizadeh Tehrani Datum: dinsdag, 27 januari 2026 01:05 Aan: freebsd-current@freebsd.org CC: madpilot@freebsd.org Onderwerp: we should enable RFC7217 by default > > 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? > > -- > Pouria > > > > Hi, Totally agree with your proposal. I had a similar change to if_epair in 15.0. https://cgit.freebsd.org/src/commit?id=3a2d4a1017e57f19f5a101da15acbdd861d353ae The sysctl was merged to 14, but the default was kept 0 on that branch. In 16 you can document the change in UPDATING Commit it with "Relnotes: yes" so the change of the default also ends up in the release notes when 16.0 is released. IMHO that is all the effort we can do. And as said earlier by somebody else, if an admin really needs a fixed IPv6 address the user would have configured it differently already or would do proper production testing after a major upgrade. So I think we should not make flipping the default harder than it has to be: UPDATING, Relnotes and maybe an heads-up mail on current. Regards, Ronald. ------=_Part_790_1097856801.1769601362202 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Van: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>
Datum: dinsdag, 27 januari 2026 01:05
Aan: freebsd-current@freebsd.org
CC: madpilot@freebsd.org
Onderwerp: we should enable RFC7217 by default

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?

-- 
Pouria
 


Hi,

Totally agree with your proposal.

I had a similar change to if_epair in 15.0.
https://cgit.freebsd.org/src/commit?id=3a2d4a1017e57f19f5a101da15acbdd861d353ae
The sysctl was merged to 14, but the default was kept 0 on that branch.

In 16 you can document the change in UPDATING Commit it with "Relnotes: yes" so the change of the default also ends up in the release notes when 16.0 is released.

IMHO that is all the effort we can do. And as said earlier by somebody else, if an admin really needs a fixed IPv6 address the user would have configured it differently already or would do proper production testing after a major upgrade. So I think we should not make flipping the default harder than it has to be: UPDATING, Relnotes and maybe an heads-up mail on current.

Regards,
Ronald.
  ------=_Part_790_1097856801.1769601362202-- From nobody Wed Jan 28 17:37:30 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 4f1TxS4cfFz6QSNT for ; Wed, 28 Jan 2026 17:37:32 +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 4f1TxS41bzz3YQr; Wed, 28 Jan 2026 17:37:32 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769621852; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=5aYB1FON3ysNXX8RK+QsILk4gy520/iGWF8VxnJaG70=; b=dBUojs7lKOTquCBY0I6rJTg8Z1JYdBeNHh9wmVuQgIeGrZiJCCexAqJbmWzfIyH65+mrTX eo0mZX1HtDeQR1sT8fAgezoDv4AWDgdH6aDyYb9UcKHp98LhQF8m4c68MYX9UteEj8X4hd O7YKMfBaF1pB2HcWKYMRfr+ujiOd5V+7mztbw9W65+M60sxTWtxtLp8mEzPs7W7wjmGbEx MN+h2NnLzdBjPYEtIU0O+YlAw+VAsGPHy6BIU2tPCxLYKgyv9f7W+pDHkogfguN37nl2Td E3u6+IkBnnkeN0GnbvSVgWXuxbZHPKzmxbteSuwBD0Q8kXnUb+ma8ttJVq16Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769621852; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=5aYB1FON3ysNXX8RK+QsILk4gy520/iGWF8VxnJaG70=; b=E0yqYfClAiTkPhiFqffsLxqRpgYz0uF6KNiDxTbkdn2EOCR1lp5atMi8XhPE3lH8IcjxqA FpV/M3EBXfThQIRJAa12DAZXTQ2oWk4ifr9S7G8JVM+7XJEOp9HR0QIEg/d1eDr1YgKSd6 vy1DBXlL1zI7McOZkGK3JWEbP3p8hkq8HHkAi0ZuH1OdSFFLsIlzPxrX6X+SfR4FTgVfJH YKDuo+o2LE1PMrYd44saJRufiTt2pq3Pb+oXqoTnjePW4rWw7QXrhscD7V3ZfD494qTCcL r607N4axnN7aBNjRoHEvNT/h7NJ6GJVdE1CxkVJP+oXsCVCASl/1oU8rm0fs9A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769621852; a=rsa-sha256; cv=none; b=BHyw8xD+9zgatAD2V446CEMUu05lIjIJGUHPi6XGwjHyTy+KqPZ6FkFk0xT11gmJv/Zgqa cUsjpP04FIrrefV1Z5VeX+K3PUtLfLhgBh7a39KD+/2h3gaNJ5PiCWMlVZcJOx7xyYvywg 5RRkCu9BYd38ag75AdIlKoPRh0AnGcDsruns9HNe0KN0ojCvC37Z1ktHerszGo5i58ipZw K5Cq7maAKj/Iz7grSydGSwvm/mftSwdrAf2iuT1j6loF0PlBJvsWv5owe6ueNNfQ8rN8Er QZppBf/XgvOhacXv07n+iSfwo151DyCj8hTBcu0JDLwMGTwratwycer6KqNCpw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [IPV6:2a01:e11:2002:4280::13:1] (unknown [IPv6:2a01:e11:2002:4280::13:1]) (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 4f1TxS07T2z12lJ; Wed, 28 Jan 2026 17:37:31 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <80344ea0-02fb-486c-817a-6c69094d8655@FreeBSD.org> Date: Wed, 28 Jan 2026 18:37:30 +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: Pouria Mousavizadeh Tehrani , =?UTF-8?Q?Olivier_Cochard-Labb=C3=A9?= Cc: freebsd-current@freebsd.org References: <9cda2fbc-b8fb-44d1-8c1f-88395d741af7@FreeBSD.org> <4a83b581-1960-48b5-a589-ee47d85e8f18@FreeBSD.org> Content-Language: en-US, it, en-GB 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: <4a83b581-1960-48b5-a589-ee47d85e8f18@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/27/26 22:15, Pouria Mousavizadeh Tehrani wrote: > On 1/27/26 4:56 PM, Olivier Cochard-Labbé wrote: >> In a server environment, administrators typically assign static IPv6 >> addresses manually and do not use the EUI-64 method. > To add a note, administrators usually avoid *using* EUI-64 addresses for > production, especially for their DNS records. > However, they often have an EUI-64 address because having default routes > and other parameters automatically configured by accept_rtadv is > convenient. > That's why I believe there will be an impact on servers. however, as you > said, it's not an issue here. > > At least, we use accept_rtadv in our production AND people typically > configure their rtadvd with the autonomous bit. So this results in > having EUI-64 addresses on the servers, which may be used in source > selection. > > I would like to kindly request @madpilot to create this patch for > review, including a note in the UPDATING file, if everyone is in agreement. > I will create a review with this changes soon. But at present my priority is getting the feature MFCed to stable/15 -- Guido Falsi From nobody Wed Jan 28 20:49:26 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 4f1ZBx6Rgxz6PYH6; Wed, 28 Jan 2026 20:49:29 +0000 (UTC) (envelope-from glebius@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 4f1ZBx5rT6z44Ft; Wed, 28 Jan 2026 20:49:29 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769633369; 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=R6MTVNN5trDSnBUA20+QgD6JkZweKly/NA4EzXFEYhE=; b=rxApiejOqLGW9q9m2LcfN8uKIgM8S394/w+8QrFhR9kTZV3GOuIWhF9EkJ5j1QHsRSkzQN 2dk62Bg+TrF6mggQzs+na7O+kQ/ejavMCLGwQg76UF35W3yN5l9fOD8bj1M57KLFF6YRHN pNA+KwpHCynHZYwka5K2OCQ1V2tOUCNj9lW5/uSoFaqyZlVQvz3JALGcbplJp2QdmbkKDG FZ7Ds2VtiTh8+Z7NF8HHMwRwNZBOKurlgmPUKzdaEBJpssI4WZwqHNXdGyl7FdSOZsrYkK pEChpIIdf6cAEL6UDbzCWKOhnMADczbGdzBzRNohxwJPwcKIKzoGpOQAeXAYog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1769633369; 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=R6MTVNN5trDSnBUA20+QgD6JkZweKly/NA4EzXFEYhE=; b=LyuuWIcimEkWPwEFeIXNUM3OWGmglFnnWUVn6NS/1RYyxODd4o/xxwkFyhHMcmimSOPVcL qT7/SY7gcF1NlARDKciI0AyX4oC8CZiVtJhVJuHBe/FrfcAledmY26CO6KxoGuBcINFWSt xjn+lO24ytiBI5XF7Wgd6ozzqeDvu1SjIY48564oHm3qX5u60xjz90QgrJbSyfrJP/X5CJ cfwAxq0qmp0F9zla+tg/siCHgTD9P9WSCfNs95gt48Cah5L9eo23bcDTGZRR5VGBGJTyoD pr3GretA8XhrFq3J+8+DLhlY7Az9ZY4ZrAj2CBkPfpxlGNoMDhan5mO6g3bEsA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1769633369; a=rsa-sha256; cv=none; b=HlDabljCYSjw+FlaQ/dwErRwEGwm23Z3KSAlUuxeUwulqDNO3USI14KikGjPNESdURgFKn Lc46Lgs2lNO+aZJfE5wqpy2Jtg7zGaK0Spk0hDDMPcH/ceTTdSGxE1gPCoFiS1oDyGREWO rOyWbZHKgYpiN5eQn3OwLv33pIpf5dr1yHSGHkKs9aON2izazeP9rf1Hkx/SPmZdDM8XaP 0ToplOOrtNKDIDzApk4xkHrsnxYpIoaMnDcsUiVd+D2LC8h9Ioh8zLIzCyJhO1ybAieSV7 4r2D0r1pYlKcstLyvLFHaR10CkxBUcp4/ZmhSy605pojf09hcVdkPsThqeMxSg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4f1ZBx2D02z16Nn; Wed, 28 Jan 2026 20:49:29 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Wed, 28 Jan 2026 12:49:26 -0800 From: Gleb Smirnoff To: freebsd-current@freebsd.org, src-committers@freebsd.org Cc: ShengYi Hung Subject: Re: January 2026 stabilization week Message-ID: References: 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: On Mon, Jan 26, 2026 at 01:00:25AM -0800, Gleb Smirnoff wrote: T> This is an automated email to inform you that the January 2026 stabilization week T> started with FreeBSD/main at main-n283376-8ef8c6abfadf, which was tagged as T> main-stabweek-2026-Jan. The snapshot underwent A/B performance testing at Netflix and several people upgraded their laptops, desktops and home routers. Following problems were identified in this snapshot: 1) INVARIANTSs panic when using ipfw(4) dynamic rules. ipfw(4) users are recommended to cherry-pick d8a78048a246 and 29c3350f395a. 2) The AMD CPPC switched on by default instead of Cool`n'Quiet caused problems on certain hardware. For laptops see bug 292615. At Netflix A/B test we discovered that CPPC mode reports wrong frequency levels to powerd, which results in reduced performance. This problem is still not resolved. 3) Panic in vm_map code: https://people.freebsd.org/~novel/misc/core20260128.txt Note that this was discovered on pre-stabweek CURRENT. Only Roman seen this panic and there's no reproduce yet, so unresolved. The advisory code freeze is over. -- Gleb Smirnoff From nobody Wed Jan 28 21:16:47 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 4f1Zpl1DDwz6Pbfh; Wed, 28 Jan 2026 21:17:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4f1Zpk3zRwz48Wm; Wed, 28 Jan 2026 21:17:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 60SLGlpD015095; Wed, 28 Jan 2026 23:16:50 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 60SLGlpD015095 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 60SLGl1u015094; Wed, 28 Jan 2026 23:16:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 28 Jan 2026 23:16:47 +0200 From: Konstantin Belousov To: Gleb Smirnoff Cc: freebsd-current@freebsd.org, src-committers@freebsd.org Subject: Re: January 2026 stabilization week Message-ID: References: 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: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.2 X-Spam-Checker-Version: SpamAssassin 4.0.2 (2025-08-27) on tom.home X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4f1Zpk3zRwz48Wm On Wed, Jan 28, 2026 at 12:49:26PM -0800, Gleb Smirnoff wrote: > 3) Panic in vm_map code: https://people.freebsd.org/~novel/misc/core20260128.txt > Note that this was discovered on pre-stabweek CURRENT. Only Roman seen this > panic and there's no reproduce yet, so unresolved. > The panic string, as I understand, is panic: object 0xfffff80c49a4f8b8 charge < 0 This code was removed by d160447129fe060b28. And I cannot find rev e8141c80ab93 in our repo. From nobody Wed Jan 28 21:52:56 2026 X-Original-To: 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 4f1bcX526bz6Pfcr for ; Wed, 28 Jan 2026 21:53:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4f1bcW0h1Mz4GV4 for ; Wed, 28 Jan 2026 21:53:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=J7cK9mFw; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::432) smtp.mailfrom=wlosh@bsdimp.com; arc=pass ("google.com:s=arc-20240605:i=1") Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-82361bcbd8fso167111b3a.0 for ; Wed, 28 Jan 2026 13:53:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1769637189; cv=none; d=google.com; s=arc-20240605; b=Yg4UudcEocfjgxFA5wj6x+Q32txUs6GjdoTsYbofVQyFWvE8NiTXU43lP4aBRGtmBj k0jqUONw5YtVL9WG9BHiR+K7yctRk5/1iqav7Oeep0cfy13lOLGcuAFrfmH4K41ryoUF AW7EG4e15KPxNfS6P3M7ka2LwvCKodRrFRUmnW7gfzUAIViYWyzhdg9ptKHoeNTCcaD5 rzK6ghDgiVJzPnDuMzgxNDZXCh5xtzzmDDybuAaviBDQYcMzEiF+ekpMLTVpcq3eRuCV zGpmKD6suykXr6uNGhpafUsU9WZeKW6Evp0BNeDHxPoh2V1WCPgp6SksT6ZBDpil8GzE E5nA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=cSVV5V/T8bQKaU6NZHurw+e6d9mal3+Kmyi9G1qz3Hw=; fh=ikQNRbMg1TdKSfXXjdyc3G+L0xJbh8kPoLoAiKDdoyE=; b=EQjF6bAKI+W3W83pzMZ7eE2NyS6ApVMno+/ZYH0Y0x6umSUjRGgTD6trZ3/2gXWAOe xBpYG5+0W2SMi1Afn91993hRrIzKwqV8nW986iJ/pnoDrM6ZWVOLAVuquQ0iLpID7aIf kF1B0UXAWESlxBdgF0AKjZER5LtlTMprStfLpx6A5kWxIE+neqVQ3G/s8Qw6nVlGNKnF S30OZd59Hb+LOMyrN1o7tKmj89jU37M+0yRTGoIvLPns5C1l+KMhrv7MXkg1P96C9n/W p/TJ6NpO8SItOFYOQAkFw5tnvq0/hj0Sv7rGoNtGcsybMWb1YanHccdFktzbxbiVc/Fn 88Fg==; darn=freebsd.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1769637189; x=1770241989; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cSVV5V/T8bQKaU6NZHurw+e6d9mal3+Kmyi9G1qz3Hw=; b=J7cK9mFwJHWlXiyD8ueMgXtFVoW4AgchV1VkX70vZELT14WeHgiI9GYGUexFhtdcjV YuGrHzF4ZJXJLRoFgeCCbf8imv3iwen7CWIMpkrwJVsxYyf8/8CHMEs/JHdjv+2BxLGA YA7GmFYmNIgJTxHccAGLQPsUc+LLbtULRnuWquTBXrJ/WbltFZT9tTP07257yw5vnJ/x BZW+VjtEZyZkDyhjvxrGSTfId1jQTsdq6jcEHqasm1mo4xTxw1yPRbHv2GiYw/8TnBx8 KgALp1jhQ7TfD/k++ysAtbLp6W7tbPw0Lj0UJfVPIPvNaHoiIDod2kbZGr+SktWyKjp1 MgjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769637189; x=1770241989; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cSVV5V/T8bQKaU6NZHurw+e6d9mal3+Kmyi9G1qz3Hw=; b=joc99L4WIwHa0vNFWGR92kSTezayOnewXiYN9lGdkHNFMtS02xf4L6qiYRdealxp0C 74zsJdn2hNxB295zff92+xdkTFfM5cYOv19KRVAQboLLiVUYs9XJBZKD0KR/27dBBAU0 J5Y+kyG/W4yOpDbiMPQzdZg/WDeCoI/ddFOA8Oqo1TFqgfyks5IbHIUErn58hQizcLna AZzv0kL5GG0MzbcqK3OCKG9fH56PTc8kIa9o1xnxW6J6Gyu3xN8IbpLYRe/dLDqMpNOW 1pzlMNYhJFUKpJjdBMzNoiTWKq1PfhGJntR4t7ucvictQtPZSF480Ov/CYNKLsfaT8iS jb9g== X-Gm-Message-State: AOJu0YzNuBZbAqNB/iQqFRSiaP7dwD2EMCJkDDbA1t37q4EAeuh0Ga5j Zm5tz5oe7sXQ7VwmrsKSWJBz9gvIHeqAltxa6Ip+JRne3w8VSY//e17MQYPBgh6c0kMRsOzI4it V/7lUZYrTgN0/Q3fZcBQboW/D+QBcu/gJkMZWGo23utN/h7FR0IyX X-Gm-Gg: AZuq6aJcSmADozIauijeiacdE0UArHcUHSc4oUHeiDHfXSHxtgfoqBX17Ow7YuH4fGE FAy6XJCrwKjnQsm9B243TIFQ76fXI3+t4fs++nzI38zQ21WMxUSYj+A/GLM7piW0zQeDiUZfL5E AvLkWvKa1TIXsymQO+230asCBuNlQPpQSkQRO8r4qKc0OlcDmqHzA6JuiPrLdtXRwrOffxsytI7 3XHXSTdSkKagVI5g3HoNHtaFEVyr/hmWCRwgSe3174YmNSiADPMYR08tHWij1M4+es3fNg= X-Received: by 2002:a17:90b:2d83:b0:34c:6124:3616 with SMTP id 98e67ed59e1d1-353fed87b05mr6000702a91.27.1769637188831; Wed, 28 Jan 2026 13:53:08 -0800 (PST) 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 References: <202601270815.60R8FMHK006897@critter.freebsd.dk> In-Reply-To: <202601270815.60R8FMHK006897@critter.freebsd.dk> From: Warner Losh Date: Wed, 28 Jan 2026 14:52:56 -0700 X-Gm-Features: AZwV_QhVi6jQ2yMdjSGzcMUd-Mro5mTpZmL-M5k4itrnkZgzwbt48FEyj_CILSg Message-ID: Subject: Re: cam_da too noisy about SYNCHRONIZE CACHE To: Poul-Henning Kamp Cc: current@freebsd.org Content-Type: multipart/alternative; boundary="000000000000059b07064979c47c" X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_ALLOW(-1.00)[google.com:s=arc-20240605:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::432:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; MISSING_XM_UA(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4f1bcW0h1Mz4GV4 --000000000000059b07064979c47c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 27, 2026 at 1:15=E2=80=AFAM Poul-Henning Kamp wrote: > I have a Rpi3B which runs 15.0 on a Seagate USB-SATA gadget. > > Every few hours usually around XX:X0:30 it spits out: > > Jan 27 00:40:30 rpi3b kernel: (da0:umass-sim0:0:0:0): MODE SENSE > for CACHE page command failed. > Jan 27 00:40:30 rpi3b kernel: (da0:umass-sim0:0:0:0): Mode page 8 > missing, disabling SYNCHRONIZE CACHE > Jan 27 00:40:30 rpi3b kernel: (da0:umass-sim0:0:0:0): Devices > already quirked for NO_SYNC_CACHE, maybe remove quirk table > > The relevant code in cam_da is: > > if (mark_bad) { > bad: > xpt_print(done_ccb->ccb_h.path, > "Mode page 8 missing, disabling > SYNCHRONIZE CACHE\n"); > if (softc->quirks & DA_Q_NO_SYNC_CACHE) > xpt_print(done_ccb->ccb_h.path, > "Devices already quirked for NO_SYNC_CACHE, maybe remove quir= k > table\n"); > softc->quirks |=3D DA_Q_NO_SYNC_CACHE; > softc->disk->d_flags &=3D > ~DISKFLAG_CANFLUSHCACHE; > } > > I can understand emitting the message the first time after a reboot, but > that program logic makes absolutely no sense to me ? > That should have all been behind bootverbose. My bad for letting it linger for so long. I added this verbosity when I was worried about people complaining that I broke their drive. I fixed it too well: They've only complained about the messages... Warner --000000000000059b07064979c47c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 27,= 2026 at 1:15=E2=80=AFAM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
I have a Rpi3B which runs 15.0 on a Seagate USB= -SATA gadget.

Every few hours usually around XX:X0:30 it spits out:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jan 27 00:40:30 rpi3b kernel: (da0:umass-sim0:0= :0:0): MODE SENSE for CACHE page command failed.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jan 27 00:40:30 rpi3b kernel: (da0:umass-sim0:0= :0:0): Mode page 8 missing, disabling SYNCHRONIZE CACHE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jan 27 00:40:30 rpi3b kernel: (da0:umass-sim0:0= :0:0): Devices already quirked for NO_SYNC_CACHE, maybe remove quirk table<= br>
The relevant code in cam_da is:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 if (mark_bad) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bad:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xpt_print(done_ccb->ccb_h.path, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Mode page 8 miss= ing, disabling SYNCHRONIZE CACHE\n");
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (softc->quirks & DA_Q_NO_S= YNC_CACHE)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xpt_prin= t(done_ccb->ccb_h.path,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Devices already quirked for= NO_SYNC_CACHE, maybe remove quirk table\n");
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 softc->quirks |=3D DA_Q_NO_SYNC_C= ACHE;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 softc->disk->d_flags &=3D = ~DISKFLAG_CANFLUSHCACHE;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 }

I can understand emitting the message the first time after a reboot, but that program logic makes absolutely no sense to me ?
<= br>
That should have all been behind bootverbose. My bad for lett= ing it linger for so long. I added this verbosity when I was worried about = people complaining that I broke their drive. I fixed it too well: They'= ve only complained about the messages...

Warner=C2= =A0
--000000000000059b07064979c47c--