Difference between revisions of "Nftables families"

From nftables wiki
Jump to navigation Jump to search
(Create page with basic content)
 
(reestructure page)
Line 3: Line 3:
In the past, all the families were handled by different tools: iptables, ip6tables, arptables, ebtables.
In the past, all the families were handled by different tools: iptables, ip6tables, arptables, ebtables.


By now, the nftables families are:
Please note that what traffic/packets you see and at which point in the network stack depends on the '''chain hook''' you are using.
You can create tables/chains/sets/rules in any family with the '''nft''' command line interface, out of the box, no need for different tools.
Additional families may be added in the future for extended nftables functionalities.
 
== ip ==
 
Tables of this family will see IPv4 traffic/packets.
The iptables tool was the equivalent in the old x_tables world.
 
== ip6 ==
 
Tables of this family will see IPv6 traffic/packets.
The ip6tables tool was the equivalent in the old x_tables world.
 
== inet ==
 
Tables of this family will see both IPv4/IPv6 traffic/packets, designed to improve dual stack support.
Mixing iptables and ip6tables rules in the same box was the equivalent in the old x_tables world.
 
Both IPv4/IPv6 packets will traverse the same rules. Rules for IPv4 packets won't affect IPv6 packets.
Rules for both L3 protocol will affect both.
 
Examples:
<source>
# this rule only affects IPv4 packets
add rule inet filter input ip saddr 1.1.1.1 counter accept
# this rule only affects IPv6 packets
add rule inet filter input ip6 daddr fe00::2 counter accept
# these rules affects both IPv4/IPv6 packets
add rule inet filter input ct state established,related counter accept
add rule inet filter input udp dport 53 accept
</source>
 
== arp ==
 
Tables of this family will see ARP-level (i.e, L2) traffic, before any L3 handling is done by the kernel.
The arptables tool was the equivalent in the old x_tables world.


* '''ip''': tables of this family will see IPv4 traffic/packets
== bridge ==
* '''ip6''': tables of this family will see IPv6 traffic/packets
* '''inet''': tables of this family will see both IPv4/IPv6 traffic/packets, designed to improve dual stack support
* '''arp''': tables of this family will see ARP-level (i.e, L2) traffic, before any L3 handling is done by the kernel.
* '''bridge''': tables of this family will see traffic/packets traversing bridges (i.e. switching). No assumptions are made about L3 protocols.
* '''netdev''': tables of this family will see raw packets at L2 directly from the attached NIC. No assumptions are made about L2/L3 protocols.


Please note that what traffic/packets you see and at which point in the network stack depends on the '''chain hook''' you are using.
Tables of this family will see traffic/packets traversing bridges (i.e. switching). No assumptions are made about L3 protocols.
The ebtables tool was the equivalent in the old x_tables world.
Also, some x_tables modules such as ''physdev'' are now natively served from this family.


You can create tables/chains/sets/rules in any family with the '''nft''' command line interface, out of the box, no need for different tools.
Note that there is no nf_conntrack integration for this family. However this may change in the future.


For those that come from the x_tables world, we can create some similarities:
== netdev ==


* ip family <-> iptables
Tables of this family will see raw packets at L2 directly from the attached NIC. No assumptions are made about L2/L3 protocols.
* ip6 family <-> ip6tables
There was no equivalent in the old x_tables world.
* inet <-> mixing iptables and ip6tables rules in the same box
* arp <-> arptables
* bridge <-> ebtables, plus some x_tables modules like physdev
* netdev <-> no equivalent in x_tables


Additional families may be added in the future for extended nftables functionalities.
Note that every table is directly attached to a given NIC. If the NIC goes down rules in chains in this table will not match.
Not all hooks are allowed in this family. (TODO: add details about allowed hooks).

Revision as of 12:49, 9 November 2017

nftables families are a new concept introduced with this technology which was previously missing in the iptables world. You may already know that the nftables framework is designed to work with all typical address families (IPv4, IPv6, ARP). In the past, all the families were handled by different tools: iptables, ip6tables, arptables, ebtables.

Please note that what traffic/packets you see and at which point in the network stack depends on the chain hook you are using. You can create tables/chains/sets/rules in any family with the nft command line interface, out of the box, no need for different tools. Additional families may be added in the future for extended nftables functionalities.

ip

Tables of this family will see IPv4 traffic/packets. The iptables tool was the equivalent in the old x_tables world.

ip6

Tables of this family will see IPv6 traffic/packets. The ip6tables tool was the equivalent in the old x_tables world.

inet

Tables of this family will see both IPv4/IPv6 traffic/packets, designed to improve dual stack support. Mixing iptables and ip6tables rules in the same box was the equivalent in the old x_tables world.

Both IPv4/IPv6 packets will traverse the same rules. Rules for IPv4 packets won't affect IPv6 packets. Rules for both L3 protocol will affect both.

Examples:

# this rule only affects IPv4 packets
add rule inet filter input ip saddr 1.1.1.1 counter accept 
# this rule only affects IPv6 packets
add rule inet filter input ip6 daddr fe00::2 counter accept
# these rules affects both IPv4/IPv6 packets
add rule inet filter input ct state established,related counter accept
add rule inet filter input udp dport 53 accept

arp

Tables of this family will see ARP-level (i.e, L2) traffic, before any L3 handling is done by the kernel. The arptables tool was the equivalent in the old x_tables world.

bridge

Tables of this family will see traffic/packets traversing bridges (i.e. switching). No assumptions are made about L3 protocols. The ebtables tool was the equivalent in the old x_tables world. Also, some x_tables modules such as physdev are now natively served from this family.

Note that there is no nf_conntrack integration for this family. However this may change in the future.

netdev

Tables of this family will see raw packets at L2 directly from the attached NIC. No assumptions are made about L2/L3 protocols. There was no equivalent in the old x_tables world.

Note that every table is directly attached to a given NIC. If the NIC goes down rules in chains in this table will not match. Not all hooks are allowed in this family. (TODO: add details about allowed hooks).