Whilst the RIR that covers the US isn't projected to run out of IPv4 until mid-next year (and Africa not until 2015) it's important to note that the Asia/pacific one is currently projected to run out in the next 4 months. If you have customers accessing from Asia, you may want to ramp up your consideration of IPv6. What can't be predicted at the moment is what kind of a gold rush effect we'll experience, or what tricks companies based in Asia, or other regions, will do to sneak IPv4 allocations from other registers.
It could be that we'll see all regional authorities run out significantly quicker than historic usage patterns can predict.
ISPs are implementing various ways of tunnelling IPv4 traffic to IPv6 addresses but all solutions are kludges, and all will result in unusual behaviour for site access, anything from slow to unreliable to worse. The majority are relying on a combination of 6rd and Carrier Grade NAT, meaning lots of traffic will appear to be coming from a pool of IP addresses, with traffic liable to randomly switch which IP it appears from. If you're running something like a shopping cart or something relying on persistent sessions, and it's not written to correctly maintain sessions it could be completely unable to cope with the tricks used. Now is the time to test and be sure.
Actually implementing IPv6 on the border is considered relatively straight forward, at least for presenting content to the world, you don't have to switch all your internal systems to run IPv6, you can do the translation internally to IPv4 if necessary, however businesses ought to be planning to roll out a dual-stack system, and be reviewing all their infrastructure for IPv6 capability now, so that you can budget for any replacement equipment as necessary, rather than suddenly facing a nasty bill. The White House requirement for Federal agencies to be presenting IPv6 at the latest by mid 2012 has already ensured that those major vendors who'd been putting off IPv6 on some of their product lines (*cough* Cisco) have finally pushed out updates to enable it, and that's starting to trickle down to the smaller vendors too.
Putting this stuff off is ultimately going to bite you in the butt, instead of having an opportunity to be on the curve and proactively stop problems. Waiting until you have a problem is too late, because you can be sure by that time others will have already had a problem and just not mentioned it, and it will take time to get new equipment in place and ready.
IPv6 is a technology more than 10 years old, so its nicely mature, and is being used successfully in many small and large businesses all around the world. The only reason to drag feet on it is an unwillingness to learn IPv6 and its different approach to networking concepts, naming schemes.
There is very little good argument for service providers not to be able to supply you with an IPv6 address. Unlike getting a new allocation of IPv4, where you have to present solid evidence of why you need it and what it'll be used for etc, all you have to present to be allocated an IPv6 address range is proof of your existing IPv4. ISP grade equipment has been capable of IPv6 for over 10 years (an ISP I worked for a few years back had had a full IPv6 network from very early 2000s all over standard hardware), and there has been a push for IPv6 for long enough inside the industry. If your ISP won't, keep pushing until they do. Make noise about considering alternative providers who are more forward thinking and capable of meeting your business needs. If your solution is valuable enough your salesman will want to keep his recurring commission! Even if it's not valuable enough, the more smaller businesses that do make a noise, the more likely they'll start to pay attention.
Anecdotally, I'm hearing a number of network professionals across the US who have been having the most fascinating conversations with their service providers about getting IPv6. "IPv what? Is this a prank call?"
You may want to attend the next Hawaii IPv6 Task Force meeting in-person or remotely.
© 2023 Created by Daniel Leuck. Powered by