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=FBhdbitm; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id D51075A065D for ; Mon, 22 Dec 2025 06:57:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202512; t=1766383050; bh=fw8uTp8TWN3YHrf6AKHJb6kd2f7PAvHOVuEkzG7l8h4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FBhdbitmpF63khsIeMgwtRk1HM+6Z7g2vFwwUE9ZIZdDdZEerH+eVNVsFzDlX9mUZ mhrzZY806XivIuRFMjoqfISn95OTAKLjgVzhIHQRzy3RFfZFE5BnEkvz3R0V/Q+T7C 0HpkNtdc++HHoaiYLeklISJaKbvMU+AuPdjz4nuBl7i5R7gw4vFAHHHbnUGyWRV/fW hJK5Np81hKA5IKOb3yyE2uiWB4Fj8vTHLQMCxbXgTVu/j1eFiAzS69J494CgnhwFtU NdNzVcAlEuelclaxTOOESNH3+hkqZ/CZqQKxYfjoQbS58tMrhbsmn7i9znPwlmFka9 ++g2UzGgsc1JQ== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4dZS8p67tPz4wR4; Mon, 22 Dec 2025 16:57:30 +1100 (AEDT) Date: Mon, 22 Dec 2025 16:57:14 +1100 From: David Gibson To: Jon Maloy Subject: Re: Thoughts on interface modes / multiple guest addresses Message-ID: References: <20251217012936.5aefec93@elisabeth> <7314536d-ecdd-4f72-9071-b3c38fd92abb@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JBjG2ww2hJid+9Nj" Content-Disposition: inline In-Reply-To: <7314536d-ecdd-4f72-9071-b3c38fd92abb@redhat.com> Message-ID-Hash: Q33OGCFXRIT564FRXJPOSJGH56QZI3ZO X-Message-ID-Hash: Q33OGCFXRIT564FRXJPOSJGH56QZI3ZO 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: Stefano Brivio , 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: --JBjG2ww2hJid+9Nj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 18, 2025 at 08:40:45PM -0500, Jon Maloy wrote: >=20 >=20 > On 2025-12-17 19:14, David Gibson wrote: > > On Wed, Dec 17, 2025 at 03:01:31PM -0500, Jon Maloy wrote: > > >=20 > > >=20 > > > On 2025-12-16 21:01, David Gibson wrote: > > > > On Wed, Dec 17, 2025 at 01:29:36AM +0100, Stefano Brivio wrote: > > > > > On Tue, 16 Dec 2025 16:53:49 +1100 > > > > > David Gibson wrote: > > > > >=20 > > > > > > Hi Jon, > > > > > >=20 > > > > > > As discussed on the call yesterday, I've written up my thoughts= on > > > > > > what a bunch of the address semantics should be. Turns out I'd > > > > > > already done some of this at: > > > > > > https://pad.passt.top/p/InterfaceMode > > > > >=20 > > > > > Two general comments: > > > > >=20 > > > > > 1. local mode is already implemented, and some things such as the > > > > > interface name ("tap0") are already defined, see man page and > > > > > 'pasta -- pasta --config-net ip a' > > > >=20 > > > > Yes, I'm aware. The two modes have the "normal" and "local" local = to > > > > indicate the existing modes they're more similar to (neither is > > > > identical to current behaviour). Another point I left out is that > > > > this is intended as an endpoint to aim at. Getting there I expect = to > > > > involve extra stuff for compatiblity along the way. > > > >=20 > > > > > 2. I think it's more relevant to define the basics of how one swi= tches > > > > > between the existing local mode and a mode where we copy add= resses > > > > > and routes (as they become available on the host), rather th= an > > > > > defining every single detail of these modes. > > > >=20 > > > > Oh.. right. I guess I did't make this clear: these are modes set by > > > > the command line (details TBD), we never switch between them at > > > > runtime. They kind of have to be, because which mode we're in affe= cts > > > > how we respond to runtime changes. > > > >=20 > > > > > In these terms, I think it would actually be helpful to *avo= id* > > > > > seeing them as separate modes. If there's no host connectivi= ty, we'll > > > > > start in local mode, and switch to the other mode as we get = addresses > > > > > and routes configured... just to switch back to the previous= mode if > > > > > we lose them. > > > >=20 > > > > The whole point of all-interface mode (better name suggestions > > > > welcome) is that the guest's routing configuration *doesn't* change, > > > > even if the host's does. > > > >=20 > > > > Advantages: > > > > * The host can have whatever source-dependent, multi-path, bizar= ro > > > > routing configuration, changing as often as it likes and we (a= nd > > > > the guest) don't care. Guest routes to the host, host routes > > > > onward from there. > > >=20 > > > And the other way around, the guest should be able to set up whatever > > > he wants if that is his choice, without affecting the host. Maybe > > > even multiple interfaces, for whatever reason that might be. > >=20 > > I'm not sure I follow. We can't change net config on the host, so > > that's basically always true - in both proposed modes, and right now. > > So maybe you're meaning something different? I'm not sure what, > > though. >=20 > No. I was just stating a fact. Ok. > But if we want to give the guest full freedom > to adapt or screw up his own namespace we may in the name of consistency > allow him to create his own interfaces (dummy, veth, tun/tap?) They already can, and indeed we can't really prevent it. Moreover, there are legitimate, working cases where the guest will create other interfaces. The most obvious is if the guest creates a VPN tunnel, with the back end encrypted traffic going over the pasta link. > > > We could have two modes: "transparent" and "opaque" > >=20 > > I'm not 100% sold, but I think those are at least a bit better than my > > current names (doc updated). > >=20 > > > In opaque mode we get basically what you describe above, plus that we= allow > > > the guest to add new addresses/routes in runtime. > >=20 > > THe guest could always add extra routes at runtime. Adding extra > > addresses... well, it always could, the question is what - if anything > > - passt/pasta should do about it. What do you propose? >=20 > Just allow it and handle it right, i.e., as expected by the guest. We don't necessarily know what's expected by the guest. If a physical machine on a DHCP managed LAN were to ignore DHCP and just pick an address, it *might* work, or its traffic might just get blackholed, or it might get messy address conflicts, depending on the router configuration, and what else is on the subnet, and possible firewalls between it and the internet at large. > > > So, we keep the multi-address configuration and and the nameaspace si= de > > > subscription, but block host-side subscriptions in this mode. > >=20 > > My intention was that we don't use a host-side *route* subscription in > > this mode. We would still need a host-side address subscription to > > implement '-a auto', which I was proposing to have allowed (and > > enabled by default) in opaque mode. >=20 > That beats the whole purpose of opaque mode, doesn't it? Not as I see it, no. > > > Conversely, we are fully open to host-changes in transparent mode, we > > > subscribe for host-side changes, forward those to the namespace, > >=20 > > With --config-net, yes. For passt and !--config-net we can't control > > the guest configuration; we can only reflect as much of the host state > > as possible via DHCP and NDP, and hope the guest will consult that and > > update itself. > >=20 > > > However, we don't allow the guest user to manipulate anything in run-= time. > >=20 > > Well, we can't really prevent it. I guess you mean if the guest > > reconfigures itself, then things might break entirely and it's not our > > fault? >=20 > Yes. Give him full freedom. To fix or break his own namespace. Agreed. --=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 --JBjG2ww2hJid+9Nj Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmlI3bkACgkQzQJF27ox 2Gdxwg//VN4p+86/VgGxvjz3MapZb7WXLAEqpLhbXsb6nslbW3oGm8M31rDigHOA f07TkjSIzAml4gMrSRt/GkwfgtQWikvXMr+UIz0e5Ml1Hk3VL/YH0jG9jWkaTz2r LtqBEVrk7XYY7JssdtfKSaLpgjKVaqCLcqSMu854SiBnwUoqpHi7DeEDO+C4T4QM CcuovZCoz4/clphdo8yre5hyy+wNTbYcedNlYehpWUrIrZkxgE2u4KepmJwCR5SA sD/aJaH/4usWx86Bs0E+Mq7rrJTgZDNGC4i6yKCd92K+ntlgTq9YwYQfTfA85alT AHK4jv3SvVUQI7AzbfcSCp4wkKuMFE4ytHwTX7+9iCSkTee9GPZG9cDrFUPEIkrR aBA0jnWG1FVsDScLt1mEEvgQLVomNuZuXs6CbZDnlqyj13ySrD1STAVqKAfkIMnu 3mAFqAIlcHW1O6VnwJQNd01o8dm19wDS4DPkEFH4AHwzf4pC39XIL6B+tUEorYr8 rL8GZb8SIMAa8YLQqkXqLBywpkXW2EOzcrouLUwtf+BTX05n+2LDlY4TOiQu8E+P TJT37lLgRMpAqwfpV4fjfr4CsGdoAZ6Q7h6MNn9lKilXm0YU1XsVhQafyjHfA/jO RuEeVNfr7SSqCbXoRDkTwpgo5twkLfLVavpqW1RFFCLsPbjY2h4= =4GYY -----END PGP SIGNATURE----- --JBjG2ww2hJid+9Nj--