Re: [v6ops] The need for local-ipv4 socket transition solutions -- NAT64/DNS64 remains insufficient

[Lorenzo Colitti <[e-mail]>]

On Tue, Mar 24, 2015 at 10:06 AM, James Woodyatt <[e-mail]> wrote:

> as an endpoint software developer, if every host I want to deploy on has a
> CLAT provided by the system, then I'd observe that my incentives to stop
> writing IPv4-only software logic would evaporate for all practical purposes.
>

I'm not sure that's true. We have four scenarios, in order of decreasing
incentives (from 100% to 0%) to write IPv4-only code:

   1. IPv4-only device
   2. Dual-stack device (native IPv6 and NAT44 or NAT444)
   3. IPv6-only device with "compatibility quality" IPv4 (e.g., 464xlat).
   4. IPv6-only device

Based on personal experience, I know that #3 provides less incentives to
write IPv4-only code than #2. I've heard developers say multiple times,
"Double NAT and 464xlat? (i.e., #3.) Man, that sounds pretty flaky, and
high latency too. What do I need to do to fix my code to support IPv6?" In
contrast, #2 is seen as, "well, we still have IPv4 right? So we can just
continue to use it. You say IPv6 has no NAT? But we deal with NAT today,
and it works fine..."

I think the real discussion here is whether going from #2 to #4 without
passing through #3 is possible at all. If you believe that it's possible,
then #2 makes sense. If you believe it's not possible, then the only thing
that makes sense is to do #3 ASAP.

I don't believe that going from #2 to #4 is possible for the industry. It
may be possible for a tightly-controlled, substantial subset of the
industry (e.g., Apple) to do it, but if we did not have a substantial part
of the industry doing #3 already, we'd likely get stuck.

#3 does provide strong advantages over #2 to operators; in some networks,
#2 doesn't actually fix anything because the problem is private IPv4
address exhaustion. For those networks, the only options are #1 or #3 -
which is why those networks are doing 464xlat.