Re: Thoughts on interface modes / multiple guest addresses

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 5196 bytes --]

On Fri, Jan 16, 2026 at 04:24:13AM +0100, Stefano Brivio wrote:
> On Mon, 5 Jan 2026 15:26:34 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Thu, Dec 18, 2025 at 06:32:49AM +0100, Stefano Brivio wrote:
> > > On Thu, 18 Dec 2025 14:47:06 +1100
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >   
> > > > For multi-address support there are at least four things to consider:  
> > > 
> > > For the bits related https://bugs.passt.top/show_bug.cgi?id=141, I
> > > thought Jon was working on a proposal.
> > >   
> > > > (a) What goes in our internal list of addresses to give the guest?
> > > > 
> > > >     a.1. Everything listed with -a?  
> > > 
> > > 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).  
> > 
> > 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.
> 
> I'd really keep it for much later and I didn't, on purpose, add this to
> https://pad.passt.top/p/netlinkMonitor.
> 
> 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.
> 
> > > >     a.2. Everything on the host?  
> > > 
> > > 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.  
> > 
> > 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.
> 
> 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.
> 
> > > >     a.3. Everything on the host template interface?  
> > > 
> > > Everything on the host template interface if available (as currently
> > > documented).  
> > 
> > As a first step, sure.
> > 
> > > >     a.4. A link local address we pick?  
> > > 
> > > 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.  
> > 
> > Right, but if this is permanent it potentially conflicts with
> > link-local addresses from the host interface
> 
> 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.
> 
> -- 
> Stefano
> 

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]