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=217, 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.
> 
> 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.
> 
> This should only be an issue in IPv6 local mode, because, otherwise,
> we source address and default gateway address (presumably compatible)
> from the host.
> 
> 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.
> 
> Reported-by: Paul Holzinger <pholzing@redhat.com>
> Link: https://bugs.passt.top/show_bug.cgi?id=217
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

Reviewed-by: David Gibson <david@gibson.dropbear.id.au>

[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 = inany_from_v4(c->ip4.our_tap_addr);
>  		} else {
> -			tgt->oaddr.a6 = 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 = c->ip6.our_tap_ll;
> +			else
> +				tgt->oaddr.a6 = c->ip6.our_tap_addr;
>  		}
>  	}
>  	tgt->oport = 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;
>  
>  	/* PIF_HOST addresses */
>  	struct in6_addr dns_host;
> -- 
> 2.43.0
> 

-- 
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