As in what is (unfortunately) actually being used. ISP's have taken so long to even begin to look at moving to IPv6 that stopgaps like CGN have to be put in place. Then, of course, why break what is working so IPv6 is put off even further.
CGN has a real cost. ISPs like T-Mobile and Time Warner have found that IPv6+CGN (either DS-Lite or 464) is cheaper than CGN alone because 50% of traffic can bypass the CGN.
That's actually exactly what this is. Currently coal is the cheapest electricity you can get. However, as the price of coal, oil, and natural gas goes up, and as the price of cleaner alternatives (through research, scale, etc.) goes down, we will eventually arrive at using much cleaner energy. The big problem with this is that those two prices aren't moving fast enough to avoid a global climate disaster we will be facing within several decades.
That's why the current incarnation of Capitalism (finance-based, quarterly-results oriented) is broken beyond repair. Kicking the can down the road sound like a hell of an option if you can be relatively sure there will be a different guy doing all the eventual cleanup.
Sort of. IPv6 adoption is a matter of supply/demand economics. The supply of IPv4 is quickly approaching zero, while the demand is rising fast. At the same time the supply if IPv6 is effectively unlimited, but the demand is not there. At some point, the supply of IPv4 will go so low that its cost will suddenly jump. The cost of IPv6 deployment is still too high (mostly in human labor to set it up, and somewhat in equipment costs since some large legacy networks are not IPv6-ready). However, that jump in the IPv4 cost will price IPv6 deployment at a point much cheaper than alternatives (IPv4 large scale NAT or other workarounds). That's when we'll see a huge jump in IPv6 deployment.
I think the next big step for ISP's is to provide IPv6-only native service to their clients, and add IPv6-to-IPv4 gateways to allow access to IPv4-only internet.
> I think the next big step for ISP's is to provide IPv6-only native service to their clients, and add IPv6-to-IPv4 gateways to allow access to IPv4-only internet
Edit: for my money, NAT64 + DNS64 would get us 90% of the way there. OS support for pseudo-IPv4 would really fix this 100%: if the application wants to talk IPv4, the OS would transparently translate it into an IPv6 address in the 64:ff9b::/96 address prefix.
Take a look at https://github.com/ayourtch/nat46 - I've coded it primarily for OpenWRT (so it requires forwarding), but the core portion is usable in userland as well - so I have this crude hack (https://github.com/ayourtch/example-nat46/) to get something-of-a-CLAT running on OS X with zero changes to the nat46-core.[ch] code - I literally sync them between the two repos periodically.
Why can't the handset itself do the DS-lite IPv4 NAT/encapsulation, or why is 464XLAT easier to do on handset than DS-lite?
Yeah, I've made exactly the same argument. As you found, there's a lot of history here. As I remember it, T-Mobile was originally pitching NAT64 because it required no support on the phone at all and DS-Lite would require the phone to do encapsulation. People pointed out that DS-Lite supports v4-only apps and NAT64 does not, but it seems like T-Mobile chose not to hear that argument. Then, having already committed to the NAT64 route, they added a stateless NAT46 agent on the phone to fix v4-only apps.
I think that agreeing on a standard is more valuable than continually iterating towards perfection, so I wish the industry had just declared DS-Lite "good enough" and stopped, but now we have this menagerie of transition schemes.
