| I think this statement should be considered more as a criticism of pfSense and not of IPv6 in general. In fact there are a number of RFCs around how IPv6 firewalling should be implemented on _consumer_ routers but since pfSense seems to be mostly aimed at enterprise customers my guess is they don't necessarily follow all that. Specifically I'm referring to: - RFC4864 | Local Network Protection for IPv6, - RFC6092 | Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service and - RFC7084 | Basic Requirements for IPv6 Customer Edge Routers, which pulls in the other two by reference. In fact RFC4864 is specifically about this "Perceived Benefit of NAT" and how to preserve the security benefits in the v6 world. [RFC4864]: https://tools.ietf.org/html/rfc4864 [RFC6092]: https://tools.ietf.org/html/rfc6092 [RFC7084]: https://tools.ietf.org/html/rfc7084 Just as an example, OpenWrt, a more consumer focused router distribution follows RFC7084 and provides the default deny behaviour on IPv6 ingress from WAN much like IPv4-NAT would do. Also note that IMO the author is simply conflating NAT as known in the IPv4 world with it's usual implementation of actual Address Translation plus Stateful firewalling. In fact prefix translation which he's going on about here isn't necessary at all to be exposed to this security problem. Just plugging a IPv6 (and DHCPv6-PD) capable router into a WAN would do if it weren't for the stateful firewall. |
I've been running pfSense for years, but it's clear that it just is not made with residential IPv6 in mind. Been looking at the NanoPi R2S, think I'll try out OpenWrt on that as a replacement.