I was looking over ripe (for those who don't know, RIPE used to be the African RIR before AFRINIC was formed, my first LIR training was with RIPE so I tend and like to follow their proceedings). Anyway so I was going through RIPE 62's IPv6 sessions (that is all they discussed it seems) and realized how some 'operators' might get a very interesting edge over other players just by showing a readiness and willingness to work with key stakeholders in their respective markets.
Remember if you have done nothing up to now about IPv6, you stand to lose out quite a bit. you miss out on getting cheap experience for your engineers, you miss out on working out the kinks in pricing, application modelling and a host of other issues. In my case I imagine DPI and billing will be a pain in a tender area. You will lose customers.
Also most of what is being done now is pure experimentation, which is fine. The entire internet model is an experiment, try this, do that, tweak here; it's constantly improving and morphing. I never expected, ever to deploy a site with 30Gbps of bandwidth in Kenya, ever. But it's been done.
The present value of IPv6 and associated technologies is very very discounted. It will cost you more in the future to train, to migrate, to work with IPv6. You'll also probably lose alot of staff if you don't give them an opportunity to participate, an outlet for the enthusiasm we feel when dealing with new technologies and toys.
So it was no wonder that transition mechanisms are at the top of the list of issues for content providers too. Will tunnels work? I doubt it, not for everything anyway. what about NAT? we all know what that does. Content providers obviously want end to end IPv6 (native IPv6). This clears a path for their content from the user to the content. It's perfect for them.
It was rightly pointed out to me at Afnog that waiting for user demand is really not a wise idea. Users don't care much how they get their content, why would they start now? because you have a new buzz word? for bragging rights? 'heyy duuuude, check out my IPv6!'...Ha!
Anyway, to break this loop; waiting for user demand by carriers/ISP's and waiting for ISP's/Telcos to deploy IPv6 by content providers before deploying IPv6 on their systems, we all need to jump together. We learn together. Content providers need to dual stack or at least start running audits. ISP's pretty much know they need to have IPv6 on their core network, they should be peering with IPv6. Most have done that. Most are working on the access side now.
If you are a content provider, you're probably right in fearing that ISP's and other carriers will hide their traffic, their users, your customers behind NAT's (NAT can break your billing for instance) and other content gateways when IPv4 is finally trully completely depleted. They'll create walls around their users.
It's a risky situation and ISP's can exploit it; If I introduce NAT and hide the users, you have to come to me and negotiate for some sort of 'cdr'/customer data to effectively bill, also forget any lawful intercepts or proper logging - hence the need for regulator intervention if IPv6 uptake is slow by all parties. I don't think this is a major risk in Kenya. We don't have that many content providers or neutral data centers - sad but true.
There is no excuse for an ISP to not have basic IPv6 set up. It on the same note is irresponsible for a content provider or datacenter owner to not start playing around with content provision over IPv6, and requesting for IPv6 connectivity upstream. Datacenter and other content owners need neutral networks to sell their services. To help things along, it is imperative that content owners turn on dual-stack at the content level.
Don't get me wrong, there will be issues. But isn't it better to deal with them with everyone? Isn't it better to train your noc now? you want a situation where if a customer calls in the future with IPv6 related issues, it's handled just like any other call because your staff are so 'with it'.
Note customers get connectivity from an ISP or ('insert favorite name for a guy offering connectivity services here'). Customers know them as 'internet providers'. They call them if they have a problem. No customer I know in Kenya calls facebook when that page is unreachable. Most call Safaricom, or whoever connects them. Nothing will necessarily change their thinking in a post IPv4 world.
Which means if content providers don't do their transition properly the service providers helpdesk gets congested with calls from angry consumers. That creates unnecessary tension. I hope you now begin to see why this effort has to be end to end.
It is a good time as disruptive times tend to be to try and exploit the opportunity and improve your relative position and control of the market. Kenya doesn't have many content providers, I hate that fact, looking at those statistics can be very disheartening and I hope in the future to get involved in content generation, or just fund or help build platforms.
There is a huge untapped potential. However if we move fast and show the world and ourselves that we can offer native IPv6 to a popular content provider and you are a network with many many users with native IPv6, then you stand a higher chance of nailing that business.
Look in the end customers want content. ISP's are unfortunately just pipes for now unless you are very creative. You can work now and partner with content providers or wait for your demise.
It's a good time for re-invention. As a guy that designs networks and sometimes applications to get by, and have done it for a while now. I know this will probably be one of the most interesting periods for me. I also know this transition can't be wished away. Soon there will be real market forces driving it.
Either way we have far bigger issues to deal with. Lets just get this IPv6 done. Its easy, its fun, life can get much much more complicated than a few extra bits.....
I am going back to more deployment like technical implementation scenarios and writing, the focus is on processes and documentation, IPv6, data center technologies and multicast.... so if you'd like something tested out - let me know.