[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABhP=tbUuJKOq6gusxyfsP4H6b4WrajR_A1=7eFXxfbLg+4Q1w@mail.gmail.com>
Date: Thu, 12 Jun 2025 20:19:53 +0200
From: Antonio Ojea <antonio.ojea.garcia@...il.com>
To: Phil Sutter <phil@....cc>, Antonio Ojea <antonio.ojea.garcia@...il.com>,
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 15:56, Phil Sutter <phil@....cc> wrote:
>
> 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?
> > 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?
Indeed we'll benefit a lot, see what we have to do :)
> > 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?
The current approach does static NAT64 first, switching the IPv6 ips
to IPv4 and adapting the IPv4 packet, the "real nat" is done by
nftables on the ipv4 family after that, so ... it may work?
Powered by blists - more mailing lists