[Libguestfs] Re: appliance not getting ipv4 assigned when host kernel has CONFIG_IPV6_SIT builtin

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" <rjones(a)redhat.com&gt; 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.