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=202512 header.b=Pswz6Cno; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 6909B5A004E for ; Thu, 29 Jan 2026 06:18:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202512; t=1769663890; bh=97NjqviqdlXu7On0ftoP2zhY89VWOBiWtRfDGmxpnVs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Pswz6CnoWiRmoneqYgkaltdCD9bKpy2k0vP3PqNDeBzMr6X3hgAk8XhPl+pjaoBL9 MLLXA5hPpPGJP+V76MlYuiIe9E1qFhSbMDEtRVPfH9LzX/DY5dk8Tspcn6oLL3bBGx o7ChRMFsvvCEd+7/h68WLThlnGQhhKBUStxwpLmUweFnf1P948irmN2+MCQZQRveEh HXXX93xhFuyR+1f+WwSSN1qVH+9dKJ9rJfSNVRbM6hF6+nZn6r+4KliYgIsNUeUTlc gdnYe9HaJ6C1xbW5bCL5REklbEa0eP8yShm9e9D7FGo2BfsMk6QhFe0d4V+j5WxxN7 L6VtsI33FAEtA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4f1nTt1TBWz4wGT; Thu, 29 Jan 2026 16:18:10 +1100 (AEDT) Date: Thu, 29 Jan 2026 16:18:05 +1100 From: David Gibson To: Stefano Brivio Subject: Re: Thoughts on interface modes / multiple guest addresses Message-ID: References: <20251217012936.5aefec93@elisabeth> <20251218002220.18311a7b@elisabeth> <20251218063249.095e7614@elisabeth> <20260116042413.7c954c4f@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vRT6yyG972oIxSmK" Content-Disposition: inline In-Reply-To: <20260116042413.7c954c4f@elisabeth> Message-ID-Hash: OQ3BY42A73SGEWUQN62KM5ZQO6EN6STI X-Message-ID-Hash: OQ3BY42A73SGEWUQN62KM5ZQO6EN6STI 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: Jon Maloy , passt-dev@passt.top 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: --vRT6yyG972oIxSmK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 16, 2026 at 04:24:13AM +0100, Stefano Brivio wrote: > On Mon, 5 Jan 2026 15:26:34 +1100 > David Gibson wrote: >=20 > > On Thu, Dec 18, 2025 at 06:32:49AM +0100, Stefano Brivio wrote: > > > On Thu, 18 Dec 2025 14:47:06 +1100 > > > David Gibson wrote: > > > =20 > > > > For multi-address support there are at least four things to conside= r: =20 > > >=20 > > > For the bits related https://bugs.passt.top/show_bug.cgi?id=3D141, I > > > thought Jon was working on a proposal. > > > =20 > > > > (a) What goes in our internal list of addresses to give the guest? > > > >=20 > > > > a.1. Everything listed with -a? =20 > > >=20 > > > If anything is passed, yes, those, and just those (separately for IP > > > version), because the user is clearly overriding addresses (as > > > currently implemented and documented). =20 > >=20 > > So far, so good. But including both explicit addresses and host > > addresses seems potentially useful to me (especially for an > > intermittently online host). It's not the first step, but I think we > > want to think about how we'd allow this. >=20 > I'd really keep it for much later and I didn't, on purpose, add this to > https://pad.passt.top/p/netlinkMonitor. >=20 > But I guess we could eventually have some pointers / special values for > -a, say, -a 192.0.2.1 -a eth0/* would add all the addresses that will > ever be added to eth0, while keeping 192.0.2.1 ("preferred"?). Right, something like that is pretty much what I had in mind. > For scrapers: if, instead, you pass -a *, that will obviously add the > list of filenames in the current directory as IP addresses. Not many > know this, but .. is indeed a valid IPv6 address, in this paragraph. >=20 > > > > a.2. Everything on the host? =20 > > >=20 > > > No, because you can't assume you can configure all those addresses on > > > a single interface. Adding multiple interfaces is something we could > > > consider later. =20 > >=20 > > Hm, depends what you mean by "can". The only case I can see they > > really can't be configured on the same interface is if they're > > link-local. But AFAICT, there's nothing to really stop you putting > > any combination of global-scope addresses on a single interface. It > > will less resemble the host's configuration, but again, there are > > degrees of transparency not a single standard. >=20 > Hmm, right, I was actually thinking of the associated routes: it might > be impossible to have meaningful routes / default gateways. We don't > necessarily care though. Maybe not. Working out something sensible to advertise to the guest in the case of a complicated and dynamic routing setup on the host, is what I had in mind for "opaque mode" (still needs a better name :/). The idea is that by *not* exposing the host's routing set at all, the host can have an arbitarily complex, arbitrarily changing set of routes and the guest can still work. Trying to deal with complex and changing host setups while retaining route transparency, at minimum requires multiple interface support, but (IMO) worse it requires us to understand and monitor essentially every possible routing config on the host so that we can reflect it into the guest. > In any case, I'd just pick addresses from the template interface for > the moment being. It's the least surprising option, the closest to what > we do now. >=20 > > > > a.3. Everything on the host template interface? =20 > > >=20 > > > Everything on the host template interface if available (as currently > > > documented). =20 > >=20 > > As a first step, sure. > >=20 > > > > a.4. A link local address we pick? =20 > > >=20 > > > A link-local address if nothing else is available (as currently > > > documented). This will need to be permanent for the requirement we > > > already discussed months ago with Podman developers. =20 > >=20 > > Right, but if this is permanent it potentially conflicts with > > link-local addresses from the host interface >=20 > Ah, well, yes, but we should never copy those. If the same address > appears on the host... mark things as broken and fallback to NAT? Never copying host link-local addresses would simplify things, but if so, I don't think we should ever forward anything to link-local peers of the host either, which we do at the moment. The question here is whether the link-local space of the tap interface is quasi-bridged to one of the host's link-local spaces, or is it a private space restricted to just the guest and host (and maybe sibling-guests handled by the same passt instance, if we support that in future). The two choices are what my proposed two mode are fundamentally about. > This is something we should take care of right away, I guess. But the > problem is actually pre-existing because we already have "local mode". > I'm not sure if there's a problem, actually, I guess we should check. >=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 --vRT6yyG972oIxSmK Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAml67YwACgkQzQJF27ox 2GcBGQ/+NKSBPmg1Nfp5W+ofz0J1llIb1Vgevp5Q0j7ObAjYvhgGhD9eKuNrigs+ qSY0QA11diSXxQq2eWN0rZRwrG+i7PzVkCBloONUfGwIgL35DSo+cUzUo24ejj5N QxcEtXsTYxaL3jMocI+LdD/qVX37ScbrXMAtyELqBU+OmXjsLN/XNXsR7Ou6CZeV YNqkZUd+A9OoeqGHDvwlPIMoW0N2QW3TGNYDdqpHAH9LCWjZi0qbc3rvROp0+1r3 EGhQgGTczxTFv2AaRH90bkPb9/6l2HkmnfiCm/KymHrwkdX4UYRfkEbczNtSoVCc 4iXBiKiamILlZO2GRktVNN7s4J3m7XsT2X/Boj0nTZCvf5Uuk9KuhHj3zcmx41TO kCiYZGou9uDrxoMq8xOksWXKag0657j4AX4y8f2AlwEOdADhNv5ZvBorax8+c8wf qwr+ptz/LYV8I1a9mK65RDAscLuqHKB5dMMR8nU1eOZm+2bqxAgiiRH4pddtAHre bqXpj72yCyH3wYpEFxvkrPjdCZjnMoPFqbc5XQVcoueibXAI4aq189cQFsGHi72A 3rx/tFnJOSonNvxlA9lOwLS08oa95Nh+QKVjhpFqZ47L8sDNxvWAbQhfx+CrZssF iHWMnlRrEeN/5KpYqitlloCj48wnYeZa4+poop0fR1+SYSHtj74= =Xxjz -----END PGP SIGNATURE----- --vRT6yyG972oIxSmK--