The IPv6 Mess
cr.yp.to
cr.yp.to
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.
I just hope the current attitude of Cisco is proving me wrong.
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.
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.
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.
http://www.ict-partner.net/en/US/prod/collateral/iosswrel/ps...
http://web.archive.org/web/*/http://cr.yp.to/djbdns/ipv6mess...
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.
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 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.
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.
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.
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.
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.
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.
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
This strategy requires a whole group of players to move simultaneously. We're back to the chicken-and-egg problem.
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.