NFTables To Replace iptables In the Linux Kernel 235
An anonymous reader writes "NFTables is queued up for merging into the Linux 3.13 kernel. NFTables is a four-year-old project by the creators of Netfilter to write a new packet filtering / firewall engine for the Linux kernel to deprecate iptables (though it now offers an iptables compatibility layer too). NFTables promises to be more powerful, simpler, reduce code complication, improve error reporting, and provide more efficient handling of packet filter rules. The code was merged into net-next for the Linux 3.13 kernel. Iptables will still be present until NFTables is finished, but it is possible to try it out now. LWN also has a writeup on NFTables."
again? (Score:5, Interesting)
ipfwadm.. ipchains.. iptables.. nftables... progress sucks. :(
Re:again? (Score:5, Interesting)
And the iptables docs haven't even been finished yet. I was at the North Carolina Biotechnology Center at the Linux Expo in 1997 when one of the speakers that was talking about iptables promised they would write docs for it. I think I was the only teen girl and only black female there, so if you were there, you'll probably remember me. How about finishing what you start rather than screwing the users with half-ass unfinished projects?
Re:Noooooo (Score:5, Interesting)
Okay so after RTFMing, I like the changes.
It reminds me of the ip command, which is so much better than route.
NFTables FTW!
I really like the idea (Score:5, Interesting)
The main advantage of this is moving protocol knowledge out of the kernel into userspace.
Which means that the kernel doesn't need a million modules that understand the various bits of various protocols. If something new comes up, the userspace compiler can patched to deal with it.
It should also make the kernel part much smaller and easier to make secure.
Re:pf (Score:2, Interesting)
Can't we have OpenBSD pf instead? Powerful, nice, decent documentation on how to use it, syntax that makes a lot more sense than iptables.
That would be nice. I was very happy when pf was imported into NetBSD (my preferred BSD). iptables is just meh in comparison. I'll reserve judgment on this NFTables until I see it for myself.
Re:I really like the idea (Score:5, Interesting)
It should also make the kernel part much smaller and easier to make secure.
You hope.
I've learned to become suspicious of change for change sake.
Long running well debugged code is almost always better understood than new code.
Re:again? (Score:4, Interesting)
Going to a random page: "If the IP filter implementation is strictly following the definition, it would in other words
No, "in other words" is only appropriate after you've worded things once and are about to re-iterate using different terminology, in other words are using "other words" to describe the same thing.
Re:Noooooo (Score:5, Interesting)
When NAT came in it was a pity we needed that shit due to a lack of numbers instead of having everything adressable, and now for some reason people like the smell of that shit. They think it smells like security.
If you think I'm wrong please spend at least five minutes learning how a firewall works and look up router on wikipedia or something before you reply. You should work out from that that the devices that provide the security will still be upstream whether you have NAT or not.
Re:again? (Score:5, Interesting)
Hear hear! A bit of background to the politics of this:
NFTables is brought to you by a group of codes created when Alexey Kuznetsov decided to replaced the low level linux network stack for Linux 2.2 to make it more like what Cisco provided in IOS. The result added whole pile of new functionality to Linux (eg routing rules), and a shiny new highly module traffic control engine. Alexey produced a beautifully written postscript documentation [smc.edu] for the new user land routing tools (the "ip" command), and 100 line howto [columbia.edu] for the far more complex traffic control engine tools (the "tc" command).
Technically it was a was tour de force. But to end users it could at best be called a modest success. Alexey re-wrote the net-utils tools ("ifconfig", "route" and friends) to use the new system, and did such a good job very few bothered to learn the new "ip" command even though the documentation was good and it introduced a modest amount of new features. But real innovation was the traffic control engine, and to this day bugger all people know how to use it.
At this point it could have gone two ways. Someone could have brought tc's documentation up to the same standard Alexey provided for ip, or they could ignore the fact that almost no one used the code already written and add more of the same. They did the latter.
It was also at this time the network code wars started in the kernel. Not many people know that a modest amount of NAT, filtering and so on can be done by Alexey's new ip command. But rather than build on that Rusty Russell just ported the old ipfwadm infrastructure, called it ipchains (and later replaced it with iptables). There was some overlap between Rusty's work and tc, and this has grown over time. For example the tc U32 filter could do most of the packet tests ipchain's introduced over time on day 1. Technically the modular framework provided by tc was more powerful than ipchains, and inherently faster. Tc was however near impossible for mere mortals to use even if they had good documentation. There were some outside efforts to fix this - tcng [sourceforge.net] was an excellent out-of-tree attempt to fix the complexity problems of tc. But in what seems like a recurring theme, it was out of tree and ignored. In contrast, Rusty provided ipchains with the some best documentation on the planet. In the real world the result of these two efforts are plain to see - while man + dog uses iptables, there maybe 100 people on the planet who can use tc.
Another example of the same thing is IMQ [linuximq.net]. IMQ lets you unleash the full power of the traffic control engine on incoming traffic. (Natively the traffic control engine only deals with packets being sent, not incoming packets - a limitation introduced for purely philosophical reasons). IMQ was very well documented, and heavily used. The people who brought you tc had a list of technical objections to IMQ. I don't know whether they were real or just a case of Not Invented Here, but I'd give them the benefit of the doubt - they are pretty bright guys. So they replaced it with their own in-kernel-tree concoction. (For those of you who don't follow the kernel "in-tree" means it comes with the Linux Kernel. An out-of-tree module like IMQ means at the very least you have to compile the module source, and possibly the entire kernel.) For a while this discouraged the developers of IMQ so much they stopped working on it. If you follow that link, you will see it's back now. Why? Because the thing that replaced it had absolutely no documentation. They never do. So no one could use the replacement. Again, in the end, the thing code that was documented won the day.
By now you might be guess where this is heading. We have two groups in the kernel competing to provide the