[Bp_ipv6] Can we do the math? ( was [MEAC ICANN] Fwd: Interesting IPv6 metrics)

Marco Hogewoning marcoh at ripe.net
Thu Aug 25 09:12:44 EDT 2016

> Hello,
>  One more thing:
>  In case this information is going to be put in a excel sheet CAPEX
> information should be added to it.., many times Cameron has said the
> CAPEX to implement v6 in their network was zero. Not much information
> about the v6 OPEX (at least that I know)

That might be a "too specific”, which only holds for T-mobile. Even when there is no purchase of hardware involved, many companies would probably still treat any development cost or project management as CAPEX and amortise them.

The only sources I’ve seen in relation to OPEX are ones comparing v6-onloy (or v4-only) vs dual-stack, where obviously running a dual-stack environment increases OPEX.

I believe Facebook at some point made claims that a v6-only back-end was cheaper (by which I assume OPEX) than running v4-only. But that might be again a very unique one, which is largely due to the management complexity of depleting RFC1918 address space. A problem which was also initially voiced by some larger US based operators. Once you exceed the ~20 million nodes (or customers), there is not much left to avoid some address duplication.

From what I understood from "mobile land”, the likely contributors to the cost are changes in the OSS/BSS workflows and possibly a bit of licensing (feature set) in the mobile network. Which apart from a true greenfield will probably be a combination of OPEX/CAPEX by the time it hits the spreadsheet.

From a financial perspective turning OPEX into CAPEX makes sense, especially since we know the return on IPv6 develops slowly at best.


More information about the Bp_ipv6 mailing list