On Wed, Nov 19, 2025 at 12:42:04PM +0100, Stefano Brivio wrote: > 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? Maybe one day, but not soon, I think. > I don't think we have to care about that right now, though. Agreed. > > 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". 'dualstack_any' is definitely a better idea. Unfortunately, I forget to change this in my last spin. > 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. True. > 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. Ok. Sounds like it's definitely worth a respin. Perhaps I'll add a rename patch into some future series. -- 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