[Jool-list] Getting NAT64 to work with systemd-nspawn containers connected with ipvlan.

[Ondřej Caletka]

On 17/12/2023 21:08, Rob Ert via Jool-list wrote:
> What I need now, is for the IPv6-only systemd-nspawn containerized 
> machine instances
> connected over ipvlan to be able access IPv4-only hosts (e.g. github.com 
> <http://github.com>).
> 
> I wasn’t able to get NAT64 working with my particular setup and my first 
> tries with tayga;
> ping -6 github.com <http://github.com> works on the host, but not on the 
> IPv6-only containers, as they don’t
> automatically have access to the host's nat64 tun device among other 
> things.  Is there any
> chance jool would be easier to get working with this particular setup?

Hello Rob,

what I see here is that due to the fact that you are using ipvlan, there 
is not a router owned by you in this setup. This makes it really tricky 
to put NAT64 in place. If your setup used a more traditional way of 
routing incoming traffic between the upstream interface and a bridge 
interface with veth pair to each container, deploying NAT64 would be 
pretty straightforward.

The problem with ipvlan interface is that you cannot alter the routing 
decision - on egress side, everything is either sent on the wire or to 
another ipvlan interface if it contains destination address. On ingress 
side, the destination address decides which ipvlan interface will 
receive it.

What you need to do is to route a prefix like 64:ff9b::/96 into a 
container that would work as NAT64. But this cannot happen with ipvlan 
as ipvlan driver will not figure out where to send such data - the 
destination IPv6 address will not belong to any ipvlan interface so the 
packet will end up forwarded to the wire.

I don't see any easy way out of this other than changing host setup to 
routing instead of ipvlan or deploying a separate NAT64 outside of your 
host.


--
Best regards,

Ondřej Caletka