> But how does eg a device programmatically tell the firewall to allow traffic in in this case? This is done via UPNP on ipv4 NAT.
https://en.wikipedia.org/wiki/Port_Control_Protocol, which also allows for UPnP-like functionality when NAT64 is in play.
That said most "P2P" traffic is still mediated by a central server though and does not need this. The lack of port remapping from NAT means that tricks like UDP hole punching work simply and reliably rather than the semi-random performance seen through NAT. Multiplayer gaming, VoIP, voice/video chat, etc. where a central server does the setup doesn't need ports opened to the world, it just needs to punch a hole for that specific session. A SIP phone opening a port forward on 5060 for itself is a bad thing, but it's sometimes needed in the NAT world.
True unsolicited incoming traffic will still need an allow rule but that's a lot more rare.
> If you're going to say there isn't a way and you need to add the firewall rules manually, then this is absolutely no improvement for 99%+ of consumer users who have absolutely no chance of understanding how to configure that.
I disagree. These days the sorts of things normal people do that deal with P2P connections are pretty good at dealing with NAT, but far from perfect. You don't have to look far in to the gaming world to find people complaining about not being able to join a session, not being able to connect to voice, etc.
Any VoIP provider serving users on their own internet connections is going to be doing things like regular keepalives, setting their media systems to accept RTP from and send it back to whatever port it comes out of the user's NAT on instead of the one it's supposed to be on, etc.
All these things work pretty well, most of the time. But they're not perfectly reliable because every NAT implementation is different in subtle ways.
> Think of for example Xbox users. On ipv4 with NAT it automatically configures it for serving games using upnp. If you had ipv6 only with a default deny rule and no upnp equivalent then the Xbox cannot open itself up to incoming connections. It's actually a downgrade in terms of "P2P" connectivity from NAT.
As noted previously, in IPv6 it doesn't need to open the port at all. Anything the Xbox, or any other modern game console, will be doing is server-mediated P2P for which standard basic UDP hole punching is a perfect fit.
Basically anything that definitely always requires a port forward in IPv4 NAT will probably still require an allow rule in the firewall, but anything where port forwards aren't supposed to be required but sometimes they help some people more reliably connect is a problem caused entirely by the NAT and those problems go away. Hosting a dedicated game server is in the former category, playing games is in the latter category.
There's a reason all the modern consoles include NAT tests in their network diagnostics, but can only offer vague suggestions at the fix, because how the NAT is breaking things varies by the NAT and may or may not be fixable. The only real fix is to eliminate the NAT.
FWIW Xbox prefers IPv6 when available and Xbox Support specifically recommends having it enabled if you can. That tells me that it works either equally well or better than IPv4 in the real world, which fits my view of things.