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--