Let’s look at another part of the lengthy comment Bob left after listening to the Rise of NAT podcast. This one is focused on the NAT traversal mess:

You mentioned that only video-conferencing and BitTorrent use client-to-client connectivity (and they are indeed the main use cases), but hell, do they need to engineer complex systems to circumvent these NATs and firewalls: STUN, TURN, ICE, DHT…

Cleaning up the acronym list first: DHT is unlike the others and has nothing to do with NAT.

Now that we’re left with three acronyms, let’s try to figure out what they do:

• STUN detects NAT devices in the forwarding path and uses clever tricks to create the NAT translations that can ultimately be used to reach a peer node behind another NAT device.
• STUN does not work with all types of NAT. In particular, it does not work with symmetric NAT (NAT using 5-tuple NAT translations – what you’d see on Cisco IOS). TURN tries to fix that.
• ICE seems to be an umbrella solution on top of the other two (please write a comment if I got it wrong)

Wouldn’t it be better if, instead of the above mess, the host could tell the NAT device it needs a public port? Of course, we have at least three protocols to do that, proving yet again the infinite wisdom of xkcd:

• Internet Gateway Device Protocol part of Universal Plug and Pray Play
• Port Control Protocol
• NAT Port Mapping Protocol

Why do we need STUN/TURN/ICE if we have a (supposedly) working solution? It often comes down to I don’t want to deal with those uncouth people from the IT basement (aka “networking engineers”), a well-known strategy used by the likes of Novell and VMware, or to I want to make this work even though some stupid security people think it should be blocked (see also: using Signal to plan bomb strikes).

I never said NAT is a great solution (it’s not), but it’s still a necessary evil (even in the IPv6 world) that has to be dealt with. There are standard ways to do it, and fortunately, we have tons of libraries you can use to get the job done without going into the details. A quick search for “Python [STUN|TURN|ICE] NAT” resulted in a half-dozen GitHub/PyPi projects. Ideally, we’d have a single library that everyone uses to get the job done (like OpenSSL¹ and OpenSSH), but maybe we’re not at that stage yet.

Last but not least, networking engineers love to think that networking’s complexities are unique. Well, I can point you to numerous other IT disciplines full of complexities, but they managed to build layers of abstraction around them. For example, people stopped reinventing compilers, operating systems, and databases ages ago. I haven’t heard anyone (apart from a small circle of database developers) talking about the complexities of distributed databases that arise because they have to deal with byzantine faults and the consequences of the CAP theorem. Why should NAT traversal be any different?

But It Would Be Better in IPv6 World

Here’s the most common counter-argument to my “NAT is a necessary evil” rants, this time made by Daryll Swer:

All these problems don’t exist on native routed (and static) IPv6.

TL&DR: Bollocks.

Most hosts connected to the public IPv6 Internet over a LAN or WiFi sit behind a stateful firewall² (for various reasons³). Punching holes through that firewall is equivalent to establishing NAT translations.

Oh, but dealing with firewalls is so much simpler in the IPv6 world:

Firewall hole punching only involves STUN, and that’s it. We move on with our lives.

Sort of⁴. Decent stateful firewalls match on the full 5-tuple, which is functionally equivalent to symmetric NAT, but don’t change the UDP port numbers when packets traverse them (making them equivalent to ‌port-restricted cone NAT), so it’s easier to discover what hole your peer punched in their firewall.

On a more practical note, even the Cisco router⁵ between me and the global Internet seems to be using port-restricted cone NAT (another term for the same behavior seems to be Endpoint-Independent Mapping – EIM), and I don’t remember when a VoIP call or a video conferencing app would not work. Yes, things are unnecessarily complex (from the perspective of IPv6 fans), but they work. It seems the NAT-induced complexity is still not expensive enough to make migration to IPv6 cost-effective.

However, to be fair, CG-NAT in the IPv4 world does introduce a whole new level of evilness not present in the IPv6 world. For example, if two devices in the same CG-NAT cone⁶ want to communicate but happen to use a server outside of the NAT cone⁷ to find their respective IP addresses, the traffic has to go through the NAT device (hairpinning).