There are a ton of /8 still assigned to companies that don't need them.
Ford, GE, IBM, AT&T (x2), Xerox, HP (x2), Apple, MIT, CSC, Eli Lilly, Nortel, Prudential Insurance, DuPont, Cap Debis, Merck, SITA.
All of those can return their /8. That's 18 /8 potentially available.
And does the DoD really need 12 /8's? I get that they want to network every person, gun, ship, tank, truck and plane. But none of those need to be on the public internet. (Well, maybe the people do - but 1 /8 should be enough for that.)
There are various reasons that the legacy IPv4 assignments are not returned. At the normal rate of IPv4 address assignment, circa 2011 when IANA ran out, reclaiming all those addresses would have delayed address space exhaustion by maybe 2 years at most.
All it would have cost was unpredictable, unbound man-years of work as each organization tracked down each of their publicly addressable machines, not all of which were recorded, and vacated into smaller subnets of their address space. I'm sure you know of the servers that sometimes disappear behind walls during renovations. And some of the older machines require the kernel to be recompiled and rebooted to change their IP address. Ah, those were the days.
We just have to face the fact that IPv4 was not designed to be used on a network the size of the Internet. NAT and CIDR have stretched it out amazingly, but we've stretched it out about as far as it will go. We need to switch to IPv6.
I think the suggestion was that they expected those blocks could become very valuable in the future and could thus be sold for a healthy profit. I don't think GP meant that IBM wanted to actually use those addresses themselves.
> All of those can return their /8. That's 18 /8 potentially available.
If say, Apple is using at least a little bit of that /8 here and there (safe assumption, no?) its going to be hard for them to return it. I'd wager corporations that have /8s have policies that rely on the assumption that they have the whole /8.
So I wouldn't hold my breath on getting one back from them.
Presumably, as the good in question becomes scarcer, its value will increase to the point where it makes sense to sell it, or use alternative solutions.
When IPv6 is fully implemented, an IPv4 /8 will be essentially worthless. Reasonable people can disagree as to when that day will come, but it will come. It's probably not that far off.
Why not sell it or suballocate it while you can still get money for it?
Reassigning some ipv4 IPs on a handful of corporations' internal networks would dwarf the cost of upgrading the entire internet infrastructure to ipv6?
I get assigned a new ipv4 IP by DHCP every time I reboot my computer. And you should hear the infrastructure people at my ISP and workplace and university squeal when you ask them about ipv6 - far too much work, they say, no plans on the horizon.
The entire internet infrastructure (backbone routers, etc.) is already using IPv6, so the cost of implementing IPv6 is, by now, entirely on the end-site side.
You should also include a number of additional cost of reassignment, including growth of routing table size.
I'm sorry to inform you that apparently your ISP, your workplace and your university are all either lazy, lying, or both. Implementing IPv6 takes, maybe, a few weeks if you have many servers and a large internal network. If all you have is a webserver which you want to be reachable by IPv6-only customers, an interim solution (tunnel) can be implemented in a few minutes.
>I get assigned a new ipv4 IP by DHCP every time I reboot my computer.
Sure - from your router's subnet. The route to that address still goes to that router. There's no BGP update to propagate, no routing table entry to add to every router on the internet.
I mean, why not assign every IP address individually? That way we'd be fine for up to 2^32 internet-connected devices. Every router would just have to store all 2^32 routes in memory and send out a BGP message whenever anyone rebooted. Can't see any problem with that.
See, you'd like to think so. You'd like to think that there's an easy solution not involving you, because it would mean you don't have to do anything or learn anything new.
However, as pointed out in many other comments in this thread, this (and many other knee-jerk reaction "solutions") won't actually work, or would be significantly more expensive than implementing IPv6.
It's been on the horizon for nearly 20 years. It's coming soon now. The IPv4 end is nigh. Repent!
In the global market, returning those addresses won't help at all.
Currently, the only reason the American registry still has any IP addresses left, is because their pool was separated from the emerging markets in Asia. As such, if IANA would start extracting IP address as suggested, the global market would eat it up faster than IANA could collect them. It would only "work" if IANA gave all the addresses exclusively to the American pool, working towards a local Internet rather than global.
How would end-user software deal with an IPv6 address though? Surely some of it is IPv6 capable already, but I would imagine that a lot of it makes assumptions about IPv4. If the OS were operating on a IPv6 network, would that software function correctly as long as the addresses were IPv4-compatible (i.e. within the IPv4 range, and not in IPv6 notation)?
They had enough time. This is not a new thing. Some ISPs were more proactive, some were not. Those invested man hours and hopefully they will reap the benefits while their competitors struggle.
Same with OS and software support.
In the end some will profit from this (even the lazy ones -- "quick, pay us for a new version that enables IPv6 support) and some will lose (they'll find competitors did a better job at IPv6 support).
Dual-stack, proxies, and (if absolutely necessary) actual tunnels can compensate for critical IPv4 apps. You can layer whatever you need to on top of IPv6.
Non-critical applications where people aren't willing to jump through any hoops... Well, it's not exactly news that sometimes old apps get left behind in technology transitions.
Of course it does, but not necessarily a publicly-routable one. Dual-stack is necessary because otherwise the IPv4 application literally won't run at all. How the packets actually traverse the public internet is a different matter addressed by things like NAT, proxies, or tunnels.
"It depends", is unfortunately the answer. For very old software where it's not possible to patch it for IPv6 support (this is rarer than you might think!) then some kind of IPv4 NAT or a DNS64 style "application layer gateway" is required.
You could also potentially add a specific wrapper for your application e.g. wrapping MySQL connections inside of stunnel allows them to run over IPv6 in version of MySQL built with v6 support, or for simple daemons you can do things like set up socat to proxy between an IPv4 socket and an IPv6 socket.
Almost no software you're likely to be running is incompatible with IPv6, though. Software support for IPv6 is way ahead of actual network implementation.
>Almost no software you're likely to be running is incompatible with IPv6, though. Software support for IPv6 is way ahead of actual network implementation.
How sure are you of this ?
Now, ofcourse all the major widely deployed software, be it browsers, web servers, mail servers and clients, remote file systems and similar are already IPv6 ready. What about all the many many millions of custom built systems and applications ? The kinds you will never see, that's hidden behind a corporate wall in use by 10-100 people.
Or all the devices that people have bought - all the wifi routers, IP cameras, network printers, DSL modems and so on ? It doesn't matter how much anyone says that these should have had time to support IPv6. If they arn't, it'll cost someone money to replace them - not all are willing to do that.
You can run both at the same time. Any software that is not IPv6 compatible would still be able to connect through IPv4 and just not have access to IPv6 addresses.
The bigger issue would be connecting to IPv6 only servers from an IPv4 program. The first question is how many IPv4 only programs exist in the wild. If you happen to have one, and cannot update it, then you still have the option of creating an IPv4 to IPv6 proxy for the specific site(s) you need.
We had some software that stored IP addresses in a field in a ':'-separated text line; luckily, the files were quite transient, so we could just change the separator into a semicolon and be done with it.
Elsewhere, the IP addresses were used as part of a file name on Windows; we replaced all colons in the IPv6 address with '!' to fix that.
There's bound to be lots of old software with similar problems around.
> There are a ton of /8 still assigned to companies that don't need them.
You've got no idea how they're structured internally. Some of those companies uses their blocks to make every machine in their network globally routable, they don't "need" them but they do use them and they're part of their network architecture.
They are using 16,777,214 IP addresses? I think that's quite a stretch. I work at a company that has 19,000 employees with locations all over the world. We couldn't make a dent in 16.7MM routeable IP addresses.
Please note that not only can there be multiple IPs per employee, there are also IPs assigned to services and servers.
I would ask you to please note that there are non-routeable addresses that can be used for these purposes. You do realize that the /8 they've been granted is a public Internet netblock? You realize that 99.999% of the world doesn't use public Internet addresses on their employee's workstations or internal servers?
But for the sake of argument let's assume Ford (one of the owners of a /8) has 200,000 employees and that each of them is using 10 public IP addresses. That's 2MM. Then let's assume they have 10,000 servers and each one is taking up 100 IP addresses. That's another 1MM for a total of $3MM which is less than 1/5 of the addresses they're currently allocated.
Oh, and Ford only has 164,000 employees and I guarantee that each employee isn't even using 1 public IP address let alone 10. And 10,000 servers with 100 public IP addresses is just as ridiculous. Do you see now how wasteful it is that certain organizations have these /8s?
Beyond that, it really sounds like you don't know the difference between a public and private IP address. If for no other reason, places like Ford should have been using private IP address space for internal servers and workstations for security purposes.
No, it does not sound like the parent doesn't know the difference between public and private IP addresses.
What it sounds like is that you expect Ford to take the time and energy to renumber their entire network just because they presumably don't need a /8. And while it's true that they probably don't need a whole /8, making them renumber is ridiculous.
I just knew someone was going to totally change the argument. The argument I was replying to was that they use 16.7MM addresses. I proved that there is no way they use 16.7MM addresses.
So either you didn't read the original argument, or you just like to argue so you are now changing the argument. In either case, I'll bite.
Nobody is asking Ford to be altruistic about this. Right now their /8 has some value. They have a lot of options, not the least of which is to suballocate it for a tremendous amount of money. That's a given - they could probably also come to an arrangement with IANA/ARIN to just sell a part of it back. They'd make a tidy sum in any case. The alternative is the status quo. In 10 years their /8 will go from being worth a lot of money to being worthless. After all, what value would 16.7MM addresses have after IPv6 is fully implemented with its 2^128 addresses?
Companies renumber all the time. And let's be honest... how much renumbering would they really have to do? That whole fantasy land that "every employee must be using multiple public IP addresses" is just plain silly.
> > No, they are using their block and their network strategy is predicated upon having an essentially infinite set of IP addresses available.
> I just knew someone was going to totally change the argument. The argument I was replying to was that they use 16.7MM addresses. I proved that there is no way they use 16.7MM addresses.
No, the argument you were replying to was that they make use of the entire address space, which does not at all require every address to be in use. For example, each of their /16s may be used for a different organization, product, or location, and it's likely that many of the /24s for each /16 are further logically divided for organizational and routing purposes.
The idea the original claim was trying to disagree with was that all the network infrastructure in place was using a monolithic /8 with no logical divisions. Specifically, "them" in masklinn's comment was referring to "blocks", not addresses.
> Some of those companies uses their blocks to make every machine in their network globally routable, they don't "need" them but they do use them and they're part of their network architecture.
You're arguing that masklinn intended to say something he didn't say. I argue that he meant exactly what he said. He said they're using their blocks. You're interpreting blocks as "sub-blocks" but I disagree. masklinn also said in supporting his position:
Some of those companies uses their blocks to make every machine in their network globally routable
Really? If you're anything resembling a network engineer, surely you see how ridiculous this is? And how about this other thing he said:
Please note that not only can there be multiple IPs per employee, there are also IPs assigned to services and servers.
Again, really? Multiple public IPs per employee? That's just poppycock. He was wrong, I called him out on it and you can try to re-interpret what he said all you like but the fact is he is just plain wrong. They're not using 16.7MM addresses, they're probably not even using 10% of 16.7MM addresses and assuming that every /8 holder broke their netblocks up in the least flexible and most wasteful way possible is nothing more than an assumption on your part.
Legally it's an allocation, not ownership. The registry could simply revoke your allocations if it caught you selling them (though whether it would is another question).
Exactly, its more like a lease. You can't actually sell an IP because you don't own them, but you are given a lease/license to use them.
Frankly, the only way to truly transfer an IP block between companies is to have one company buy the other, then the IP addresses can be reallocated to the new owner. You can't just transfer an IP block to another entity according to ARIN's registration agreement.
When I owned an ISP in 1996 I paid a larger ISP money to suballocate a range of a couple /24s to me. This happens all the time - look up any random netblock on arin.net.
It depends on the policies of the RIR (Regional Internet Registry) in the region where the IPs are from.
That said, if you're willing to ignore the RIR's policies (which a lot of people do) you can usually "black market" trade IP addresses, so long as you can convince your upstreams to accept them (which they usually will).
Meanwhile, in Europe, RIPE ran out of IPv4 a year ago[1], and people have been happily implementing IPv6 ever since. In Sweden, there is a government directive[2] that all state infrastructure should implement IPv6 and DNSSEC by this year (2013) at the latest.
Bah. All this IPV4 "exhaustion" stuff can be simply solved. Almost overnight. Right now, most of the space is underused and simply being hoarded.
Want to free up 90% of the IPs? Easily? Then charge for them!!!
If MIT had to pay $1/mo for each IP address ($16 million per month), it would immediately give most of them back.
If MIT had to pay $1/year for each IP address ($16 million per year), it would immediately give most of them back.
And yet for people like me, paying (in round numbers) $50 / month for Internet, $1/year or even $1/month would be "in the noise".
So how many hundreds of billions of dollars will instead be spent on the designed-by-nerds very-difficult-to-implement not-very-backward-compatible solution of IPV6?
Such policy would lead to an explosion of fragmented patterns in routing, expanding the global routing table. That mean latency and costs would go up while throughput would go down.
If I remember right, there doesn't exist hardware for backbone networks that can handle a fully fragmented global routing table at the required speed of today. They are thus unlikely to also handle the increased speed of tomorrow without quantum computers.
Making ipv4 a second class citizen working like an low performance compatibility layer for legacy seems like a great migration plan to me. Especially if performance would go down progressively.
The backbone network is unlikely separated by hardware for IPv4 and IPv6. If one drains resources, the other gets effected.
They could start to charge differently for IPv4 traffic and IPv6. If peering Terms of IPv6 interconnection agreements was free/radically lower than ipv4 (by say, increasing ipv4 charge rate), ISPs would see a direct encouragement to move to ipv6. Its not a unique concept, as similar suggestion has been made in 2011 (http://www.canscouncil.net/presentations/CANS2011/china_ipv6...)
The main argument for migrating existing websites to IPv6 in the near-term is merely to aid the policy goal by showing "Hey! IPv6 is in actual use!".
On the technical side, there are various transition mechanisms that can ensure even "IPv6-only" clients will be able to communicate with most legacy IPv4 services for years to come. HN is not holding up progress.
No, such a thing does not exist. At least not automatically. There are stories[1] about large corporations getting complaints from end customers in Asia about not being reachable - and it turns out the customers only have IPv6. IPv4 FAIL.
(Note: APNIC ran out of IPv4 addresses more than two years ago[2], and has had rapid internet expansion in the mean time. Asians are heavy IPv6 adopters.)
Such a thing you imagine could conceivably be implemented, but it would be an extra thing for the IPv6-only ISPs to implement, and they do not have the incentive to do so. The current companies with servers do have an incentive to be reachable by IPv6-only customers, and are the only parties who can reasonably solve the situation, by implementing IPv6.
IPv6 doesn't exist automatically, either. If an ISP is going to move their customers to it without setting up the requisite transition mechanisms, I don't see how that's any different than failing to meet the myriad requirements for provisioning a functional IPv4-only network in the modern age. Whom do you blame when an ISP forgets to configure BGP on their routers?
You might think such a scheme is "requisite", but the fact remains that there is insufficient incentive for the ISPs to do them, and they plainly don't do them, as my cited example shows.
You can assign blame however you like, but it won't help your IPv6 customers/users to reach your servers.
I really don't know what your example shows, because I don't read Swedish, and the Google translate version is predictably mangled and difficult to parse. To the extent it says anything, it's very vague and seems to recount a single, unique incident. This and your apparent inability to provide case studies in English leads me to the belief that the problem is rare.
I'll also add that I've been in the employ of a company that does business exclusively in Asia for years. We've as yet not encountered this problem.
If you have experience with Asian ISPs, could you then maybe report on how common it is for them to have IPv6-only versus IPv6-plus-transition-mechanism?
This data would be better than my anecdotal story about an unnamed company, so please provide any you have.
In my experience? Exactly 0% of ISPs are strict IPv6-only. That doesn't mean there isn't one anywhere, we don't have millions of users throughout the continent, mostly Taiwan and (to a lesser extent) China. But we've yet to find one.
When I say the issue has not arisen, I mean it. We have two infrastructures, one is basically 8 years old, the other is about three. At the time the latter was setup, our provider wasn't even ready to deploy IPv6 widely, they were still learning and testing with a handful of select customers.
Both legacy and modern run solely on IPv4, and we've not had cause to revisit the issue.
When we get reports of network problems not attributable to simple user error, the cause is almost always either misconfigured routers breaking path MTU discovery, or ridiculously strict firewall rules that don't even allow port 443 out.
I don't even know how many of our users have IPv6 at all. I have no reason to know nor any good way to measure it short of calling all the ISPs or sending people to our customer's homes to check.
I have a very real other reason: One of the hosting companies I use doesn't account IPv6 traffic, so all IPv6 traffic going to some of my websites is essentially free for me.
I'd really hoped we'd have more support for IPv6 by now. It's funny, every so often there's a big "We need IPv6" push with lots of media coverage which is forgotten about shortly afterwards.
As far as I know there's only one ISP (Internode) here in Australia which offers IPv6.
There is some network effect in there and I've experienced it myself.
In a product we make, we can go the extra mile and start supporting IPv6 but the libraries we use, the rest of the echo system we play in, don't support it. So we feel like it would be wasted effort at best and it would break things at worst.
A good way we found to force others to configure and bother about IPv6 support is if we deliberately add extra and better features only tied to IPv6.
There is now a 60 day payment window that wasn't there before. And a review of previous procedures that could result in various minor revisions. So it is different, but not a lot different.
There's always been a vocal group who maintains that the IP addresses that are not visible on the internet should be returned. There are a number of problems with this argument.
Firstly, there are legitimate business reasons for having assigned, non-RFC1918 addresses that are only used internally. Interconnecting private networks belonging to different organizations that have overlapping 10.x addresses is a painful process. Sure it's possible to NAT, but given that the IP addresses are effectively an asset of the organization, why not use them? I'm not implying that this is right, but it's how the system was in the past and the cost of changing internal networking and applications could be very high.
Secondly, how do you prove that an IP address is accessible on the Internet? Many IPs do not respond to pings and I can easily set up a device that will answer for all IPs behind the corporate gateways.
> how do you prove that an IP address is accessible on the Internet?
If an address isn't announced in BGP, then for most practical purposes, it's not on The Internet.
But I'm sure that if someone acquired the authority to start reclaiming unannounced /8s, the entities holding them would figure out how to announce them quite quickly.
> Why does Xerox need an entire A block, why do Apple, BMW?
They don't, but retroactively taking away their /8s would be extremely complicated and expensive for them, not to mention that there is very little benefit from prolonging exhaustion by perhaps 1-2 years at most.
They could buy the ranges back if they really desired. The results from the Carna botnet show just how sparse the usage of the allocated ranges is. It's practically empty for the entire left upper quadrant.
What's the time lag until we run out of IPv4 addresses at the VPS/hosting provider and broadband ISP level?
I see the situation getting progressively more dire, and presumably these notifications are there to try and get people moving to avoid the wall; but assuming everyone keeps operating as close to the status quo as they are able, how long before we truly hit the wall?
Its not really so bad. Its not like end users need IP addresses. All you need is addresses for all the major servers, and then like a couple dozen for each ISP, right?
It means that NAT-punching may stop working (because there may be two or three levels of it).
It makes fraud detection harder.
Plus, it's error prone -- once in a while, you'll get data that happens to look like your IP address, and you'll find that you can't send that precise sequence of bits in a packet ever because it'll get mangled by the NAT.
> once in a while, you'll get data that happens to look like your IP address, and you'll find that you can't send that precise sequence of bits in a packet ever because it'll get mangled by the NAT
How so? Those bits should only matter to the NAT logic if they are found in their expected position in the IP header, not in the payload portion of the datagram.
Some cheap NAT devices rewrites stuff that "looks like" the internal IP addresses inside the TCP payload, in a hackish attempt to "fix" things like FTP and other protocols that send addresses in the payload. A really stupid and dangerous way to do things, but it's been known to happen.
Crazy. Has that been observed in carrier-grade NAT boxes, though? Or only in el-cheapo residential devices? It seems an incredible risk to the carriers to do things that way.
Five (or ten) years ago, NAT was "the solution" – which helped and worked for longer than the doomsayers predicted.
Today, I suspect SNI will be the important stop-gap measure. There's a whole bunch of websites out there on shared hosting with dedicated IP(v4) addresses for their vhost just so they can use SSL certs for https connections. If we can ignore Windows XP users and IE6 users, SNI allows SSL certs on shared IP addresses - if I can think of a few dozen "unnecessary" IP addresses this little web development firm consumes, I suspect big hosting companies could probably find thousands or tens of thousands of similarly used IP addresses.
(Having said that, analytics still shows a startlingly high number of WinXP and IE6 users out there. It'd be interesting to see if any of them ever "convert" in ways that'd require SSL certs? I understand why the use of pirated XP and 10 year old hardware are rampant across the 3rd world, for _my_ clients that demographic is almost certainly not likely to be ecommerce customers... That's a bit of a personally skewed perspective though, there's no good argument to be made that says wikileaks/twitter/gmail users on old hard/software shouldn't get ssl protection, but I suspect high-end bed linen online shops wouldn't be hurt at all by using SNI and thereby increasing friction for IE6/WinXP users…)
> I can think of a few dozen "unnecessary" IP addresses this little web development firm consumes, I suspect big hosting companies could probably find thousands or tens of thousands of similarly used IP addresses.
That's the problem. A few million addresses would stretch things out by a couple of months.. But the cost of getting a few million websites onto SNI would far exceed any benefit.
Perhaps. As well as "returning" a few million addresses, it'd also plug one of the drivers behind demand for new addresses (I've got no idea if it's just my blinkered little web-dev worldview talking here - anyone actually know what the big consumers of new ipv4 addresses are doing with them? Is SSL certs for websites a significant consumer?)
If my view is even vaguely supportable - I see things happening that give me some optimism - WHM/cPanel, a fairly significant webhosting management system, rolled out SNI support earlier this year (a few months behind schedule, but it's out now and it works). I assume Plesk and other webhosting management packages are doing the same thing. Perhaps this'll stave off the ipv4 apocolypse by longer than expected? (Or perhaps I've got no idea about what's really going on out there…)
No, I don't think so. Kicking the can down the road doesn't help much, the longer you kick it the more people say "Whatever, they'll keep putting this off for at least a decade, let's just drop IPv6 from Linux 3.2 and put it back in Linux 4.0" and then where are you.
IPv6 isn't going to just magically happen if you don't make it happen.
Ford, GE, IBM, AT&T (x2), Xerox, HP (x2), Apple, MIT, CSC, Eli Lilly, Nortel, Prudential Insurance, DuPont, Cap Debis, Merck, SITA.
All of those can return their /8. That's 18 /8 potentially available.
And does the DoD really need 12 /8's? I get that they want to network every person, gun, ship, tank, truck and plane. But none of those need to be on the public internet. (Well, maybe the people do - but 1 /8 should be enough for that.)