From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=bropWfKA; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 3452E5A0271 for ; Wed, 19 Nov 2025 12:42:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1763552540; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yauNYcZ82q0GIANiU0jAxPjYSDK/uuRJbelLXupSuH4=; b=bropWfKABARxaH7o6cAmc/z/6tP4Wvbj/z1ALwwQAUoPvKv4/+vvCcQNcDE8MQw24yfTY7 zv2hjgFzKRaN56Lp2TVN2S3jbseedISQFxkdB0ujaey8buUhwwcn6RN0j/xjDDA8bqfi3q VdoTiKTil2Ikenx/xpB5YXVZ/me4ADM= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-164-s-ogh28xNFSVNCth76o6rw-1; Wed, 19 Nov 2025 06:42:18 -0500 X-MC-Unique: s-ogh28xNFSVNCth76o6rw-1 X-Mimecast-MFC-AGG-ID: s-ogh28xNFSVNCth76o6rw_1763552535 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-42b478551a6so1225226f8f.1 for ; Wed, 19 Nov 2025 03:42:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763552535; x=1764157335; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=yauNYcZ82q0GIANiU0jAxPjYSDK/uuRJbelLXupSuH4=; b=M49VNHIF3+0U7NnwfFBgur6977JDQLbQXUO/1LT6LMj+4c2szMAB5btNe3w6itwtyp ldyDO9/0cDH8TbslTKN/bjHkQVSSRlaTr3r6cZajUL77/ThFS1mRQUX3SmlzHhc0litL hYoJPTe3qXozqondFPvqrrSfc84gQuZzm9xOuKDJSU5QNLWPZzotDh5iqrbbNp0kTF8w LMGMdVqPHZx1ACwG5zpJ1YStWQLGqhVVc37VbgrO0bxySJzRoit4ZSPsMlQQnqQozRnw FlQre4DRLjqTSEiB/2I9lMFK5teYfHd1ClS0bqIsOPfVnKNMZdSdzMuQzyzyVPHkK++G M6wQ== X-Gm-Message-State: AOJu0YyxcC1yL5DMh7oAbfYIenw52NYfIcDmU+LOZw6AuSF+00x60tEa V+A0jzuU0elPbczmM/fb5UmPFJiAVkOF6yiVca53RgHiSUKeijF2jhyHEc1v4C6J5IgkZVVanzd fZMshptsatmBBJOogqml+7YTgFGGN2AQL3PKLEJyYnh/zTmsaSsPPuA== X-Gm-Gg: ASbGncszWw4bIEYXeKcouqmB9Rmcp0v38/E9d03N4ayr5THOOdQi2xAMctXrgFTL/oU r+xah7jiPs+WlcrANzdYZfuYuOwcXqyGOpujrlxgz30eY75Q/0mOsfWUqraSC5XLgd9DW5aUtzG yfeknirWuWmsS18pLQ57wXX9p2zOVo+QIOFX8/hbajdaSeIiAi+xyis4rWr39A1j4U/g6TAq4fp 4AH2gn0Jq8HArbSu6Dl0zOZkEQxAlozoyWQtgOPWggg07gqBh4fuuhAQqgAgRISk7q2iGJGwYbg Iap+4UPUXfYFwdNz1tsxsMFBMSJfrvZnvNpAQuNHsz59ruxuPwCMh+M+lRPcFU66T4Hmkfbjt+m n45hAIjxNTm5HbRHybJCZ X-Received: by 2002:a5d:5847:0:b0:429:bc68:6c95 with SMTP id ffacd0b85a97d-42cb1fb9ccfmr2503323f8f.47.1763552534686; Wed, 19 Nov 2025 03:42:14 -0800 (PST) X-Google-Smtp-Source: AGHT+IFjatOt7BAbWcZcN8jiPw+GYLwy9MktY9egy+YqDIiJjk8wt3loO5BoA1T9L2lIArdhX1lxtQ== X-Received: by 2002:a5d:5847:0:b0:429:bc68:6c95 with SMTP id ffacd0b85a97d-42cb1fb9ccfmr2503279f8f.47.1763552533949; Wed, 19 Nov 2025 03:42:13 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42b53f0b62dsm37528854f8f.24.2025.11.19.03.42.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Nov 2025 03:42:13 -0800 (PST) Date: Wed, 19 Nov 2025 12:42:04 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH v3 2/8] util, flow, pif: Simplify sock_l4_sa() interface Message-ID: <20251119124204.25650cb3@elisabeth> In-Reply-To: References: <20251029062628.1647051-1-david@gibson.dropbear.id.au> <20251029062628.1647051-3-david@gibson.dropbear.id.au> <20251113073313.1287b4dc@elisabeth> <20251118011921.4094e698@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 2dfkhdEttQkL8equM1LXgLWTII1DFWFKv8ZrpdngtGQ_1763552535 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: DO6U2ATCGSDRCDXXO4DUL7C5MORYZVBG X-Message-ID-Hash: DO6U2ATCGSDRCDXXO4DUL7C5MORYZVBG X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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/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