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=hWh0Vm1x; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 690ED5A0265 for ; Thu, 23 Jul 2026 11:42:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1784799761; 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=Q+lTUpfN5WP8KI/pqQbA/GDMRf27RBhW7H+taqj/rPE=; b=hWh0Vm1xgpK5DXbLjBl9OG7yGBMhAC4Pvx7Al28FffdTQ/FeVeOAJAC0G14XysZV62m662 eDnyHhAl8Mm59Lv+BEuspKtd3TReURHUiaYCWOvB+2/YtCaJr3WR9HrT/HfFpBoAWmFM9o TBB8gQYv4kZY6V/T90vT9Kze2nincnM= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-493-WpHrMHJ7MgS0Wkd5HBek7g-1; Thu, 23 Jul 2026 05:42:39 -0400 X-MC-Unique: WpHrMHJ7MgS0Wkd5HBek7g-1 X-Mimecast-MFC-AGG-ID: WpHrMHJ7MgS0Wkd5HBek7g_1784799758 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-47d81cf0c4cso259811f8f.2 for ; Thu, 23 Jul 2026 02:42:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784799758; x=1785404558; h=date:content-transfer-encoding:content-type:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=Q+lTUpfN5WP8KI/pqQbA/GDMRf27RBhW7H+taqj/rPE=; b=k1Ug73VcR/2oy3ojbvP9J0OFvlPyCw55LgGsra4IteZwoSzts30XgBpG3NLYvdycWO WfQFPwEmUvibbIMCvtfVdUlu7HAFlAIcrtuKPiLfAEMkwOB1hEhanTkQFo8D015F1VBw sHeoMxHjpjd5Pj1tuKcoFVafbNwOqxXXPAQYbXmt4BebQgwwNfCTqWiOVe22YaWUiMns gcxJas+fBXtUIbq14Ss+hdFJ1F0tAAPXtlgfpa36tHsYatWgB7k26twoIyPr+Nkr6i+k RXF1g2Ai1sfi0oVhv0KM1LAY0rJqEwMCjP5Kx7CFOEKzVDzkRNtLzroMZ0DuB5HaJXEE dtuQ== X-Gm-Message-State: AOJu0Yz1fbdBqwS9bgiguz9Ry3Uj3tRkzaPzLzU5vlNrTLrY2+r1C382 hKhwS1Wf7yMguqRkhYqsDN7UFLWF6oNtmjJpa/VieY4juIahv5mkJd8fLL0tBiH1iWZWbjoa0Fj Ij9VGa5NDwoqa0hkdgY1NSXsLStcx7MRj4Iv5N7XgT4Qmq1PHbs5sHtSCjnVLyw== X-Gm-Gg: AR+sD12+JROFdO+tqtiNAUe8G5jXsasrYoICqCjBiz7A6LlHjnu5zFHwaPUE8R/vVC6 1dWKusZbq07OjJfDP0Fz4WGXg/Aqvettcrc0nByCBjb/by3xH89lSrAEHKrT3GxeJSnhdfuhij0 ndbOoboBW2i0LVNAvZYgapTPRquj7IcbJIoV8GqQyLkKz0ncNgUn4da72vuIt7T9MXqvvLzyZOH p7U+/zsPhq6BWK0z1gCmV13DEMrJUykQ5aFwIzoxzi5jjPi18QyEIHSP5OcjpYKb0tcgNrv/KvS o5fMCNMiyTfc28Ir7hQz/ft6Web9fnC2I2GdAmVqlna+sMqhm9JIm0gUfJ5vGnP96E3x5UR8vQJ 7ckJS4zrslCbIeeeI8p5wJkU6+uqD X-Received: by 2002:adf:e182:0:b0:47f:86d5:d1d7 with SMTP id ffacd0b85a97d-47f8d61a44amr3186768f8f.6.1784799758230; Thu, 23 Jul 2026 02:42:38 -0700 (PDT) X-Received: by 2002:adf:e182:0:b0:47f:86d5:d1d7 with SMTP id ffacd0b85a97d-47f8d61a44amr3186721f8f.6.1784799757494; Thu, 23 Jul 2026 02:42:37 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f85c532d4sm13439732f8f.22.2026.07.23.02.42.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2026 02:42:36 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 2/2] conf, fwd: Prefer same-scope address as inbound source address from host Message-ID: <20260723114234.2266f6dc@elisabeth> In-Reply-To: References: <20260722232639.1105561-1-sbrivio@redhat.com> <20260722232639.1105561-3-sbrivio@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Thu, 23 Jul 2026 11:42:36 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: IFEy4f174IPE0387fISS1vfKXdQ2cyK_QzcgQvIsvGA_1784799758 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: JAAIDL3DCTG3R4MGAA6TSOEVW5CALLQK X-Message-ID-Hash: JAAIDL3DCTG3R4MGAA6TSOEVW5CALLQK 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, Jan =?UTF-8?B?Um9kw6Fr?= , 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: On Thu, 23 Jul 2026 13:36:58 +1000 David Gibson wrote: > 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 > > Link: https://bugs.passt.top/show_bug.cgi?id=217 > > 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 = 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. 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: > 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 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, and we should always try to do that (same here, RFC 6724 Section 5 Rule 2). 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). 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): 1. if there's a possible link-local source address and a possible destination source address, pick both 2. if there's a possible unicast source address and a possible unicast destination address, pick both 3. if there's a possible link-local source address, pick it, and then pick any (mismatching) destination address 4. otherwise, pick any available source address, and any available destination address ...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). > 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 -- Stefano