Although some people still see IPv6 as a solution for a problem that has never actually arisen — exhaustion of the IPv4 address supply — we take a very different view. All the IPv4 address were actually used up long ago. The main reason why that hasn't brought the internet to a screeching halt is that various technical workarounds have been adopted. The best known is Network Address Translation (NAT), which allows a large number of users to access the internet via a shared IPv4 address.
By deploying NAT and other short-term fixes, we may have headed off the acute problem, but we've also shot ourselves in the foot. Most users don't actually have a proper internet connection of the kind envisaged by the net's designers. Without a unique IP address, your computer is unreachable for the outside world. And the arrival of Carrier-Grade NAT (CGNAT), a cascade of multiple NAT layers, has made things even worse.
As long as you initiate connections yourself (like your connections to web and mail servers), it doesn't matter that your computer isn't directly accessible from the internet. However, for real-time applications such as internet telephony (VoIP), instant messaging and multi-player gaming, users need to be able to exchange UDP data packages without any discernible delay. If either party doesn't support IPv6, interaction has to rely on IPv4. And, if you're on a NAT network, which almost all IPv4 users are, that's impossible without a special STUN server (Session Traversal Utilities for NAT). One of the clients uses the STUN server to establish its own external IP address/port number. The relevant application then shares that information with the other client using the session management/signalling protocol.
But, if both clients are on NAT networks, things quickly get very complicated: various NAT traversal strategies have to be used, depending on the forms of NAT separating the peers that want to communicate. As a user, the main thing you notice is that it's simply not possible to establish a good connection. Who hasn't experienced a VoIP or WebRTC session where someone has no picture or no sound, making proper interaction impossible? That happens when the necessary data links (which are usually based on RTP) can't be established.
TURN and ICE
In problem situations of the kind described, the ultimate solution is a TURN server (Traversal Using Relays around NAT). As the names suggests, that's a server that acts as a relay station between two peers. Multimedia data is sent to the TURN server by one client and picked up by the other. In other words, the problem of peers being unable to reach each other is resolved by linking them both to a separate internet server (which does have a unique IPv4 address, of course).
TURN has two big drawbacks: each connection needs its own resources (data buffers) on the server, and the relay station needs a lot of centralised bandwidth. It's therefore an expensive solution and not readily scalable. What's more, having an extra communication step causes delay, which is highly undesirable for real-time applications.
Finally, there's the ICE protocol (Interactive Connectivity Establishment), which was developed to minimise the need for a TURN server. With ICE, a sequence of methods and transmission addresses (IP addresses/port numbers) are tried in turn in an effort to connect the peers. Only if all else fails is the TURN server used.
It's not surprising that Microsoft is an advocate of IPv6. The multi-player games on the company's Xbox consoles work fastest (and most cheaply) when players can communicate with each other directly, on the basis of IPv6. Having a relay station in the form of a TURN server impairs real-time interaction between players, and therefore spoils the game.