IPv6 is in no sense here. The fiat allocators can exhaust their address space completely and the Internet will continue to function indefinitely; it will simply become more expensive (first marginally, and then significantly) to hold a static address.
There are deep problems with universal deployment of IPv6 far beyond simply getting people to throw a switch; the number of popular software packages that will malfunction when addresses cease being representable in scalar integers is large.
The internet can only continue to function "indefinitely" as you so put it unless there are no further end points created or demand comes to a grinding halt by users, servers, anything with a public facing IP address. However, that's not the case and many new devices are requiring public facing addresses, and RIR's typically do not give out new blocks until ~3/4 or more (ARIN requires 80%) of the last block they were given is fully utilised. Now for ISP's issuing dynamic assignment to customers that may only happen during peak periods - but if they don't have addresses to give, they along with everyone else that requires public facing IP addresses have two options: more NAT, or IPv6. Quite frankly the idea of being inside an ISP size NAT like many mobile broadband users are on my home DSL connection is quite an unappealing idea.
There are many problems of deploying v6, nobody is saying it'll be a walk in the park, but end devices (like my €100 Nokia dumb phone and my desktop) support it + can also support transitional methods like 6to4, Teredo etc. Tier 1 providers like NTT have been offering it for years - the problem is now the bit in between the end user and tier 1. I think DSL providers with ancient, non-software upgradable DSLAMs (I'm looking at you Ericsson), and the hundreds of millions of home routers out there doing nothing but IPv4 NAT are the bigger challenge than a few bits of code parsing a longer address.
I think that getting home users to upgrade their home routers is easier than getting all of the various software packages out there upgraded to work with IPv6. Getting ISPs to upgrade expensive hardware is another issue...
Which software packages are you talking about, specifically? I seldom encounter libraries or packages that entirely do not support IPv6 (except for MySQL). At the very most it's a configuration flag or compile option to switch it on, if it's not on by default. I'm also curious as to how easy you'll find these homes with a myriad of routers either ISP supplied or third party, and the case you have to convince them that the little box they had needs to be upgraded with firmware or replaced entirely.
The other thing to note is that IPv4 won't just be left in the dust, it'll have to be transitioned - the immediate future at least won't be entirely IPv6, and the world will have a bit of time where dual stack is inevitable for parts.
If cable-companies can figure-out how to transition users from their analog cable boxes to the digital ones, I'm sure ISPs can figure out how to transition their customers to IPv6-capable routers. It should be dead-simple for the ISP-leased routers, but for people with their own routers, it's still an ISP-level issue. They just need to tell their new customers that they need an IPv6 capable router, and to figure out a way to transition existing customers that own their routers.
My cable company lost my business when they last year began requiring a "box" to receive TV. I already had a newer digital-capable TV, and did not want yet another gadget and tangle of wires on my TV stand. It was the final straw, the other two being the cost and the low-value content.
I actually didn't drop them completely, but did fall back to "basic" (no box required) + internet (cheaper than internet alone, which is what I really wanted).
The natural solution will be that IPv4 addresses will start getting more and more expensive as they become scarce. At some point, switching to IPv6 will be the cheaper option, and then the switch will happen.
Or companies and universities will give up there unused IPv4 addresses so there will be a lot available again. They may even sell them at large prices.
But then again, it's just a matter of time before we are really out of IPv4.
http://en.wikipedia.org/wiki/IPv4_address_exhaustion#Reclama...
But if you only buy an ipv6 address, the people who are only on ipv4 can't get to you. By itself, the ipv6 address is nearly worthless. The only people who have them now are people who also have an ipv4 address. ipv4 isn't going away any time soon...
Well, when ISP hits a cap they either have to get more IPv4 addresses (which they won't be able to do soon) or use some NAT. Except for legacy systems support, NAT64 is clearly a winner here.
NAT64 works fine if you have an ipv6 client and want to talk to ipv6. That's just regular old network address translation. But if your server is on ipv6, NAT64 still needs an ipv4 address so that people there can get to you. The ipv6 address is pointless-- it's easier just to put your server on ipv4 and not mess with NAT64 or ipv6.
Currently IPv4 addresses fix nicely (exactly) into a 32-bit integer. How do you propose that software storing addresses as such will be able to use a larger address without an update? (Not to mention all of the other reasons, like the different packet format to accommodate the larger address space among other things)
Yeah. The switch to IPv6 will cause lots of things to break. This is unavoidable now.
It's worth noting that on the 8th of June this year, Google, Facebook, Yahoo!, Akamai and others are going dual stack IPv4+IPv6 for a 24 hour period to make people with broken setups aware that they have broken setups. "World IPv6 Day":
Basically, if you're one of the people with a system which thinks it has IPv6 access but doesn't, then you're not going to be able to access Facebook, Google, Yahoo etc on that day.
The internet will not function indefinitely. You're forgetting that some of those software packages that are expecting IPv4 addresses also may not function behind a NAT box/router very well or at all.
If your application doesn't work behind an IPv4 NAT box, then your application is broke already. It will likely be broke in IPv6 as well since firewalls are not going away (and many of the same protocols that break because of NAT also break with stateful firewalls).
I'm implying a legacy application that only works with IPv4 addresses, and doesn't work well behind a NAT. I know those are two separate issues, but the transition to IPv6 will likely require those software packages to be rewritten anyways so the idea that it will be broken even on IPv6 is moot because it won't even work on IPv6 as it currently is.
So the application is broke with IPv4 and NAT, it is broke with IPv6 as it currently is, and somehow in the future it will be able to be re-written in IPv6 and made to work?
Most of the problems that I encounter with NAT and applications deal with protocols that have a control channel and then spawn separate streams frequently which are UDP. H323 is a perfect example. Both ends and the intermediate NAT devices have to understand how to handle the sub-channels.
This problem won't go away with IPv6 as firewalls will still need to understand the sub-flows. Additionally, we will be living in an IPv4 AND IPv6 world with NAT so not only will you likely have to go through an IPv4 NAT you also probably will have to go through a protocol tunneling device for some large set of users.
Those most likely are not running against the internet as a whole or at random, or they would be screwed already.
VPNs and IPv4 networks that exist today won't disappear...
Why wouldn't they? The IPv4 addresses would either be behind some sort of NAT, or they would be IPv4 addresses in IPv6. If the apps can't handle IPv6, then they can't handle IPv4 addresses in IPv6, and they definitely won't be able to communicate with newer hosts that have IPv6 addresses outside of the range of IPv4.
While it is a big deal, it's really something that needs to happen. I'm hoping that once IPv4 addresses become more and more expensive, that people will start making their content available over IPv6.
There is indeed a very large amount of software that is going to break with the change. Right now, there's little motivation to make your software IPv6 compatible, as everything is either dual stack or IPv4 only. Hopefully news like this makes developers take notice.
This needs a better headline, given the gravity of the announcement. IPv6 is by no means here, and really has nothing to do with this news item. To me, "IPv6 is here" says absolutely nothing about the real news here - APNIC having received two /8s (and one forthcoming), making them the recipient of three out of seven of the remaining /8s.
Definetley, inaccurate headline. The problem is, this is a historic moment, it's just extremely difficult to explain why.
This is more lime the beginning of the end. It's going to be long and drawn out.
Is nobody else afraid that instead of IPv6 we're now going to get more and more layers of NAT?
Sure, for us geeks that's totally unthinkable... no servers, no P2P?!? But most users, who are content with just web & email, will probably never notice the difference.
ISPs will surely find it easier to turn NAT on than to switch to IPv6, and the backlash might be close to nonexistent.
As I understand it, this is the last few IPv4 blocks being handed out. This leads people to conclude that IPv6 is here? If anything, it seems to me that it's "IPv4 is gone", and we need to take steps to ensure that that wasn't the last thing we had.
Setup a tunnel. There are many great tunnel brokers available. It's free too. Then add a AAAA (DNS) record for your website. IPv6 isn't nearly so scary once people see that the big bad hex numbers can have names too:
None of the first four urls I randomly tried slashdot, ibm, dell, ycombinator have AAAA records.
IPv6 is not here and won't be for a long time. While v6 may be better in some circumstances, it is worse in others. I'll be keeping my offices behind NAT routers thank you!
I like it. You should also add checks for ipv6 glue records. I advertise ipv6 dns servers but I do not yet have glue, so you still need to connect to my dns servers over ipv4. According to your tool I just have to convince google to add AAAA records to their MX targets and I'm set, but I'm not :)
Even after innumberable discussions about this subject, I still don't get why people are so afraid of NAT.
The main concern seems to be about ISPs starting to NAT everybody and their dog. Well, guess what, they just can't do that. For starters because their users would get very angry when their torrents stop working, and would jump ship for any other ISP that announces that it either doesn't do NAT or has implemented IPv6.
There is still a huge amount of work that can be done to compress the usage of v4 address space. Maybe not much that the RIRs or the ISPs can do, but as the cost of owning a static IPv4 address goes up (and I believe that it will go _way_ up), end users will start compressing their public services into fewer addresses and giving back small subnets to their providers to reduce costs. I mean, who the hell needs to have a mail server and a web server in two different public addresses when they can just do port-forwarding over a single address? (And since most servers are on DMZs with private addressing, they are mostly doing it already, it's just a matter of renumbering.)
The case most likely to go NAT is also the most likely to go IPv6: mobile devices. These are mostly behind NAT already, and going IPv6 would actually reduce costs for ISPs. It would also put ISPs in the track for more extensive IPv6, since the major problem now is that people have little knowledge of how IPv6 works and ISPs are trying to avoid the pain. The issue is, of course, that 99.9% of mobile devices don't support dual-stack and even in a pure v6 configuration don't actually work properly.
For this I predict that in 10 years the move to IPv6 will still be half-way. Considering that we are so close to IPv4 depletion and there is virtually _no_ IPv6 to be seen, I'm being faily optimistic.
For people that don't actually have their own allocation from a RIR, the price will likely go up. It's a matter of supply and demand, their provider is going to have a shrinking pool of IP addresses from which to assign new ones to servers. It seems likely to me they will start charging additional fees for more IP addresses.
We are by no means out of IPv4 addresses. The next step is that all of the entities who needlessly snapped up /8 space early on and sat on it for so long will be selling it off. The list includes GE, Xerox, IBM, HP, Apple, MIT, Ford, Halliburton, Prudential Insurance, Bell-Northern, Merck, Eli Lilly, the DoD/military (who has 13), USPS, and CSC. Just half of this space is 234m IPv4 addresses.
Sigh... this idea has to get thrown out every time there's an IPv4-exhaustion discussion. I guess I'll be the one to do the public service of debunking it this time.
* You can assume that each of the /8s have plenty of infrastructure relying on them, meaning $millions in migration costs. Do you think that the holders will just give them up tomorrow, or do you think its more likely they'll sick some lawyers on the problem? So even if you CAN get them back it'll take years.
* For each /8 you successfully extract this way, you buy the world mere WEEKS of time.
IPv4 allocation isn't completely efficient -- we all know that. The real problem, however, isn't efficiency. 2^32 is just too small of a number.
Also, remember that some of those large companies are USING those /8's internally. No private addresses, just unreachable /8 public IPs - the way the internet is supposed to work.
We need to stop beating a dead horse and start deploying AAAA and v6 across the board. We used to only have 3 network sizes too (/8, /16, and /24), but we managed as an internet community to get rid of classful crap and move onto VLSM and CIDR.
Although the /8s have an entire infrastructure relying on their current situation, it is not unthinkable that the economical advantage of making subsets of their space available to third parties will become more attractive than just letting it sit idle. It might even justify the migration costs. So maybe we'll see parts of IBM, Apple and HP transform to IP/DNS providers.
Apart from that, it's not a question of having the /8s 'give back' IP adresses -- it's about them monetizing their available IPv4 space, out of their own volition.
Whether that relieves the IPv4 shortage for weeks or months doesn't really matter. What matters is what value they can extract from it.
The "IPv4 marketplace" idea has serious issues of its own, though:
1. it's ARIN (and, I think, other registrars) policy that you do not `own' your assignments in any legal sense. So if you sell them you may be committing fraud. If the deal goes bad it's not clear what the legal recourse would be. This is just a flipside of the "take back the /8s" problem: it gives too much for the lawyers to do.
They might even collide: suppose a large company with a /8 (say, Haliburton) decides to open a IPv4 marketplace. In response, ARIN says "well its clear you have more IP space than you need, so we're taking back your allocation effective next month" Now who has the rights to those IPs: the people who paid Haliburton for them, or those that got them in new assignments from ARIN?
2. Just having an IPv4 address isn't useful if it isn't routable. To split up a /8 into tiny salable bits means that all of the backbones need to update their BGP route prefix filters.
If this were done under the auspices of ICANN this wouldn't be a big problem at all: if ICANN says that the allocation policy for an address range has changed then all of the big players will follow suit. (There can be a few remaining routing issues for a new /8 on the periphery but they tend to get sorted out fairly quickly)
Would a similar announcement from Halliburton have the same effect? Doubtful, especially if it is done in opposition to ICANN's wishes. So probably any IPs "bought" in this system won't actually be routable.
3. Related: even if there was a healthy, 100% legal marketplace for IPv4 space it could only be practical if they were bought and sold in large chunks exclusively. If everybody who wanted some space for their company had to buy their own /28, the global BGP routing table would completely explode.
The only workable marketplace would be at the ISP level.
4. The registries are all united in wanting IPv6 deployed. Having companies making big profits selling their lucky IPv4 windfalls means that there would be deep-pocketed people with a vested interest in stalling IPv6 even more... after all if IPv6 were widely deployed the value of `their' IPv4 addresses would plummet.
Now it is true that if the IPv4 situation becomes dire enough, some of these players might decide to suddenly get into the hosting game and put more of their IP space to use. For instance, Apple has a /8 and just built a HUGE datacenter.. maybe they want to do their own version of EC2? The idea is a little odd but maybe not unthinkable
If people are really interested in speeding IPv6 adoption, the fastest way might be for government and/or industry to subsidize IPv6-only broadband for consumers (via existing ISPs).
Imagine $1-5/month DSL to your home, price-locked for 3 years--except it's IPv6-only. Lots of cost-conscious people would sign up or switch to save $xx/month, even if it meant their Internet access was crippled for a while.
But it wouldn't be crippled for long, because with such an underserved user base, the major services most people care about (Facebook, Google, etc.) would very quickly start to cater to it (even if the demographics did skew low-income), because it would be a green field and a big opportunity to build longer-term user relationships to monetize down the road.
This might be a stupid idea, so feel free to roundly berate me, but...
Given that a switch to IPv6 has potential to cause widespread problems, and that we might be facing such a switch before they are ironed out..
Can we not simply update IPv4 and add a new octet to the address space? So 255.255.255.255.255, then call everything distributed so far 000.xxx.xxx.xxx.xxx and make a start on the 001.xxx.xxx.xxx.xxx address space.
I appreciate that we would need to update a lot of software to handle the new octet, but I can't help feeling that would be much easier to do (with the advantage of easier "failing gracefully" / backward support).
As I understand it, the problem for IPv6 is with existing routing hardware and with testing. So if you're going to go through all the effort to add a new octet (which requires changing the IP packet format to allow for the extra space, for example), then you might as well go all the way to IPv6 and solve the problem once and for all.
Not just the IP packet format. Most software ends up storing IPv4 ip addresses in a 32-bit integer (because it fits exactly). All of those pieces of software would need to be updated to work with IPv4's 'new ocetet' as well. As the other poster stated. If everything needs to be upgraded, then might as well do it right the first time.
"APNIC reiterates that IPv6 is the only means available for the sustained ongoing growth of the Internet, and urges all Members of the Internet industry to move quickly towards its deployment."
In other words, as wmf has already said, IPv6 isn't here. But it needs to be, and soon, otherwise the game is very rapidly going to be up.
a) Eventually (most likely next year or later), if you do not have IPv6 connectivity, there will be new content and sites added to the global internet that you will have no way of accessing at all from your v4 connected computer.
a2) Alternatively, in a year or so, you get service from a brand new ISP that has no v4 connectivity (so, you are v6 native), and you cannot access anything on the v4 Internet around the world (e.g. most things today).
b) Don't store IP addresses as 32bit integers, or as 15 character strings. Be aware that geolocation services probably don't do well with v6 addresses. Make sure your deployment platform has the infrastructure in place to serve both v4 and v6 customers (or at least v6 after a year or two) - AAAA dns records, etc.
Why would a new ISP have no v4 connectivity? They'd be connected to someone, and they would likely have v4 connectivity. Wouldn't they be able to have a private network connection to them (10.x.x.x)?
You can't eBGP route private addresses.
(well, you can, but if you do, you should be shot).
The new ISP would need it's own space to announce (it's not much of an ISP if it's got no customers to give addresses too, so it needs addresses. It's also not much of an ISP if it's only got one upstream, so it'll need PI (provider independent) space, allocated to it from it's RIR (ARIN, RIPE, etc). And that'll all be gone soon :)
There are deep problems with universal deployment of IPv6 far beyond simply getting people to throw a switch; the number of popular software packages that will malfunction when addresses cease being representable in scalar integers is large.