Re: Adding NAT64 to Netfilter

[Laura Garcia <nevola@gmail.com>]

On Fri, Jan 3, 2020 at 7:10 PM Alberto Leiva <ydahhrk@gmail.com> wrote:
>
> Hello
>
> I've been working on Jool, an open source IP/ICMP translator for a
> while ([0]). It currently implements SIIT, NAT64 and (if everything
> goes according to plan) will later this year also support MAP-T. It
> currently works both as a Netfilter module (hooking itself to
> PREROUTING) or as an xtables target, and I'm soon going to start
> integrating it into nftables.
>

Hi Alberto, I was analyzing the impact to add support NAT64/46 several
months ago. It seems that you've done a very good job.

In regards to the iptables approach, do you have any benchmark
compared to the NAT in the same stack?

In regards to the nftables approach, do you mean to integrate the RFC
implementations natively into the nftables infrastructure?

Checking your code, it seems that you use several user space tools
(jool, joold) and a conntrack-like table to store the connection data.
As you know, in the nftables project it has been done a great effort
to avoid several tools for packet mangling so something natively like
the following would be probably required.

nft add table ip6 nat
nft add chain ip6 nat postrouting { type nat hook postrouting priority 100 \; }
nft add rule ip6 nat postrouting oif eth0 snat 1.2.3.4

More thorough study would be the possibility of supporting the
sessions in conntrack and conntrackd but, I believe a first approach
with stateless NAT from ingress could be a great achievement.

Cheers.


> Actually, it's the same software once advertised by this guy: [1]
>
> Several people have approached me over the years expressing their
> desire to have it integrated into the kernel by default. The intent of
> this mail is to query whether a merge of Jool into the Netfilter
> project woud be well-received. Of course, I'm willing to make
> adjustments if needed.
>
> Here are some justifications that have been listed to me. For the sake
> of credit, these are all stolen from [2]:
>
> 1. IPv6 is getting significantly more exposure
> 2. NAT64 is getting more required / will be a default thing to do,
> along with MAP-E/T
> 3. OpenBSD already has the functionality in pf
> 4. Enabling it upstream can potentially help IPv6 migration world wide
>
> Thoughts?
>
> [0] https://jool.mx
> [1] https://marc.info/?l=netfilter-devel&m=136271576812278&w=2
> [2] https://github.com/NICMx/Jool/issues/273#issuecomment-568721875