Re: [PATCH v3 2/8] util, flow, pif: Simplify sock_l4_sa() interface

On Tue, 18 Nov 2025 14:34:58 +1100 David Gibson wrote:

On Tue, Nov 18, 2025 at 01:19:21AM +0100, Stefano Brivio wrote:

...

On Fri, 14 Nov 2025 10:21:46 +1100 David Gibson wrote:

...

On Thu, Nov 13, 2025 at 07:33:13AM +0100, Stefano Brivio wrote:

...

On Wed, 29 Oct 2025 17:26:22 +1100 David Gibson wrote:

...

sock_l4_sa() has a somewhat confusing 'v6only' option controlling whether to set the IPV6_V6ONLY socket option. Usually it's set when the given address is IPv6, but not when we want to create a dual stack listening socket. The latter only makes sense when the address is :: however.

Clarify this by only keeping the v6only option in an internal helper sock_l4_(). External users will call either sock_l4() which always creates a socket bound to a specific IP version, or sock_l4_dualstack() which creates a dual stack socket, but takes only a port not an address.

I'm not sure if we'll ever need anything different, but I guess that this is not the only obvious semantic of sock_l4_dualstack(), as it could take a sockaddr_inany eventually, and bind() IPv6 address and its v4-mapped equivalent (...does that even work?).

Do you mean that if we have a v4-mapped address, then using an IPv6 "dual stack" socket will listen both for IPv4 traffic and for IPv6 traffic actually using that v4-mapped address on the wire (presumably as a result of a router translating to a local IPv6-only network)? I think that will work, though I haven't tested.

Yes, that's what I meant.

...

In that case we can determine that we need IPV6_V6ONLY from the address. The only case that doesn't cover is if we want to listen for v4-mapped traffic already translated by a router but *not* native IPv4 traffic. I don't see a lot of reason to ever do that, so it's in the "refactor if we ever discover we need it" pile.

I thought that we might want to listen on both IP versions for whatever reason, on a single socket, with a specific address (say, that v4-mapped address and the equivalent untranslated address...?).

I'm not really sure what you mean by an "equivalent untranslated address". AFAIK, the only non-wildcard case that will actually listen on both IP versions is a v4-mapped address.

I mean 192.0.2.1 (untranslated, IPv4) and ::ffff:192.0.2.1 (v4-mapped). Will we ever want to listen to both? I don't think we have to care about that right now, though.

So, yes we probably should explicitly set IPV6_V6ONLY==0 for v4-mapped addresses as well.

...

I know it can't be done now anyway, I'm just saying that sock_l4_dualstack() forcing wildcard addresses isn't something we should imply as part of "dualstack".

Hm, ok. What if I renamed it to sock_l4_dualwild()?

Short-hands for "wildcard" aren't necessarily obvious. I would have gone with "dual_any" or "dualstack_any" or "v4v6_any" or "inany_any". But actually it can also stay like that, I guess, especially as this looks refactor-prone for https://bugs.passt.top/show_bug.cgi?id=140. I just wanted to raise the fact it's not obvious that "dualstack" implies :: and 0.0.0.0. It doesn't need to be addressed in code or comments now, or ever.

...

...

Otherwise, the only case in which a single dual stack socket actually listens to traffic from both protocols is for a wildcard. Maybe there are obscure wildcard addresses other than :: / 0.0.0.0, but that's also in the "worry about it later" pile.

Sure.

...

Note that:

https://github.com/containers/podman/pull/14026/commits/772ead25318dfa340541...

implies some sort of dual stack localhost support (it treats "dual stack" ::1 as listening on both ::1 and 127.0.0.1). However, AFAICT that's just not correct. On Linux, listening on ::1 listens only on ::1 even with V6ONLY explicitly set to 0.

Right, I don't even know what "simulated" means there. Actually there's no problem description at all. Go figure. I'm not sure if we want to report something (I'm not even sure what we should report).

I think "simulated" there means using one v4 and one v6 socket instead of a dual stack socket.

Looks like that patch came in response to https://github.com/containers/podman/issues/12292

-- Stefano