The Choice: IPv4 Exhaustion or Transition to IPv6

Joe Abley jabley at
Thu Jun 28 18:02:50 UTC 2007

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 :-)


More information about the NANOG mailing list