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.'"
AnoNet is one of those who use 1.0.0.0/8 for private VPN because everyone thought it wouldn't be in use. I am pretty sure there are A LOT of organizations and other services who do too.
anoNet is a decentralized friend-to-friend network built using VPNs and software BGP routers. anoNet works by making it difficult to learn the identities of others on the network allowing them to anonymously host content and IPv4 services. Assuming that a router administrator on such a metanet knows only information about the adjacent routers, standard routing protocols can take care of finding the proper path for a packet to take to reach its destination. All destinations further than one hop can for most people's threat models be considered anonymous. This is because only your immediate peers know your IP. Anyone not directly connected to you only knows you by an IP in the 1.0.0.0/8 range, and that IP is not necessarily tied to any identifiable information.
To avoid addressing conflict with the internet itself, the range 1.0.0.0/8 is used. This is to avoid conflicting with internal networks such as 10/8, 172.16/12 and 192.168/16, as well as assigned Internet ranges. As of January 2010 IANA has allocated 1/8 to APNIC.[1] If the service does not switch to another address range then Internet hosts using 1.0.0.0/8 will be inaccessible to AnoNet users.
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.
They'll never take my 127.0.0.1 away from me, dammit!
Seven puppies were harmed during the making of this post.
Thats the IP address of my luggage.
numbers and car plates.
I'd love to have 1.1.1.1, or 29.09.19.69 (my bday)
The Cloud - because you don't care if your apps and data are up in the air.
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.
Run this script to get your own IPv6 address today:
CUR_IP=(`ip -4 addr show ${CUR_DV} | awk '/inet / { print $2 }' | sed -e 's/^\(\([0-9]\{1,3\}\.\)\{3\}[0-9]\{1,3\}\).*$/\1/'`)
IPV6_ADDR=$(printf "2002:%02x%02x:%02x%02x:%04x::%04x" $(echo "${CUR_IP} ${SLA_INTF} ${INTF_ID}" | tr '.' ' '))
ip tunnel add tun6to4 mode sit remote any local ${CUR_IP} ::/0 via ::192.88.99.1 dev tun6to4 metric 1
ip link set dev tun6to4 up
ip -6 addr add ${IPV6_ADDR}/64 dev tun6to4
ip -6 route add 2002::/16 dev tun6to4
ip -6 route add
Install radvd if you want to share your new IPv6 subnet with other people on your local network.
This is all it takes. You do not need to wait for your ISP to get a clue.
Only problem is this does not work with NAT.
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.
I will be happy to wear the consequences of owning 13.0.0.0 and following recent events I suggest China be allocated 4.0.0.0
http://michaelsmith.id.au
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.
A good example of an undesirable IP address is one that's on a bunch of spam blacklists.
Some IP addresses are more likely to have connectivity issues than others.
One major issue improper or poorly maintained filters, that effects most address blocks that were previously not being assigned from equally, hence the DEBOGON projects and testing.
There are more insidious issues that only effect some blocks, however.
For example the guerilla usage of "1.0.0.0/8" by AnoNet, and "5.0.0.0/8" by Hamachi, plus private use of those, and other ranges instead of proper RFC1918 addresses by some enterprises.
Makes hosts that use those IP addresses more likely to have communication problems with other hosts on the internet, just because their IP address is in that block.
who claim that IP exhaustion is a conspiracy thought up by Al Gore to generate more money for the British Royal Family, and that if we ignore the liberal computer scientists and their biased journals, everything will be fine.
93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
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 run an HE tunnel at home to provide IPv6 connectivity to my personal network, and it's been working great, and has the advantage over SIXXS of more geographically distributed tunnel endpoints (SIXXS' seem to be clustered on the east coast, while, HE has endpoints in California, among other places). Though you do need to rig up a script to update the tunnel should your IP address change.
Throw in a free v6-capable DNS hosting service like freedns.afraid.org and you're laughing.
When I discovered m0n0wall 1.3 hit the pavement, with support for IPv6, I made the move to transition my home network to v6, for no other reason than it seemed like an interesting thing to do (what can I say, I like to tinker). In the process, I looked to moving all my services to v6... obviously I can't completely abandon v4 internally, but I figured, why not move all my internal stuff over? Problem is, among the software I use, the following don't support v6 at all:
Linux NFS client and server
MySQL
MythTV
rtorrent
m0n0wall's VPN implementations (both IPSec (ironically) and PPTP)
And those are just the first four that popped up (though at least I was able to patch rtorrent). God knows what other software out there doesn't support v6. Of course, many of these things can live in private v4 networks for the time being, but until application vendors catch up with the times, it seems v4 and v6 will be living side-by-side for a long time to come.
ARIN is totally incompetent; Not only does the Prudential have a /8, but back in 1992 when I worked at the Prudential Bank in Atlanta, that totally separate division applied for and got a class-B (158.221) and still holds it to this day. The ridiculous thing is that they will never use it, never did and when I tried to get ARIN to look into getting it back in the late 1990s, that fell on deaf ears. In fact, the Prudential Bank doesn't even exist anymore at the address in the registry entry for 158.221; I don't know if they even exist at all anymore. Go and reclaim dead IP space, and then see what is left.
The problem with "Class E" is these addresses have a "not a valid IP address" status; the classification of the addresses are "Experimental", not UNICAST. As a result, many OSes or devices from many vendors will not allow you to assign a Class E address, or communicate with a Class E address.
Windows XP falls into that category, Vista falls into that category, I cannot confirm whether Windows 7 falls into the category or not; unless there has been a recent patch, Class E IPs are unusable. Even Linux wouldn't allow you to communicate with a Class E address or assign it to an interface, until a kernel patch that was first introduced in January 2008
Many routers and firewalls are in a similar situation. There is a lot of old software running at internet sites that is unlikely to be updated.
If "Class E" address space is ever opened, it's likely that IETF would not direct IANA to assign Class E to the RIRs for public allocation, instead it might be made available for private purposes, much like the RFC1918 address space.
The possibility of allocating 240/4 for use has been discussed on various network engineering mailing lists.
Their findings were that many software programs and hardware devices recognize "Class E" addresses and indicates an error.
So the thought that "Class E" is just more IP addresses to pick up for free, is a nice idea, but unfortunately no panacea. It would be very hard to resurrect that range to 'usefulness' at this point in the Internet's evolution (with such a large installed base).
among the software I use, the following don't support v6 at all
Please file bugs. Most Free Software projects take IPv6 very seriously indeed.
We are going to run out of IPv4 addresses in March next year (422 days from today) /JB
http://ipv4depletion.com/?page_id=4
In the case of NFS and MySQL, both know about it, and both are looking to fix it, but we won't see the changes any time soon (MySQL expects to see v6 support in version 6.0, and I have no idea when NFSv6 support will land). rtorrent has a patch, but it isn't in stable yet, and I inquired on the m0n0wall mailing list, but alas, received only radio silence. As for MythTV, there's absolutely no mention of v6 anywhere, aside from a stub page on their wiki, so I'm not sure it's even on their radar (though you're right, I should inquire).
There has been an increasing amount of IPv6 support out there. Part of the problem in terms of going IPv6 right away is that many of the high end routers out there accelerate IPv4 but don't accelerate IPv6. Basically when you deal with large amounts of data, it is infeasible to do everything in software. So you have ASICs to help speed everything up. Works great, but said ASICs have limits to what they can do and being hardware, can't simply be reprogrammed. This means you have to buy new hardware to support IPv6, which is of course expensive.
We had that situation on the campus I work on a few years ago. Some people were wanting IPv6 but we didn't support it. Technically, it could be enabled and run on the routers' CPUs but that would only work if a few people used it. If usage got higher, the routers would crash under the load. We needed new routers (or more properly new supervisor modules for them) to support it. However, it was really expensive, a few million for all of campus. That money was not going to be spent just so people could play with IPv6.
However, we've had to upgrade the routers anyhow to support more traffic and such, so now they have IPv6 hardware and IPv6 is routed on campus.
Thus I think you'll see this continue to happen. New hardware supports IPv6, companies will get it, and will then be able to support IPv6 no problem. It just won't be an immediate process. They aren't going to go and buy IPv6 hardware just to get IPv6 support if they don't need it. However, when they need new hardware anyhow, the stuff they get will have IPv6 support.
I think we are more likely to see a gradual change. More and more networks will start supporting IPv6, and people will start using it because it'll be cheap. An ISP will say something like "Well sure, you can buy IPv4 addresses for $10/month each, however your account includes more IPv6 addresses than you can ever use for free anyhow." So people will start using it.
Uh, no, not at all. To resolve v6 hostnames, you have to retrieve AAAA DNS records instead of A records. That's an application-level activity. Once a v6 address is chosen, the application must be written to create a v6 socket from that address.
Now, it's true that higher-level APIs can hide these details (I believe Java applications are automatically v6 aware thanks to the higher-level APIs exposed by the JDK), but applications written against POSIX must be explicitly written to support v6.
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
IANA network expert
Mod parent funny for the double-entendre.
ISI.EDU is no longer DoD contracter for the IANA function.
ICANN is the current holder of the USG contract for the IANA function.
Many of IANA's roles were stripped from it and assigned to other entities which makes sense.
Still, it is perhaps among the saddest moments in internet history, that this change happened...
Good and bad things have come of it. But don't think of IANA as a separate entity anymore, it's really just ICANN.
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.
Am I the only one that can see the connection? :)
"which has continuously and reliably estimated global pool IP address exhaustion for late 2011 and regional registry exhaustion by late 2012"
The Maya Calender ends 2012 a coincidence I think not!
They have foreseen the end of IPv4 address space.
It's the beginning of the end.
::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.
POSIX support is easy if you use the new generic getaddrinfo and getnameinfo. Code needs to be ported from the old way which hardcoded IPv4 addresses (AF_INET). A properly written program will support both IPv4 and IPv6 and will use the right one based on network interfaces and DNS.
I'm told, by sources that are usually authoritative enough that I'm going to be lazy and not go find the original references (:-), that APNIC has in fact done the right thing and reserved several commonly-misused subnets of 1/8 and 27/8. Slashdot won't let me quote the actual table because it has too many "'junk' characters", but they did 1.0.0.0/24, 1.1.1.0/24, 1.2.3.0/24, 1.50.0.0/22, 1.255.0.0/16.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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.
My xkcd "Map of the Internet" poster just got outdated.