From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202606 header.b=YEBpUKuN; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 825005A0271 for ; Tue, 07 Jul 2026 06:27:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202606; t=1783398434; bh=TaZgHIpg+VVlIVQ/mO3yq+MeV21Z0tk8RO+TJwjS27c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YEBpUKuNmOtajN/32+SKhLxUNGB7Me+2DTePyDUZzMIgatYonoEUPjOjtFTVXwO7e S6MRXy29zMz97X62cceSb2wr8QfZcJ31Jgt/VSA2lFTJJNGnMna/u31TuUha6gWD07 m37IaEWkDq9mfsAHlXUsYOeNnJZu3yK/aFeWWkGlFdhDx/b4jcwonPAWOo4jpMgnZw rI4Bf3Jab8Vt+A0vsmJ/u1TRlPec42CHzEYU1KHKnr1HPhq9/LOLFjM/P4FlzYSyov Fk4jggaRUpMTFhv1zRwONLUn4wYqhOFiLqckFEtG7m+F5zESKxk6Q6X3fLxYOPucrK CMdJvK2QhOURQ== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4gvSqk5FQBz4wHs; Tue, 07 Jul 2026 14:27:14 +1000 (AEST) Date: Tue, 7 Jul 2026 14:27:07 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v2 1/2] fwd_rule: Parse target addresses for forwarding rules Message-ID: References: <20260702073215.751291-1-david@gibson.dropbear.id.au> <20260702073215.751291-2-david@gibson.dropbear.id.au> <20260704172705.71da2cf3@elisabeth> <20260707004829.09651fb7@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VxoV8trgIPxdXmgG" Content-Disposition: inline In-Reply-To: <20260707004829.09651fb7@elisabeth> Message-ID-Hash: JJQFYGJYLI7CP2TV7CXK6VXC6KJLOBVR X-Message-ID-Hash: JJQFYGJYLI7CP2TV7CXK6VXC6KJLOBVR X-MailFrom: dgibson@gandalf.ozlabs.org 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: --VxoV8trgIPxdXmgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 07, 2026 at 12:48:30AM +0200, Stefano Brivio wrote: > On Mon, 6 Jul 2026 13:08:29 +1000 > David Gibson wrote: >=20 > > On Sat, Jul 04, 2026 at 05:27:06PM +0200, Stefano Brivio wrote: > > > On Thu, 2 Jul 2026 17:32:14 +1000 > > > David Gibson wrote: [snip] > > > I wonder: if !addr, shouldn't we replace it, for the moment, with > > > inany_any4 or inany_any6 depending on !!inany_v4(tgt_addr)? > > >=20 > > > I see that an empty address already works with -4 or -6, and I > > > understand that, by doing this, we'll have a change in behaviour once > > > forwarding between IP versions is implemented. > > >=20 > > > But it will take a while before we get there, and, meanwhile, I guess > > > almost all users will just want to do stuff like -t 8080:192.0.2.1/80, > > > just to hit: > > >=20 > > > Forwarding between IP versions (* =3D> 192.0.2.1) not implemented > > >=20 > > > which isn't obvious if you aren't familiar with the implementation. I > > > can also picture a constant flow of incoming tickets as a result. =20 > >=20 > > That's a reasonable concern. I did think about this and came to the > > tentative conclusion that automatically restricting to one family > > would be worse, but I'm open to persuasion otherwise. Reasoning as > > follows. > >=20 > > First, it is a little awkward to implement: I think we should still > > prevent an explicit *:192.0.2.1, which means we'd have to distinguish > > the explicit * and implicit any cases. >=20 > Fair, and I think we should, but that looks relatively simple judging > from fwd_rule_range_except() and callers. Ok. > > Mind you, we probably want > > something similar when we allow listening addresses for -[TU], so it's > > not such a big deal. > >=20 > > More importly this would become the _only_ place where the target > > designation affects where and how we listen - in all other ways, > > that's fully determined by the first part of the spec plus global > > flags like -[46]. This gets particularly striking when looking at > > something like: > > -t 5000,5001:192.0.2.1 > >=20 > > With an automatic restriction, we'd end up listening on *:5000, but > > only on 0.0.0.0:5001, which seems pretty confusing. >=20 > So... I wasn't really aware or the fact that: >=20 > - t x,y >=20 > would always be equivalent to: >=20 > -t x -t y >=20 > as it is now. I originally intended , as a separator for ports and > ports only, but originally we just had ports as port forwarding > specifications. Then forwarding specifiers grew and I missed that, but > it wasn't my intention. Right. Nonetheless, it's been that way for a good long while. > I think that, eventually, we should make -t x_0,...,x_n a mere port > specifier like it already is for ranges, because it's rather intuitive, > as opposed as, say: >=20 > -t 5000 -t 5001:192.0.2.1 >=20 > where it's clear that we want to map port 5001 to 192.0.2.1 as > destination address. If we say -t 5000,5001:192.0.2.1, it's rather > obvious that we do *not*, and yet that's the outcome. Agreed in principle. However, to do it differently we'd need to work out how it interacts with target port specifiers. I don't think the meaning of -t 5000,6000:7000 is particularly clear one way or the other. > On the other hand, "fixing" this is clearly behind the scope of this > series, so, unless you have in mind a quick way to implement it, let's > forget about this, and go ahead with this approach which is consistent > with the existing situation, I'd say. I don't see a quick way to implement it, but more than that it's not really clear to me what our options are for syntax without breaking backwards compatibility too badly. > > > The change in behaviour once we implement forwarding between IP > > > versions, by the way, looks a bit like an extension rather than a real > > > change that could reasonably cause trouble to anybody. =20 > >=20 > > I'd argue that's even more the case with the errors as is: things that > > weren't possible before become possible. >=20 > Indeed. I was just suggesting that even with the other option we would > add an extension at some point, rather than a bug. >=20 > > > > + char bstr[INANY_ADDRSTRLEN]; > > > > + > > > > + die( > > > > +"Forwarding between IP versions (%s =3D> %s) not implemented", > > > > + inany_ntop(addr, bstr, sizeof(bstr)), > > > > + inany_ntop(tgt_addr, astr, sizeof(astr))); > > > > + } =20 > > >=20 > > > About both validations: shouldn't they live in fwd_rule_add(), where > > > we already have this kind of stuff? Or at least be duplicated there? = =20 > >=20 > > Yes, yes they should. Which also means it needs to move to the second > > patch (or fwd_add_rule() doesn't see the target address - there's > > nowhere for it in the structure). > >=20 > > For the next spin, I've moved this validation to fwd_rule_add() in > > patch 2. I've also tweaked the messages a bit, which might at least > > slightly mitigate the concerns above. >=20 > Maybe, given that these error messages are temporary, we could indulge > into some extra message like: >=20 > "Did you want to say 0.0.0.0/... instead?" >=20 > same for ::1, along with the rest of the forwarding specifier. Users > would see that when their containers fail to start and they could fix > their syntax right away. Good idea, done. --=20 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 --VxoV8trgIPxdXmgG Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmpMgA0ACgkQzQJF27ox 2Ge3uw/7BaIbrqpEMptj94IjNLup1y12Lk7nl0BQo9F7k6NzvVC4L2dgF66JfX6w i/dzLfKjCcB3ybILF34VrdWh9O7lYzCjd+1Cucq7wHNnA4/JFM5BAxkNeWEdaZA/ VfRFcRN5+zCIH/9cFjXxAbC10eOSLgSusonhOnPV2HPeACXz5+VzS6ibhV4KVHkg wkZMnnp9DB/HeyX2kAmjVDGE4ENr5256LSkoN3FHB/x+DqqtNfBxlhV1Lz86GBty cHB0iK7H9F9lzcCi66P3210DQtSLZ8Fowlh/YbYvBgxF14rSStfjARe+cYVl63FC cKi+ORTY5msxmwpSGUHiBvuCdVECDCkH+cl0ywjhtOwGnFrjjY+M2CO6AsMoDaGn 5TwPvakoJXrQOVLwYdoMFHGrbd/+KUFzFzIXgegmy7iWwoiApBnAKfibFiqu/BHW 0zrJXc/3aY73X3GeVYdXs+TyESy94L9CUc6M9yLV6Hl9N0Y99I3p9+R20t0QEEvl n+BGO1aqo1zeZJngLX1r09gCFqw+adn3GSbIOPvs5itMPqeUgEfU5GmQzUTt5FYR I4YJP88iEYip6EPMXH+Yiu83SQRbuqMevQ+YYPJeFrkHd4X6ybdVufmKPuYhd+uu k3ymHXJlOwAKVYVcKfjKpmWGiQTVHEHSzfO2/+uoEpwQ4ih4xOQ= =mvjE -----END PGP SIGNATURE----- --VxoV8trgIPxdXmgG--