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=202608 header.b=f/JyC77E; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 3BFC65A0265 for ; Tue, 18 Aug 2026 03:09:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202608; t=1787015337; bh=JopCH/RAEQD0hg6tn+U5sgoM5KFk2rB4Oncuapne6eA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=f/JyC77EvEfRh9SxPa1maA148ZEcj2LZVuCJNmsVKXBa2DS8D225+5fkGKLqfM3Bc Zft7rzMS9VkIApilwetCZstz7MY7+ldOaQ3uvy3XsdZgJybA1nezEP6nO+7ReNwKfh Xi9S+5jJEKrqI7jeNyg1dP4uOP/zxDwjrl1cYF1Xxm9OIJoCk00fN3jbjwIfdCfXdv XJXXdqJGWHDuhkr5MMiT+w4GAzNPNpVpW501SqzgtZfA3w9IB0QwCEH/ttiEItQwFr 4wahazYMekRkdI1s4cqgrT9g+oWOMfMQCtDsGnDcsUY4+e+9Kh8UYG69ghDMfmXml3 I6H1VCtQemLlA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4hPBRY1DRkz4w8x; Tue, 18 Aug 2026 11:08:57 +1000 (AEST) Date: Tue, 18 Aug 2026 10:34:34 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 2/2] conf, fwd: Prefer same-scope address as inbound source address from host Message-ID: References: <20260722232639.1105561-1-sbrivio@redhat.com> <20260722232639.1105561-3-sbrivio@redhat.com> <20260723114234.2266f6dc@elisabeth> <20260817221830.0835d9fb@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RKQJvsE1GsSK7YD/" Content-Disposition: inline In-Reply-To: <20260817221830.0835d9fb@elisabeth> Message-ID-Hash: BDCFY6547CHBANN2HUUQWDM6BXHVCELX X-Message-ID-Hash: BDCFY6547CHBANN2HUUQWDM6BXHVCELX 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, Jan =?iso-8859-1?Q?Rod=E1k?= , Paul Holzinger 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: --RKQJvsE1GsSK7YD/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 17, 2026 at 10:18:31PM +0200, Stefano Brivio wrote: > On Mon, 27 Jul 2026 11:52:50 +1000 > David Gibson wrote: >=20 > > On Thu, Jul 23, 2026 at 11:42:36AM +0200, Stefano Brivio wrote: > > > On Thu, 23 Jul 2026 13:36:58 +1000 > > > David Gibson wrote: > > > =20 > > > > On Thu, Jul 23, 2026 at 01:26:39AM +0200, Stefano Brivio wrote: =20 > > > > > We might have situations, such as the one described in > > > > > https://bugs.passt.top/show_bug.cgi?id=3D217, where using a link-= local > > > > > address as source in a given namespace doesn't guarantee that we = can > > > > > reach the intended destination, because, for instance, the inbound > > > > > traffic we forward is in turn forwarded to a different interface,= such > > > > > as a bridge. > > > > >=20 > > > > > In that case, the assumption from 9618d247006a ("ndp, dhcpv6, tcp, > > > > > udp: Always use link-local as source if gateway isn't") isn't a s= afe > > > > > one: the user might have specified a valid gateway address, match= ing > > > > > the scope of the destination address, but we won't use it as addr= ess > > > > > of last resort, and prefer a link-local address with a mismatch in > > > > > scope instead. > > > > >=20 > > > > > This should only be an issue in IPv6 local mode, because, otherwi= se, > > > > > we source address and default gateway address (presumably compati= ble) > > > > > from the host. > > > > >=20 > > > > > So, in local mode, if the user specifies a given default gateway > > > > > address for IPv6, note that as 'our_tap_addr', like we would do w= ith > > > > > with IPv4, and stick to Rule 2 of RFC 6724, Section 5, when selec= ting > > > > > a source address, by preferring an address with the same scope, if > > > > > available. > > > > >=20 > > > > > Reported-by: Paul Holzinger > > > > > Link: https://bugs.passt.top/show_bug.cgi?id=3D217 > > > > > Signed-off-by: Stefano Brivio =20 > > > >=20 > > > > Reviewed-by: David Gibson > > > >=20 > > > > [snip] =20 > > > > > diff --git a/fwd.c b/fwd.c > > > > > index 7152169..4ba0af3 100644 > > > > > --- a/fwd.c > > > > > +++ b/fwd.c > > > > > @@ -1090,7 +1090,11 @@ uint8_t fwd_nat_from_host(const struct ctx= *c, > > > > > return PIF_NONE; > > > > > tgt->oaddr =3D inany_from_v4(c->ip4.our_tap_addr); > > > > > } else { > > > > > - tgt->oaddr.a6 =3D c->ip6.our_tap_ll; > > > > > + if (inany_is_linklocal6(&tgt->eaddr) || =20 > > > >=20 > > > > Just to make sure you're aware: this will only trigger if tgt->eaddr > > > > has been set at this point, which is not always the case. In fact = it > > > > will usually only be the case when the rule specifies a target > > > > address. In other cases we pick tgt->oaddr first then pick > > > > tgt->eaddr's scope to try to match it. =20 > > >=20 > > > Right, yes, I had half a mind to try and change this slightly (see > > > below) but then I realised that luckily it wasn't needed for this > > > minimal fix, as Podman will specify an explicit destination address, = so > > > I preferred to avoid the topic altogether for the moment (including > > > avoiding comments that risk ignoring some corner cases) because: > > > =20 > > > > I think the fact that the order in which we pick eaddr and oaddr > > > > varies is pretty confusing, but I haven't so far seen a way to avoid > > > > it without breaking something worse. =20 > > >=20 > > > ...I think that, at least in the !nat_inbound() case, we should avoid > > > a strict ordering in the selection of source and destination address > > > (we should look into both at the same time) because in general we know > > > upfront if we can match the scope between source and destination, =20 > >=20 > > I'm not entirely sure what you mean by that. >=20 > I mean that we shouldn't try to do something like: >=20 > 1. check table with mapping of source addresses, apply transformations >=20 > 2. check table with mapping of destination addresses, apply > transformations >=20 > but rather: >=20 > 1. check table with mapping of source addresses and table with mapping > of destination addresses, and apply relevant transformations > (establishing some rules on how to check both "at the same time" is > more complicated than the alternative, but also more useful) >=20 > > > and we > > > should always try to do that (same here, RFC 6724 Section 5 Rule 2). = =20 > >=20 > > AFAICT the RFC rules are assuming you already know the destination addr= ess. >=20 > Yes, true, I'm not saying that we should apply the RFC as it is (it > doesn't cover what we're doing, just something that resembles it). >=20 > I'm just saying that if we consider both source and destination address > mappings at the same time, we can find a combination that satisfies > that rule. Ok, makes sense. Doing that certainly complicates the design, but yeah the flexibility is probably necessary. > > > And, if there are multiple ways to match the scopes, we should prefer > > > the most specific / smaller common scope (same rule as above, Section > > > 3.1 helps in the interpretation). =20 > >=20 > > Ok, makes sense, although again I'm not sure it really follows from > > the RFC which seems to assume a known destination. >=20 > Same here: we shouldn't apply those sequentially (even though that > makes sense in the general scenario foreseen by the RFC, but we don't > need to apply the RFC -- it's just that those rules are useful to draw > some inspiration). Ok. > > > But this would be much simpler to implement once we have Jon's changes > > > generalising address storage, because at that point we could have a > > > lookup function for the smallest scope of usable address, or even a > > > joint lookup function altogether. In detail, I think we should do this > > > (again, under the !nat_inbound() condition): =20 > >=20 > > Right. > >=20 > > >=20 > > > 1. if there's a possible link-local source address and a possible > > > destination source address, pick both =20 > >=20 > > Did you mean specifically a link-local possible destination address > > here? >=20 > Ah, yes, sorry. Both link-local. >=20 > > > 2. if there's a possible unicast source address and a possible unicast > > > destination address, pick both > > >=20 > > > 3. if there's a possible link-local source address, pick it, and then > > > pick any (mismatching) destination address > > >=20 > > > 4. otherwise, pick any available source address, and any available > > > destination address > > >=20 > > > ...and once we have that series, we can probably avoid implementing > > > these as distinct steps. I would defer all this to that point, and > > > meanwhile just fix whatever critical case might come up (like the > > > current one with Podman). =20 > >=20 > > Ok. > >=20 > > > > I still think this change is correct: not previously having > > > > ip6.our_tap_addr was only possible because we did this odd dance to > > > > pick eaddr based on oaddr's scope rather than the other way around. > > > > =20 > > > > > + IN6_IS_ADDR_UNSPECIFIED(&c->ip6.our_tap_addr)) > > > > > + tgt->oaddr.a6 =3D c->ip6.our_tap_ll; > > > > > + else > > > > > + tgt->oaddr.a6 =3D c->ip6.our_tap_addr; > > > > > } > > > > > } > > > > > tgt->oport =3D ini->eport; > > > > > diff --git a/passt.h b/passt.h > > > > > index a61baca..51ccd4f 100644 > > > > > --- a/passt.h > > > > > +++ b/passt.h > > > > > @@ -121,6 +121,7 @@ struct ip4_ctx { > > > > > * @dns: DNS addresses for DHCPv6 and NDP > > > > > * @dns_match: Forward DNS query if sent to this address > > > > > * @our_tap_ll: Link-local IPv6 address for passt's use on tap > > > > > + * @our_tap_addr: Non-LL IPv6 address for passt's use on tap (if= any) > > > > > * @dns_host: Use this DNS on the host for forwarding > > > > > * @addr_out: Optional source address for outbound traffic > > > > > * @ifname_out: Optional interface name to bind outbound socket= s to > > > > > @@ -140,6 +141,7 @@ struct ip6_ctx { > > > > > struct in6_addr dns[MAXNS]; > > > > > struct in6_addr dns_match; > > > > > struct in6_addr our_tap_ll; > > > > > + struct in6_addr our_tap_addr; > > > > > =20 > > > > > /* PIF_HOST addresses */ > > > > > struct in6_addr dns_host; > > > > > --=20 > > > > > 2.43.0 =20 >=20 > --=20 > Stefano >=20 --=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 --RKQJvsE1GsSK7YD/ Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmqDqIoACgkQzQJF27ox 2Gfmow/8DOJedS29ke5hoxphSrUy/MfijpERYorC6DmOkjA8h2ovmcBLxZ2EYtAy fH3EcOrQ52uGcMn33BOM2K98vOJU9syInXF7GvoUFFiS4tzgMiYY2pESc7XwI/tq onjhgqpOhZM+HPanEcqfYc7+oAJaZf8jmm7Z7jcp7hUNyKPpyXrMg8gBI/SOqKqm p28w7dkG2Ve2a4UoVYxQw5TJ/UTzYZjKaQ6d0vX+k4J/aPywYgJiFPE5US9R9YYi F8vP830L8u/Ex4d/n8ZN/71ngXovWxn7JXV81vE48/yb0vuiMwEPOay2B51GJL65 BmLA7Br7dgQ+G/mCYc3BXinjwbKRrmW68sSfPeZL8JjXRTGCInFt1FAjgnB3trGC MDU9uEq3CpxTiDiiSbXnOEOSae8PVMA66mIdaOWjUoc4yDpuOlqQ58czdTulCBb1 6O1TuLHdpJkItxAu2ypOdo6mRVFQWQnfjt5DLnBZd1Lh8TudaS2gtver1U41DwnA Y8RQobgIBKZJ0CMC1MTJee8t1r/jSKmqo38BYW6j1M+ZjIbb7+nFODsFQNCpIXL6 mFz0Gtb1sJOIUoEqCUjl5tACCXKsm4Bsoj2sGVskGEvaRBZMBgAcdFA/vngtCHjh efIfhfo5jB76p3uVpmU0qqKCnoF1riaFqLHS+WraFm8nR6nTUUY= =D0dN -----END PGP SIGNATURE----- --RKQJvsE1GsSK7YD/--