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=MYYwbex3; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id EBB845A026D for ; Thu, 23 Jul 2026 05:37:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202606; t=1784777824; bh=vdBUxR8U976s7huM0tw0HdRDtSiFuhGgEKtwjxK5jU0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MYYwbex3uciPWAyi3oo/XkxrM7fkWKVTr35R9a/5D+wFhy2omly8jeVwlL5By3kgQ Aw7ievTZfxsmWDY2KVTzOgBzLtLJXZVBh7VKDPt9+D5k/8xXmL5NvUgmFVGHMO23OW kmBNOqtdDh2ex5LoBgvu9Mqa/DnAb5n6TtrxYaygIGZlBP4D2RzkFjG0PsJjEO8SHk VUwLr4kSqy4ep8N07Wlbd8j/RtQ8jWNDS0C2WQGzCQc7aZAN9DWqeDEDefKbZzIWJX u6xBkAw/TJWnwrJns9LrH7HbEwhAyi5Z6Ze7/IyRQRWnsjaVe+Rc9PNOKgCkq+c/G5 k1N+SI4G1Tsxg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4h5GyS2jxYz4wCJ; Thu, 23 Jul 2026 13:37:04 +1000 (AEST) Date: Thu, 23 Jul 2026 13:36:58 +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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="974rbzkhvoDfMuge" Content-Disposition: inline In-Reply-To: <20260722232639.1105561-3-sbrivio@redhat.com> Message-ID-Hash: VPBRXUCDGZ3YWDCHBJA24JHR7OZDVJCI X-Message-ID-Hash: VPBRXUCDGZ3YWDCHBJA24JHR7OZDVJCI 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: --974rbzkhvoDfMuge Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 23, 2026 at 01:26:39AM +0200, Stefano Brivio wrote: > 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 safe > one: the user might have specified a valid gateway address, matching > the scope of the destination address, but we won't use it as address > 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, otherwise, > we source address and default gateway address (presumably compatible) > 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 with > with IPv4, and stick to Rule 2 of RFC 6724, Section 5, when selecting > 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 Reviewed-by: David Gibson [snip] > 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) || 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. 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. 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. > + 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 sockets 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 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 --974rbzkhvoDfMuge Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmphjFkACgkQzQJF27ox 2GfkoA//dH24/RPV0+gsBjBlQuBzuarsqe3dK27Rdn5pp7oTfMWv2+EUXlKzEdqk mru15HgyfLQvND6qoh7VhNDeC9brVIXhVq2Lb3CnI2K39VoUsSbtXtB1dgQq0ppj QKVIniyHvVIdb6EX8Rqhj+7rh/TSCflZ7o0LvWlT408UlKT5OEPPa9kZqKr5q+Ti 8lf4/Xb3Tgdh6Gl1Fbl/HbryldiKLtX2GkEQeDb4xlMc7sZTjvjbSu8G/pGENR8W +r34mwH8PNRtbnwJhviNsbgP0puOnV/VVHgSylYYRygQIR6YFJmVaZEywPVgM25d mKPM7jLQa/lYeXW0zMEP9rrVjW5FBQVAemma6p14qeNUAx6S1C4N+IL25wLyNZPA 5eYh5r0QqMigWlagOIxydugWYPstToaAjdWr+umYth6z3L24Bht7bzI+oexQZjt2 /ydrUc4j5nB2Ogx4a4gtdb6gL2LPt2plHxMd12quWhZgfsFa+DyfweHVZpF0Wl8j h9SUwNAYJceCFvZYOIHmwEoxzI9y9HpcKHAAPPcPKeYXDk/pL0FnTNttzEAKKGgK vuAiWjVKEVC+F1twASv4tpMCv37UeO6KOj5nea1I/jlrMnlr8SKEwBRLQf5JEipQ AJY1olwHiTQNLe/4jdar2B8r5+XkX1AmSeYwYdW9XbKlUzDo87s= =epYu -----END PGP SIGNATURE----- --974rbzkhvoDfMuge--