On Thu, 12 Jun 2025 at 11:57, Phil Sutter <phil@xxxxxx> 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 :)
