I don't think it really matters what percent of clients are IPv6-capable. Nobody is incentivized to actually deploy servers to IPv6 while there exist zero IPv6-only clients.
> Nobody is incentivized to actually deploy servers to IPv6 while there exist zero IPv6-only clients.
Facebook is a counterexample.
> Over the past few years, Facebook has been transitioning its data center infrastructure from IPv4 to IPv6. We began by dual-stacking our internal network — adding IPv6 to all IPv4 infrastructure — and decided that all new data center clusters would be brought online as IPv6-only. We then worked on moving all applications and services running in our data centers to use and support IPv6. Today, 99 percent of our internal traffic is IPv6 and half of our clusters are IPv6-only. We anticipate moving our entire fleet to IPv6 and retiring the remaining IPv4 clusters over the next few years.
They might have actually done it, but my point is that the incentives for companies to do so generally aren't there. And as long as there exist some large sites that believe the costs to adopting IPv6 exceed the benefits, ISPs will continue to give IPv4 addresses to their clients.
My phone's IP is in the private 10 range. A request to Facebook must go through the provider's expensive NAT router.
If they assigned my phone an IPV6 address in addition, that traffic could go directly to Facebook through cheaper switches, which is faster for me, and cheaper for them.
The main benefit of IPv6 is that it allows all endpoints to have a real IPv6 address, including the ones that don't have a real IPv4 address.
It serves its purpose if it allows end user devices to directly communicate with each other even if cloud servers with real IPv4 addresses continue to use IPv4 until the end of time.
Wouldn't it be expected to have a firewall with "NAT" type rules anyways? Inbound blocked until an outbound flow is made?
And UPnP seems to get around this right now anyways. At least, every NAT'd connection I'm on, when I run a Bittorrent client, I have no trouble getting inbound connections.
> Wouldn't it be expected to have a firewall with "NAT" type rules anyways? Inbound blocked until an outbound flow is made?
There are known solutions for this.
For host firewalls, the application can open a port for itself during installation.
For network firewalls, the firewall can implement Port Control Protocol (RFC6887), which supports opening even IPv6 ports.
> And UPnP seems to get around this right now anyways. At least, every NAT'd connection I'm on, when I run a Bittorrent client, I have no trouble getting inbound connections.
UPnP is a rubbish fire. The protocol itself is badly designed and unnecessarily complicated and many of the implementations are broken. Section 9 of RFC6886 is informative.
One of the common failure modes is that a client will create a port mapping with a random UPnP device that isn't the real gateway. Many applications will then falsely indicate that incoming connections are working but none ever come through.
And it's still sharing an IP address. Only one device can have the ssh port, or the SMTP port, or any other port.
Comcast is one of the leaders in this space in the US. They are nearing 100% deployment and their X1 platform is supposed to run IPv6 only internally (SetTop Boxes to their content source).