Message-ID: <aErch2cFAJK_yd6M@orbyte.nwl.cc>
Date: Thu, 12 Jun 2025 15:56:23 +0200
From: Phil Sutter <phil@....cc>
To: Antonio Ojea <antonio.ojea.garcia@...il.com>
Cc: Klaus Frank <vger.kernel.org@...nk.fyi>,
	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?

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?
> > >
> > > All I was able to find so far:
> > > * scanner patches related to "IPv4-Mapped IPv6" and "IPv4-compat IPv6"
> > > * multiple people asking about this without replies
> > > * "this is useful with DNS64/NAT64 networks for example" from 2023 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7b308feb4fd2d1c06919445c65c8fbf8e9fd1781
> > > * "in the future: in-kernel NAT64/NAT46 (Pablo)" from 2021 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=42df6e1d221dddc0f2acf2be37e68d553ad65f96
> > > * "This hook is also useful for NAT46/NAT64, tunneling and filtering of
> > > locally generated af_packet traffic such as dhclient." from 2020 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8537f78647c072bdb1a5dbe32e1c7e5b13ff1258
> > >
> > > It kinda looks like native NAT64/NAT46 was planned at some point in time but it just become quite silent afterwards.
> > >
> > > Was there some technical limitation/blocker or some consensus to not move forward with it?
> >
> > Not to my knowledge. I had an implementation once in iptables, but it
> > never made it past the PoC stage. Nowadays this would need to be
> > implemented in nf_tables at least.
> >
> > I'm not sure about some of the arguments you linked to above, my
> > implementation happily lived in forward hook for instance. It serves
> > well though in discovering the limitations of l3/l4 encapsulation, so
> > might turn into a can of worms. Implementing the icmp/icmpv6 translation
> > was fun, though!
> >
> > > I'm kinda looking forward to such a feature and therefore would really like to know more about the current state of things.
> >
> > AFAIK, this is currently not even planned to be implemented.
> >
> > Cheers, Phil
> >
> 
> 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?

> 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?

I also recall some loose ends regarding MTU since the packet size
increases when translating from v4 to v6.

Anyway, funny to see there is a public DNS64 run by Google. I had used a
DNS proxy named totd (the trick-or-treat daemon), but can't even find it
in the web anymore.

> phil point about icmp is really accurate :)

That wasn't ironic! Compared to other problems, getting ICMP working was
easy. :)

Cheers, Phil

Powered by blists - more mailing lists