At Current Rates, Only a Few More Years' Worth of IPv4 Addresses

An anonymous reader excerpts from an interesting article at Ars Technica, which begins "There are 3,706,650,624 usable IPv4 addresses. On January 1, 2000, approximately 1,615 million (44 percent) were in use and 2,092 million were still available. Today, ten years later, 2,985 million addresses (81 percent) are in use, and 722 million are still free. In that time, the number of addresses used per year increased from 79 million in 2000 to 203 million in 2009. So it's a near certainty that before Barack Obama vacates the White House, we'll be out of IPv4 address[es]. (Even if he doesn't get re-elected.)"

Comments

I'll believe it when I see it

[haus]

It has not yet become a big enough of a problem for the large sections of unused address by universities such as MIT and Harvard to be recalled.

Re:I'll believe it when I see it

[fm6]

Do you think the current owners are hanging onto their address spaces out of pure spite? If they rely on the Internet to do business, this crisis hurts them more than anybody.

This mess happened because of the simplistic addressing schemes that were implemented without taking into account the explosive growth of the Internet. One result is that that some early adopters ended up with Class A networks (16 million addresses) because they needed more than the 64 thousand addresses in a Class B network. Only one Class A space belongs to a university (MIT). (There used to be two, but Stanford gave its IP space back.) Other owners include Halliburton, Apple, IBM, and Xerox PARC. HP has two, counting the one that was originally issued to DEC. DoD has eight.

Reassigning all these addresses would be a logistical nightmare, because you're changing the basic logic of network routing. Imagine all the routers that would have to be reprogrammed or replaced, and the expensive down time that would result. Much more cost effective to just go to IPv6 already. Plus there are other features of IPv6 we really, really need.

Except that nobody's doing it. I used to work at Sun, where I kept suggesting that our embedded lights-out management system (all Sun servers have them) start supporting IPv6. The answer I always got was, "customers aren't asking for it." Which means that everybody is putting off this problem until the last minute. As usual.

Re:I'll believe it when I see it

[Anonymous Coward]

Well, where I live it's impossible to get a fixed IPv4 address for a reasonable fee. So yes I certainly believe it - for all practical purposes addresses have already run out. Arguing about recalling addresses previously handed out sort of circles around the main problem, namely that there are so few addresses that they are a scarce resource. Even if only half the addresses or so would be actually assigned, that would probably still impose a monetary value on something which could be free, were it not for the fact that we're only using four bytes and doing so for no good reason at that.

No real scarcity yet

[bizitch]

I just helped out a friend who lives in a remote rural section outside of Chicago. I tried for years and years to get her lit up on decent broadband service.

Finally, we got a relay from a WiMAX provider --

When I went to connect her broadband with a Cisco router - I discovered that she was assigned a FRIGGIN /27 of public numbers!! (i.e. she now personally burns 32 usefull IPV4's)

I was gonna call their support ... but why bother?

You never know if she's gonna need 30+ public ip numbers right? Just because she lives alone - she may get many friends real soon!

Re:No real scarcity yet

[jrumney]

This seems to be a common theme in comments from posters in the US. 5 IP addresses, 32 IP addresses... Meanwhile in the rest of the world, you get one, and you're lucky if it is not NAT'ed. It seems the US treats IP addresses the same way they treat oil.

Re:No real scarcity yet

[wagnerrp]

NAT is not a security tool, has never been a security tool, and was never intended to ever be used as a security tool. It does no more good than a basic 'block all inbound' firewall, and only serves to limit and complicate every application you wish to use.

If I want to run multiple computers accessible over SSH or VNC, I have to run them on separate ports. If I want to run multiple web servers, I again have to run on different ports, or otherwise proxy them all through a single external server. SIP and other protocols that embed the address in the protocol are outright broken by NAT. Like XanC said, it is a necessary evil that should be dumped with extreme prejudice.

Great... now do I switch?

[Anonymous Coward]

I live in one of the most tech-focused parts of the country (downtown San Francisco) and as far as I can tell there's no way for a normal consumer to order native (i.e. not tunneled) IPv6 here.

When I moved to my current apartment in 2004 I specifically went with Speakeasy because they were talking about rolling out IPv6 to customers. Over 5 years later, those plans are still stalled as far as I can tell. None of the other providers seem to be even making a peep about it. If I'm wrong, someone please correct me - I'd love to switch to an IPv6-capable provider.

I've pretty much concluded that IPv6 just isn't going to happen -- instead providers will just force all of us normal people into shared IP addresses. From a technical perspective this isn't hard to do: just move the software that's currently running in your home NAT router onto the DSLAM and only provide a NATed view. For the ISPs there's no downside to this since not only can they avoid rolling out IPv6, it means they have complete control of your network connection.

I bet in 10 years we still won't have IPv6 in our homes, and the idea of having your own IP address (even a dynamically allocated one) will just be a memory. It's a shame.

Re:Don't say "NAT"

[Anonymous Coward]

I happen to know that IBM uses a good chunk of the 9.0.0.0 space.

For what? Do all their PCs have public IPs?

Where I work has an entire class B and all of our PCs are public and we're talking now about NAT'ing them all, for security reasons. Once upon a time this would have been a nightmare because all of our devices have static IPs, but now we have a process to easily map in MAC addresses of authorized devices into a DHCP address so they all get their own IP.

What I'm saying is, once upon a time having to give that class B back would have been a nightmare -- right now, not really. We could probably live with a class C.

(Posted anon since someone where I work would probably take great exception to this...)

Now if IPv6 could get fixed...

[Junta]

There are so many ways IPv6 remains broken and too many of the people with influence can tend to say 'working as designed'.

I know that's controversial, so I'll enumerate my pain points:
-DHCPv6 DUID is a pain to 'pre-provision'. When any operating system or firmware instance dhcpv6 for the first time, it sends out something that you'll never know what it would be ahead of time. In 99% of cases, the DUID is a generated value at 'OS Install time' that is used only for that specific OS, and a reinstall or livecd boot will change it out completely. stateless boot, multi-boot systems and multi-stage booting (i.e. pxe -> os) cannot hold together a coherent identity because DHCPv6 is explicitly designed not to do that. Binding by MAC is considered 'evil', but it has been the strategy used for ages. I wouldn't mind so much if DUID was commonly implemented as a value retrieved from motherboard firmware tables, but no one is stepping up to drive that behavior in a spec visible to all parties.

No PXE/bootp boot. I believe they are trying to reinvent, from scratch the boot design from IPv4, and are nearing completion. I fear the extent to which the baby has been tossed out with the bathwater (i.e. 'root-path' was dropped and no one has pulled it into dhcpv6).

Some standards are missing the capability to operate in IPv6. I.e. IPMI hase some IPv4 specific portions of the standard without IPv6 capable equivalents.

Re:Now if IPv6 could get fixed...

[swillden]

Why use DHCPv6? I much prefer stateless autoconfiguration. I was amazed at how well it works. The first time I fired up the radvd daemon on my home gateway (which is using a tunnel broker service to get v6), I was amazed at how every device on the LAN instantly had v6 access, with no action whatsoever on my part.

I don't have any comment on PXE/bootp. Haven't looked into that in the v6 world. It seems like v6 should make that trivial, though. Just pick a standard reserved local suffix to hold the boot service. The booting device should wait for a router advertisement to find out what network it's on, append the standard suffix and open a connection to get boot code. Done. That's just off the top of my head, of course.

Re:Don't say "NAT"

[gmuslera]

Inertia could make your car crash even if you started to turn when saw the danger. A few meters more could be the difference between your life or death.

Re:Don't say "NAT"

[drmerope]

Less scare oriented analysis have shown less than 50% of the IPv4 space in actual use. IPv6 is considered a to be a broken ill-designed protocol that screws up more than it fixes. Its basically unusable with mobile networks (WiMax, WiFi, etc). It significantly increases the cost of routers, switches, etc--the exceptions being those hardware that treat IPv6 in the slow-path. i.e., by trapping to the control CPU.

The IP network was designed to be a gateway network, not to connect every dippy host to every other one. Which is a broken, insecure, nonsensical practice. If you believe in it, you should review the Geek Social Fallacies.

The truth will be in the pudding. Once address space begins to be clawed back, abusive users (like IBM; IBM does NOT have millions of protocol compliant IPs: they ought to be NATed), will face a cost of reconfiguring their broken network topologies using IPv4 or switching to IPv6. Then we'll know.

Re:So, how many applications break?

[tftp]

The number of applications that make this assumption is not small, but it is not unmanageable.

I would say that IPv4-only apps are majority:

#include <netinet/in.h>

struct sockaddr_in {
short sin_family; // e.g. AF_INET
unsigned short sin_port; // e.g. htons(3490)
struct in_addr sin_addr; // see struct in_addr, below
char sin_zero[8]; // zero this if you want to
};

struct in_addr {
unsigned long s_addr; // load with inet_aton()
};

You need to hack the source to use in6_addr and sockaddr_in6 wherever appropriate, and change the code that processes them (such as inputs addresses, compares them, works with netmasks, etc.) I'm sure most coders never even thought of adding IPv6 support to their specialized, made to order applications. They weren't paid to add features that nobody asked for, and they never even had an IPv6 network to test the code on. In my career I had only one (1) customer specifically asking to support IPv6 - and he paid for it, and he got it. Everyone else got IPv4 only - as a business we had to be lean.

This is a lot of work, both coding and testing, and you will never see it done to a legacy software as a free patch. Software is sometimes very expensive - tens of thousands of dollars per seat. There is zero chance that this investment will be just scrapped, and you'd have to do that if your PADS Layout or SolidWorks or, $deity forbid, CST can't talk to its license server. The latest releases may, of course, fix all that, but they are never free. And the worst news is that some of *your* production software, like your beloved OrCad 10.3, is not supported any more, and you can't upgrade to the latest OrCad, jumping over six revisions, because it will break millions of things in your business process (or your bank.)

Address scarcity predictions

[oojah]

I'm sure many of you have seen the IPv4 Address Report, which attempts to predict when the IANA and RIRs will exhaust the unallocated pool of IPv4 addresses.
I've been tracking the results of those daily predictions for a while now and since this time last year, they've moved further away by about 6 months. There are graphs online at http://atchoo.org/ipv4/
We're still roughly at the same place we were back when this was discussed in April (ARIN Letter Says Two More Years of IPv4).

Cheers,
Roger