But, I don’t like the presumption in IPv6 that everything supports 1280. What if there is a VPN running over a 1280-MTU link, what is the MTU of the encrypted IPv6 payload? Now add in a couple more layers of VPNs for good measure.
For example, in the bad old days, when there was still a lot of ATM, packets would routinely get transmitted in 48 byte pieces (with a 5 byte header). Nobody wondered whether this kind of fragmentation should honor the DF bit.
If I recall correctly, multi-link PPP could also split a packet in smaller pieces to transmit it over multiple links at the same time.
So for IPv6, anything that is 1280 octets or smaller needs to forwarded without triggering a packet too big ICMP. Otherwise the link violates the IPv6 standard.
I’m leaning towards satire but in case you are serious, IPv6 built-in encryption is IPsec using opportunistic encryption (which then relies on dnsec…), and it’s not built into all IPv6 endpoints. Nor easy to configure, debug or support.
WireGuard, OpenVPN, etc are easier for users to configure and set up than IPsec, and less chances of mismatched configs, unsupported cipher suites, etc.
As for NAT, that’s irrelevant to the reason for using a VPN. IPv6 has Unique Local Addresses (ULA), which can be routable across and organisation but not from the internet, and so you may want a VPN for access to those. You may also simply want to extend your IPv6 network to a remote location that doesn’t have native IPv4, or whose ISP doesn’t provide sufficient delegated subnet ranges for your requirements. The VPN could also be to provide access to an IPv4 network behind the IPv6 router. The list goes on…