> Peer-to-peer communications such as gaming usually have to deal with NAT traversal, but with IPv6 this is no longer an issue, especially for multiple gamers using the same connection
You know the list of "benefits" is thin when the second item is entirely theoretical. Even though IPv6 doesn't have to do NAT traversal, it still has to punch through your router's firewall which is effectively the same problem. Most ISP provided home routers simply block all incoming IPv6 traffic unless there is outbound traffic first, and provide little to no support for custom IPv6 rules.
Even if that were not an issue, my bet is that there are close to zero popular games that actually use true peer to peer networking.
Running a firewall with upnp enabled has always amused me. Might as well just turn the firewall off if you let any machine shoot any hole it wants in it.
Typically firewalls will record the src and dst header values of outbound IP packets then temporarily allows inbound IP packets that have those values flipped.
You're just asserting that without explination. Please correct me if I'm wrong, but afiak the only difference in NAT hole-punching is that clients don't know their public port mapping ahead of time. This actually doesn't make a huge difference to the process because in practice, you still want a central rendezvous server for automated peer IP discovery. The alternative being that each peer shares their IP with every other peer "offline", as in manually through an external service like IRC or discord, which is a horrible user experience.
They linked a whole article detailing the complexities of specifically NAT traversal.
I should think it obvious that by removing an entire leaky layer of abstraction the process would be much simpler. Yes, you still need a coordination server, but instead of having to deduce the incoming/outgoing port mappings you can just share the "external IP" of each client--which in the IPV6 case isn't "external," it's just "the IP".
>Also NAT is a pretty simple abstraction, it's literally a single table.
...And now, let's try punching a hole through this "simple" table. Oops, someone is using a port-restricted or symmetric NAT and hole punching has gotten just a tad more complicated.
> it just has to be established from the local side
This is exactly the problem. Unless you expect users to manually share their IPs with every other user in a given lobby through an external service, you would need to make a central peer discovery and connection coordination mechanism which ends up looking pretty similar to classic NAT traversal.
The complication starts when such an ephemeral port gets connection from somewhere else, which is the crucial part not the creation of such ports. That is not supported necessarily by firewalls, or not that simple than just having a stateful firewall.
Also NAT66 exists and I use it on my home network so you still have to have the machinery to do NAT traversal when needed. It's nice to use my public addresses like elastic IPs instead of delegating ports. IPv6 stans won't be able to bully their way into pretending that NAT doesn't exist on IPv6.
You know the list of "benefits" is thin when the second item is entirely theoretical. Even though IPv6 doesn't have to do NAT traversal, it still has to punch through your router's firewall which is effectively the same problem. Most ISP provided home routers simply block all incoming IPv6 traffic unless there is outbound traffic first, and provide little to no support for custom IPv6 rules.
Even if that were not an issue, my bet is that there are close to zero popular games that actually use true peer to peer networking.