Jool: Merge Jool into nftables

[ydahhrk]

This has been mentioned several times, particularly in #140 and the survey. It appears that some people want Jool to merge with the Linux kernel.

Why, though? I get that people don't like installing from source, but wouldn't official packages fix that satisfactorily?

Personally, I sympathize with the Unix philosophy, and feel that IP translation is a tad too specific a need and too far from core to expect a kernel to ship with it by default. Wouldn't most distributions disable it?

[CodeFetch]

NAT64 keeps state information etc. It is hard to get it merged into mainline kernel. NAT46 can be easily merged as a virtual network device and will unlikely change much over the years. The kernel janitors would always keep it up to date. Thus Jool could concentrate on NAT64 and e.g. bpfilter support or whatever is coming. If Jool's NAT64 would also become a virtual network device and the design is conform with the kernel's (e.g. using the upcoming rhashtables etc.), it would also be well-suited for the mainline kernel, but it's a long journey to that point...

[ydahhrk]

(e.g. using the upcoming rhashtables etc.)

Question: Where do you hear about this kind of stuff? LWN.net?

Not sure if Jool has strayed far from the kernel's design. I probably need to update my understanding of it.

[CodeFetch]

I'm learning Linux kernel development for some years now, because I'd like to add some functionalities to mac80211, which is quite hard (MCCA). Thus I've read all the O'Reilly books and indeed a lot of LWN articles.

Actually I'm still quite bad at it. At the moment I'm working e.g. on a heavily modified NAT4(2)6 virtual network layer 2 device which does connection tracking to allow seamless roaming for clients in Babel mesh networks. I held a talk on the Battlemesh about it, but it's a bit outdated. The setup has become even more complex as I don't want TCP connections to break and don't rely on intelligent client behavior which means the module needs to do connection tracking to fake a single gateway.

That's why I've talked to some kernel devs about how a kernel module needs to look and "feel" like to be merged in mainline kernel. A simple, RFC-conform NAT46 virtual network device which is NAPI and net-utils compatible would very likely be accepted upstream.

[ydahhrk]

(Not much of an update, but I want to merge the two conversations and respond this e-mail at the same time.)

There's nothing stopping me from knocking some doors upstream, other than the higher-priority feature requests still awaiting implementation. That said, if I attempted such a thing, I'd expect to run into some obstacles:

1. Whenever a new feature is added to the kernel, I understand it needs to be justified, and I'm completely incompetent as a debater. I think it would be difficult to justify Jool's inclusion, particularly considering it can be (and currently is being) packaged. IP translation has a niche audience still and Jool might be too large to be worth shipping by default on every Debian, for example.
2. nftables and device driver modes are probably necessary modernizations, but they're not implemented yet. (Though the way the survey is going, this isn't going to remain an obstacle for long.)
3. @CodeFetch suggests (above) that SIIT and MAP-T would be likely accepted into the kernel, but NAT64 would not. Merging SIIT and MAP-T while leaving NAT64 as a module is more work.
4. The code has a lot of comments in some places. Kernel devs abhor that :p

Addressing 2, 3 and 4 is a matter of time, but I would like to hear some arguments to defeat 1.

For starters, here's a technical reason why merging Jool with the kernel would be a good idea:

1. lowest-ipv6-mtu would be far easier to implement and substantially more performant if kernel modules were allowed to inform Linux's fragmentator a maximum fragment size. (Sort of an MTU associated with a packet instead of an interface.) If Jool were merged into Linux, the latter would probably be tempted to include such a feature.

[telmich]

(Not much of an update, but I want to merge the two conversations and respond this e-mail at the same time.)

There's nothing stopping me from knocking some doors upstream, other than the higher-priority feature requests still awaiting implementation. That said, if I attempted such a thing, I'd expect to run into some obstacles:

1. Whenever a new feature is added to the kernel, I understand it needs to be justified, and I'm completely incompetent as a debater. I think it would be difficult to justify Jool's inclusion, particularly considering it can be (and currently is being) packaged. IP translation has a niche audience still and Jool might be too large to be worth shipping by default on every Debian, for example.

I can help in this regard. I've been involved a bit with the RSBAC discussion in the early 2000s (and the problems around it) and seen the wireguard approach.
It will certainly take some time and probably some modifications to fit into current kernel design/code standards, but this should not pose a real problem, I assume.

1. nftables and device driver modes are probably necessary modernizations, but they're not implemented yet. (Though the way the survey is going, this isn't going to remain an obstacle for long.)

That sounds very promising!

1. @CodeFetch suggests (above) that SIIT and MAP-T would be likely accepted into the kernel, but NAT64 would not. Merging SIIT and MAP-T while leaving NAT64 as a module is more work.

I think this is subject to discussion and maybe a talk with the netfilter group is a good thing to do. If you want to, I can reach out and
start the general discussion on the netfilter mailing list to hear about the sentiment about jool going upstream.

1. The code has a lot of comments in some places. Kernel devs abhor that :p

Addressing 2, 3 and 4 is a matter of time, but I would like to hear some arguments to defeat 1.

For starters, here's a technical reason why merging Jool with the kernel would be a good idea:

1. lowest-ipv6-mtu would be far easier to implement and substantially more performant if kernel modules were allowed to inform Linux's fragmentator a maximum fragment size. (Sort of an MTU associated with a packet instead of an interface.) If Jool were merged into Linux, the latter would probably be tempted to include such a feature.

I see a lot of convincing arguments for merging it into mainline:

• IPv6 is getting significantly more exposure
• NAT64 is getting more required / will be a default thing to do, along with MAP-E/T
• OpenBSD already has the functionality in pf
• Enabling it upstream can potentially help IPv6 migration world wide

If 2/3/4 are kind of easy from your side, I can support a bit with 1 and reach out slowly and get an understanding of how the general attitude is towards jool in upstream.

[ydahhrk]

I think this is subject to discussion and maybe a talk with the netfilter group is a good thing to do. If you want to, I can reach out and
start the general discussion on the netfilter mailing list to hear about the sentiment about jool going upstream.

Ok. I'm currently writing a message I should post on the Netfilter Developer Mailing List tomorrow.

From the archives it seems there have been a couple of attempts to raise a bit of hype about NAT64 many years ago, but they seem to have been unsuccessful.

So feel free to chime in, or even beat me to it. I can't imagine my message being persuasive on its own.

[ydahhrk]

https://marc.info/?l=netfilter-devel&m=157807496904032&w=2