Re: [RFC net-next 08/15] ipxlat: add translation engine and dispatch core

[Beniamino Galvani]

On Mon, Jun 22, 2026 at 05:56:11PM +0200, Ralf Lici wrote:
> > speaking as a maintainer of NetworkManager, I would also like to see
> > this feature in the kernel!
> >
> > In NetworkManager currently we are using a BPF program [1] to
> > implement the CLAT, but that approach comes with limitations: for
> > example, we can't fragment v4->v6 packets if needed, and it's not
> > possible to recompute checksums in certain cases (e.g. for v4->v6 UDP
> > packets with zero checksum, and for fragmented ICMP). systemd-networkd
> > is also adding CLAT support via BPF [2], with a fallback to userspace
> > for the cases that can't be handled in kernel.
> >
> > It would be very useful to have a native in-kernel CLAT that solves
> > the limitations of BPF-based solutions, and can be used by different
> > tools without having to re-implement everything from scratch.
> >
> 
> Thanks, this is really useful context.
> 
> CLAT is exactly the kind of consumer ipxlat aims to serve, and the gaps
> you hit in BPF line up directly with paths ipxlat already handles. I'll
> cite this as motivation in the next cover letter, if that's alright.

Yes, please do!

> While reading the BPF programs, two things stood out that would help
> shape v2. On addressing, both implementations use a single NAT64/PLAT
> prefix for destinations plus an explicit local_v4<>local_v6 mapping for
> the host itself. ipxlat today maps both source and destination through
> one RFC 6052 prefix, so this suggests v2 should probably support
> explicit 1:1 address mappings (EAM, RFC 7757) alongside prefix
> embedding. Is a single local mapping enough for your case, or do you
> foresee needing several?

Based on these:

  https://datatracker.ietf.org/doc/html/rfc6877#section-6.3
  https://www.ietf.org/archive/id/draft-ietf-v6ops-claton-14.html#name-obtaining-clat-ipv6-address

there are two cases to consider for CLAT.

If the node doing CLAT extends the IPv4 connectivity downstream, it
should acquire a dedicated prefix via DHCPv6-PD for the downstream
network, and use this prefix to generate IPv4-Embedded IPv6 Addresses
(RFC 6052 2.2) for downlink hosts. In this case, the ipxlat device
would need to be configured with two prefixes: one is the NAT64 prefix
used to synthesize IPv6 destinations for IPv4 Internet addresses, and
the other is the delegated prefix used to synthesize IPv6 source
addresses for hosts on the downstream IPv4 network. Ideally, the
ipxlat device should also be aware of the address range of the
downstream IPv4 network, and check that the source addresses of
packets belong to that network.

If the node doing CLAT does not extend IPv4 connectivity downstream
(or it does, but it also uses NAT44), the "downstream network" is
basically just one host. The CLAT only needs to map a single
locally-generated IPv4 address (usually in the 192.0.0.0/29 range) to
a single SLAAC IPv6 address reserved for the CLAT. In this case, the
ipxlat device would need to know the CLAT IPv4 address, the CLAT IPv6
address and the NAT64 prefix.

Currently, NetworkManager only uses a single IPv4 address and doesn't
request a dedicated prefix via DHCPv6-PD for the CLAT. If it needs to
provide downstream connectivity, it does IPv4 masquerading so that the
traffic originates from a single IPv4 address. I think the ipxlat
implementation should also support the delegated-prefix case, as this
architecture is described in the standards.

> On the consumer side, is there anything in how NM models a connection
> that would make a particular kernel model awkward to drive, e.g. needing
> to attach to an already-managed interface, or conversely being able to
> create and own a dedicated device? We're still settling the
> kernel-facing model for v2, so consumer input here is genuinely
> valuable.

Any of the solutions mentioned in the thread (dedicated device,
netfilter, LWT) would be fine from NetworkManager's point of
view. Compared to what we are doing now, they would be a great
simplification ;)


Beniamino