David Miller <da...@davemloft.net> wrote: > > How many of those wide-spread applications are you aware of? The two > > projects you have pointed out (docker and kubernetes) don't. As the > > assumption that many such tools would need to be supported drives a lot > > of the design decisions, I would argue one needs a solid empircal basis. > > I see talk about "just replacing the iptables binary". > > A long time ago in a galaxy far far away, that would be a reasonable > scheme. But that kind of approach won't work in the realities of > today. > > You aren't going to be able to replace the iptables binary in the tens > of thousands of container images out there, nor the virtualization > installations either.
Why would you have to? iptables kernel parts are still maintained, its not dead code that stands in the way. We can leave it alone, in maintenance mode, just fine. > Like it or not iptables ABI based filtering is going to be in the data > path for many years if not a decade or more to come. iptables is a > victim of it's own success, like it or not :-) Yes, the ABI is > terrible, but obviously it was useful enough for lots of people. Sure, but looking at all the things that were added to iptables to alleviate some of the issues (ipset for instance) show that we need a meaningful re-design of how things work conceptually. The umh helper translation that has been proposed could be applied to transparently xlate iptables to nftables (or e.g. iptables compat32 to iptables64), i.e. legacy binary talks to kernel, kernel invokes umh, umh generates nftables netlink messages). But I don't even see a need to do this, I don't think its an issue to leave it in the tree even for another decade or more if needed be.
