If you are looking for excuses not to deploy IPv6 this is not the article you are looking for. As many people are aware of the transitioning from IPv4 to IPv6 hasn't been going smoothly. The challenges IPv6 has been facing are mostly caused by RFC 1918, NAT, and people inventing excuses for not deploying IPv6.
In this article I will outline an alternate timeline which I think could plausibly have happened if RFC 1918 had not existed.
The demand for more hosts on each LAN than the number of IPv4 addresses provided by ISPs would definitely have existed. Without RFC 1918 an alternative would have been provided by 6to4. With 6to4 you would get a quadrillion IPv6 addresses for each IPv4 address. That's more than enough for a LAN. In fact it's enough to run 65536 separate LAN segments.
All of the networks which used 6to4 in this way would be able to communicate with each other as packets would be encapsulated in IPv4 between those networks. The challenge would be in how hosts on those LAN could connect to external IPv4-only hosts.
In the setting described above the invention of NAT64 would have been inevitable. The requirements would have been obvious to any person with sufficient networking knowledge. It's quite likely that more than one person would have invented NAT64 independently of each other.
Interoperability between competing NAT64 implementations would not have been any major concern as NAT64 gateways tend to not communicate with each other. However as the need for DNS64 would have quickly become apparent the need for interoperability between NAT64 and DNS64 would arise. That means that some standardisation of how to embed IPv4 addresses within IPv6 would have emerged. It would have looked similar to RFC 6052 and would have included the same 96-bit prefix format, but it would not have been entirely identical and would for example not have included the 40-bit prefix format that exists in RFC 6052.
With the combination of 6to4, DNS64, and NAT64 the stage is set for rapid adoption. A few different things are going to be happening in parallel. The reason this rapid adoption would be possible is that the 6to4-DNS64-NAT64 combination is powerful enough to be useful for individual networks deploying it the same way RFC 1918+NAT44 got traction. It would be a useful combination even if the servers you are communicating with are IPv4-only.
Next we'll take a look at the things which would start happening in parallel once 6to4-DNS64-NAT64 had proven useful.
Consumer routers would quickly adopt 6to4-DNS64-NAT64 as their default configuration since this would be the only option supported across most ISPs.
Client applications would get IPv6 support sooner than we'd otherwise have seen. The reason being that the number of client hosts with IPv4 would stagnate and the number of client hosts with 6to4 addresses would grow rapidly. As such client applications simply needed IPv6 to work on most networks.
Server administrators would realise that most clients were accessing their servers from a 6to4 address through NAT64. Though this would work it would be slightly less reliable than running 6to4 end-to-end. Consequently more and more domains would create AAAA records with 6to4 addresses.
In our timeline lots of resources have gone into developing NAT hole punching techniques. In this alternate timeline that would never have happened. Adoption of 6to4 was a prerequisite for NAT64 to happen. This had the consequence of ensuring every peer behind a NAT would have a 6to4 address. So all the resources which would have been used developing NAT hole punching would instead have gone into supporting IPv6 in all of the applications which wanted end-to-end connectivity. This would be more productive as there would be no need to support a very varied landscape of NAT products, it would also be more reliable as those hosts could communicate end-to-end using 6to4 and completely bypassing the NAT.
In this timeline the widespread usage of AAAA records with 6to4 addresses would eventually mean there would be practically nothing left for DNS64 to do. Eventually implementors would choose to drop support for DNS64 and NAT64 leaving only 6to4. At this point more than 99% of the traffic across the backbone would be 6to4 traffic. Native IPv6 would have been absent up to this point.
ISPs would still run out of IPv4 addresses. The usage would have been slightly smaller than in our timeline. In our timeline some customers would need multiple IPv4 addresses. But in the alternate timeline one IPv4 address per customer would have been sufficient.
We know that still didn't provide enough IPv4 addresses as in our timeline ISPs would eventually need to deploy carrier grade NAT. In the 6to4 timeline this problem would arise at a time where NAT was already a dying technology. What would happen at this point is carrier grade 6to4.
A typical carrier grade 6to4 configuration would involve routing a /24 IPv4 prefix to a gateway such that it would have a /40 of IPv6 address space. This would then be subdivided into a /56, /60, or /64 per customer. One advantage compared to CGN is that carrier grade 6to4 is stateless. Multiple devices with identical 6to4 configuration can be deployed.
RFC 3056 which defines 6to4 says that 6to4 prefixes more specific than 2002::/16 must not be propagated in native IPv6 routing, to prevent pollution of the IPv6 routing table. ISPs deploying carrier grade 6to4 would ignore that requirement.
Initially bilateral agreements around network peerings would allow for 6to4 prefixes to be announced alongside the corresponding IPv4 announcements. When both sides are using carrier grade 6to4 it is advantageous for both sides to announce these prefixes in order to reduce the load on carrier grade 6to4 devices.
This trend puts customers with their own IPv4 address and own 6to4 gateway at a slight disadvantage. There would likely be ISPs who offer customers to trade in their IPv4 address for a /52 carrier grade 6to4 prefix.
Eventually there would be consensus that each AS is allowed to announce a small number of 6to4 prefixes through transit providers. The hope is that this will stop the growing fragmentation of IPv4 address space leading to a growing routing table. As long as the average AS announces 1-2 6to4 prefixes it would be an overall win. An RFC would be published to address this.
Native IPv6 and 6to4 haven't been working great together. That is equally true in this alternative timeline, but for different reasons. In the 6to4 timeline the problem affects communication between conventional 6to4 and native IPv6. However carrier grade 6to4 with prefixes announced as both IPv4 and IPv6 will communicate reliably with both.
At this point ISPs will have incentive to turn down IPv4 for their customers. New customers will predominantly get carrier grade 6to4 since that communicates reliably with the largest number of networks and uses less address space per customer than IPv4. A few ISPs may start giving native IPv6 to their customers, which increases the incentive to convert from IPv4 to carrier grade 6to4.
The majority of customers will at this point be happy to convert. The ability to communicate with the increasing number of native IPv6 networks is more important than the amount of IPv6 address space which most customers weren't using anyway. The customers who needed the additional address space will grudgingly accept that they will have to exchange their /48 of 6to4 address space with either a /56 of carrier grade 6to4 address space or a /48 of native IPv6 address space.
Everything discussed in this article is hypothetical. It didn't happen and nobody will ever know if the lack of RFC 1918 would have turned out as described here or in some other way.
This article is not a proposal for how to fix the current situation with IPv6 deployments. There is no way to go back and try to deploy 6to4 in the way described here. The two main reasons are that in our timeline there is a widespread perception of 6to4 as unreliable, which we cannot change now and secondly the widespread use of CGN means 6to4 is no longer viable.
Individual customers will have no benefit from deploying 6to4 as described here. There are three reasons for that: Most likely they are behind a CGN which will prevent them from using 6to4. There are too many native IPv6 networks that they wouldn't be able to communicate reliably with. And some of the benefit which DNS64+NAT64 would have provided has instead been addressed by NAT444.
ISPs have zero incentive to deploy carrier grade 6to4 as described here. The reason for carrier grade 6to4 being viable in the alternate timeline was lots of individual deployments combined with no native IPv6. However at the current point in time in our timeline there is no benefit in 6to4 compared to native IPv6.
The use of RFC 1918 and NAT44 has harmed IPv6 deployments in a couple of different ways which you may have noticed illustrated in this article. First of all it provided temporary relief for the IPv4 shortage which slowed down the drive for IPv6 before it even got started. This has harmed adoption of the much more future proof NAT64 approach. Additionally NAT44 is in many cases preventing individuals with no access to native IPv6 from using common tunnel solutions to get IPv6 that way.
I have no doubt that there are people who will disagree with most of the things I have written in this article. My main response to that is that this article describes a hypothetical scenario, so there is no way to verify who is right. This article does not discuss any ideas for how to solve the problems, constructive ideas on how to solve the problems are welcome. In most cases the one important step to take is simply to prioritise IPv6 support. I am doing my part in making that happen wherever I have the opportunity.
If you are going to argue that IPv6 should be more backwards compatible with IPv4 remember that 6to4, DNS64, and NAT64 do provide lots of backwards compatibility. There is no denying that 6to4 failed, but that hasn't stopped several people from making alternative suggestions which learned nothing from the failure of 6to4. I have yet to see a proposal which provides more backwards compatibility than those three protocols. DNS64 and NAT64 are still going strong and I see them as helping us in the right direction.