It has been alleged that: 1. if you drop all ICMP(v4), things may break (https://en.wikipedia.org/wiki/PMTUD). 2. if you drop all ICMPv6, things WILL break (RFC 4890). 3. if you accept all ICMPv6, things WILL be pwned (RFC 4890). On that basis, I came up with the rather verbose @ICMPv6_RFC4890_policy and @ICMP_policy verdict maps here: http://cyber.com.au/~twb/tmp/nftables-router.nft It has also been alleged that 4. if you --ctstate ESTABLISHED,RELATED -j ACCEPT, then the only explicit ICMP rule you need is for echo-request. Everything else is covered by the conntrack rule. Is that true? It was only asserted for ICMP[v4] (not ICMPv6), and it was only asserted for a host (i.e. INPUT chain), not a gateway/router (i.e. FORWARD chain). To what extent is this still true for a dual-stack gateway/router? The RFC 4890 Appendix B has a VERY old-style ruleset, because the RFC itself is from that era. It knows about --state ESTABLISHED,RELATED, but doesn't seem to be using it very intelligently. What is best practice for ICMPv6 rules in a stateful nftables ruleset? Specifically, what parts of RFC 4890 are covered implicitly by "ct state established,related accept" ? I'd start doing my own testing, but a) I don't have a good IPv6 test network yet; and b) I'm scared my testing would miss something important. I apologize in advance if this turns into a bikeshedding thread!
