Is IPv6 support a "nice to have" feature anymore?

Question

I work on an app that does a lot of network communication. I know that IPv4 addresses are being exhausted. At the same time, none of our customers are asking for IPv6 yet. We are examining which new features to add to the next release, so I ask: is IPv6 support a "must have" or a "nice to have" feature at this point?

Answer 1

Something else to consider - when's your next release and when's the release after that?

The next release (6 months time, say) might be officially "too soon", but the release after that (18 months away, say) might well be "too late".

In that case it might be something you have to do now to ensure you're not out of the game later.

Answer 2

Right now the transition to IPv6 has been moving glacially for years, however once the big networks are done with their transitions, I expect that the rate of uptake will increase significantly. There are also some organizations (esp. in government and very large corporations) that require or strongly prefer purchasing software that can support IPv6 so that they know their software and infrastructure is ready when they flip the switch. So, depending on your target market, IPv6 support might not be a total non-feature right now.

If your customers really don't need IPv6 support, then okay, don't make it a priority. What you want to avoid however, is accumulating too much ipv4 related technical debt (and really, you should work on actively reducing it). Ideally, if your customers aren't asking for ipv6 now, you should take the opportunity to clean up your existing networking code to use system calls that are ipv6 compatible, make sure your code can handle the larger addresses, etc. Update your standards to make sure old code that only works with ipv4 doesn't sneak back in.

If you eliminate the legacy networking calls, then you can still focus on supporting ipv4 only, but have a decent chance at updating your product to support ipv6 when your customers do start asking for it. If you wait too long to pay down the technical debt then you may find that it takes too long to add support and you start losing customers to competitors who can support ipv6.

Answer 3

If you're the first to have it, you will lead the competition. You don't want to be scrambling when everyone suddenly starts asking for it all at once. On the other hand, I'm not really up to date on how serious the IPv4 address exhaustion problem is... But if you can squeeze it in there, I'd do it.

Answer 4

Really hard to know if this is an over-hyped problem or not. Those selling IPv6 consultancies and similar have a clear vested interest in playing up "the problem". But there is still a heck of a lot of IPv4 stuff being sold including vast numbers of small embedded devices.

A great many companies are changing over to private addressing internally (ie 10.x.y.z ranges) with huge NAT boxes just like we have at home, this free up large numbers of class B addresses and may even release some class C addresses.

My GUESS, and its only a guess, is that the magnitude of the problem is being overstated and technical patch ups and work-arounds on IPv4 will keep the life breathed into it for some considerable time yet. There may be a lot of trading-in of existing addresses and other hacks to make this happen.

My understanding in the small embedded device field is that an IPv6 stack is much bigger and uglier than IPv4 and this is a significant impediment to those devices making the move. (By small embedded I'm referring to things with <64K memory, not linux boxes).

Answer 5

With the current rate of IPv6 adoption it is still a "nice to have."

The US government released it's migration plan last year and it doesn't even call for agencies to have IPv6-accessible public websites until the end of 2012, with a full overhaul to native IPv6 at the end of 2014.

The bottom line is that IPv6 as a required feature is still quite a ways off for your everyday run-of-the-mill applications.

Answer 6

At this point hard-coding a IPv4 requirement into a program is probably not a good idea. Aiming for stack independence would be preferable. Stay tuned for World Y2K Day.

I think this is the next Y2K problem. There were lots of programs which either didn't deal with dates or used the system libraries and were able to state with confidence, if your system is Y2K compliant so are we. Other programs failed miserably. In 1998, I saw programs being developed with two digit year fields and no way to handle year 2000.

According to reports I have seen at least one cell phone provider is IPv6 to the phone. (I assume they do protocol translation to the Internet when required.)