IPv4 Unallocated Addresses Exhausted by 2010

An anonymous reader writes "Ars Technica is reporting on how the unallocated IPv4 address pool could run out as soon as 2010. The IPv4 Address Report gives details on just how fast the available pool of IPv4 addresses is diminishing. Will ISPs be moving towards IPv6 any time soon? Or will IPv4 exhaustion become the next Y2K?"

Comments

Re:From TFA: free pr0n!

[mengel]

The problem is, that claim makes no senses whatsoever. The IPv4 addresses are a subset of the IPv6 space -- you can get to all of the IPv4 systems from an IPv6 network.

There are two issues:

1. Switching protocols
2. Getting IPv6 addresses

You can use the IPv4 subset of the IPv6 address space, and everyone can still talk to everyone while you convert. It's only the folks that have IPV6 addresses before the IPv4 users have migrated that become unreachable by anyone.

So the online businesses are going to want to be the last ones to switch, so that their customers don't become unable to reach them.

But anyway, IPV6 gives you access to all the same content.

Re:it's tghe next Y2k

[Kadin2048]

i've been hearing about how ip4 will run out in the next 5 years for the last TEN years.

Well, it would have run out a lot faster, had it not been for CIDR, which allowed addresses to be allocated more efficiently. However that -- like proposals to re-allocate unused space in some of the old corporate A-blocks -- slowed the bleeding but doesn't really do anything about the real problem.

Re: From TFA: free pr0n!

[Dolda2000]

If what you say is true, then you definitely know something that I don't, and then I still think that I know more about IPv6 than at least most people do. I would think that you confuse either the ::/96 or the ::ffff:0:0/96 prefix for the IPv4 address space as a "subspace" of the IPv6 space. If you do, neither is true.

::/96 is a method for routing IPv6 traffic over IPv4. In other words, if you send a UDP packet to ::1.2.3.4, what is being transmitted onto the wire is an IPv4 packet (src: the address of your system's IPv4 stack, dst: 1.2.3.4), encapsulating an IPv6 header (src: the address of your system's IPv4 stack in the last 32 bits left-padded with zeroes, dst: ::1.2.3.4), in turn encapsulating a UDP header. It's a simple way of setting up a SIT tunnel, nothing more. You won't be sending any raw IPv4 packets that way, and neither is any router on the way going to convert it to IPv4 for you.

::ffff:0:0/96 is merely a way of talking to the IPv4 stack in your system, even if the program in question only uses IPv6. It does not work on a system without a working and properly configured IPv4 stack. In fact, I hear that the IETF is starting to work against the ::ffff:0:0/96 prefix due to some security issues that I have yet to understand.

In fact, if IPv4 truly were a subspace of IPv6, then what sources address would an IPv4-only host be seeing when it receives such a packet from an IPv6-only host?

It is perfectly possible to use both an IPv4 and an IPv6 stack simultaneously, and there are some NAT-like technologies that run on a router to give IPv4 connectivity to IPv6-only hosts, but you'll still need an IPv4 stack somewhere on your network to access IPv4 content.

Re:Reshuffle existing IPv4 space

[Kalriath]

Oh really?

Department of Defense Network Information Center 21.0.0.0 - 22.255.255.255

That's a... /7? And check THIS out:

Department of Defense Network Information Center 6.0.0.0 - 7.255.255.255
Department of Defense Network Information Center 11.0.0.0 - 11.255.255.255
Department of Defense Network Information Center 21.0.0.0 - 22.255.255.255
Department of Defense Network Information Center 26.0.0.0 - 26.255.255.255
Department of Defense Network Information Center 28.0.0.0 - 30.255.255.255
Department of Defense Network Information Center 33.0.0.0 - 33.255.255.255
Department of Defense Network Information Center 55.0.0.0 - 55.255.255.255

So that's... about 330 MILLION IP addresses for the US DoD alone? And people bitch about MIT hoarding!

Re:Worse than Y2K

[sirket]

This is so patently wrong I don't know where to begin-

My home network sits behind a Cisco 2621 running an IPv6 IOS image- and I have a /64 and a tunnel to tunnelbroker.net (By Hurrican Electric). It took ten minutes to set up- and another minute to enable IPv6 on my FreeBSD desktop- at that point I was able to get to www.kame.net via IPv6 with no problems.

I even set up an IPSEC / GRE tunnel with a friend of mine along with mBGP (multiprotocol BGP). No problems. I set up route-maps and filters all without a problem. My friend and I were then able to get to each others Unix servers via ssh over IPv6 using hostnames that resolved via AAAA records.

I also run OSPFv3 internally- again without incident. Deploying IPv6 to my network took a grand total of an hour- and we're talking about BGP, OSPF, GRE IPSEC tunnels and so on.

In fact- the change was so easy I immediately began a project to upgrade my company to IPv6. So far it has been incredibly easily and completely transparent to everyone.

What's holding IPv6 back is two things: public perception that the change will be difficult (completely unfounded) and the unwillingness of anyone to just start deploying it. I have SpeakEasy for my home connection (business class SDSL with a /27) and they neither offer IPv6- nor do they even have any IPv6 plans (or so customer service told me. This is just sad. The same goes for my employers upstream provider- and backbone provider.

-sirket
Senior Network Engineer for a company you've definitely heard of

Re:From TFA: free pr0n!

[Kadin2048]

The stateful firewall you'd need on an IPv6 connection isn't inherently any more complicated than an IPv4 UPnP+NAT box. In order for NAT to work, the device performing the translation must keep track of all the individual connections; it's basically a stateful firewall already. If you can do that, then you can firewall IPv6 (provided you have the capacity for the longer addresses). You need a protocol, like UPnP, so that clients can request "holes" (so that things like FTP, Bittorrent, and VoIP work), but that's no worse than NAT right now.

Now, I think this is a completely crappy way to run a network, and I think we just need to get rid of the idea of firewalls completely (at least as a generic cureall, I'm all for retaining them for specific applications); security needs to be at the client level, not at the network-gateway level; as more and more devices become mobile, they cannot and should not ever assume that their local network is secure.

But unfortunately, people have gotten so used to the idea of firewalls that they're attached to them, particularly because it allows for a certain amount of laziness (running old, crummy operating systems on Internet-enabled systems, not patching, etc.) while giving the perception of safety. So I suspect that all IPv6 implementations will mimic the brokenness of NAT, at least initially.

Re:From TFA: free pr0n!

[kickdown]

That's really just not true. With IPv6, you can get a lot more anonymity than you have now with IPv4. v6 has all sorts of special provisions for randomly assigning addresses, letting you reset them when you want, so that you can appear to be a new user in the middle of a browsing session. That's tough to do with IPv4; even if you try a DHCP release-and-renew from your ISP, generally they won't issue you a new address until the other one has expired.

IPv6 doesn't force you to give up any privacy, and there's no 'user serialization' unless you buy into it voluntarily. Sorry, but that is just not true. There's some fuss in the air about IPv6 privacy extensions, which is basically bullshit. As an IPv6 customer, you'll typically get a /64 prefix of the address space for your broadband connection. The entire address length is 128 bits, so you might *think* that you can play a lot with different, random, "anonymous" addresses.
BUT: The whole /64 is assigned to YOU, the contractor of this specific broadband account. So however you variate behind your /64 prefix, it will always be accountable to the same block. If your ISP does it's job right, your customer details will be delivered to RIPE, so that every content provider can conveniently look it up - no need to bug the ISP with such stuff, your cease-and-desist letter goes directly to your letterbox.
To illustrate my example, there's a IPv6 ISP in Germany that gives out even a /48 prefix - you could almost literally give an IP address to all the atoms in your house, and still have random space left for variations. Still, a RIPE query on the prefix 2001:4b88:107d:: shows that whatever happens with this /48 block gets this specific customer's credit.
If we're not counting accountability, but just usage tracking on websites etc, easy: just don't treat every Ip address as unique (like in IPv4), but instead every /64. There you go, almost as accurate as before in IPv4.

Re:IPv6 can give out your hardware MAC address als

[TheRaven64]

I take it you haven't been following IPv6 closely, since that hasn't been the case for about six years (see RFC3041). The MAC address part of the IPv6 address was never used as a substitute for ARP; doing so would have broken addresses assigned in different ways (e.g. stateful autoconfiguration, manual configuration), which were always allowed. The low bits are a hash of your MAC address, and so only a mapping from MAC to IP is possible, not the other way around. If privacy is a concern for you, then you can easily pick a different IP at pseudo-random.