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

[Ralf Lici <ralf@mandelbit.com>]

On Tue, 23 Jun 2026 10:05:06 +0200, Beniamino Galvani <bgalvani@redhat.com> wrote:
> On Mon, Jun 22, 2026 at 05:56:11PM +0200, Ralf Lici wrote:
> > 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.
>

I see. Your CLAT breakdown makes it clear that the single-prefix model
in this RFC is too narrow for v2. What I am currently thinking is to
shape the config as a far-side prefix plus an optional near-side map.
The 2 CLAT cases then can be represented roughly as:

    remote-prefix6 64:ff9b::/96
    local-map      192.0.0.1/32 2001:db8:1:2::1234/128

for the single-host CLAT case (which is an explicit 1:1 mapping), and:

    remote-prefix6 64:ff9b::/96
    local-map      192.0.2.0/24 2001:db8:100:64::/96

for the downstream/delegated-prefix case.

The idea is that remote-prefix6 is the RFC 6052 prefix used for the
NAT64/PLAT side, while local-map optionally describes the near-side
mapping. If local-map is omitted, the translator falls back to the
symmetric v1 behavior where the same RFC 6052 prefix is used for both
source and destination.

On the source-range check you mentioned: it falls out of the near-side
map for free. In the 4->6 direction the source is resolved through
local-map only, so a source outside its IPv4 domain (the /32 or the /24
above) simply has no near-side mapping and is dropped, so no separate
anti-spoofing knob should be needed. Anything broader than "is this a
valid near-side source" I'd leave to routing/nft rather than bake into
the translator.

Names and exact attribute shape are still WIP, but does this capture the
two CLAT cases you had in mind?

> > 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 ;)
>

Nice, thanks for confirming!

-- 
Ralf Lici
Mandelbit Srl