A straightforward transition plan (was: Re: V6 still not supported)

Sat Mar 26 10:51:54 UTC 2022

> > If there is a magical transition technology that allows an IPv6-only host t
> o
> > talk to an IPv4-only host, then let's deploy it.
> 
> DNS64/NAT64, DS-Lite, 6rd, 464XLAT, MAP-T, MAP-E, ? pick a transition
> protocol and see what happens!  (with more coming every year...)

The problem with these is that they are not full solutions. That's why we
get new ones every year: everybody picks the subset of the problem they
want solve.

To go over the ones you listed:
- 6rd. That's the odd one out here. 6rd privdes IPv6 over an IPv4
  infrastructure. Very useful when there was not a lot of IPv6 native. Not a
  good approach for organisations that lack IPv4 addresses. Also not a good
  approach if you want to switch off IPv4 at some point.
- DS-Lite, MAP-T, MAP-E. Good for connecting CPEs to IPv4aaS over an IPv6-only
  backbone. Downstream from the CPE is dual stack. For this reason those
  protocols do not see much use outside ISP networks. Got a great transition
  technology because hosts will keep IPv4 until the last IPv4 on
  the internet is gone. It is a bit of an IETF failure that we have so
  many ways to connect a CPE to IPv4aaS.
- NAT64/DNS64. This is the closest to an actual transition technology.
  Unfortunately it is completely flawed in too many ways. 
- 464XLAT fixes many issues with NAT64/DNS64. The downside is again that
  hosts have to have an IPv4 stack until forever and in addition to that
  a complex IPv4-to-IPv6 translation module. That fails the requirement
  that an IPv6 stack should have roughly the same complexity as IPv4 and
  talk to IPv4-only.

Basically, there is no solution to the transition problem. There are
lots of partial solutions, each with their own advantages and disadvantages.

If we could go back in time, then developing NAT64 along with IPv6 and
making sure the translation really works including edge cases like IPv4
literals, DNS A records, NAT traversal, etc. would have made a 
difference.

I don't know if such translation gateways were considered, I can't recall
much discussion about them. By the time the IPv6 socket API was created
it was already too late to get things like IPv4 literals right.