[arin-ppml] An article of interest to the community....

[Owen DeLong]

On Sep 1, 2011, at 3:10 PM, Chris Engel wrote:

>> The extreme costs of IPv4 at the access provider level WILL drive access
>> customers to IPv6. Even to the extent that access customers are able to
>> maintain some level of IPv4 capability, it will be significantly degraded and
>> they will begin to prefer sites and services that can deliver to them on native
>> IPv6.
> 
> You are going to need to be more specific when you are talking about "significantly degraded" sites and services. What sort of degradation exactly are you talking about?  I'm willing to bet 95% plus of the existing users of our services are behind NAT on their end....and our server are behind NAT on our end. So you've already got NAT on both ends of the connection. In 10 plus years of offering these services now we've had ZERO complaints involving NAT and exactly ZERO support calls that involved NAT. What's likely to change about that? Why should someone running native 6 and translating to 4 be any different in that regard?  If the average user running a native IPv6 today can't translate and reach the majority of IPv4 sites without experiencing significant degradation of services then I really don't think I'm going to have to worry much about IPv6 tomorrow....because IPv6 will already be dead on arrival and will never reach tomorrow. If IPv6 is gaining in adoption today.....that tells me that the people using it aren't generally having problems using most IPv4 hosted services.... either that or there are way more masochists out there in the world then I would imagine.
> 

You're limiting this to simple web services. The NAT on your end is irrelevant because you have designed your application(s) to work in an opaque network.

The NAT on the consumer end is only slightly more relevant because it has UPnP, NAT-PMP, and other traversal technologies under the user's control (or the automated control of their applications).

This is very different from the addition of a second layer of NAT at the access provider level (which is what is coming) that creates an opaque environment with significantly less opportunity for user-controlled work-arounds.

Will this cause you a problem in your environment tomorrow? Probably not. Will it cause you a problem further down the road? Maybe.

However, you are a corner case. A microcosm.

Looking at the bigger picture, assuming that the access networks have any choice other than to deploy IPv6 to their users strikes me as utterly and completely absurd at this point. A lot of the people I talk to that run pretty large access networks say the same thing. They will implement NAT444 and/or some form of protocol translation solution only to the extent that they have to to deal with content providers that aren't yet converted.

In the end, it won't be a comparison of the current IPv4 performance against NAT64, but, of the IPv6 native performance between your users and the sites that have IPv6 capabilities vs. the performance of your site which is behind NAT. This will become even more apparent as those other sites start to offer services and capabilities that depend on a more transparent network which cannot be provided in your opaque environment.

> In terms of what end users of our services actually care about, the choice of transport protocol used to reach our sites rates somewhere below what our lead programmer had for breakfast this morning.  I'm not saying that case will hold true for every content provider.....but I'm just not seeing how it is going to make much difference to most of them.
> 

That may be true for your little corner of the world. It is NOT true for a very large portion of the internet.

Will the end users care about the transport protocol? Of course not. What they will care about is the features, capabilities, and speed of the sites they visit. If your site is stuck in today's NAT+NAT environment (or worse as you won't have any control over whether the providers does NAT64 or NAT444 for such customers), then the rest of the world will pass you by with the new features available in a transparent native IPv6 network.

Access networks cannot continue to scale without IPv6.

Maintaining IPv4 compatibility for their end users will be expensive and will provide a significantly suboptimal solution for them which will increase their support costs. Their end users likely aren't only using your applications on your servers. They probably use other things like instant messaging services, VOIP, gaming applications, etc. All of these things have been shown to suffer to varying degrees in an opaque network. There will also come a time when the availability of a transparent network will again lead to development of applications that take advantage of that openness to provide features that are not available on today's opaque networks.

Nonetheless, if you want to wait until your competitors pass you by and then play catch-up, you are more than welcome to do so. Nobody is twisting your arm.

Just don't pretend that your efforts to remain a protocol luddite are in any way representative of the reality that is faced by the majority of the internet.

Owen