On Tue, 30 Jan 2024, at 5:00 PM, Slavko wrote: > Dňa 30. januára 2024 15:17:32 UTC používateľ Kerin Millar > <kfm@xxxxxxxxxxxxx> napísal: > >>Granted, one cannot create a set that is typed in such a way that an element can be either an IPv4 or IPv6 address/interval. > > Nowadays IPv6 becomes more and more common. While allmost all > can stay on IP(v4) only host, not all can use IPv6 only host (yet, as many > services are still IPv4 only). In other words, many will have dual stack, > to can access (or be accessible for) all and they will need dual stack FW, > and IMO will need it for many years. > > Having separate support for IPv4 and IPv6 was acceptable at time, when > ip6tables was born, but nowadays IMO firewall cannot be named modern, > if any of its part separates that. And any argument (memory, complexity, > etc) against it is pointles, as dual stacks are (and will be) here. It is easy to say that it is pointless if not the one to be responsible for implementing and maintaining the code and trying to take into account diverse - and occasionally conflicting - user desires. There have been various set-related bugs in nftables over the years. Complexity surely matters to someone. There are multiple open bugs now that concern both performance and memory usage. Efficiency surely matters to someone. > > Nftables now has inet family, that is great step from iptables. But still > requires to maintain separate rules in it for anything with network layer > address, eg. mentioned sets (and for icmp/icmp6 too). I hope, that it > is temporary state only and will be improved soon. For it to improve, you could put forward a concrete suggestion as to how it might be improved, be it supporting logical disjunctions in rules, supporting a generic address type in sets or whatever else. That would, at least, be a step along the road to (potentially) convincing whoever is going to do the work that it is justified. On my part, and despite having been a user of nftables for many years now, I would prefer to see its QA and documentation improve ahead of - though not wholly at the expense of - new features being added. -- Kerin Millar
