Message-ID: <s4ffjiihvgv6glpvd3rbqr3cedprmgqijxiz2dh6v5lq4doabd@gpis5xfdyea5>
Date: Thu, 12 Jun 2025 22:19:46 +0000
From: webmaster@...wa338.de
To: Phil Sutter <phil@....cc>, Klaus Frank <vger.kernel.org@...nk.fyi>, 
	Antonio Ojea <antonio.ojea.garcia@...il.com>, netfilter-devel@...r.kernel.org, 
	Pablo Neira Ayuso <pablo@...filter.org>, Florian Westphal <fw@...len.de>, Lukas Wunner <lukas@...ner.de>, 
	netfilter@...r.kernel.org, Maciej Żenczykowski <zenczykowski@...il.com>, 
	netdev@...r.kernel.org
Subject: Re: Status of native NAT64/NAT46 in Netfilter?

On Thu, Jun 12, 2025 at 11:55:06PM +0200, Phil Sutter wrote:
> On Thu, Jun 12, 2025 at 08:13:02PM +0000, Klaus Frank wrote:
> > On Thu, Jun 12, 2025 at 09:45:00PM +0200, Phil Sutter wrote:
> > > On Thu, Jun 12, 2025 at 08:19:53PM +0200, Antonio Ojea wrote:
> > > > On Thu, 12 Jun 2025 at 15:56, Phil Sutter <phil@....cc> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Thu, Jun 12, 2025 at 03:34:08PM +0200, Antonio Ojea wrote:
> > > > > > On Thu, 12 Jun 2025 at 11:57, Phil Sutter <phil@....cc> wrote:
> > > > > > > On Sun, Jun 08, 2025 at 08:37:10PM +0000, Klaus Frank wrote:
> > > > > > > > I've been looking through the mailling list archives and couldn't find a clear anser.
> > > > > > > > So I wanted to ask here what the status of native NAT64/NAT46 support in netfilter is?
> > > > 
> > > > > > we ended doing some "smart hack" , well, really a combination of them
> > > > > > to provide a nat64 alternative for kubernetes
> > > > > > https://github.com/kubernetes-sigs/nat64:
> > > > > > - a virtual dummy interface to "attract" the nat64 traffic with the
> > > > > > well known prefix
> > > > > > - ebpf tc filters to do the family conversion using static nat for
> > > > > > simplicity on the dummy interface
> > > > > > - and reusing nftables masquerading to avoid to reimplement conntrack
> > > > >
> > > > > Oh, interesting! Would you benefit from a native implementation in
> > > > > nftables?
> > > > 
> > > > Indeed we'll benefit a lot, see what we have to do :)
> > > > 
> > > > > > you can play with it using namespaces (without kubernetes), see
> > > > > > https://github.com/kubernetes-sigs/nat64/blob/main/tests/integration/e2e.bats
> > > > > > for kind of selftest environment
> > > > >
> > > > > Refusing to look at the code: You didn't take care of the typical NAT
> > > > > helper users like FTP or SIP, did you?
> > > > 
> > > > The current approach does static NAT64 first, switching the IPv6 ips
> > > > to IPv4 and adapting the IPv4 packet, the "real nat" is done by
> > > > nftables on the ipv4 family after that, so ... it may work?
> > > 
> > > That was my approach as well: The incoming IPv6 packet was translated to
> > > IPv4 with an rfc1918 source address linked to the IPv6 source, then
> > > MASQUERADE would translate to the external IP.
> > > 
> > > In reverse direction, iptables would use the right IPv6 destination
> > > address from given rfc1918 destination address.
> > > 
> > > The above is a hack which limits the number of IPv6 clients to the size
> > > of that IPv4 transfer net. Fixing it properly would probably require
> > > conntrack integration, not sure if going that route is feasible (note
> > > that I have no clue about conntrack internals).
> > 
> > Well technically all that needs to be done is NAT66 instead of NAT44
> > within that hack and that limitation vanishes.
> 
> I don't comprehend: I have to use an IPv4 transfer net because I need to
> set a source address in the generated IPv4 header. The destination IPv4
> address is extracted from the IPv6 destination address. Simple example:
> 
> IPv6-only internal:     fec0::/64
> v6mapped:               cafe::/96
> external IPv4:          1.2.3.4
> internal transfer IPv4: 10.64.64.0/24
> 
> Client sends:       IPv6(fec0::1, cafe::8.8.8.8)
> nat64 in fwd:       IPv4(10.64.64.1, 8.8.8.8)
> nat in postrouting: IPv4(1.2.3.4, 8.8.8.8)
> 
> Google replies:     IPv4(8.8.8.8, 1.2.3.4)
> nat in prerouting:  IPv4(8.8.8.8, 10.64.64.1)
> nat64 in fwd:       IPv6(cafe::8.8.8.8, fec0::1)

The IPv6 subnet has more IPs than the internal transfer IPv4 network.
Therefore doing a NAT66 to condense all of them into one IPv6 address
means you only need 1 IPv4 in the internal transfer net. Therefore the
limitation stated above no longer applies. Admittedly if you do the
nat44 within a dedicated network namespace while sharing an IPv4 with
the host you'd still need to do NAT44 too.

> 
> > > The actual issue though with protocols like FTP is that they embed IP
> > > addresses in their headers. Therefore it is not sufficient to swap the
> > > l3 header and recalculate the TCP checksum, you end up manipulating l7
> > > headers to keep things going. At least there's prior work in conntrack
> > > helpers, not sure if that code could be reused or not.
> > 
> > If nat64 functionality was added within conntrac itself then it would be
> > easy to reuse the l7 helpers. If it was anywhere else the l7 helpers
> > within conntrack would have to be re-implemented as conntrack wouldn't
> > know the mappings and therefor it probably would be quite hard to do the
> > rewrites.
> > Also in regards to FTP not just L7 headers but also payload needs to be
> > edited on the fly. As it often uses differnt commands for IPv4 and IPv6
> > (even though the IPv6 ones also support IPv4) and it embeds the IPs as
> > strings.
> > 
> > EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
> > 
> > where "net-prt" is either 1 for IPv4 or 2 for IPv6. and net-addr is the
> > string representation.
> > However a client may send the "PORT" command instead...
> > Also RFC2428 may be helpful in this context.
> > 
> > I think if it was possible to get the nat64 into conntrack it should
> > also be possible to take care of this more easily as with external
> > "hacks".
> 
> I agree it would probably be the cleanest solution.
> 
> > Also in regards to the above code it looks like currently only tcp and
> > udp are supported. All other traffic appears to just dropped at the
> > moment instead of just passed through. Is there a particular reason for
> > this?
> 
> I guess tcp and udp are simply sufficient in k8s.

doesn't k8s also support sctp? Also still no need to just drop
everything else, would have expected to just pass through it without
special handling...

> 
> Cheers, Phil

Powered by blists - more mailing lists