IPv6 Ignorance

[Brian E Carpenter]

On 05/10/2012 17:31, Tim Densmore wrote:
> Hi Thorsten,
> 
> On 10/5/2012 4:03 AM, Thorsten Dahm wrote:
>> I completely understand your situation. And I know that you can't do
>> much about it.
> 
> So things are clear, I was just using cost as an example.  We *are*
> deploying IPv6, but not using slaac for anything yet.  How we get v6 to
> small customer CPE is still not decided, so we'll have to work that out
> down the road.  I'm obviously still "just getting my feet wet" but I'm
> working towards 100% IPv6 availability.
> 
>>
>> Simple example: If I come to you as a small company and want from you
>> connectivity and a /24 for my servers, office and so on. And you have
>> to tell me that you don't have a /24 anymore and you also can't offer
>> me IPv6. But the next company is offering me IPv6, maybe a special
>> service contract to set up my router initally and such. You may can
>> keep existing customers, but it will be hard to get new ones. And to
>> keep the old ones, because they may ask for something else sooner or
>> later as well.
> 
> Forgive me if I'm missing something obvious here, but assuming I only
> have basic dual-stack connectivity available, how much value is even a
> /48 going to be to a customer who wants to collo servers? Making the
> assumption that the customer wants these servers in place for internet
> facing services, what percentage of the internet connected hosts would
> be able to reach that service at this point in time?  I don't have
> nat64/dns64 setup yet, and honestly am not sure that it's the direction
> I want to go.

Indeed not, unless you have to support a bunch of IPv6-only clients, and that
isn't likely any time soon, is it?

The value to a content provider is being ready for IPv6-only clients when
they show up.

More at
https://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance/

> 
> Using my own internet connection as an example, if I turn off IPv4, I
> can reach almost nothing via a browser, and I don't think it's much of a
> stretch to say that most people think email+browser=internet.  Dual
> stack, I reach some services via v6, like google and youtube and cisco
> pages, but most of them seem to be sort of half-baked v6.  So, bringing
> this back around to your point, how does a v6 only connection help this
> hypothetical customer?  

It doesn't.

> Or is the assumption that we'd give them, say, a
> v4 /29 and a v6 /48 and have them do their own nat64 or whatever?

Why would they need to do NAT64? If they are dual stacked, they are
home free.

   Brian



> 
>>
>> Again, I can understand your point. And you can argue that you don't
>> need IPv6 in 2012 to run your business. But what's about 2020? 2025?
>> 2050? As long as your company has a long-term plan, like "we will
>> switch to IPv6 between 2025 and 2028, before that IPv4 only is
>> sufficient", that's good enough. If it works out that way or not is a
>> bet, nobody knows, since we can't go to the future and check what
>> happened. I just know that I wouldn't put too much of my money into
>> this bet.
> 
> Well, my argument isn't exactly that IPv6 isn't needed, only that I have
> seen significant resistance to spending money and very little desire for
> the product itself.  Add to that the fact that, for most people at
> least, IPv6 doesn't allow them access to anything they want that they
> don't already have, and I can understand why there's not more uptake. 
> In terms of supply and demand, there's very limited of supply (I'm only
> seeing around 10k IPv6 BGP routes in my routing table, and I'd estimate
> 2 or 3 percent of websites I visit are "IPV6" according to sixornot),
> and basically zero demand. Again, IMO/IME, I don't mean to speak in
> absolutes here at all.
> 
> I hope this changes, but I can't see the often referenced "IPv6 killer
> app" scenario panning out.  What company in their right mind would
> purposely limit their exposure in the marketplace?  Again, I'll be
> delighted if I'm proven wrong, but IME so far, money talks, technical
> purity walks.
> 
>>
>> cheers,
>> Thorsten
>>
> Thanks for you input!
> 
> TD
> 
> TD
>