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