[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aEqka3uX7tuFced5@orbyte.nwl.cc>
Date: Thu, 12 Jun 2025 11:56:59 +0200
From: Phil Sutter <phil@....cc>
To: Klaus Frank <vger.kernel.org@...nk.fyi>
Cc: 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 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
Powered by blists - more mailing lists