Hello all, I need IPv4 connectivity for my particular ipvlan server setup and was hoping someone might be able to help. My grasp of the subject matter is too limited, but more knowledgeable people are telling me that NAT64 will be difficult if not impossible to get working with ipvlan: https://mail-lists.nic.mx/pipermail/jool-list/2023-December/000498.html I am a little reluctant to do away with my ipvlan setup (described in the link above), as it works very well, albeit minus IPv4 connectivity :-). Since “Tundra-NAT64” is designed as a translator for one host, I was thinking, maybe NAT64 could be realized with Tundra-NAT64 running inside the individual systemd-nspawn containers as an alternative to setting up full dual-stack IPv6 and IPv4-rfc1918 with masquerading for the individual containers? I can install Tundra-NAT64 in a systemd-nspawn container with the following systemd.nspawn overrides: [Exec] PrivateUsers=off Timezone=off Capability=CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_NET_ADMIN CAP_SYS_NICE CAP_CHOWN CAP_IPC_LOCK [Network] IPVLAN=enp1s0 I would rather not keep these overrides in production, but I assume if it works with the overrides, it can be set up beforehand with systemd-networkd without overrides. According to the documentation, ipvlan in L3S mode provides netfilter hooks: “In L3S mode, virtual devices process the same way as in L3 mode, except that both egress and ingress traffics of a relevant container are landed on netfilter chain in the default namespace. L3S mode behaves in a similar way to L3 mode but provides greater control of the network.” I was hoping someone might be able to give me some pointers as to how to get something like this to work, or tell me definitively that it is not practically possible; but then, I really don’t understand what L3S mode is good for. I am also open to using “Jool” or “Tayga” for NAT64. Many thanks, all the best and Happy Holidays, Rob
