Everyone is always quick to complain that we're going through N number of NAT gateways or N number of proxies, but this is virtually never a problem for most of the Internet. Even despite this rats maze of proxies and NAT gateways we're still supporting virtually all the applications that consumers use and love such as VoIP, WebRTC, HTTP(S), DNS, Gaming, Streaming Video, Mobile Apps, etc.
NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience, but there has to be some sacrifice to keep the Internet running for the billions of users.
NAT and by extension CGNAT are the unsung heroes of the Internet.
>Even despite this rats maze of proxies and NAT gateways we're still supporting virtually all the applications that consumers use
That's a tautology: "Despite the limitations of IPv4, we're still supporting all the applications that can work within the limitations of IPv4".
Lots of potential P2P applications (that might solve a lot of problems with have with the current centralised model of the internet) either don't make it past the drawing board because of NAT, or have to be encumbered with complex, expensive-to-develop, best-effort NAT-punching behaviour that burdens everyone involved (and can stop an application from being truly P2P by having to run things like STUN servers).
>NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience
I think there would be many more that wanted this if it were trivially easy to do
>but there has to be some sacrifice to keep the Internet running for the billions of users.
> I think there would be many more that wanted this if it were trivially easy to do
I've seen figures from proponents of Future Internet Architectures such as Named Data Networking claim that consumption is about 80% of Internet traffic. The truth is not everyone needs a Internet addressable host, mobile phones for example don't. And well, we're living in this situation today with CGNAT and you don't hear complaints from customers about not having Internet addressable IPs.
> What's the sacrifice in using IPv6?
Support. Enabling IPv6 on broadband consumer networks, small medium businesses, etc. means that you have to support the various devices v6 stacks and applications and ensure they continue to work just as well as they did with IPv4. IPv6 can still cause damage and the ability to support and fix these issues throw out virtually all incumbent knowledge.
If it were really just a "flip of a switch", everyone would've done it by now.
In some countries almost everybody already did it. The way they did it is by starting 15-20 years ago, and making sure every new replaced device supports it.
Any kind of application that acts as a server needs a direct IP connection.
Gamers get errors about "strict NAT." Traditionally the solution to this problem caused by NAT was to forward the ports. If their ISPs has chosen CGNAT port forwarding is impossible.
VoIP calls that have one way audio are a symptom of reachability issues caused by a firewall or address translation problems. VoIP services have adapted to IPv4 NAT by relying on proxying instead of STUN but CGNAT really degrades reliability.
Video chat uses the kludges of TURN when peer to peer connectivity does not work. This increases costs for the video chat service who in turn require a paid subscription as they will not relay traffic for free.
BitTorrent and file transfer services need direct IP connectivity. If p2p file transfers worked on any network we would not need to mind Gmail's 25MB attachment limit, or pay for intermediary cloud storage.
Most of the applications that could communicate peer-to-peer use relay servers that make delay and scalability worse. Some combinations of NAT may sometimes work without a relay server, but figuring this out is complex and increases connection setup time. Every early SIP/VoIP user had the 'the connection only works in one direction' experience, usually caused by NAT.
A CGNAT is a stateful component which makes it expensive to operate. Failover to a backup is hard, as is scalability with this kind of components. And then there are legal requirements. You have to know what user had which IP address at a given time. I'd rather invest in dual stack instead.
Peer-to-peer still wouldn't work even in a fully IPv6 world without something like STUN or TURN, since endpoints would still be protected by stateful firewalls preventing external connections to them.
With a firewall, the application knows its public-facing ipv6 address/src port number without STUN. A stateful firewall does not alter packets.
It can open the firewall simply by sending something. If it can communicate its public-facing ipv6 address/src port number to the remote side using a SIP proxy (ok, for this signalling, you need a relay), it can receive traffic. No TURN needed either.
If the two peers are each behind its own stateful firewall (as would be common with something like BitTorrent), then you still need some 3rd party server accessible to both of them that either relays traffic between them, or at least allows them to negotiate the port pair that they'll communicate on (so that the one which will accept the TCP connection can send a TCP SYN with the other's source port as destination).
The second option may not even work with more paranoid firewalls, which might not allow TCP SYN packets on existing connections.
NAT seems to always get a bad rep because it inconveniences the very few that want to have an end to end experience, but there has to be some sacrifice to keep the Internet running for the billions of users.
NAT and by extension CGNAT are the unsung heroes of the Internet.