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

[Alberto Leiva]

> Also, I am not able to get jool compiled for my kernel at this time;
> I am dependant on a recent kernel, as I am using/testing bcachefs:

In regards to this, please note that jool.mx is now a zombie domain.
We've been trying to recover it (or destroy it), but so far our
efforts have been fruitless. At present, Jool's official website is
https://nicmx.github.io/Jool/en/index.html, and the latest version is
4.1.10, not 4.1.7.

... That said, 4.1.10 also doesn't support kernel 6.7:
https://nicmx.github.io/Jool/en/intro-jool.html#compatibility

But I just tried Jool's latest commit (from the main branch) in kernel
6.7-rc6, and it compiles without issues.

I realize Jool 4.1.11 is quite overdue at this point, so I will try to
squeeze a new release into this week's schedule. But I'm not confident
I'm going to make it in time; December is a difficult month.

In any case, can you compile the latest main?

On Mon, Dec 18, 2023 at 5:16 AM Ondřej Caletka via Jool-list
<jool-list at nic.mx> wrote:
>
> 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
>
> _______________________________________________
> Jool-list mailing list
> Jool-list at nic.mx
> https://mail-lists.nic.mx/listas/listinfo/jool-list