On Tue, Jun 24, 2025 at 01:57:09PM +0200, Stefano Brivio wrote:
> On Tue, 24 Jun 2025 12:33:17 +0100
> "Richard W.M. Jones" <rjo...@redhat.com> wrote:
> > I'm a bit confused here.  How does host IPv4 or IPv6 affect what
> > happens in the appliance?
> 
> The appliance still needs to connect to hosts using IPv4 or IPv6
> addresses.
> 
> My hope was simply that availability of IPv6 would work around the
> issue, because IPv4 isn't configured here (due to the issue I'm pointing
> out).

OK I see, I think.  By "isn't configured" you mean because we pick the
sit0 interface instead of eth0?  (Obviously that's wrong, but the
"ls -I" command is a bit of a hack.)  We could add "-I sit" there.

> The interface appliance/init selects to configure IPv4 via DHCP is
> sit0 instead of eth0.
> 
> > For example if the host only had IPv6, it should still work wouldn't
> > it?
> 
> With IPv6 only, appliance/init would at least need to bring up the
> interface to configure the interface via SLAAC. I don't see it being
> done, so, unless it's done implicitly somewhere, that shouldn't work,
> either.
>
> I guess that should be fixed as well, with, say:
> 
>     ip link set "${iface}" up
> 
> > Also I'm confused where sit0 comes from (or even what it is, really).
> > Why does it appear inside the appliance at all?
> 
> See original report from Aithal for full details (and in my opinion a
> reasonable request to offer a way to disable the module inside the
> appliance).

"the module" meaning ipv6/sit.ko?

> Long story short, you configure the kernel with CONFIG_IPV6_SIT, and
> the kernel will automatically create the sit0 interface at boot, which
> causes appliance/init to ask dhclient to configure it (instead of eth0).
> 
> SIT stands for "Simple Internet Transition" and it's essentially the
> 6to4 (https://en.wikipedia.org/wiki/6to4) implementation on Linux. It's
> not supposed to be used in the appliance at all, but the interface
> appears merely because the kernel is configured with it.
> 
> > My mental model is that passt provides an IPv4 address inside the host
> > on eth0.  If the host has, say, only IPv6, then requests would be
> > proxied out over that.  We don't care how that happens precisely.
> 
> Protocol families are not simply proxied between each other because
> there's no shared address space between IPv4 and IPv6.

If passt is like slirp, then it would originate connections itself
(ie. calling connect(2) on the host side), so I don't understand how
the address family would be relevant.  I guess passt is not like slirp
in this regard?

> Let's say you connect to 88.198.0.164 from the appliance, but there's
> no IPv4 routing available on the host: passt will *not* reverse-resolve
> 88.198.0.164 to passt.top and connect you to 2a01:4f8:222:904::2
> instead. That would be kind of surprising and add convoluted DNS
> requirements.
> 
> We have a request for CLAT:
> 
>   https://bugs.passt.top/show_bug.cgi?id=43
> 
> where one could do something like that, but you would need to configure
> it explicitly (the day it's implemented).
> 
> In any case, this has all little to do with the actual issue. The
> problem is that the appliance runs dhclient or dhcpcd on sit0 instead
> of eth0, because excluding "all", "default", and "lo" is not enough. If
> you prefer a minimal fix:
> 
>     iface=$(ls -I all -I default -I lo -I sit0 /proc/sys/net/ipv4/conf)

Yes, this seems like the more obvious change, but there seems there
might be something very deep that I'm missing here.

> would also work.
> 
> I can send a patch, too, but it might take me a while before I find a
> moment to prepare the test setup.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
_______________________________________________
Libguestfs mailing list -- guestfs@lists.libguestfs.org
To unsubscribe send an email to guestfs-le...@lists.libguestfs.org

Reply via email to