You might not but NAT has many different flavors, and many people don't get to choose which is used on their network.

https://serverfault.com/questions/208522/what-is-strict-mode...

This can particularly play havoc with sensitive protocols like STUN. I believe many game consoles make use of this when in multiplayer matches. I have personally run into this using OpenBSD's pf, but I'm fortunate enough to have access and the known-how to fix it for my consoles.

It's one of those things that's fine until you run into "edge cases," and unfortunately NAT configurations can introduce a lot of undefined behavior from the user perspective.

VoIP.

Two peers, each behind a CG-NAT (or other symmetric NAT), depend on somebody running a relay in order to be able to communicate.

This makes it very expensive (and sometimes risky, since unrestricted relays can be used for all kinds of nefarious things too) to deploy any new VoIP service.

I'd call that "broken by NAT".

> everything works right now.

Yes, everything that works right now works right now, but that's a tautology, not proof of anything. The things that don't exist because they wouldn't work in a predominately NATted world don't work, because we live in a predominately NATted world.

Doesn't that present a privacy issue? One can _casually_ infer who you are talking to merely by examining network traffic.

You're always free to use a relay for privacy reasons. Many common VoIP solutions allow just that.

IPv6 (or more generally, the absence of NAPT) just changes the switch label from "try [not] to use direct connections, unless NAT gets in the way" to "[always|never] use direct connections".

In other words, it cleanly separates the two distinct concerns of privacy and connection topology. I think that's a good thing.

I remember having to do a lot of port forwarding to get certain things to work behind a nat. Certainly doable but beyond the competence of a non-expert.

And that's entirely out of your control if your ISP is doing the NATing.

Not even your ISP - it could be university, business, shared internet for apartments, etc.

And sometimes, entire nations. Qatar used to share a single IPv4 address, which I found out when news articles started reporting that the entire country could no longer edit Wikipedia without an account, which at the time, was also restricted if your IP was banned from anonymous edits. If you didn't create an account prior to the ban, you were completely blocked from editing.

https://en.wikipedia.org/wiki/User:82.148.97.69

https://techcrunch.com/2007/01/01/wikipedia-bans-qatar/

This isn't entirely about static port-forwarding. As others have pointed out, STUN, VoIP, PASV, etc rely on deterministic NAT behavior to work. That is not always guaranteed, and often out of your control.

The existence of PASV mode and STUN/TURN is because the end-to-end addressibility of the IP protocol was broken with CGNAT.

Furthermore, in populous countries like India, ISPs enforce extremely aggressive timeouts on IPv4 connections in order to keep the 5-tuples on the egress side of things manageable. Trying to make a request that takes 10 seconds to process (like a user requesting a report consisting of multiple SQL queries)? You get a connection reset.

I must also must point out the HN guidelines because you bring a combative tone to this entire conversation which is not helping it.

> Be kind. Don't be snarky. Converse curiously; don't cross-examine.

> The existence of PASV mode and STUN/TURN is because the end-to-end addressibility of the IP protocol was broken with CGNAT.

But isn't all that still necessary as long as the typical user isn't going to be opening their firewall on those ports to arbitrary incoming connections? That's the whole point here.

STUN yes (since you'll need to coordinate outbound traffic which creates the appropriate inbound rules), TURN no (since STUN will always succeed with stateful but non-translating firewalls).

And STUN scales almost infinitely better than TURN.