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@xxxxxx> 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
