From nobody Mon Apr 21 10:16:04 2025 X-Original-To: freebsd-net@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 4Zh1VN16xyz5tHJj for ; Mon, 21 Apr 2025 10:16:12 +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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Zh1VM4smPz3SqM; Mon, 21 Apr 2025 10:16:11 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745230571; 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=rH3AIuuhVAsWnxMMeFItGWQBO5moTYaY8FUwIIM83I4=; b=PNfuswg8DXItL3OennB5gD6THOVQgw7sper1F3450wjdTzIh4B/ZVN0J22Jy1wHU897ppJ QdDjNQ8JPasCfcQp4+a9n4yhj5gom2ejq7VYv8Uq0zKpHG9TmYxGlTzktq8TMU3eIAJQ7/ rZanfHv9n/IZOKYQpwfojwaRB9z4Hc5kzb0WC43GlimbjYmuR8DI0xnLpPpZ0hl2bZ7/C6 zYrk3BGzO8ESnDPrlN1GRda2uqYRhITOJOh2LYsybVeH4NftSBSzCvbbHLsfTXMewq+25a wQ6y1sZ7Gz7ynDDHQ+BSvL2uFjGH8lmTfeIlMvf00d7xRlT66Lh5U8MV4zsj6w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1745230571; a=rsa-sha256; cv=none; b=Jh5+IwIxn8KAFBS7klIIYdiuqNn/C+LteA8+G9Q1AQBRVIEYcjtNcXP88Y1ijlxPJv5KCc 28DbTaKC8aUNvtvdVp7G1o/CyD4TcU6UqKYohdG6MbIs3PkN1cRis7ZxmZRVg/32qLaa/+ 1m6mNeqdM9ny2cCk+95/FLNpYfnB/DnblQ34EaWCynj1MfCXgcmaUbtCaFDSKopWBYFaHo ownWGsawYJ7sxLc51UcPRB4uR3chJOtadATzZHH1D6EoNFUkogxmdp46uSQ5L0DqYA18bb xDw2xXP27J43NBcyfhXGo6Qb9K+sk3pzigF6y2gc852ckF8ZYXikOBizxkRylw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1745230571; 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=rH3AIuuhVAsWnxMMeFItGWQBO5moTYaY8FUwIIM83I4=; b=oTc0epJ0QL4AH2J6dgusxXutb8CIizih9fZdkMcuTjSKIfxWyOKjrP9482RCaliUTJE4mD eYKkaO459ezr6kuf004+YkoJUY5L3QfDnXMA5EjcMAOdP778j/USvr4diCYJxicguZO+S3 heN9mdY5dyi3oVWcjrMdv/WFkcaLUEbLKfgEuzNueEpnCeZ0sq4WNkDqXIGetDouG3yaSk 2cQiAlWEORpcDNXPQ758fsMGtBtQ9kkZHbddrvDgU9UUpt/f+EVslsF7YDnkTDnvRpL3O5 QtXSC2FaxCHRTT7dPRfzrWkLZqet8uiDyMSwzgMLNJmvhJEBLZgM6XSGOVi2Dg== Received: from smtpclient.apple (ns1.oxydns.net [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 4Zh1VL2C8hzFlW; Mon, 21 Apr 2025 10:16:09 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <84990CAF-2E38-4BFB-A4C3-88B604C5DC6C@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_9EE07377-5F8D-4D1F-BEA7-C2EB63DAF41D" List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: FIBs with IPv6 Date: Mon, 21 Apr 2025 18:16:04 +0800 In-Reply-To: Cc: freebsd-net@freebsd.org To: Paige Thompson References: <83cc7ce5-70b6-4578-8e1a-f5ee04f2c7b9@me.com> X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_9EE07377-5F8D-4D1F-BEA7-C2EB63DAF41D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 20, 2025, at 7:51 AM, Paige Thompson wrote: >=20 > I forgot to mention the post I was referring to on the forums:=20 >=20 > https://forums.freebsd.org/threads/fibs-with-ipv6.95984/ = I did a quick overview about the HE tunnel setup mentioned in the forum, = and I think that is wrong. >=20 >> On Apr 19, 2025, at 7:36 PM, Paige Thompson wrote: >>=20 >>=20 >> Hey yall,=20 >>=20 >> I came across a thread today on the forum regarding an issue with = trying to get IPv6 to work on something like a epair interface, I'm = having the same issue myself when one end of the epair is assigned to a = FIB that differs from the other. I replied to this thread, but it's = pending mod.=20 NDP do not need to consult the fib to work correctly IIRC. >>=20 >> In any case I glossed over the tests of this in = /usr/src/tests/sys/netinet6/ndp.sh and proxy_ndp.sh but nothing about = them would lead me to believe that they're also testing with a FIB, = nothing in the man page would lead me to believe that FIBs have ever = been considered with regards to NDP either.=20 >>=20 >> IPv4 works fine, I can assign a /31 to both ends of the epair with = one interface using a different FIB from the other and both are able to = reach each other end to end, and also looking at a packet dump seemed to = confirm that with IPv4 ARP is working correctly.=20 >>=20 >> I thought I was going crazy for a minute because I remember this = exact configuration (or something nearly identical at least) worked for = me on OpenBSD. Linux is another story but as I recall if you don't = factor in the problems that netfilter adds (like trying to use ct_zones = as an after thought for coalescing the identity of a VRF from fwmark) I = recall this at least worked as one would expect.=20 >>=20 >> I don't really see anything in the git log about FIB for NDP, thing = is I can probably create a static NDP entry and make this work, will = have to try later but I'm just wondering if maybe this just got = overlooked. setfib would seem to be older than NDP but I don't know... = looking at ndp.c I'm very unfamiliar with it but it does look like it's = querying routing tables at certain points. I'll try turning on = debugverbose later and see if anything comes up but I just wanted to = mention this just in case this stands out to anybody. By implementation, setfib(1) set the fib number to current thread ( = context ). Commonly used network utils such as netstat(1) and route(8) = have already support querying / operating on different fibs. So no need = to `setfib N netstat ...` . >>=20 >>=20 >> Thanks >> -Paige >=20 >=20 Best regards, Zhenlei --Apple-Mail=_9EE07377-5F8D-4D1F-BEA7-C2EB63DAF41D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 20, 2025, at 7:51 AM, Paige Thompson <paige@paige.bio> = wrote:

I forgot to = mention the post I was referring to on the forums:

https://forums.freebsd.org/threads/fibs-with-ipv6.95984/

I did a = quick overview about the HE tunnel setup mentioned in the forum, and I = think that is wrong.


On Apr 19, 2025, at 7:36 PM, Paige Thompson <paige@paige.bio> = wrote:


Hey yall,

I came across a thread today on the = forum=20 regarding an issue with trying to get IPv6 to work on something like a=20= epair interface, I'm having the same issue myself when one end of the=20 epair is assigned to a FIB that differs from the other. I replied to=20 this thread, but it's pending mod.
<= div>
NDP do not need to consult the fib to work = correctly IIRC.


In any case I glossed = over=20 the tests of this in /usr/src/tests/sys/netinet6/ndp.sh and proxy_ndp.sh but nothing about them would lead me to believe that they're also=20 testing with a FIB, nothing in the man page would lead me to believe=20 that FIBs have ever been considered with regards to NDP either.

IPv4= works fine, I can assign a /31 to both ends of the epair with one=20 interface using a different FIB from the other and both are able to=20 reach each other end to end, and also looking at a packet dump seemed to confirm that with IPv4 ARP is working correctly.

I = thought I=20 was going crazy for a minute because I remember this exact configuration (or something nearly identical at least) worked for me on OpenBSD.=20 Linux is another story but as I recall if you don't factor in the=20 problems that netfilter adds (like trying to use ct_zones as an after=20 thought for coalescing the identity of a VRF from fwmark) I recall this=20= at least worked as one would expect.

I don't really see = anything in the git log about FIB for NDP, thing is I can probably create a=20 static NDP entry and make this work, will have to try later but I'm just wondering if maybe this just got overlooked. setfib would seem to be=20 older than NDP but I don't know... looking at ndp.c I'm very unfamiliar=20= with it but it does look like it's querying routing tables at certain=20 points. I'll try turning on debugverbose later and see if anything comes up but I just wanted to mention this just in case this stands out to=20 = anybody.

By implementation, setfib(1) set the fib number to current = thread ( context ). Commonly used network utils such = as netstat(1) and route(8) = have already support querying / operating on different fibs. So no need = to `setfib N netstat ...` .



Thanks
-Paige


Best regards,
Zhenlei

= --Apple-Mail=_9EE07377-5F8D-4D1F-BEA7-C2EB63DAF41D--