Why nftables?: Difference between revisions
Jump to navigation
Jump to search
(Created page with "We like iptables after all, this tool has been serving us (and will likely keep serving still for a while in many deployments) to filter out traffic on both per-packet and per...") |
(add paragraph break) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
We like iptables after all, this tool has been serving us (and will likely keep serving still for a while in many deployments) to filter out traffic on both per-packet and per-flow basis, log suspicious traffic activity, perform NAT and many other things. It comes with more than a hundred of extensions that have been contributed along the last 15 years!. | We like iptables after all, this tool has been serving us (and will likely keep serving still for a while in many deployments) to filter out traffic on both per-packet and per-flow basis, log suspicious traffic activity, perform NAT and many other things. It comes with more than a hundred of extensions that have been contributed along the last 15 years!. | ||
Nevertheless, the iptables framework suffers from limitations that cannot be easily worked around: | |||
* Avoid code duplication and inconsistencies: Many of the iptables extensions are protocol specific, so there is no a consolidated way to match packet fields, instead we have one extension for each protocol that it supports. This bloats the codebase with very similar code to perform a similar task: payload matching. | |||
* Faster packet classification through enhanced generic set and map infrastructure. | |||
* Simplified dual stack IPv4/IPv6 administration, through the new inet family that allows you to register base chains that see both IPv4 and IPv6 traffic. | |||
* Better dynamic ruleset updates support. | |||
* Provide a Netlink API for third party applications, just as other Linux Networking and Netfilter subsystem do. | |||
* Address syntax inconsistencies and provide nicer and more compact syntax. | |||
These, among other things not listed here, triggered the nftables development which was originally presented to the Netfilter community in the 6th Netfilter Workshop in Paris (France). | These, among other things not listed here, triggered the nftables development which was originally presented to the Netfilter community in the 6th Netfilter Workshop in Paris (France). | ||
Latest revision as of 13:34, 18 August 2017
We like iptables after all, this tool has been serving us (and will likely keep serving still for a while in many deployments) to filter out traffic on both per-packet and per-flow basis, log suspicious traffic activity, perform NAT and many other things. It comes with more than a hundred of extensions that have been contributed along the last 15 years!.
Nevertheless, the iptables framework suffers from limitations that cannot be easily worked around:
- Avoid code duplication and inconsistencies: Many of the iptables extensions are protocol specific, so there is no a consolidated way to match packet fields, instead we have one extension for each protocol that it supports. This bloats the codebase with very similar code to perform a similar task: payload matching.
- Faster packet classification through enhanced generic set and map infrastructure.
- Simplified dual stack IPv4/IPv6 administration, through the new inet family that allows you to register base chains that see both IPv4 and IPv6 traffic.
- Better dynamic ruleset updates support.
- Provide a Netlink API for third party applications, just as other Linux Networking and Netfilter subsystem do.
- Address syntax inconsistencies and provide nicer and more compact syntax.
These, among other things not listed here, triggered the nftables development which was originally presented to the Netfilter community in the 6th Netfilter Workshop in Paris (France).