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

[Brian E Carpenter <[e-mail]>]

On 25/03/2015 04:26, Lorenzo Colitti wrote:
> 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?" 

I think this is important. The biggest problem that I see is how to incent
smaller content providers (smaller than Google and Facebook, I mean) that
it is in their own interest to support native IPv6. If they perceive IPv4
as becoming a second-class service for millions of users, that might push
them in the right direction. #3 is useful in that context.

   Brian

> 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.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>