In nftables, what does the `inet` family mean when you write `table inet filter`, and what does it change compared with maintaining separate iptables and ip6tables rulesets?

## Families come first in nftables In nftables nothing exists outside a table, and no table exists outside an **address family**. The family is the first word of the declaration — `table inet filter`, `table ip nat`, `table netdev ingressfilter` — and it determines two things: which kind of traffic the table's base chains are able to see, and which match expressions are legal inside them. The families are: - `ip` — IPv4 traffic only. - `ip6` — IPv6 traffic only. - `inet` — IPv4 and IPv6 together. - `arp` — ARP traffic. - `bridge` — traffic traversing a bridge. - `netdev` — traffic at the device level, used for the `ingress` and `egress` hooks. ## What `inet` actually does A base chain in an `inet` table is registered on the IPv4 *and* the IPv6 version of the hook it names. One chain object, one ordered list of rules, evaluated for a packet of either protocol. Nothing is duplicated behind the scenes and nothing is translated — the same rules simply run for both. ```bash nft add table inet filter nft add chain inet filter input '{ type filter hook input priority filter; policy drop; }' nft add rule inet filter input ct state established,related accept nft add rule inet filter input iif lo accept nft add rule inet filter input tcp dport 22 accept ``` That SSH rule covers IPv4 and IPv6 SSH. Under the old tooling it would have been one `iptables -A INPUT ...` and one `ip6tables -A INPUT ...`. ## Which rules are protocol-neutral and which are not Most of what a host firewall does never mentions an address family at all: `tcp dport`, `udp dport`, `ct state`, `iif`/`oif`, `meta l4proto`, `meta mark`. Those are written once and are correct for both stacks. Address matches are not neutral, and this is legal and important inside an inet table: - `ip saddr 10.0.0.0/8` matches only IPv4 packets. Against an IPv6 packet it simply does not match — the ruleset still loads, the rule is just inert for that traffic. - `ip6 saddr fd00::/8` is the mirror case. - `meta nfproto ipv4` (or `ipv6`) lets you gate a whole block on the protocol when you want a section that applies to only one stack. - `ip protocol tcp` is an IPv4 header match; `meta l4proto tcp` is the family-neutral way to say the same thing and is what you want in an inet table. ## The ICMPv6 trap The single most common mistake with a dual-stack default-drop chain is allowing `icmp` and assuming ICMPv6 came along with it. It did not — `icmp` is the IPv4 keyword, ICMPv6 is matched with `icmpv6`. IPv6 depends on ICMPv6 for Neighbour Discovery, so dropping it does not merely block pings, it breaks on-link IPv6 connectivity in ways that look like a routing fault. A dual-stack chain needs something like: ```bash nft add rule inet filter input icmp type echo-request accept nft add rule inet filter input icmpv6 type '{ echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert }' accept ``` ## Why this matters operationally The security value is not aesthetic. With two separate rulesets, the IPv4 one gets written on day one and the IPv6 one gets written when someone remembers. Hosts acquire IPv6 addresses by autoconfiguration without anybody deciding to, and a service bound to `::` on such a host is exposed with no rules in front of it. A single inet ruleset removes that entire failure mode: there is one place to look, and `nft list ruleset` shows the complete picture for both protocols. ## What `inet` does not cover It is IPv4 plus IPv6 and nothing else. ARP filtering still belongs in an `arp` table, bridged-frame filtering in a `bridge` table, and device-level filtering in a `netdev` table. `inet` also does not mean "internet-facing" — the name is the socket-address-family convention, not a direction.