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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 4033 bytes --]

On Tue, Nov 18, 2025 at 01:19:21AM +0100, Stefano Brivio wrote:
> On Fri, 14 Nov 2025 10:21:46 +1100
> David Gibson <david@gibson.dropbear.id.au> 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 <david@gibson.dropbear.id.au> 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.

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()?

> > 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/772ead25318dfa340541197e92322bd2346df087
> > 
> > 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

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]