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=O0BocxC9; 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 DF82B5A0262 for ; Thu, 14 May 2026 01:08:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778713701; 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=iU+SZq7I6IakjFF+SQZ3KMdvvPDJT9Rk7AxR72128JU=; b=O0BocxC9oBqHJjJi+vwKw3XWv95eXDI0dHGB+1FjFj+vTGR9PPk6qHi+um96YmWFRljfZP 3shFjNVlY9iX66L3wvYt7uiH+Gq/uHf7oRwot2mUltwX3HK2DzEP6arzW6L7mIokz+kT8A NU3ODyO1JrdDyRYq4lSnwUOrvKKY4DQ= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-257-i2yiPrcpMWa2u6Q9AnerdA-1; Wed, 13 May 2026 19:08:20 -0400 X-MC-Unique: i2yiPrcpMWa2u6Q9AnerdA-1 X-Mimecast-MFC-AGG-ID: i2yiPrcpMWa2u6Q9AnerdA_1778713699 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-48e7572b739so27259905e9.3 for ; Wed, 13 May 2026 16:08:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778713699; x=1779318499; h=date:content-transfer-encoding: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; bh=iU+SZq7I6IakjFF+SQZ3KMdvvPDJT9Rk7AxR72128JU=; b=G3MVVtgnUe32pFQcB8Zy1X7AwAor38hAas9ItIRq5Gim7FtrgeQz/fI+hL0mrbwgNk OhU3oLviODRm7p1z3grTKXErSPvsi3IcEloQBHWnp4aIq4+m0C0Vo3MrUcjn945ax/iX +ulj94e60rYOkv4fxQqzEwngjbYGSAIlzeLyexOcbmOuHVkgXpJn2X7tSJ0TvODPxBFf bH9YTV+B3fJwnkhc1nFm+tLyQtQ17vWMRQ53ulW+XfTP0XtQEsGTvtlUKqePAi8iXrmC 9/Jhz4Z7VMN9Jgyn3pyGKRU6LupqtmXn2BkLkr0BaXVFhoJD5oiZ/18PVgrSYbszLwMn F4og== X-Gm-Message-State: AOJu0Yzgr82YdH7xaolzQUT6ZiXUTRl7VPTBquYSc7Pq5WT+ibXVOdQU w7owZo3x00FWyrukAKXL+ZHdvFCBFzT7LCIL1Lp6x9IFc39GVRQ9AeTusrPUvYesOhL4PPRxDTT f/FTJLMz/wvClyrbGtAOVdnwwkR1iOQ7VCUOT/3WkaDiIlHr55erxrg== X-Gm-Gg: Acq92OHo987zsaYusLraxzQWDXXu9YV3KEsIW5XRkm+5ko1NYN/1LE7UOl1JUdtU0L9 ewUNdx0HnDyhfADO5kKhCgcAJyoBUNhJlMc9xlqt/pQJ2DjWRuBawIZcyfN5R5e18E8y6gCuXJ1 WJLcCQnP5nAGvk1UVgHseEhFMb6CzpzUH3a8abnQHBjk4ZU37caZ3Tu5oqOauI0X25JMiqnT7BG O5mi6nLkbxxlfw3T979dYbFC6bkVB1N+HGUwA44I+U+kBmUIrkROCq8bsNXTlf0LaBcbKF8yaXG ycrZX72Wn14s09Qh36akqlAf7qVcD+J29RApD+puZApJfuAOaKNVwTTm0tw7kNpP1JQEbY+rYJi aAMzw9zcZiUSvPaJznM8F6VSZ/uvYo23T X-Received: by 2002:a05:600c:4e54:b0:489:1cd2:610a with SMTP id 5b1f17b1804b1-48fc9a0dd7fmr79555085e9.9.1778713698715; Wed, 13 May 2026 16:08:18 -0700 (PDT) X-Received: by 2002:a05:600c:4e54:b0:489:1cd2:610a with SMTP id 5b1f17b1804b1-48fc9a0dd7fmr79554905e9.9.1778713698214; Wed, 13 May 2026 16:08:18 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fd62b55f7sm6842155e9.3.2026.05.13.16.08.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2026 16:08:17 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH RFT] fwd: Only do inbound IPv6 NAT to map_host_loopback / map_guest_addr with matching scope Message-ID: <20260514010816.5ccc02de@elisabeth> In-Reply-To: References: <20260507043149.1989693-1-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, 14 May 2026 01:08:16 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: BcqeuJXcRvQ1EoMfyO_tG7HLTD7e3k5Rr0CQQhNER-E_1778713699 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: ARUGCJD6SEAQAXO3ZEH4VK7UOFHH2EO7 X-Message-ID-Hash: ARUGCJD6SEAQAXO3ZEH4VK7UOFHH2EO7 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, 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 Wed, 13 May 2026 15:04:35 +1000 David Gibson wrote: > On Thu, May 07, 2026 at 06:31:49AM +0200, Stefano Brivio wrote: > > I'm sharing this mostly for debugging / investigation of: > > > > https://github.com/containers/container-libs/pull/755#issuecomment-4390420134 > > > > even though the change is probably correct and needed regardless of > > that. > > > > If we have map_guest_addr or map_host_loopback addresses set for IPv6, > > before using them for inbound NAT from the host, make sure they match > > the scope of the original packet, otherwise we might unexpectedly > > turn global unicast addresses into link-local ones for packets coming > > from the host itself. > > > > Link: https://github.com/containers/container-libs/pull/755#issuecomment-4390420134 > > Signed-off-by: Stefano Brivio > > There's a real problem here. However, I don't think this patch really > addresses it. Details below. > > > --- > > fwd.c | 20 ++++++++++++++++++-- > > 1 file changed, 18 insertions(+), 2 deletions(-) > > > > diff --git a/fwd.c b/fwd.c > > index 0697435..d224c0a 100644 > > --- a/fwd.c > > +++ b/fwd.c > > @@ -974,6 +974,20 @@ uint8_t fwd_nat_from_splice(const struct fwd_rule *rule, uint8_t proto, > > return PIF_HOST; > > } > > > > +/** > > + * fwd_scope6_match() - Check if the IPv6 scope of two addresses match > > + * @a: First address > > + * @b: Second address > > + * > > + * Return: true for two IPv6 link-local or both not link-local, false otherwise > > + * > > + * NOTE: This currently ignores any other difference in scope > > + */ > > Nit: we probably want this helper (or ones like it) in ip.h and/or inany.h. > > > +bool fwd_scope6_match(const struct in6_addr *a, const struct in6_addr *b) > > +{ > > + return IN6_IS_ADDR_LINKLOCAL(a) == IN6_IS_ADDR_LINKLOCAL(b); > > This considers only linklocal vs. not linklocal. Officially those are > the only two scopes for unicast IPv6. But... site-local unicast used > to exist, and while it's deprecated we have once seen it in the wild. > There's also host-local scope which I'm not sure is a term used by > IPv6, but is used by kernel netlinkg, and kind of exists in practice > (::1 and nothing else is host local). Yes, see the NOTE above. I was trying to find out if this was in any way useful (and it looks like it wasn't, at least from the current progress of https://github.com/containers/container-libs/pull/755). > > +} > > + > > /** > > * nat_inbound() - Apply address translation for inbound (HOST to TAP) > > * @c: Execution context > > @@ -993,13 +1007,15 @@ bool nat_inbound(const struct ctx *c, const union inany_addr *addr, > > /* Specifically 127.0.0.1, not 127.0.0.0/8 */ > > *translated = inany_from_v4(c->ip4.map_host_loopback); > > } else if (!IN6_IS_ADDR_UNSPECIFIED(&c->ip6.map_host_loopback) && > > - inany_equals6(addr, &in6addr_loopback)) { > > + inany_equals6(addr, &in6addr_loopback) && > > + fwd_scope6_match(&addr->a6, &c->ip6.map_host_loopback)) { > > This test will always be false: we just checked that addr == ::1, > which is not link-local (it's host-local, if we're admitting that > category). Oh, right, I didn't actually test this case. > > translated->a6 = c->ip6.map_host_loopback; > > } else if (!IN4_IS_ADDR_UNSPECIFIED(&c->ip4.map_guest_addr) && > > inany_equals4(addr, &c->ip4.addr)) { > > *translated = inany_from_v4(c->ip4.map_guest_addr); > > } else if (!IN6_IS_ADDR_UNSPECIFIED(&c->ip6.map_guest_addr) && > > - inany_equals6(addr, &c->ip6.addr)) { > > + inany_equals6(addr, &c->ip6.addr) && > > + fwd_scope6_match(&addr->a6, &c->ip6.map_guest_addr)) { > > This may be usually be right in practice, but it's kind of by > accident. > > The problem with both these checks is that they compare the scope of a > host side address (addr) with the scope of a guest side address > (c->map_*). Note that inany_equals6(addr, &c->ip6.addr) is pre-existing. Further, this "mismatch" is actually intended (see commit message and Podman's pull request I mentioned above), as I was trying to (quickly) make sure that we don't turn a global unicast request into a link-local one. > That's not what matters: what matters is that source and > destination on the tap side have the same scope. Not for this particular issue: again, I was just trying to make sure that a global unicast request doesn't get translated to a link-local one. This can probably checked in an indirect and more correct way "at the source". > In flow table terms, > that is, on a single flowside oaddr and eaddr must have the same > scope (or must they? see later). > > The scopes on one side of the flow don't need to match the scopes on > the other side of the flow. In fact we need to allow them to be > different: --map-host-loopback is *always* transforming a host-scope > flow on the outside to something else on the inside (either link-scope > or global-scope will work, as long as it's the same for both > addresses). We don't do it yet, but I can imagine cases where it > would be useful to translate a flow that's global-scope on the outside > to local-scope on the inside (because for some reason we want to or > have to hide the external peer's address from the guest). Or from > local-scope on the outside to global-scope on the inside (because the > outside flow is using local-scope addresses which are not meaningful > to the guest). Yes, definitely, that might actually be a feature, I just think we don't want to do that by default / mistake. In this case we had an inbound request to a global unicast address that was translated for some reason (we didn't really investigate) to a link-local destination address. But if it's explicit it should be allowed, by all means. > This has some tricky implications for what we do about assigning > addresses for "local mode" or any future variant where we need to > assign a guest address, but can't take one from the host. If we > assign a link-local address, as was our plan, that implies under this > assumption that the guest can only talk to link-local machines. In > practice that would mean only the host (via -map-*) or in future > things we added explicit NATs, where the guest side address is > link-local. The guest would have no ability to contact the internet > at large. I don't think that's desirable. > At least once we have the netlink monitor, maybe that's ok. While the > host has no address, the guest has only link local, so it can only > talk to the host (or explicitly configured forwards/NATs). But the > host has no connectivity anyway, so there's nothing else to talk to > anyway. When the host gets connectivity we add a global-scope guest > address, so it gets connectivity too. > > If that's not good enough, I can only see two approaches, neither of > which look great. > > a) For incoming connections from the world, to a guest with only an > LL address, we NAT *both* source and destination address (ugh, the > bookkeeping). The bookkeeping is already in place though. > Outgoing connections to the world are only possible for targets > where we've preconfigured a NAT. > > b) We _do_ allow different scopes on the two guest-side addresses. > This implies that the guest *expects and requires* their gateway > (us) to SNAT them. > > I suspect that the guest simply won't allow (b) to work for IPv6, but > it might for IPv4, since most things don't actually look for RFC3927 > addresses, and NAT is much more expected in general. I think it's rather complicated to define this before having played with the netlink monitor implementation itself, but again, this is well beyond the scope of this patch. The idea here is that *if* we have a global unicast address in a container, the mere fact that we have a link-local address in --map-guest-addr (not actually the case, it seems, but we haven't investigated further), shouldn't cause inbound traffic to be mapped to that link-local address. But note that I'm not sure if it's an actual problem or if it's even happening at all, at this stage. -- Stefano