[97632] in North American Network Operators' Group
Re: The Choice: IPv4 Exhaustion or Transition to IPv6
daemon@ATHENA.MIT.EDU (Joe Abley)
Thu Jun 28 14:51:03 2007
In-Reply-To: <4683ECEC.6050009@psg.com>
Cc: John Curran <jcurran@mail.com>,
Stephen Wilcox <steve.wilcox@packetrade.com>, nanog@nanog.org
From: Joe Abley <jabley@ca.afilias.info>
Date: Thu, 28 Jun 2007 14:02:50 -0400
To: Randy Bush <randy@psg.com>
Errors-To: owner-nanog@merit.edu
On 28-Jun-2007, at 13:16, Randy Bush wrote:
>> Interoperability is achieved by having public facing
>> servers reachable via IPv4 and IPv6.
>
> that may be what it looks like from the view of an address allocator.
>
> but if you actually have to deliver data from servers you need a path
> where data from/in both protocols is supported on every link of the
> chain that goes all the way to every bit of back end data in your
> system. and if one link in that chain is missing, <sound of glib idea
> imploding>.
I think this is one reason why the transition is hard: supporting
dual stacks in clients when the demonstrated quality of the v6
network is noticably worse than the v4 network is a difficult
business case to sell.
When you depends on users being able to talk to you reliably, having
them use a low-quality transport when a high-quality transport is
also available has a direct impact on the bottom line, without even
considering the capex/opex costs of supporting IPv6. The difference
in performance/reliability might be relatively small to a single
user, but to a company who is trying to service millions of clients
every minute (and is earning revenue from each visit) the aggregate
effect is surely much more significant.
Providing access to (e.g.) web services over both IPv4 and IPv6 using
(e.g.) a single URL hence reduces revenue when serving the non-zero
(but small) set of dual-stack clients, and does not increase revenue
from the set of IPv6-only clients in any practical sense since that
set is (to all intents and purposes) empty.
Providing separate URLs for services over IPv6 requires user
education, which is arguably even more expensive.
The way to avoid this scenario is presumably to improve the quality
of the IPv6 network such that the risk of revenue loss from IPv6
support falls below an acceptable threshold. Which would be much
easier to do if people were using it, and opening trouble tickets
when things need to be fixed :-)
Joe
