netdev - Re: Status of native NAT64/NAT46 in Netfilter?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABhP=tZRP42Dgw9+_vyAx80uPg4V2YFLfbGhpA10WzM46JYTNg@mail.gmail.com>
Date: Thu, 12 Jun 2025 15:34:08 +0200
From: Antonio Ojea <antonio.ojea.garcia@...il.com>
To: Phil Sutter <phil@....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?

On Thu, 12 Jun 2025 at 11:57, Phil Sutter <phil@....cc> wrote:
>
> Hi,
>
> 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

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

phil point about icmp is really accurate :)