IPv6 *is* like AMD
IPv6 *is* like AMD
Posted Jan 27, 2011 8:39 UTC (Thu) by bojan (subscriber, #14302)In reply to: IPv6 *is* like AMD by khim
Parent article: LCA: IP address exhaustion and the end of the open net
Wow! Still not gettin' it. It's not about the network and networking hardware. Network in itself has no value. IPv6 right now has zero value, because there are no hosts on it (i.e. nothing to route). And how are you going to get the hosts on it when it has no value? You won't (not right now anyway). That's why there is talk of multiple layers of NAT and other rubbish (I personally detest this and would like IPv6 to succeed).
You get _all_ the value to the network and ISPs will follow. We had a chance to do this, transparently, but because of a few purists, it never happened.
It's only cheaper not to run IPv6 because there is nothing to run there, of course (i.e. your fancy IPv6 routers see packets every couple of hours). Why would people sink millions into equipment when all of their customers are on IPv4 (i.e. their IPv4 addresses and configs are unusable on IPv6)? And yet, some forward looking ISPs have the whole core enabled for IPv6 already. But guess what? No customers. Why? Because nobody cares to reconfigure for no immediate benefit. More importantly, why should they have to? It's just nonsense.
You know, you are kinda disproving your own points :-)
PS. It was also cheaper to keep running 32-bit software. Ergo, no need to enable 64-bits in hardware. We could have had PAE for a few more decades, I'm sure. :-)
Posted Jan 27, 2011 10:26 UTC (Thu)
by khim (subscriber, #9252)
[Link] (35 responses)
No, we had no such chance. Instead we had the following discussion: Sorry. DJB plan was either fairy tale or a fraud - depending on your viewpoint. Because it still does not solve problem X - and this is the only part that matters. DJB's plan does not change it because it does not solve problem X. Valid question - and because DJB's plan does not solve problem X it does not change the answer. Yup. This is incorrect: there a lot of customers. They just don't know they are customers because there are nothing to see on the IPv6 network. Yup. Think about it: 0.3% penetration is about 4 million of people. Do you really believe every single one went and separately configured IPv6? No, it happened automatically for most of them - without any DJB plan at all. Where exactly? Sorry, but no. PAE only goes to 64GiB. Systems with 128GiB are already common. On the customer side systems with 4GiB are common and indeed these systems are orten 32bit even today.
Posted Jan 27, 2011 17:22 UTC (Thu)
by lutchann (subscriber, #8872)
[Link] (32 responses)
Thanks, this made me laugh, and it's a perfect summary of the argument.
Posted Jan 27, 2011 22:05 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (31 responses)
He does it in crypto, he does it for signal processing, for mail, DNS, you can bet that if DJB takes an interest in something you know about he'll have written about why your ideas are bogus and why everyone should do whatever DJB thought up in five minutes.
Something about a DJB rant encourages people who don't know the subject very well to become convinced that experts are idiots and they now know better thanks to DJB. I'm sure such power could be harnessed in some way, but frankly I'd rather nobody had it at all.
Worse, there is always someone, somewhere with a vested interest in slowing or outright preventing acceptance of the Right Thing. DJB's alternative helps confuse the issue of what they're doing. One notable provider deployed DJB's "alternative" to DNSSEC for example. Why? Well unofficially the reason is very simple, that provider injects adverts into DNS replies to generate revenue. DNSSEC makes this impossible (preventing tampering with records is the whole point) but DJB's solution does not.
Posted Jan 27, 2011 22:17 UTC (Thu)
by lutchann (subscriber, #8872)
[Link]
Posted Jan 28, 2011 1:44 UTC (Fri)
by cmccabe (guest, #60281)
[Link] (29 responses)
1. The transition was impossible. Nobody could have possibly done it correctly.
2. The transition plan was bungled. The Right Thing was a Wrong Thing. Or possibly, there were other Right Things that should have been done.
Ad hominem attacks against DJB-- or anyone else for that matter-- don't prove anything.
I tend to lean towards position #2. This is because I've read of other successful technological transitions-- even major ones! Some good examples are x86 -> x86_64, Apple's PPC -> x86 transition and DOS to Windows. Some examples of failed transitions are Commodore 64 to Commodore 128, x86 to Itanium, and the Apple ][ to the Apple III.
The failed transitions all have something in common: the people in charge underestimated the importance of having a transition plan. Compatibility was for little minds, people who couldn't see the big picture, the Right Thing. Itanium was so much better than x86 that its architectural superiority would crush x86 by sheer force. The fact that it ran legacy apps at a slug-like speed was irrelevant.
The successful transitions always involved a "no regressions" philosophy where existing setups would continue to work just as well, or possibly better, after being upgraded. Engineers often spent months or years working around bugs that had nothing to do with the new stuff, and everything to do with the mistakes of the past. For example, in one OS upgrade, Microsoft wrote special-case code that only triggered if the program was named simcity.exe, to work around bugs in that program that the old OS had not exposed. When new security features in its OS put additional burdens on application developers, those burdens were added gradually rather than all at once. Upgrading was made mandatory rather than optional by shipping the new version on all new machines.
Of course, you're free to disagree with me and insist that IP is fundamentally different than the other transitions described above. But at least give reasons.
Posted Jan 28, 2011 1:51 UTC (Fri)
by bojan (subscriber, #14302)
[Link] (2 responses)
Don't say that! IPv6 transition is a grand success. Look, my ping6 started working too:
$ ping6 ipv6.google.com
:-)
Posted Jan 29, 2011 4:44 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
64 bytes from 2a00:1450:8006::63: icmp_seq=1 ttl=56 time=121 ms
For comparison Google via IPv4 gives results like:
64 bytes from 209.85.229.99: icmp_req=1 ttl=57 time=42.5 ms
Almost the entire 80 millisecond difference is tunnel time, as my packet travels via whichever is the closest organisation to provide IPv6 connectivity to refugees like me - my ISP could decide tomorrow that this wasn't acceptable, deploy their own endpoint as per the RFC and that number would be substantially reduced without me (or any other customer) changing a thing. But that would cost money.
Posted Feb 7, 2011 15:42 UTC (Mon)
by rleigh (guest, #14622)
[Link]
% ping6 ipv6.google.com
Not too bad!
Posted Jan 28, 2011 5:12 UTC (Fri)
by lutchann (subscriber, #8872)
[Link] (15 responses)
Transitions (paradigm shifts, in touchy-feely business parlance) happen when the pain associated with the change is outweighed by the advantages of the new way of doing things. The IETF was wrong in its belief that IPv6 had advantages that would motivate a meaningful number of users to change. But, contrary to what many people seem to think, they did put a great deal of effort into trying to minimize the pain of transition. IPv6's undoing was that vendors took years to get anything implemented in products, so every time the IETF came up with a new transition path, it was three to five years obsolete by the time it was available to end users. 1998-- 2002-- 2005-- 2010-- After watching this process for more than a decade, I'm a little skeptical when somebody comes along with a great idea for how the IPv6 transition "should have been done"--it invariably involves going back in time and implementing something that couldn't possibly have been foreseen to be necessary at the time it needed to be implemented.
Posted Jan 28, 2011 7:06 UTC (Fri)
by cmccabe (guest, #60281)
[Link] (14 responses)
The big mistake is to think that people will do the right thing because it would be better for everyone. That never works. The other big mistake is to think of the internet as a single thing. As well as being a series of tubes, it's also a collection of organizations and individuals who each have their own agenda.
We need some kind of effective carrot or stick to make the individual organizations do the right thing. It could be a government mandate. It could be a feature that you only get if you make your network IPv6 capable.
I almost wonder if it's too late, though. NAT may have won the battle by default. Another poster here said that as soon as blocks of IPv4 addresses start getting major cash value, change will have become impossible-- the same way patent reform is impossible.
Posted Jan 28, 2011 21:31 UTC (Fri)
by lutchann (subscriber, #8872)
[Link] (10 responses)
What were these supposed advantages? The same advantages that drew people to the Internet originally. Unfettered end-to-end connectivity. The opportunity to participate as an equal without having to pay through the nose. The liberating concept that you could plug in anywhere without having to worry about what kind of access you get and what the tariffs look like.
Fifteen or twenty years ago, the IPv4 Internet gave people freedom from the tyranny of buying ISDN circuits or paying exorbitant fees to be a mere "terminal" on an X.25 network. Today the IPv6 Internet gives people freedom from the cruft that litters IPv4 today as a result of the scarcity of addresses and the widespread use of NAT.
As it turns out, the people who want these things have already been using IPv6 for years. We apparently account for 0.2% of the Internet's user base.
The telcos had it right to begin with. Most people just want a dumb terminal. Provider-side NAT is as good as IPv6, as long as the Youtubes still work.
Posted Jan 29, 2011 9:43 UTC (Sat)
by TRS-80 (guest, #1804)
[Link] (6 responses)
Posted Jan 29, 2011 18:31 UTC (Sat)
by lutchann (subscriber, #8872)
[Link] (5 responses)
My point was that the IETF wasn't so naive as to think that the world would move to a new protocol simply because it was "the right thing to do". Their mistake was in misjudging the perceived value that IPv6 had over IPv4.
Posted Jan 31, 2011 0:51 UTC (Mon)
by khim (subscriber, #9252)
[Link] (4 responses)
Their mistake was in overestimating interest and underestimating price. Repeatedly. The initial plan called for the upgrade of everything on ISP level - the idea was that customers will push the ISPs and they will install IPv6-capable hardware/software. Of course there are huge number of people who want "circa-1992 Internet" but few of them care enough to endlessly pester ISPs. And since for ISP IPv6 is pure headache without any gain they just ignore these people anyway. The fact that the people who felt "little transition pain" in this scenario and people who benefited from the transition were different people doomed that plan. The next plan provided end-to-end connectivity to some people. To the ones who have "white" IPv4 address - it was not done as easy and elegantly as in DJB's plan, but it was done. Good idea? Nope: the people with "white" IPv4 address are precisely the people who don't need IPv6 at all! It's kinda hard to ask someone to feel "a little pain" and get end-to-end connectivity if said someone already have end-to-end connectivity! The next plan was the most sane one: it provided connectivity to people who are behind NAT. These are the people who really need/want IPv6! Sadly it took too long to develop this plan: it works only with UDP-punchable NATs and by the time it was usable most NATs were multiple-layers stateful NATs. So this plan failed as well. What next? Well, one way will be to design something usable for the people with multiple layers of stateful NATs - and/or wait for the new wave of users with intrinsic IPv6 support (LTE users, for example are supposed to be like that). But the key are new users, not the existing users! It's obvious: This is why DJB's plain is so crazy: it introduces additional complexity to the IPv6 for the sake of minor convenience of some people who are not part of the solution to the "IPv6 deployment problem" at all!
Posted Jan 31, 2011 2:36 UTC (Mon)
by dlang (guest, #313)
[Link] (3 responses)
they may get by with their ISPs doing NAT64, but if each ISP is doing NAT64 before the traffic leaves that ISP, and the ISPs do not want the users to be running servers (see their various terms of service if you doubt this), then why should the ISPs bother to expose and route the underlying IPv6 addresses instead of just having everything go through the NAT64 boxes?
Posted Jan 31, 2011 12:19 UTC (Mon)
by khim (subscriber, #9252)
[Link] (2 responses)
Sure, but this is the first step. There are many ways to exploit even simple ubiquitous point-to-point connectivity between two points you control. Think remote desktop, remote play, access to your home video library, etc. Once most people have IPv6 access (used for point-to-point connections mostly) you can start to use it to build P2Ps on top, etc. But this plan falls apart because IPv6 is about the worst technology for the point-to-point connectivity in today's internet. Different forms of VPN, SSL tunnels, etc are much better for that. Forget about ISPs already! Any transition plan which starts with "ISPs must do ..." is doomed from the onset. The most you can expect from them is indifference. Some of them will actively fight IPv6 but most of them will just ignore it's existence when they discuss different plans. ISPs will join when there will be active IPv6 community and people will actively demand IPv6 - not before.
Posted Jan 31, 2011 22:25 UTC (Mon)
by dlang (guest, #313)
[Link] (1 responses)
why would anyone demand IPv6 until there are any IPv6-only resources?
and why would anyone ever willingly deploy an IPv6-only resource if the vast majority of users will not be able to reach it?
until something breaks this stalemate how will IPv6 gain any traction?
Posted Feb 1, 2011 15:18 UTC (Tue)
by khim (subscriber, #9252)
[Link]
Have you actually read what I wrote? IPv6 promised "end-to-end connectivity". You can use end-to-end connectivity for a lot of things besides accessing public IPv6-only resources. You can access your own resources: console in your living room, NAS with your collection of MP3s and videos, etc. Sadly IPv6 in it's current form can not be used for this: there are no simple way to connect to IPv6 network from behind multilevel stateful NAT (cheapest and the most common version of Internet access available). Yes, you can use, for example, stunnel to reach some kind of bastion host and use said bastion host to enable access to IPv6... but why will you do that? If you've connected your console or NAS with bastion host you can as well just connect directly to the bastion host without adding IPv6 to the mix! This is correct question - and the answer is simple: it's Ok if the resource is intrinsically designed to be only accessible by very limited number of users. I've shown some examples above, but you can invent many other similar uses. Some of them will not use IPv6 for that anyway (for example for a lot of organizations it's better to deploy their own VPN because it's more secure), but some of them may do. For it to be useful you need some simple way of obtaining connection to IPv6 network - and currently all simple ways assume that ISP will do that. And ISPs are the last persons to participate in such plan. Poorly are we can see.
Posted Jan 29, 2011 12:38 UTC (Sat)
by khim (subscriber, #9252)
[Link] (2 responses)
Wow! That's cool promise. I really like it. I have it. Kinda. I'm almost always connected to VPN and anyone who's connected to our VPN can reach me easily. It's stunnel-based VPN so it works almost everywhere - and this is really cool.
But how can I actually cash in on that promise in case of IPv6? The answer is simple: I can not. 6to4 does not work with NATs at all while teredo only works with "mild" NATs with working UDP hole-punching. Compare it with other technologies which promised "to participate as an equal" (like Skype or Tor): they use all available technologies to create working tunnels. Somehow all these IPv6 technologies are designed to give "unfettered end-to-end connectivity" to the people who already have unfettered (or barely fettered) IPv4 connectivity! WTF? Why will I do anything to get what I already have? DJB's idea is stupid for the same reason: it gives access to the people who already have "white" IPv4 address and who's ISP was farsighted enough to enable IPv6 support on routers. These people are people who least interested in IPv6 because it does not give them anything worthwhile! Sorry, but no. There are lots of people who need more then dumb terminal. Me, for example: I regularly work with programs which are installed on server in our office and need unfettered acceess to my workstation. SSLvpn gives access to me. I can attach my laptop to the network in hotel or cafe, start my vpn script - and voila: I can talk to servers in our office, these servers can talk to my laptop, everyone is happy. IPv6 gives excuses to me instead. I can attach my laptop to the network in hotel or cafe, start miredo and see list of the reasons for why it does not work. Rarely (if ever) I've seen working ipv6.google.com... and this is 20 years after IPv6 effort started. P.S. Oh, and of course I can use my SSLvpn connection to reach IPv6 internet via our office... but why will I want that? This will be transition to IPv6 because it was "the right thing". Connectivity problem was already solved for me with SSLvpn, so I can safely forget about IPv6...
Posted Jan 29, 2011 22:34 UTC (Sat)
by dlang (guest, #313)
[Link] (1 responses)
but I don't want the end-to-end connectivity for my Grandmother.
and users like my Grandmother outnumber users like you and me by something like 1000-1
Posted Jan 31, 2011 0:24 UTC (Mon)
by khim (subscriber, #9252)
[Link]
Why the heck no? How can I help my Grandmother if her computer will not be reachable from outside? But again: SSL gives me what I want, IPv6 does not. Not all people desire end-to-end connectivity, but there are a lot of people who do. Yet IPv6 technologies are designed to provide said end-to-end connectivity to the people who already have it (if they have "white" IPv4 address then they already have end-to-end connectivity and if their firewall supports "UDP hole punching" then there are tons of IPv4 technologies which can be used to establish end-to-end connectivity). DJB's plan is crazy for the same reason: it improves IPv6 accessibility for the people who don't need it!
Posted Feb 1, 2011 10:21 UTC (Tue)
by Cato (guest, #7643)
[Link] (2 responses)
The bigger costs of staying with IPv4 for content providers are considerable - SEO (search engine optimisation) and the increased use of SSL tends to require a unique IP address for each domain, yet server side NAT or Apache virtual hosting breaks that. More generally, the huge cost of bypassing multiple NAT layers for complex applications will become an increasing issue.
Posted Feb 1, 2011 16:04 UTC (Tue)
by khim (subscriber, #9252)
[Link] (1 responses)
Not right away. Think SMS. The global average price of SMS is 3 cents. It's much higher then you need to actually send it, so SMS are generating substantial profits for operators yet it makes no sense for the companies to try to replace SMS with anything: to do that you must spend billions of dollars and to justify such cost you need to send hundreds of billion of SMS per months - and nobody sends this much. Situation with IPv4 addresses is the same: to replace it with something (IPv6 or anything else) you must spend billions of dollars (perhaps tens of billion of dollars) and it's just stupid when price of one IPv4 address is low enough (typical price for IPv4 address today is between $2 and $5). The same problem: people who feel the pain and people who can do something are different people. We need some kind of peacemeal plan or it'll not work.
Posted Feb 1, 2011 18:35 UTC (Tue)
by Cato (guest, #7643)
[Link]
Expensive IPv4 blocks mean that the price of hosting a website on IPv6 is cheaper, or getting IPv6 access via broadband, so ultimately this will have an effect. A similar example: the price difference between Windows and Linux web hosting is one reason why Windows only has about 20% of the market there, which illustrates this can happen despite switching costs. The price difference per month is only a few dollars for Windows vs. Linux but it does have a market impact, and totals to a big impact on Microsoft's potential revenues.
Going IPv6 on a webhost is not that expensive initially - they must ensure the OS is configured OK on the servers they start with, and provide a 6to4 tunnel to someone like Hurricane Electric. That's all endpoint configuration and can be the end of phase 1 - only once they get customers on IPv6 do they need to look to a native IPv6 end to end with an IPv6 upstream, which can be phase 2 once they have IPv6-driven revenues. Much easier to make the business case.
Ultimately the customers of webhosts will decide - if they get more problems with IPv4 due to NAT, they will ask their webhosts for IPv6, and some of them will switch to hosts that do provide IPv6.
Posted Jan 28, 2011 8:48 UTC (Fri)
by khim (subscriber, #9252)
[Link] (9 responses)
Sure, but noone attacks DJB. They attack DJBfiles who push his stupid paln against any logic. And the only question people are asking is: how will this solve real problem - the lack of agreement among ISPs? Sure. That's why you hand-picked them, right? Let's consider different set of successful transitions: LP to CD, VHS to DVD, TV to DTV, and, heck, even NCP to IPv6. In all cases transition made existing setups either completely useless with no upgrade path or required to change setup just to have the same amount of basic functionality. Now let's consider all these cases one-after-another. LP -> CD: it was supported from the day one by recording companies. They agreed to participate before the first sale of equipment happened. VHS -> DVD: the same. Earlier VHS-relpacements (like Laserdisk or Video-CD) were unable to only to replace VHS but to even gain significant traction. Yet DVD pushed VHS to obscurity even if "existing setups" become useless and "upgrade" was worse in many cases (most DVD players had no recording capabilities). Dual-stack players were used for some time, but when major studios stopped selling VHS with new movies - it went away. TV -> DTV: you needed adapters to watch old channels. Switch was successful because neither TV stations nor users had a choice. NCP -> IPv4: the same. Internet backbone was switched to IPv4 and you had no way to continue to use Internet without upgrade. x86 -> x86_64: stagnated for years, only become mainstream when Microsoft (which had a monopoly) started pushing Windows x64 hard. When it was just an offer (Windows XP x64) it was mostly ignored. Apple's PPC -> x86 transition: my way or the highway. Apple just stopped offering PPC hardware so you had to update - or lose Mac users as customers. DOS -> Windows: this is the closest case to the IPv4 -> IPv6 transition. Windows was promised in Las-Vegas in 1983, showed in 1985, stagnated for years (the first version to gained recognition and not laughs was Windows 3.0 released in 1990) and it only "killed" DOS when Microsoft stopped selling MS DOS separately after release of Windows 95. Commodore 64 -> Commodore 128: good example. Unlike Commodore Plus/4 this model was compatible with Commodore 64. Yet it didn't help because computing ladscape changed and people switched to incompatible offers (IBM PC and Mac). x86 -> Itanium. Itanium successfully killeed incompatible Alpha, PA-RISC, and MIPS (this one only workstations; it was revived as embedded CPU), yet failed to do the same with compatible i386 - because there it had viable and cheaper rival. Apple ][ -> the Apple III: Again - business moved to incompatibe IBM PC, not to compatible Apple III. There were many reasons, but in the end it was because alternative was available and it was just better. Well, not exactly. In all cases there was a transition plan - but people found another, often incompatible alternative - and used that. Transition plan is important, that's absolutely true, but the compatibility itself is not important. In you examples of unsuccessful transitions two times out of three people switched to incompatible alternative where "existing setups" were useless - not to compatible, yet unwanted, "upgrade". It's not different at all: people are choosing the best alternative available. If it's compatible or not is of little importance. Concerted push (like with DVD) or monopoly (like with DTV) may change things rapidly, but "better compatibility mode" only helps you if you have strong backers.
Posted Jan 28, 2011 18:24 UTC (Fri)
by cmccabe (guest, #60281)
[Link] (8 responses)
In the case of TV to DTV, there was a government mandate to get the transition done. Enough said.
In the case of the Apple III, there were a bunch of problems. It had Apple II emulation, sure, but that was "intentionally hobbled" (according to Wikipedia). There were some plain old engineering mistakes like circuit boards malfunctioning because they were poorly designed. The Apple II was Apple's bestselling model ever, as a percentage of the market. They've never again had the same level of success since Steve Jobs decided to torpedo it and start with something completely incompatible.
Did Itanium kill off Alpha, PA-RISC, and the rest? Well, sort of. Intel made threatening noises and those companies basically decided to fold. The fact that Itanium was later a flop makes the whole situation kind of funny.
The truth is, though, it probably wasn't economically viable any more for those companies to compete with Intel/AMD in high-performance computing. Intel's process technology is so far superior to anything they have access to that that kind of competition is a joke. And the HPC market is so small that it can't support the kind of investment in process technology that Intel makes every year. HPC clusters now are built with Intel or AMD's latest, not with PA-RISC.
As I said before, it's a matter of motivation. Figure out who the key stakeholders are, and get them on board with the transition. Give them a reason to upgrade, rather than just telling them to do it for the good of the galaxy.
Posted Jan 28, 2011 21:22 UTC (Fri)
by khim (subscriber, #9252)
[Link] (7 responses)
Well, sure, I agree. I just want to point out that this position is radically different from your previous position: the successful transitions always involved a "no regressions" philosophy where existing setups would continue to work just as well, or possibly better, after being upgraded. Backward compatibility is important, but it that important. You've already showed good case: Apple ][ -> Apple III transition. Apple III had some issues, true, but it was backward-compatible. And while it had some issues with compatibility it was not the problem. The problem was much simpler: price of Apple ][ was between $1298-$2638 (for 48KB) while price of Apple III was $4340-$7800 and price of incompatible IBM PC was $1565 (for 16KB). Well, sometimes you must do something "for the good of the galaxy" - in these case government mandate does wonders. The IPv6 designers were naive not because they refused to go with insane DJB's scheme, but because they insisted for 20 years that it's internal IT-industry affair. It was easy to solve the problem by forcibly moving everyone to IPv6 in year or two. Witness how fast the problem of incompatible phone power adapters was solved. Given the motivation ISP may do a lot to ease these transition process - but why should they? Nobody is paying them and nobody punishes them...
Posted Jan 31, 2011 2:11 UTC (Mon)
by cmccabe (guest, #60281)
[Link] (6 responses)
> Originally intended as a direct replacement to the Apple II series, it was
So, in other words, the Apple III had backwards compatibility, but only of a crippled and limited kind. Itanium was the same story. It could run x86 code, sure-- very slowly.
> Witness how fast the problem of incompatible phone power adapters
When the EU created that mandate, it didn't magically make existing power adaptors stop working. It just affected the adaptors that were shipped in the future. So this isn't directly relevant to the compatibility debate.
> It was easy to solve the problem by forcibly moving everyone to IPv6 in
Maybe this reflects my ignorance, but I don't see why that would be easy, even with a government mandate. If compatibility between IPv4 and IPv6 is an "insane scheme," then what is the alternative? Just don't use the internet for "a year or two"? Come back soon-- under construction!
Nothing happens instantaneously. Even recalls of tainted food take a few weeks to happen. The lack of any transition plan seems very foolish.
> Given the motivation ISP may do a lot to ease these transition process -
The ISPs are motivated, all right-- motivated to use IPv4. Let's count the reasons:
1. IPv4 doesn't involve disrupting existing customer setups.
2. IPv4 creates an artificial scarcity of IP address blocks, which makes those blocks a "strategic resource" for the companies that own them.
3. IPv4 will allow ISPs to charge extra for things that are now free. For example, having your very own IP address, as opposed to NAT privileges, will one day cost you.
4. IPv4 will eventually force the use of NAT. NAT will make it even harder for customers to use P2P programs. Since, at least in the US, those P2P programs compete with the ISP's own "content offerings," that's all gravy to them. Comcast would love it if the new shape of the internet makes bittorrent impossible.
C.
Posted Jan 31, 2011 2:22 UTC (Mon)
by cmccabe (guest, #60281)
[Link]
I suppose one scheme that would have worked is giving everyone both an IPv6 and an IPv4 address-- then, taking away the IPv4 address after a few years.
The problem with this scheme is that, even if the US government mandated the transition, it's not clear that the rest of the world would follow. For example, France could decide that IPv6 wasn't such a great idea, and not mandate it. Since the US kind of likes being connected to the rest of the world, that would effectively derail the transition indefinitely.
Maybe it's time for a new saying to be coined: "If your transition plan requires a world dictator to implement, your transition plan is broken"
Posted Jan 31, 2011 11:53 UTC (Mon)
by khim (subscriber, #9252)
[Link] (4 responses)
Why will you want this? By the date X no new connections without IPv6 are allowed, after date Y all connections with IPv4 must be upgraded, by date Z IPv4 is disabled. Simple and effective. Witness similar transition working as planned. The idea that it can be done using "market forces" is foolish as you've showed later. Where "market forces" does not work government should. The problem here was that IETF did so much without government mandates they believed they can convince ISPs to do the transition. One day may cost you? "White" IP is rare commodity outside of US. It may cost you between $4 and $10 per month. Not a large sum, but if you'll recal that slowest NATed internet access is in the same price range... Yup. And you have limited amount of local ISPs to choose from. Often just one. That's why government regulation makes sense.
Posted Jan 31, 2011 22:17 UTC (Mon)
by dlang (guest, #313)
[Link] (2 responses)
there is no Internet Dictator who can enforce a policy like this.
Posted Feb 1, 2011 14:53 UTC (Tue)
by khim (subscriber, #9252)
[Link] (1 responses)
Actually there is as shown quite recently. You can easily enforce such rule in a single country and for internations efforts there are WTO and other similar organizations. It's not like Internet exist in vacuum and can exist government regulations... Yes, it's completely different approach from the existing one, but it's kinda strange to see so much energy expended on one kind of approach while another is completely ignored.
Posted Feb 2, 2011 9:39 UTC (Wed)
by cmccabe (guest, #60281)
[Link]
The WTO's powers are not what you seem to think. It's not like the WTO can give marching orders Hu Jintao or Barack Obama. Rather, the WTO is sort of a forum for nations to talk to each other. Both China and the US, and a lot of other countries, have anti-free trade policies that the WTO is powerless to change. For example, the US gives tons of subsidies to farmers, who then use it to undercut farmers in the third world. China keeps its currency artificially cheap to pump up exports, and tends not to enforce any intellectual property laws at all (unless the owner of said property is Chinese.)
Or think about the 2010 United Nations convention on climate change. China and India basically refused to agree to any greenhouse reductions at all. With the greatest possible tact and diplomacy, they said "screw you." China builds a new coal-fired power plant every day and has no plans to slow.
International cooperation may work in the case of the IPv6 transition. Then again, it may not. Time will tell.
Posted Feb 4, 2011 21:18 UTC (Fri)
by sorpigal (guest, #36106)
[Link]
Posted Jan 28, 2011 2:24 UTC (Fri)
by bojan (subscriber, #14302)
[Link] (1 responses)
Please don't put words in my mouth.
All I keep saying is that mistakes were made. Even the best of the best do that from time to time.
Your claim boils down to this: it was not possible to design IPv6 as an upgrade to IPv4.
History of software development and network protocols shows otherwise. History also shows current non-adoption of IPv6. You make of this what you want. I see a bad plan.
I'm sure you read what DJB wrote and the main idea is that things should be easily interoperable and compatible as much as possible. This is pretty much the way technology evolved over time. We usually don't just throw things that work away.
You may not like DJB for whatever reason or disagree with many of the things he wrote (I do for sure), but his reasoning here is simple and common sense.
You can also ridicule me all you want. But I know one thing: my ping6 still doesn't work and it should. So, even if DJB and myself are utter nutters (which is a distinct possibility) your grand technical solution still isn't working.
Your Problem X, as you call it, is what people should have been working on in the interim. I never denied that there would be challenges - that's just you wild imagination. But, they couldn't work on it, because the main idea did not have interoperability and compatibility in mind, so they could not plan on how to achieve this very simple goal. In fact, the didn't know what to plan for exactly, so they planned for nothing.
Posted Jan 29, 2011 16:14 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Unfortunatelly you keep saying something totally different: The answer to a very simple and common question is still the main problem with IPv6: Why does everyone already connected to the net have to reconfigure and essentially run two setups? - when in fact it's minor issue not worth talking about. This is "question A", BTW. The main issue is totally different: how can we provide IPv6 connectively to the new nodes who don't have IPv4 address (they are behind NAT or in some non-IPv4 based networks)? This is "question X". Why the "question A" is unimportant and "question X" is the biggest problem there is? Question A: it only helps few people who are getting "white" IPv4 addresses. Today it's about 25% of the users in the 10 years time, it'll be about 0.5% of users. Question X: Internet is still grows about 50% per year (if it stops growing then the whole IPv6 transition will not be needed). This means if you can attach new nodes to the Internet with IPv6 connectivity then in 10 years time about 98% of users (well, devices, not persons: people will have multiple connections by then - some IPv4 only, some IPv4/IPv6 and some IPv6-only; we only care about last two) will be connected to the IPv6. At that point IPv6-only connectivity is almost as good as IPv4 connectivity and we can talk about "IPv6-only ISP providers". Now, please explain again why do you think DJB plan which solves 0.5% of problem is more important than other plans which may solve 98% of problem? No. My clain is different: it is possible to design IPv6 as an upgrade to IPv4 (see TP/IX, for example), but DJB's idea is not a way to do it: it solves about 0.5% of problem and leaves the other 99.5% unsolved. I know that any plan which makes sure new users get IPv6 by default will succeed. In the next few years new users will come from LTE - so this is where battle should be concentrated today. Disruptive technologies never win by frontal assault - they need some new place to grow and thrive. Then eventually they make old technologies irrelevant. DJBs plan is wrong because it tries to help frontal assault - and frontal assault is doomed no matter what, so why spend so much time thinking about it? Sorry, but this is just a preamble to the DJB's article. The gist of the article is "how to make sure nodes which have white IPv4 addresses and DNS records may easily participate in the IPv6 Internet". And this is total red herring: these nodes were rare even when DJB wrote his article and today they are exception, not the rule. It does not really matter what happens to these nodes. It's important to give IPv6 connectivity to the new nodes - and DJB's idea does not help there at all. And I know another thing: what happens with a few lucky persons who have "white" IPv4 address is irrelevant. They are minority, they already have end-to-end connectivity so they are the last persons interested in migration to the IPv6. If ping6 will work for all LTE users then it'll be enough to drop IPv4 altogether. Today about half of Internet access is from mobile phones. In 10 years time it'll be 90% (if you include LTE-enabled laptops and pads) and it'll be not important for the web sites if they are accesible to IPv4 users or not. At this point users of the old IPv4 internet will find some kind of solution. It's not my "grand technical solution". I don't know a good solution to the dilemma. But I know that DJB's idea is wrong because it solves 0.5% of the whole problem at best - and it solves precisely the wrong part of problem. Interoparability and compatibility are not relevant. We either have the problem of IP address exhaustion from explosive growth of the Internet or not. If we do have such problem then what happens with "old" nodes is unimportant: they will be quickly outnumbered by "new" nodes, if we don't have such a growth then IPv6 transition is not needed at all. In both cases DJB's plan is useless.
IPv6 *is* like AMD
We had a chance to do this, transparently, but because of a few purists, it never happened.
DJB: You all are stupid - it's possible to solve A, B, C and D transparently.
IPv6devs: How will you solve problem X?
DJB: You can easily solve A, B, C and D - even if it'll lead to the trouble in the future!
IPv6devs: You plan still have no solution for the problem X.
...
bojan: Everyone is crazy - there was great plan to solve A, B, C, and D. And it was ignored. Fools you are!
khim: This plan was asinine because it ignored preoblem X - and it's the heart of problem.
bojan: No, it was pefect - it solved A, B, C, D.
... discussion is repeated 10 times.It's only cheaper not to run IPv6 because there is nothing to run there, of course (i.e. your fancy IPv6 routers see packets every couple of hours).
Why would people sink millions into equipment when all of their customers are on IPv4 (i.e. their IPv4 addresses and configs are unusable on IPv6)
And yet, some forward looking ISPs have the whole core enabled for IPv6 already.
But guess what? No customers.
Why? Because nobody cares to reconfigure for no immediate benefit. More importantly, why should they have to? It's just nonsense.
You know, you are kinda disproving your own points :-)
PS. It was also cheaper to keep running 32-bit software. Ergo, no need to enable 64-bits in hardware. We could have had PAE for a few more decades, I'm sure. :-)
IPv6 *is* like AMD
DJB: You all are stupid - it's possible to solve A, B, C and D transparently.
IPv6devs: How will you solve problem X?
DJB: You can easily solve A, B, C and D - even if it'll lead to the trouble in the future!
IPv6devs: You plan still have no solution for the problem X.
...
bojan: Everyone is crazy - there was great plan to solve A, B, C, and D. And it was ignored. Fools you are!
khim: This plan was asinine because it ignored preoblem X - and it's the heart of problem.
bojan: No, it was pefect - it solved A, B, C, D.
... discussion is repeated 10 times.
IPv6 *is* like AMD
IPv6 *is* like AMD
IPv6 *is* like AMD
IPv6 *is* like AMD
64 bytes from imaginary internet returned
IPv6 *is* like AMD
IPv6 *is* like AMD
PING ipv6.google.com(2a00:1450:8006::63) 56 data bytes
64 bytes from 2a00:1450:8006::63: icmp_seq=1 ttl=56 time=14.0 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=2 ttl=56 time=13.7 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=3 ttl=56 time=13.7 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=4 ttl=56 time=13.8 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=5 ttl=56 time=13.6 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=6 ttl=56 time=13.6 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=7 ttl=56 time=13.8 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=8 ttl=56 time=13.6 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=9 ttl=56 time=13.7 ms
^C
--- ipv6.google.com ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8071ms
rtt min/avg/max/mdev = 13.604/13.768/14.053/0.184 ms
IPv6 *is* like AMD
IETF: IPv6 is available for the latest operating systems and can automatically tunnel between end nodes over IPv4 with absolutely no administrative effort or network support!
Internet: Those tunnels won't work through our new firewalls and NATs.
IETF: IPv6 is included in the newest routers and firewalls! You can use 6to4 to create automatic tunnels to your border router, and ISATAP to create automatic tunnels safely within your site! You only have to configure one device to IPv6-enable all your workstations and servers! It takes almost no effort!
Internet: We can't, not until our new IDS and load balancers support IPv6.
IETF: Windows Vista and Linux support Teredo, so you can at least use that to restore end-to-end connectivity with IPv6. There's no configuration or network support necessary, since it automatically tunnels IPv6 over UDP.
Internet: That'd be great, but Teredo doesn't work with any NAT that has a stateful firewall, which is nearly all of them these days. Oh well, there are lots of other IPv4-only NAT traversal techniques now which do work. Skype works great.
IETF: Seriously guys...you'd better start migrating to IPv6 or you'll be in a world of pain when IPv4 is depleted. Most infrastructure has IPv6 support now. We've even standardized shiny new translation mechanisms that allow you to run your network IPv6-only as long as your workstations support it. What's the hold-up?
Internet: Well, the last three times you told us IPv6 was ready and we could turn it on and use it immediately, you were wrong. We're going to hold off on IPv6 until everyone else has worked the bugs out.IPv6 *is* like AMD
IPv6 *is* like AMD
Except that unfettered end-to-end connectivity isn't desirable any more, as Apple found out when it enabled IPv6 without a firewall. At which point you have to start running ALGs like if you're doing NAT.
IPv6 *is* like AMD
IPv6 *is* like AMD
Their cost/benefit analysis was all wrong.
My point was that the IETF wasn't so naive as to think that the world would move to a new protocol simply because it was "the right thing to do". Their mistake was in misjudging the perceived value that IPv6 had over IPv4.
1. If explosion of the Internet continues then new users will outnumber old users very soon - and if explosion is finished then we can forget about IPv6 altogether.
2. New users need to setup everything anyway, they need to fill the papers, call the support, etc. They may as well do something extra to gain that end-to-end connectivity.
3. ISPs need to setup new hardware/software to support new users anyway (if there are enough of them, of course), they may add IPv6 to the mix if enough new users will complain that it's slow and unreliable (but it must work for them or else they'll not know how cool it is).Their cost/benefit analysis was all wrong.
This is not a whole solution, true.
the problem with your 'solution' being new users is that the new users still want to talk to everything on the existing IPv4 Internet, and for that a globally routed IPv6 address does them no good.
they may get by with their ISPs doing NAT64, but if each ISP is doing NAT64 before the traffic leaves that ISP, and the ISPs do not want the users to be running servers (see their various terms of service if you doubt this), then why should the ISPs bother to expose and route the underlying IPv6 addresses instead of just having everything go through the NAT64 boxes?
This is not a whole solution, true.
Have you actually read what I wrote?
why would anyone demand IPv6 until there are any IPv6-only resources?
and why would anyone ever willingly deploy an IPv6-only resource if the vast majority of users will not be able to reach it?
until something breaks this stalemate how will IPv6 gain any traction?
That's the problem...
What were these supposed advantages? The same advantages that drew people to the Internet originally. Unfettered end-to-end connectivity. The opportunity to participate as an equal without having to pay through the nose. The liberating concept that you could plug in anywhere without having to worry about what kind of access you get and what the tariffs look like.
The telcos had it right to begin with. Most people just want a dumb terminal. Provider-side NAT is as good as IPv6, as long as the Youtubes still work.
That's the problem...
Of course my Grandmother needs end-to-end connecitvity!
but I don't want the end-to-end connectivity for my Grandmother.
IPv6 *is* like AMD
This is more complex than that...
I don't see why IPv4 blocks having a large cash value makes IPv6 less likely to happen - surely if the direct cost of using IPv4 address space rises considerably, that creates a strong economic drive to find a cheaper solution?
The bigger costs of staying with IPv4 for content providers are considerable - SEO (search engine optimisation) and the increased use of SSL tends to require a unique IP address for each domain, yet server side NAT or Apache virtual hosting breaks that.
This is more complex than that...
IPv6 *is* like AMD
Ad hominem attacks against DJB-- or anyone else for that matter-- don't prove anything.
The successful transitions always involved a "no regressions" philosophy where existing setups would continue to work just as well, or possibly better, after being upgraded.
Some examples of failed transitions are Commodore 64 to Commodore 128, x86 to Itanium, and the Apple ][ to the Apple III.
The failed transitions all have something in common: the people in charge underestimated the importance of having a transition plan.
Of course, you're free to disagree with me and insist that IP is fundamentally different than the other transitions described above. But at least give reasons.
IPv6 *is* like AMD
Agree 100%
As I said before, it's a matter of motivation. Figure out who the key stakeholders are, and get them on board with the transition. Give them a reason to upgrade, rather than just telling them to do it for the good of the galaxy.
Give them a reason to upgrade, rather than just telling them to do it for the good of the galaxy.
Agree 100%
> designed for backwards-compatibility of Apple II software in order to
> migrate users over. However, since Apple did not want to encourage
> continued development of the II platform, they limited its capabilities to
> emulate a basic 48 KB Apple II+ configuration, with no access to the III's
> advanced features, a restriction which actually required custom chips to
> enforce.
> was solved [by an EU directive].
> year or two.
> but why should they? Nobody is paying them and nobody punishes them...
Agree 100%
> even with a government mandate. If compatibility between IPv4 and IPv6 is
> an "insane scheme," then what is the alternative? Just don't use the
> internet for "a year or two"? Come back soon-- under construction!
We've already discussed it...
Maybe this reflects my ignorance, but I don't see why that would be easy, even with a government mandate. If compatibility between IPv4 and IPv6 is an "insane scheme," then what is the alternative? Just don't use the internet for "a year or two"? Come back soon-- under construction!
Nothing happens instantaneously. Even recalls of tainted food take a few weeks to happen. The lack of any transition plan seems very foolish.
3. IPv4 will allow ISPs to charge extra for things that are now free. For example, having your very own IP address, as opposed to NAT privileges, will one day cost you.
4. IPv4 will eventually force the use of NAT. NAT will make it even harder for customers to use P2P programs.
Well, it's a problem only for unpopular stuff. If there are 1000 people with the stuff you need/want someone will have "white IP". Yes, in the distant future it'll be a problem, but not today. Low-bandwidth P2P uses automatic relays (think Skype).Since, at least in the US, those P2P programs compete with the ISP's own "content offerings," that's all gravy to them. Comcast would love it if the new shape of the internet makes bittorrent impossible.
We've already discussed it...
Why do you need an "Internet Dictator" ?
there is no Internet Dictator who can enforce a policy like this.
Why do you need an "Internet Dictator" ?
For IPv4->IPv6 to be like DTV we'd need for it to (1) only effect one country, (2) for that country's government to mandate that all new devices starting years prior to the cutoff date be compatible with the new system and (3) for there to be a millions of dollars allocated for the purpose of giving away compatible equipment.
We've already discussed it...
IPv6 *is* like AMD
IPv6 *is* like AMD
All I keep saying is that mistakes were made. Even the best of the best do that from time to time.
Your claim boils down to this: it was not possible to design IPv6 as an upgrade to IPv4.
I'm sure you read what DJB wrote and the main idea is that things should be easily interoperable and compatible as much as possible.
But I know one thing: my ping6 still doesn't work and it should.
So, even if DJB and myself are utter nutters (which is a distinct possibility) your grand technical solution still isn't working.
Your Problem X, as you call it, is what people should have been working on in the interim. But, they couldn't work on it, because the main idea did not have interoperability and compatibility in mind, so they could not plan on how to achieve this very simple goal.