An informal survey... round II

michael.dillon at michael.dillon at
Thu Aug 30 14:35:47 UTC 2007

> Consider large ISP's that can no longer obtain from the large 
> blocks (e.g. /12 to /16) but instead must beg/barter/borrow 
> blocks from others which are several orders  of magnitude 
> smaller (e.g. /16 through /24) every week to continue 
> growing...  such obtained blocks would be announced into the 
> routing system very rapidly as we try to keep
> IPv4 running post depletion of the free address pool.  When 
> this inflection point is reached, how much headroom do we 
> have given equipment being deployed today?

You have described a pretty desperate state of affairs. Given that the route announcements are part of the public record, this is tantamount to holding a press conference and telling everyone that your business is in a pretty desperate state and you are scrambling just to keep your head above water in the hopes that it will stave off disaster long enough for you to get a proper solution deployed.

I wonder how many companies will let things get this bad when IPv6 is right here, right now, and mitigates against this kind of disastrous state of affairs? I wonder how many investment analysts will note that companies without a solid IPv6 deployment plan in 2008 and 2009, are likely to start hemorrhaging in 2010 as customers scramble to find a stable supplier before the inevitable day of doom?

People keep saying that there is no business case for IPv6 when the answer is staring them in the face. Growing revenue is the absolute fundamental core of any business case, and in telecom companies that is generally directly tied into growing the network. If your fancy new IPTV home banking package deal depends on connecting new customers to your network, lack of IP addresses will stop your provisioning process dead in its tracks. And that stops growth dead in its tracks. And that shows that all the money that management invested in the fancy new IPTV home banking package was actually wasted (or shall we say misdirected) investment like all that fancy décor on the Titanic.

In general, telecoms companies (read ISPs) are trying to move up the value chain, but any product which depends on network connectivity probably has a direct dependence on growing the network. This means it is directy dependent on a steady supply of fresh IP addresses. We stopped manufacturing IPv4 addresses a long time ago. ARIN and ICANN have issued end-of-life announcements for IPv4 addresses. Does it make any business sense at all to bet the farm on products which only work using IPv4 addresses?

The fact is that IPv6 and IPv4 can interwork quite well so it is not a great technical feat to make IPv6 products that work. It certainly costs more up front to develop such products, but I doubt that anyone has done a real cost analysis comparing this to marketing costs, and other softer product development costs. Companies can introduce expensive products and still make money at it. Cutting prices to the bone is not the only way to make money. Engineers like to exclaim that IPv6 costs too much, but engineers rarely ever have the data to quantify exactly what that cost is and why it is too much. 

In fact, IPv6 doesn't cost too much. Lots of companies are using it today. Government agencies are installing it because the Federal government's GAO thinks that IPv6 is money well spent, i.e. it does NOT cost too much. IPv6 is appearing with more frequency on RFPs, not just in questions about future plans, but as a real requirement for service today. Many customers will be satisfied with Hexago boxes connected to your IPv4 network. More will be satisfied with Softwires across an IPv4 network. They will be exstatic if you offer 6PE over MPLS (or dual stack) and geographically diverse IPv6 peering. IPv6 is real and moaning about how hard it is will not make it go away, especially when it gets on your CEO's radar.

--Michael Dillon

P.S. rant directed at the IPv6 naysayers, not the many people on this list who are deploying IPv6 today or at least planning their deployments for next year.

More information about the NANOG mailing list