Slashdot Mirror
IPv4 Free Pool Drops Below 10%, 1.0.0.0/8 Allocated
mysidia writes "A total of 16,777,216 IP address numbers were just allocated to the Asian Pacific Network Information Centre IP address registry for assignment to users. Some venerable IP addresses such as 1.1.1.1 and 1.2.3.4 have been officially assigned to the registry itself temporarily, for testing as part of the DEBOGON project. The major address blocks 1.0.0.0/8 and 27.0.0.0/8, are chosen accordance with a decision by ICANN to assign the least-desirable remaining IP address ranges to the largest regional registries first, reserving most more desirable blocks of addresses for the African and Latin American internet users, instead of North America, Europe, or Asia. In other words: of the 256 major networks in IPv4, only 24 network blocks remain unallocated in the global free pool, and many of the remaining networks have been tainted or made less desirable by unofficial users who attempted an end-run around the registration process, and treated 'RESERVED' IP addresses as 'freely available' for their own internal use. This allocation is right on target with projected IPv4 consumption and was predicted by the IPv4 report, which has continuously and reliably estimated global pool IP address exhaustion for late 2011 and regional registry exhaustion by late 2012. So, does your enterprise intranet use any unofficial address ranges for private networks?" Reader dude_nl sends in a summary of the issues with allocating from 1.0.0.0/8 from the BGPmon.net blog. "As Alain Durand mentioned on Nanog: 'Who said the water at the bottom of the barrel of IPv4 addresses will be very pure? We ARE running out and the global pain is increasing.'"
What will happen will be the standard that us humans have followed throughout the ages.
We will wait until the IPv4 addresses run out and then force businesses to start using IPv6 if they want to get on the internet.
There will be a temporary boon for networking manufacturers as companies will have to change their equipment
As a side curiosity, I wonder how many public IPv4 IPs are actually in use.
I seriously doubt that GE, IBM, AT&T, Xerox, HP, Apple, MIT, Ford, AT&T (again), Halliburton, Bell, Prudential securities, UK government Department for work and Pensions, Dupont de Nemours and Co., Inc, Merck, USPS and some others deserve or need a /8.
Even if you could recoup some of these addresses, this would only afford a few months of use, so it's not going to be worth the effort.
So, what? Some idiots have abused reserved or otherwise unused netblocks for their internal networks. I honestly couldn't care less. I have seen this before, even with other blocks which were already in use. It is a very bad practice. Unfortunately there is only one way people might stop doing this: Allocate the blocks now. If users won't be able to reach certain sites, the admin might change the internal addresses. Or they might not. Who cares? No, really: Who cares?
From the beginning of IPv6, something was missing: the possibility for IPv4 only hosts to reach IPv6 only hosts. The solution is a form of nat, called NAT64, but a few months ago it was just a vague proposal AFAIK. As long as this is not solved, the transition to IPv6 *cannot* work. There is a simple reason: the planned transition involves ALL hosts talking both IPv4 and IPv6. When you speak both, inevitably the least used IPv6 is not supported well, and people end up using only IPv4.
It's so obvious, I find it shocking it's not taken into account more seriously.
Oh geez, I'm gonna have to explain things to my Mom after she gets the following notice in the mail:
"Great news! Our engineers have invented an amazing new technology called IPv6 that NONE OF OUR COMPETITORS HAVE: More addresses! Greater speed! Less lag! New HD content never before available! OMG this new technology called VOIP works over it! Perform online backups! And enjoy the $20 increase to your monthly bill!
That or Obama launches a "Rebates for Routers" program - 6 months AFTER I purchase an IPv6 device.
This has been addressed time and time (and time) again. a) Those organizations would have to defrag their IP space before large blocks could get released, a process that's slow, intensive, and expensive. But more importantly, b) even if they did that, and then release those blocks for reallocation, at the current rate of consumption, it'd buy us, what? 18 months? Two years at the outside? Meanwhile, global routing tables would get even *larger*, and they're already gigantic.
No, reallocating unused IPs is a total fucking waste of time. That time would be *far* better spent getting IPv6 deployed so we could all move on from this mess.
I have dual stack at home, natively. For all intents and purposes, IPv6 is useless to me. As a result, support is worse. If it goes down, I don't really notice it, and my ISP doesn't give much of a fuck ("err, use IPv4").
Furthermore, as long as not everybody has dual stack, everybody suffers from IPv4 address exhaustion. In other words, the dual stack "solution" means that we have to use IPv4 until every single host (or at least every host we need to talk to) has implemented IPv6. In reality, it's clear that 20 years in the future there will still be idiots still running IPv4, because they can't be fucked to migrate. When I see how networking is broken in many enterprises, I don't see how they'll ever migrate to IPv6. I could tell you about all the brokenness I've witnessed, even in companies that are supposed to be somewhat technically oriented, and it's fucking scary.
Forget dual stack. And don't call it a "solution," it's not just ridiculous, it's delusional.
Want me to adopt IPv6? Make IPv6 Lite.
In my humble opinion, the problem with IPv6 is that it's too radical a methodology change for most IT folks to be interested in. I wouldn't be surprised at all if a huge number of us are silently, subconsciously "waiting it out", for someone to propose and ratify a less intimidating address-extension protocol.
It's not that I can't handle Hex... it's not that I can't handle colons. It's not that I can't handle learning about tunnels, or brokers, or 6to4 or any of the other immense pile of knowledge surrounding IPv6. It's that I don't WANT to. IPv4 is terribly simple and does its job. IP, mask, gateway. By and large that encompasses just about everything you really need to know about IPv4 as a network admin. Sure, it's tough to have huge routing tables, but that's life. Hardware keeps getting faster and memory cheaper. Deal with it.
Yeah, okay, IPv6 can't - by definition - be the same since it's got to overlay things. But really, if this standard was to have "caught on", it should have changed as little as possible at once. IPv4 machines should simply be a.b.c.d.0.0.0.0.0.0 or something equally obvious. Routers and IP stacks could be written to extend the address space a few more bits, and the same methods as used in IPv4 should have been used to denote subnets. It SHOULD have been a simple task of padding out IPv4 space into IPv6, and software that doesn't grok the full address space just couldn't use it. Imagine adding two more "numbers" to your telephone, so phone "numbers" could include Pi and e. Call me at 1-800-555-5e55. If your phone doesn't have the buttons, you can't dial it. Fine. But the backbone should have been smoothly extended.
That's what IPv6 SHOULD have done. Add more address space and nothing else.
"Oh no... he found the
IPv6 works like this. Every ISP and backbone peer has looked at the massive investment necessary to make their entire installed plant IPv6 ready, the large amount of work required, the fact that they will probably break everything about five times in the process because they did something wrong, and has decided that they will migrate when someone holds a gun to their heads and absolutely forces them. Not before.
Like most people, I'm waiting until my ISP switches to IPv6. Until they change my IP address, then I have no reason to change my internal IP addresses. I mean really, what's the point? Most of us have no control over whether IPv6 is implemented anyway.
::ffff:1.2.3.4. Not that it helps, since v6 and v4 stacks are different.
IPv6 is still network portion, host portion. You could still specify things in mask notation, if you wanted to, but it's kind of silly. Just use network prefix length notation, it's nicer for both v4 and v6. Gateways are still usually on ::1.
Ah yes, the "use more v4 bits" idea that comes up every time. Let's look at what you'd need to do to extend IPv4 addresses by one bit. First, you need somewhere to store the bit. You could use a reserved bit, or you could make a new IP option. Either way you've hit your first roadblock: no existing IPv4 equipment or software will be expecting this, so you need to replace everything with IPv4.1 equipment -- that, or randomly your packets won't go to the right destination, they'll go to the 0-bit destination instead. Oops.
You wave a magic wand and solve that problem (which is the same problem as the IPv6 support problem). Now you turn to DNS. Oops, an A record only contains 32 bits. You'll need some way for a DNS resolver to report the extra bit back, but you can't break compatibility with existing resolvers, so you will probably wind up defining a new record, let's call it the AA record. Now you can map names to IPv4.1 addresses -- but you need to roll out DNS software everywhere to support it. Oops.
Another magic wand later, you come to the application layer. It turns out that a bunch of software has a bunch of struct sockaddr_in variables that it uses to connect to services and to figure out who connected back in turn. You'll need some way to deal with that. Maybe you could define a new structure, sockaddr_in4_1 or something, that has the extra bit of information. Oh, but shit, now you need to rewrite all your application software to be aware of that new structure.
Then you try to figure out DHCP, PPP, reverse DNS, ICMP, BGP, spanning-tree, accounting systems, DOCSIS, and every other IP network protocol known to man, because every single one of them is built on the basis that there's only 32 bits in a network address.
And eventually, it turns out that the people who came up with IPv6 didn't all somehow miss the blindingly obvious solution, because there is no blindingly obvious solution.
The IPv6 spec reserves space for the entire IPv4 network, making translation between the two a snap
That reservation is more or less a joke. It is great (in principle) if you want to send a packet from an IPv6 host to an IPv4 host. But how does the IPv4 host send a reply back? The short answer is, it can't. It can't because there (obviously) is no static mapping of IPv6 addresses to IPv4 address. There is no way to cleanly fold 128 bits into 32.
That means that there are only three basic ways for IPv4 hosts and IPv6 hosts to interoperate: v4v6 network address transation (NAT), application layer gateways (ALGs), and dual stacks. Presumably, the main point of IPv6 is to avoid NAT, so v4v6 NAT is a relatively undesirable solution. Application layer gateways for every external communication protocol are even more problematic. That leaves dual stacking, which is a way of solving the IPv4 IPv6 interoperability problem by conceding the plain truth - that IPv4 and IPv6 are not interoperable and never will be.
The only way to avoid NAT or ALGs is for every last Internet connected device on the planet to be dual stacked. That is going to take at least a decade. There will probably be lots of strange NAT and ALG solutions in between.
The more interesting question is if there were a market for IPv4 addresses, such that organizations had a significant economic incentive to renumber and minimize the number of IPv4 addresses they used (and the size of the routing tables necessary to reach them) how long could we survive on the current system? I would guess a half century at least.
Given the likelihood of this sort of economically motivated renumbering effort once centrally allocated blocks of IPv4 addresses run out, at what point does the overhead of the necessary network address translation outweigh the cost of administering a parallel IPv6 network that reaches nearly every device on the planet, in addition to the IPv4 network that is already there and which must remain there indefinitely (down to the level of each individual PC) in the absence of all the alternative v4v6 NAT and ALG devices we are trying to avoid in the first place?
Essentially IPv4 has a defective design, and IPv6 has exactly the same defect, with a slightly larger address space. Slightly because hierarchical allocation will use up those initial 64 network addressing bits in a big hurry. IPv6 is no more than a stop gap for a some sort of variable length address (VLA) scheme, the only alternative that that isn't essentially an exercise in planned obsolescence.
It doesn't matter how many IPv6 addresses you have as long as there remain IPv4 only clients that cannot access them. The only way the transition is going to be gradual is with a whole host of v4v6 and v6v4 NAT and application layer gateway devices.
The main people that need to run such devices are the end user ISPs. Until they do, no IPv4 only client will ever be able to reach a IPv6 only server. SNI aside, every publicly addressable IPv6 server will require the same number of IPv4 addresses as it does now. Dual stacking will not save an iota of IPv4 address space until IPv4 clients are practically required to use some sort of v4v6 NAT or ALG to access the rest of the (IPv6) Internet. To say nothing of the v4v4 or v6v4 NAT required so that every last ISP client doesn't require a routable IPv4 address as well.
I have have seen the future, and it is NAT until the cows come home (unfortunately). All this dual stacking is a worthless exercise without the v4v6 and v6v4 NAT (or ALGs) necessary so that the number of IPv4 addresses required actually goes down. I sure hope somebody is reserving the address space so that v4v6 NAT is actually practical, because we are going to need it for a long time, and the IPv4->IPv6 transition won't happen without it.