Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
As a comment, if your application builds on good (common) networking libraries, they'll have fixed the problem for you. – the JinX Mar 9 '11 at 12:46
We know the hurricane is coming. You don't want to be the person who didn't buy groceries and a generator beforehand. – Michael Hampton Jul 30 '13 at 4:24
up vote 5 down vote accepted

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.

share|improve this answer
we're starting to get the question from prospects and their networking people. Depends on your market and sales environment. We are moving to ipv6 this year (using dual stacks) so we can tell our customers we've got it. Not having it could be used against us. – james Mar 9 '11 at 4:35

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.

share|improve this answer
Speaking as somebody who worked on some Y2K problems, IPv4 exhaustion is something you want to address before your customers suddenly need IPv6 support. At some point, they'll be busy scrambling, and if your product is already IPv6-ready that's good for you. – David Thornley Mar 8 '11 at 22:24
@David: You should post that comment as an answer! – Jake Tacholsavacky Mar 8 '11 at 22:25
@David: Well said. – eradicus Mar 9 '11 at 2:34
It's extremely unlikely that your customers will be hit by genuine public IPv4 address exhaustion issues before your next release, even if that's years away. Think about it: only public servers actually need public IP addresses, and even they can typically be load-balanced, like Google does with e.g. its DNS servers and – Robin Green Apr 16 '11 at 20:02

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.

share|improve this answer
All blocks of IPv4 addresses have been allocated to the regional authorities (there are, I believe, five such regions on the planet). At some point after that, ISPs will no longer be able to get new blocks of addresses, and then individual ISPs will start to run out, and then various expedients to get around that will get overloaded. IPv4 exhaustion is very serious, but the effects will take time to manifest. – David Thornley Mar 8 '11 at 22:21
@David Thornley: Thanks for the detailed update! :) I know the problem is quite serious, I had lost track of the details of how bad things currently are. – FrustratedWithFormsDesigner Mar 8 '11 at 22:24

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).

share|improve this answer

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.

share|improve this answer

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.)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.