From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: passt-dev@passt.top
Subject: Re: [PATCH v3 2/8] util, flow, pif: Simplify sock_l4_sa() interface
Date: Wed, 19 Nov 2025 12:42:04 +0100 [thread overview]
Message-ID: <20251119124204.25650cb3@elisabeth> (raw)
In-Reply-To: <aRvpYmMRydvb7oOU@zatzit>
On Tue, 18 Nov 2025 14:34:58 +1100
David Gibson <david@gibson.dropbear.id.au> 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 <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.
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/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
--
Stefano
next prev parent reply other threads:[~2025-11-19 11:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-29 6:26 [PATCH v3 0/8] Reduce differences between inbound and outbound socket binding David Gibson
2025-10-29 6:26 ` [PATCH v3 1/8] inany: Let length of sockaddr_inany be implicit from the family David Gibson
2025-11-13 6:33 ` Stefano Brivio
2025-11-13 22:53 ` David Gibson
2025-10-29 6:26 ` [PATCH v3 2/8] util, flow, pif: Simplify sock_l4_sa() interface David Gibson
2025-11-13 6:33 ` Stefano Brivio
2025-11-13 23:21 ` David Gibson
2025-11-18 0:19 ` Stefano Brivio
2025-11-18 3:34 ` David Gibson
2025-11-19 11:42 ` Stefano Brivio [this message]
2025-11-20 0:05 ` David Gibson
2025-11-20 2:22 ` David Gibson
2025-10-29 6:26 ` [PATCH v3 3/8] tcp: Merge tcp_ns_sock_init[46]() into tcp_sock_init_one() David Gibson
2025-10-29 6:26 ` [PATCH v3 4/8] udp: Unify some more inbound/outbound parts of udp_sock_init() David Gibson
2025-11-13 6:33 ` Stefano Brivio
2025-11-13 23:33 ` David Gibson
2025-10-29 6:26 ` [PATCH v3 5/8] udp: Move udp_sock_init() special case to its caller David Gibson
2025-10-29 6:26 ` [PATCH v3 6/8] util: Fix setting of IPV6_V6ONLY socket option David Gibson
2025-11-13 6:33 ` Stefano Brivio
2025-11-14 0:24 ` David Gibson
2025-11-18 0:19 ` Stefano Brivio
2025-10-29 6:26 ` [PATCH v3 7/8] tcp, udp: Remove fallback if creating dual stack socket fails David Gibson
2025-10-29 6:26 ` [PATCH v3 8/8] [RFC, DO NOT APPLY] tcp, udp: Bind outbound listening sockets by interface instead of address David Gibson
2025-10-30 3:58 ` [PATCH v3 0/8] Reduce differences between inbound and outbound socket binding David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251119124204.25650cb3@elisabeth \
--to=sbrivio@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=passt-dev@passt.top \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://passt.top/passt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).