pfSense

On further investigation there seems to be an explicit "NAT64 Prefix Override" option now.

Looking at #16241, the RFC says that RFC1918 address space should not be reachable when using the default 64:ff9b::/96 prefix, but there is nothing invalid or dangerous about using other prefixes.

Similarly there is no reason to prevent the use of other prefixes in DNS64/PREF64 rules - the user may want to use an external NAT64 service such as one provided by their ISP, or a public one such as those on https://nat64.xyz

Enabling the override option removes the rules to block RFC1918 address space, even when still using the default prefix. Blocking RFC1918 address space through the NAT64 is a completely separate function to forcing the use of the default NAT64 prefix.

I would suggest:

1) allow use of any NAT64 prefix by default
2) apply filter rules for private address space by default, but provide an option to disable them (this satisfies the RFC requirement)
3) do not restrict the prefixes in dns or router advertisements at all, as the user may want to use a NAT64 service not hosted on the local firewall

It doesn't make sense to tie all these things together...

Using an externally hosted prefix for RA/DNS is a sane and legitimate use case. Many ISPs offer a NAT64 service and it's not always on the default address range. By using the NAT64 provided by the ISP directly you can avoid a double NAT setup, and your firewall only needs to handle v6 traffic.

Using a custom prefix is also perfectly legitimate, it makes sense for 64:ff9b::/96 to be a suggested default but not forced.

The only thing remotely dangerous and non rfc compliant would be disabling the default filter rules, and this is what should require an advanced option with warnings.

I wouldn't consider it forced given that it's behind a checkbox which gets automatically checked on upgrade if a different prefix is in use. Feel free to continue the discussion on the forum for further consideration.