From nobody Fri Sep 5 23:17:11 2025 X-Original-To: dev-commits-src-main@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 4cJXLN2LPMz66Y8j; Fri, 05 Sep 2025 23:17:16 +0000 (UTC) (envelope-from bz@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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cJXLN1Ry4z3xvN; Fri, 05 Sep 2025 23:17:16 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757114236; 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=rkaxw/EzKNrNh0q3FYjzMys7aaVu/42ci/ANk6bijZI=; b=kFs/7kV7Q524wdbIPu9aymo4Flt2aBbX5H8lkUqDWFazDLXrHhbRGHJtuJKmaynRBTGr3O hkWi1Gl1v029AdvVGmMzLXoI+Id6VPCblhUkfkoJaD8lCcL0fzZSbht7yiKLuNJ5BVsCYM X/Z6XCJ8QEhHEB39K7s7jzTWwMNh2pVjO1Z5greeJiSKI7IPNZ8s600ZmbX6q7FGBQg4Bk 75zWmhFJXKr0A+UCE3Hh4r1KPO2I5SRR+R0T0tF8FzxXflSCXxpdx2yqReRSkt80FZE/0f w86nwRbAbWGjHU5tVYqo0PgjPNaG08OAVjfr2r7QjWZKeE9Q+yPk1w8f//jvpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757114236; 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=rkaxw/EzKNrNh0q3FYjzMys7aaVu/42ci/ANk6bijZI=; b=FGxt5qoMz6Yx52zBEnXhjhLI6ST9mpde8cSjZOhuozxfZ3WLy23cWo/ZgAoG8K07r1//dd /iBJUMDiTs4yGDwYp+xALzFX7r2asX77afU3Hd9pHybLh2fptnvaUFnMd2R7ZpsTz6c0QI fqvmnGWIPl6laNZTI4jlS87bT/tBU9wif9C/f0Qdq4D/y6Zi37UkaUmQl75oh+cTVnDQae DSWZ5EuKpUKdPz+Bibgn0vJr6rB8BwxCeAg3wWABVsVJEi0JzmRRC9yDAkS19SN/eFDR7s /jpyOEJXmKChVBTWrfjCFOyuDzOCc/kQGDNcyOSqRVgoQLTEFlZvPUvkCO0X7Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1757114236; a=rsa-sha256; cv=none; b=OPvQ2ORPVOW+b4WFTWvVZlvvlo3IpTyugC3APVVxWJEZnPnOcfvcjYWYcEe4fY0NjgM0LZ BnFwhznv6n6i49j1CMkEYmOBMuqHbPXiFPOD/CY/3B82/kh17Xn4PZVYyZ1qd4usL2cka8 NqzZSUGYtC0Ik/3222OUvIg0aQO5coN2fahiNQRAVSa9ZhhLukwhndL4IldnR7ripzHBao IlHTXgFYvKV3PetpqAKXtYxofJIRTC5q6sOT3L/4iWVu6wXxQO7TBKpTTbTZQhpaRWxpWF pEDln0aQAl9caVtUXiHMnCDiN4tvgVotPW/A4kpPW+FuLTxYmOJMCPiPV5mPSw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19]) (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 "mx-01.divo.sbone.de", Issuer "E6" (verified OK)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cJXLM5NdDz1CSt; Fri, 05 Sep 2025 23:17:15 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx-01.divo.sbone.de (Postfix) with ESMTPS id 54E42A64805; Fri, 05 Sep 2025 23:17:05 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 0EF8C2D029E3; Fri, 5 Sep 2025 23:17:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id Ml97G5KF7cr9; Fri, 5 Sep 2025 23:17:11 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:a66b:b6ff:fe40:39a9]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id AA3FB2D029D8; Fri, 5 Sep 2025 23:17:11 +0000 (UTC) Date: Fri, 5 Sep 2025 23:17:11 +0000 (UTC) From: "Bjoern A. Zeeb" To: Kristof Provost , Reid Linnemann cc: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: Re: git: 9e792f7ef729 - main - sys/netinet6: Fix SLAAC for interfaces with no /64 LL address In-Reply-To: <202509052153.585LrUjo056473@gitrepo.freebsd.org> Message-ID: <8rq4s287-pq47-58no-9r1o-p3o7659s0n60@SerrOFQ.bet> References: <202509052153.585LrUjo056473@gitrepo.freebsd.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII On Fri, 5 Sep 2025, Kristof Provost wrote: Hi, > The branch main has been updated by kp: > > URL: https://cgit.FreeBSD.org/src/commit/?id=9e792f7ef7298080c058fbc2d36a4e60e596dae9 > > commit 9e792f7ef7298080c058fbc2d36a4e60e596dae9 > Author: Reid Linnemann > AuthorDate: 2025-09-05 19:57:44 +0000 > Commit: Kristof Provost > CommitDate: 2025-09-05 21:48:48 +0000 > > sys/netinet6: Fix SLAAC for interfaces with no /64 LL address > > in6_ifadd() asserts that an interface has an existing LL address with a /64 > prefix from which to extract the ifid for SLAAC address selection (even though > the comments suggest that an ifid will be generated if one does not exist). This > is adequate for most generic cases, however to support PPP links with /128 LL > addresses we must be able to fall back on another source for the ifid since we > cannot assume the /128 LL has a unique ifid in the lower 64 bits. Excuse my ignorance but where do you have a IPv6 LL/128 on a PPP link? I am totally suprised given this hasn't been a problem in about 25 years and I wonder what software this is or what got broken where? Okay, I scrolled through the review. I see I am the third person asking the same question as the intial intuitive reply. I was intiially tempted to say 'please back this out' but see the end. For (1) do not start applying IPv4 to IPv6 just because. It's not just a different number, it is also different concepts. People said this 20 years ago and still do. (2) Both of you talk about PPPoE in the review which tells me something got wrong as that is a totally different protocol and has nothing to do with IIDs. Selecting an appropriate LL for IPV6CP can be done entirely in user space for protocol negotiations. And to my memory we have no IPV6CP implementation in the kernel to require anything different. I don't know what the mentioned if_pppoe.ko is but if this is a convoluted implenentation in-kernel incl. protocol negotiations then I am tempted to say you are off on your own with that, especially if you want to do things differently. Looking what Linux is doing is not always the best source of truth. Please follow what the IPV6CP RFC (got updated since I last implemented it 20-something years ago I have to admit) says and you end up with a /64 LL on the interface and your problem is solved. Your negotiated LOCAL_LL (fe80::LOCAL_IID/64) address goes onto the IF: IF: flags=1008051 metric 0 mtu 1492 options=80000 inet ... inet6 LOCAL_LL%IF prefixlen 64 scopeid 0x inet6 ... nd6 options=122 You get an entry in the routing table: fe80::%IF/64 link#11 US IF and possibly a default REMOTE_LL%IF UGS IF if you decide to install a default route. Other routes I would assume are installed on the link but I assume you could chose the REMOTE_LL%IF as well if you wanted to complicate things. So I crystal-ball that your real problem could have been stated that you may need to get the IID for IPV6CP negotiations in-kernel? If that is not the case, then I am still lost as-to what you are trying to accomplish. But then you'd still never need the /128. So maybe I am just lsot. .. > To do this, the static function get_ifid() in in6_ifattach.c is renamed to > non-static in6_get_ifid(), and this is used in lieu of a proper /64 LL address > to attempt to obtain a valid ifid. .. Now we can start arguing if we forget most of the explanation about PPP[not oE], if it makes sense to keep this? But then we should fix style, avoid unneeded initializations, etc. which should have been caught in proper review in first place. I assume the entire thing up there and in review distracted from the actual case more than it was good for. Sadly the commit message also kept carrying that forward. So the change is probably right, the description is not? If I am guessing right, are you going to fix style, etc.? Might want a test case for the extra condition added which I have not cross-checked yet either for all possible cases? ... > Reviewed by kp > Sponsored by: Rubicon Communications, LLC ("Netgate") > Differential Revision: https://reviews.freebsd.org/D51778 > --- > sys/netinet6/in6_ifattach.c | 7 +++--- > sys/netinet6/in6_ifattach.h | 1 + > sys/netinet6/nd6_rtr.c | 54 ++++++++++++++++++++++++++++++++------------- > 3 files changed, 43 insertions(+), 19 deletions(-) -- Bjoern A. Zeeb r15:7