Date: Fri, 5 Sep 2025 23:17:11 +0000 (UTC) From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: Kristof Provost <kp@FreeBSD.org>, Reid Linnemann <rlinnemann@netgate.com> 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 Message-ID: <8rq4s287-pq47-58no-9r1o-p3o7659s0n60@SerrOFQ.bet> In-Reply-To: <202509052153.585LrUjo056473@gitrepo.freebsd.org> References: <202509052153.585LrUjo056473@gitrepo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <rlinnemann@netgate.com> > AuthorDate: 2025-09-05 19:57:44 +0000 > Commit: Kristof Provost <kp@FreeBSD.org> > 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<UP,POINTOPOINT,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 1492 options=80000<LINKSTATE> inet ... inet6 LOCAL_LL%IF prefixlen 64 scopeid 0x<n> inet6 ... nd6 options=122<ACCEPT_RTADV,AUTO_LINKLOCAL,NO_DAD> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8rq4s287-pq47-58no-9r1o-p3o7659s0n60>