The problem will solve itself when the price of an ipv4 address becomes prohibitive. Either that, or telcos will see ipv4 addresses as a valuable source of revenue and intentionally drag their feet. And then the internet will die.
The reason that IPv6 has seen minimal adoption so far is that the market has no reason to care about it yet. When will it start caring? 541 days from today, give or take. That's when IANA is projected to run out of IPv4 addresses. It is not the day that the internet goes up in a puff of smoke if we haven't finished deploying IPv6; it's the day that market pressure begins to accumulate and the day we find out what an IPv4 address is actually worth on the open market. When it becomes cheaper for large consumers of IP addresses to transition their networks to IPv6 than to continue paying for IPv4 addresses, that is when the "magic moment" will happen.
I must have written this before I had my coffee and now it's past the edit period. "Right answer" was only agreeing with the first sentence of the parent post. The rest I think is wrong for the reasons stated.
Yes, a crisis within the next 2-4 years is going to force the issue. This crisis will cause a major disruption to the way the internet works and will affect every industry. The sad thing is it didn't have to come to this, notice that this article refers to discussions from 2002, if the IPv6 transition had been managed correctly we would now be completing the transition instead of barely beginning it.
A coworker has been transitioning our stuff to IPv6. It has been an eye-opening experience. It's not just IPv4 with a bigger address, it's not even just IPv4 with a bigger address and some stuff, it's a new Internet.
When you understand that, the sluggish rate of deployment goes from "What the hell?!" to "Yeah, of course this has taken time!" In fact I'm sort of coming around to the "what were they thinking?" point of view and beginning to think that IPv4.5 (IPv4 + bigger address packet and minimal changes to make that work) may yet have been a good idea. "Everybody" said "hey, we have to have a new protocol so let's like design it to be the awesome!" but it remains to be seen whether the problem of "running out of addresses" can actually carry the weight of all the other wishlist that has been encoded into IPv6. (I'd say "probably yes, but it was closer than it should have been".) Reminds me of some of the (X)HTML standards that basically failed for the same reason... "well, as long as we're rewriting the standard language of the web, let's go nuts and embed all kinds of stuff..." unto death, as it turned out in XHTML2.0s case.
Or it will cause massive adoption of large scale NAT, which will further centralize the internet. Because such centralization favour few, huge, powerful players, we may not see the transition at all.
I just hope the current attitude of Cisco is proving me wrong.
I just wish Cisco would fully support IPv6. Their regression of the protocol on their routers, firewalls, leaves something to be desired. But, I guess regression requires users - chicken/egg thing.
It could be more pernicious than that: IPv4, because of the potential lack of addresses, is very good at centralizing the network. For instance, most ISPs don't offer it's customers a fixed IP address. It makes installing servers more difficult. Some ISPs even share IP addresses between customers. It makes installing servers impossible. The result is a more centralized network, where you more or less have to blog and mail through big companies' servers.
The stakes are very high. A centralized network provides huge opportunities for analysis and targeted advertisement (read: spying and manipulation). IPv6, by providing an internet address to every device on this planet, is a threat to that model. However, clinging to that model is not directly making money from IP addresses, so the ICANN may not be able to do anything about telco dragging their feet.
"It gets worse. The IPv6 designers don't have a transition plan"
This is either an old article or the author is not up to speed. Good example why you should date your articles. I met with Cisco a couple months ago and they detailed their IPV6 strategy to us from the service provider perspective. In short: They're throwing a bunch of different strategies at the problem to cover all the bases. It's not an elegant solution. More like brute force with a focus on preserving total interoperability. This stuff is already in the wild today on a small scale. It works. Comcast, COX, TWC, etc all have active deployments and are looking at large scale rollouts over the next year.
The article is dated, but not outdated. The page you linked to is clear: "IPv4 and IPv6 protocols are not directly compatible, and hence various techniques are necessary for their coexistence". If IPv6 were compatible with IPv4 in the first place, the "various techniques" wouldn't be necessary, and transition would have taken years, not decades.
How would you propose making IPv6 compatible with IPv4? Recall that every IPv4 application in the history of Berkeley Sockets has 32-bit address buffers hardcoded into the binary.
Part of the reason we don't just map IPV4 space into IPv6 space, I recall reading, sensibly, was that it would make routing a mess, and potentially even get messier.
The idea was to re-issue address space in a more coherent manner to make things easier to manage at the peering level.... which seems sensible.
It also a mistake to think of the internet you see today as "Designed".... the protocols were designed, but the particular way we use them, the parts we didn't use, and the way the internet grew as it did was organic, not pre-planned. To expect some people to get together and come up for a rock solid plan to migrate all that to IPv6 is to ask for something completely unprecedented.
The tools need to be there to allow for organic adoption and growth.... and nobody should be "selling" ipv6 addresses.... there are more than enough to go around, that was the whole point. IP address space was never intended to be monetized.
I recommend everyone take 15 minutes and look up a guide to configure a 6to4 address on any interface they have with a public IPv4 address. Try with the anycast address first, and if that doesn't work get a tunnelbroker account. My opinion is all these problems can get solved over time only when everyone is first connected to the network. (there are some guides to setting up a gateway for your 'private' hosts, like this: http://74.125.93.132/search?q=cache:gX-Stzp_WdgJ:www.anyweb....)
I'm quite confused why this is getting attention. It's not hugely difficult to enable a public IPv6 address on a server alongside the IPv4 address. The advantage of doing so? If one runs a serious website, there are many more back-end servers that handle database requests etc. than there are user-facing webservers, and all of these back-end servers can use IPv6 to talk to each other and the webservers. If IPv6 addresses are cheaper and easier to get, then it's a win for the company. They can upgrade each internal client-server pair to IPv6 in unison since they're a single organization.
As if the number of servers using IPv6 mattered the slightest. It does not. What matters is the number of IPv6 servers that can talk to all clients. That means IPv4 clients as well (they are the majority, after all).
Being connected to the internet means being able to talk to every single machine on that network. If a computer can't talk to IPv4 computers, then it is by definition not connected to the internet.
We can't split the network. If we have to do it to switch to IPv6, then it just won't happen. Ever. To avoid splitting the network IPv4 and IPv6 machine have to be able to talk together.
So, as long as IPv6 and IPv4 computers can't talk to each other, we will be limited to the back end servers you are talking about. Until we go beyond that point, IPv6 will stay relatively useless.
As an ordinary user, I can abandon ipv4 as soon as the services that I use are on ipv6. I don't need to be able to connect to every one of the 500 million computers on the network via ipv6 - I only need to be able to connect to the servers and services that I actually use - Google, Amazon, YCombinator, etc.
Worst case, I'd need to connect to all the computers in my P2P network - a few million, or all the computers in my bot net - a few million more. And in both of those cases, the client software either is or will be smart enough to keep me connected via a proxy of some sort.
For example - To get to Google without ipv4, I don't need to connect to every one of their millions of servers via IPV6, I only need to get a quad A from my DNS and connect to their external facing load balancers via ipv6. As soon as I can do that, I don't need ipv4 to use Google. For all I care they could be running Arcnet on their back end servers.
Another consideration is the prevalence of NAT and proxies in the corporate world. Corp users are already NAT'd, Proxied, Content Filtered anyway, so upgrading the the corporate web proxy to do 4 to 6 translation puts the entire corp desktop on the 6 network in one shot, and isn't a major re-think of Corp networking.
That's a silly argument - any site which uses a non-trivial number of backend servers will have an internal network using RFC1918 v4 addresses, and there's no shortage of those (djb covers this).
As someone who runs such a site, I'd only think about upgrading the internal networks to v6 long after the public internet has gone to v6.
I've heard that for very large service providers, it is possible to run out of 1918's. IIRC Comcast did a presentation where they figured they needed 100 million IP addresses for a nation wide rollout of their triple play service. They appear to be highly motivated to use 6, as the alternative - partitioned 1918's would be a nightmare.
I agree, though, that exposing your services to the Internet via both 6 and 4 and leaving the backend internal data center at 4 is probably the way to go for the next decade or so. Heck - we are still running DecNet on production servers.
Suppose you are using a cloud hosting service, or multiple such services, and don't have the luxury of an internal network? Then your network IS the public internet.
An odd article. He seems to think there ought to be a Grand Plan forcing the transition.
Servers can have both IPv4 and IPv6 addresses, there's no need for everyone to just switch over at once.
I strongly suspect that the big providers will start rolling it out over the next couple of years, and that this will filter down to local users after that.
My main problem is that very few home routers support IPv6, so they'll need to be replaced. But this can happen over time, with people on IPv4 being behind NAT, and thus having less accessibility to soem applications, they can make their own choices about when to upgrade.
Assume that: (1) universal adoption of X is good, (2) individual adoption of X takes a few time and effort, and (3) individual adoption of X provide no benefit whatsoever (such benefit will come when everyone has switched).
I think X will never be adopted before either (1), (2), or (3) becomes false. That or you actually scheme a "Grand Plan forcing the [adoption]".
I the case of IPv6, the author proposed to solve (2) by embeding the switch in the normal upgrade process, and (3) by making IPv6 backward compatible with IPv4. That is not forcing anyone. It just removes a huge amount of friction, solving the chicken-and-egg problem.
I'm not convinced that (3) is going to be true in the long run. It's when using IPV4 is a problem that people will switch. And that will come when ISPs start using NAT on their users.
Agreed,and many customers will switch without knowing it.
If Comcast swapped my cable modem for a V6 capable modem, and if as a part of routine upgrades, my Dlink-whatever got swapped with one that has native v6, I'd be on v6 without knowing it. My Vista, Win7, Mac and Solaris clients would 'just work'. I.e. - when I dropped a /64 onto my home lan - consisting of a handful of laptops and an OpenSolaris server - my Vista, Win 7 and Mac picked up the V6 network and started using v6 w/o even a re-boot.
The harder part is making a decision to shut off IPV4. It's at that point that you have to make a service availability decision.
My guess is China and/or India will come up with their own solutions for transition and the rest of the world will be forced to follow that. It will probably represent a defining moment in history of the internet, when leadership passes from the West to the East.
maybe what we need to do is have servers/networks that validate that whether a client supports IP6 or not. And if it doesn't, start serving those requests more slowly than others.
Of course, that means a lot of code changes. but it will definitely create incentives to get ready for a change
if speed declines for you 10% a month for a year, you'll consider upgrading. and if outages are scheduled for you that at first last 5 minutes, then 15, then 30, eventually I expect people will take the actions required to get ready for a scheduled switch to IP6
its all a bit heavy handed though. its much better if we gave people more performance for making the switch and somehow passed the real costs of the delay on to people that insist on delaying.
maybe we should just have a market price for ip4 addresses and you pay that price unless you upgrade
The problem is giving up performance for the current overwhelming majority of computers. Slowing down YouTube slowing down for IPv4 computer won't create an incentive to upgrade those computers. It will be an incentive to leave YouTube for a faster competitor.
This strategy requires a whole group of players to move simultaneously. We're back to the chicken-and-egg problem.
It already does for other criteria, like how much is paid by the content provider to have the relevant cable "still work flawlessly" (such behaviour sometimes raises a scandal).
The problem is the network you talk about is a bunch of interconnected machines and cables, each under the control of some entity, which is often a profitable company. What you propose would be very difficult if you want to preserve (the illusion of) net neutrality.
