Noone, of course... and why should they?
Noone, of course... and why should they?
Posted Jan 27, 2011 4:01 UTC (Thu) by bojan (subscriber, #14302)In reply to: Noone, of course... and why should they? by lutchann
Parent article: LCA: IP address exhaustion and the end of the open net
The reason this did not happen with the current plan is because IPv6 is the "other" thing that causes endless headaches nobody wants to think about with no benefit in sight. There is no content right now, nobody is configured for it, so why risk supporting it?.
Imagine an ISP in this v4/v6 embedded scenario that did not follow what I'm describing above and persisted on IPv4 only support on their equipment. With all of the end points ready (and this is where the value of the net is), they would be simply swallowed by the ones that invested and were able to attract new customers en masse, because they could offer better connectivity (visibility of new and old, point to point comms, no NAT etc.).
Yes, it's dollars in the end. ISPs like to have customers. They would have had a lot less trouble keeping/getting those should the alternative plan been followed.
Posted Jan 27, 2011 4:38 UTC (Thu)
by lutchann (subscriber, #8872)
[Link] (94 responses)
Posted Jan 27, 2011 5:47 UTC (Thu)
by dlang (guest, #313)
[Link] (2 responses)
I still expect that we would 'run out' of 32 bit address space, and a secondary market for addresses would evolve (companies that have a class C network for their firewall/mail server will sell off their extra space for example), but as 32 bit addresses became more expensive, ISPs could invest in a small number of translating routers to run at their perimeter to resolve the pressure.
Posted Jan 27, 2011 16:57 UTC (Thu)
by lutchann (subscriber, #8872)
[Link] (1 responses)
But this didn't happen. IPv4 and NAT worked just fine, so customers didn't want IPv6, and vendors didn't implement it.
I see no reason to believe your proposed solution wouldn't have met the same fate. You can't force vendors to implement something that nobody wants or needs.
Posted Jan 27, 2011 19:42 UTC (Thu)
by dlang (guest, #313)
[Link]
for embedded devices, having to run dual stack is considerably more expensive and complicated than just running IPv4, a tweak like I suggested would have been pretty easy to add into a IPv4 stack, especially in comparison.
however look at the dates involved, NAT64 is a pretty recent development, within the last couple of years.
IPv6 and it's 'migration plan' is 20 years old, for almost all that time, any suggestion to implement anything like NAT64 would get shut down by the IPv6 people as being against the migration plan.
Posted Jan 27, 2011 5:53 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (90 responses)
Once again: all value of the network is on its edges (i.e. the hosts have the content and the clients). So, if DJB's plan was followed, all hosts would _already_ be configured for IPv6 _now_ (because he wrote that 8 years ago) and they could _talk_ IPv6 _now_. This would happen during routine OS upgrades.
With IPv4 address crunch coming, ISPs would have a clear _solution_ already in place, so they could easily put people on IPv6 addresses, because they would _just_ _work_ with the rest of the Internet _now_ (there would be no interoperability questions). Ergo, investment in IPv6 before the crunch would make sense, because everyone could talk IPv6 immediately, without involving any kind of reconfiguration, workarounds, 4to6, toredo (am I spelling this right?) and whatever else was proposed along the way.
> I'm sure they would have figured they could get along just fine without paying extra for hardware capable of carrying your hybrid protocol, just as they have with IPv6.
Sure. However, with all the hosts out there ready, configured and capable now, why would they avoid IPv6? Why would they be investing in multi layer NAT when IPv6 would already be deployed around them? Could they really risk being taken out by the ones that didn't do that?
For instance, my ISP is fully IPv6 ready on their core network, but they barely have any clients on it (just a trial). Had DJB's suggestion been followed, I'd be pinging ipv6.google.com today, without touching anything and my ISP would be in the position to eat other people's lunch if they didn't go for IPv6. After all, addresses will become tight. Putting people on real IPv6 addresses is the cheapest thing to do. And it would just work.
You know, it's like AMD64. At first, people had these things and nothing 64-bit to run. Chip makers stuck to it and little by little, people found ways of using this. IP should have been done the same way.
Posted Jan 27, 2011 7:01 UTC (Thu)
by dlang (guest, #313)
[Link] (89 responses)
this is an especially good point, the only issue is that the IPv6 plan was the same as the Intel Itanium plan "it's so much better that it doesn't matter if no existing code runs on it, everyone will be happy to change everything to get the benefits. after all, we will run out of address space with only 32 bits"
vs the AMD64 approach "it runs all existing stuff without a problem"
Posted Jan 27, 2011 8:03 UTC (Thu)
by khim (subscriber, #9252)
[Link] (65 responses)
Why do you say it's done differently? Networking hardware is perfectly capable of running IPv6 - it's just cheaper not to. It supports IPv4 perfectly and so it's used in this mode. When IPv4 addresses will be exhauseted it'll be switched io IPv6 mode - but not before.
Posted Jan 27, 2011 8:39 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (36 responses)
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.
Posted Jan 27, 2011 9:11 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (27 responses)
ipv6 just chucks ipv4 out the window.
See the difference now?
Posted Jan 27, 2011 10:06 UTC (Thu)
by khim (subscriber, #9252)
[Link] (26 responses)
With 32-bit OS? No, it can't. With 64-bit OS you can run 32 bit software but your 32-bit shared libraries can not talk with your 64-bit shared libraries - everything must be recompiled or proxy must be used. No. If update an OS on the router it can drive IPv4 and IPv6. And yes, for them to interoperate you'll need to recompile everything and/or use some proxies. Let me think about it... 1st try. Can you use new address space without core infrastructure update? 2nd try. Can you use new old clients with core infrastructure update? 3rd try. Can the old client talk with the new ones directly? Hmm... Funny... All the questions have the same answer... So... where is the difference?
Posted Jan 27, 2011 10:29 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (25 responses)
Right now, I have an OS that supports IPv6. It is useless to me without reconfiguration because I simply cannot participate in the IPv6. And why would I want to? This is a whole other network that has nothing on it. And that's because other people see the same.
In summary, amd64 is an inclusive technology. IPv6 is an island on its own.
You asked and answered a bunch of useless technical question, but you fail to see that 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? I can answer that for you if you like. Because someone wasn't thinking when they designed IPv6.
Posted Jan 27, 2011 10:46 UTC (Thu)
by khim (subscriber, #9252)
[Link] (24 responses)
Wow! Yes, I fail to see that. You see, we have the situation today: Sorry, but I try to see how 0.05% can be larger then 99% again and again - and fail to see that. Care to explain? You have strange mathematics if you think it's "the main problem with IPv6"... Because IPv6 solves bunch of other problems by going this route. Sure, it introduced inconvenience for some 0.03%-0.05% of users, but this is minor issue. On the contrary - they thought about it and it was obvious back then that it's a minor issue. The fact that it's minor issue is even more obvious today.
Posted Jan 27, 2011 11:05 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (23 responses)
The fact that 99% of users have to ask anything _is_ the failure. These 99% would have been _on_ IPv6 now, had it been for a proper plan.
Posted Jan 27, 2011 12:16 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (22 responses)
No, they wouldn't, because their ISP still would not have IPv6. What is your difficulty with seeing that?
Posted Jan 27, 2011 12:33 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (21 responses)
You are talking about the current situation as it was a success. And yet, both people talking about it had nothing but criticism for it.
But let's leave that aside. My bullshit detector tells me should common sense have been followed, I would be able to ping ipv6.google.com. And yet I cannot.
Posted Jan 27, 2011 14:17 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (20 responses)
I actually believe that with DJB's plan the situation would be *worse*. The more I look at it, the more I see in it an analogue of Greenspun's Tenth Law: it would have been an ad hoc, informally-specified, bug-ridden, slow implementation of half of IPv6. I try to imagine how its deployment would happen, and for every problem I see, the solution would be very similar to how IPv6 solved its own similar problem.
And in the end you have something with variable-sized addresses (even if it is just two sizes, it is still variable-sized), a very large number of deaggregated routes (I would expect it to cause the size of the routing tables in the default-free zone to double), and lacking several of the enhancements introduced in IPv6.
In DJB's plan, you have two classes of addresses: "new" (extended) and "old" addresses. In the same way, you have two classes of packets: "new" (with extended addresses) and "old" (normal IPv4). If a "new" address wants to communicate to an "old" address, or an "old" address wants to communicate with a "new" address, they have to use "new" packets. But to use "new" packets, EVERY SINGLE ROUTER in the path between them has to be able to understand "new" packets, else it will be dropped. How do you solve it?
A simple way is to compute a separate route which has only routers which understand "new" packets (this has to be done also for "old" destinations, because the source address could have to be "new" and thus also need the "new" packet). Now you have a situation similar to IPv6/IPv4 dual-stack.
Another option would be to tunnel automatically. Suppose you have a "new" host sending to a host with an "old" address. It has no way of knowing the host with the "old" address can understand "new" packets, so you need some crazy sort of NAT (here we see one point where DJB's solution is inferior - with the current situation, you know by the type of address whether the target host can understand it or not). But suppose that the target host understands "new" packets (or that you do not care if it does not). You send the packet, with a "new" source address, to the host with the "old" target address. Suppose some router in the path does not understand "new" packets, but your tunneling solution can work around that (by encapsulating the packet within an "old" packet, or by the construction of the packet itself). Where will the recipient send the reply to? It has to be tunneled; what will be the "old" address in the "old" outer packet? One simple solution is to embed this target within the "new" address, and now you have something similar to 6to4.
With all this, what is the incentive for ISPs, and equipment manufacturers, and in fact everyone else to upgrade to something which understands the "new" packets, "new" address format, and so on? After all, "old" addresses keep working, so why not just get a set of "old" addresses? And if everyone has a set of "old" addresses, why waste money upgrading the core? This is the same situation we have right now with IPv6.
Normal equipment upgrades will not be enough; with IPv6, we still have (as others have commented) new equipment with no IPv6 support, and IPv6 is simpler to implement. It is a separate protocol, so the code can be added separately, instead of having to change everything which touches IPv4 - which for a router is a lot of things. In fact, this is what Microsoft did with Windows XP (you have an IPv6 addon).
And 8 years is not nearly enough. Just for the end hosts (which tend to be easier), how long it took between IPv6 being designed and Windows Vista being released? As mentioned above, XP would not have it, since it could not be an addon. Worse, since it touches everything, it is possible that not even Vista would have it. Not even mentioning the backwards compatibility nightmare with legacy applications.
This all is just barely scratching the surface. It would be a fascinating experiment to actually write down the specifications for a "IPv4+" protocol, imagining how it would work in every situation. Perhaps we could even learn some things from it. It could even help with the design of future networking protocols, either as an example of what to do or as an example of what not to do. But it would not help with the current situation.
On a lighter-hearted note, http://xkcd.com/386/.
Posted Jan 27, 2011 19:47 UTC (Thu)
by dlang (guest, #313)
[Link] (16 responses)
one of the reasons that it took so long to get IPv6 into operating systems (why win98 doesn't support it for example) is because the IPv6 standard is so large and hard to get right. it doesn't just solve the address space problem (proposals to do that were rejected), it adds the kitchen sink of new a wonderful ideas that the researchers at the time thought would be great things to have in a network protocol.
Posted Jan 27, 2011 22:06 UTC (Thu)
by lutchann (subscriber, #8872)
[Link] (15 responses)
Your attitude of and suggests you really don't have much experience with IPv6. Yet you're confident that even an idiot could have come up with a simple extension to IPv4 that would have solved the address exhaustion problem and everyone would have enthusiastically adopted it. If you want to flesh out your proposed IPv4 extensions for how IPv6 "should have been", I'm sure we would have more to debate, but for now I'm going to lump you with the rest of the "I hate upgrades, why can't my vendor make a magic box to fix this for me" crowd.
Posted Jan 27, 2011 22:18 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (14 responses)
All of your comments suggest that you have way too much experience with IPv6, so you have become fond of it, although it's useless shit in it's present form. It happens. Most people just want their computers connected to the net. Yeah, I know - that common sense thing. Apologies from the commoners, your highness! ;-)
Posted Jan 27, 2011 23:08 UTC (Thu)
by lutchann (subscriber, #8872)
[Link] (13 responses)
But it's insulting for you, dlang, DJB, or anyone else to walk in after a decade or more of development and say, "You guys are idiots. I haven't really thought it through, but my solution is way better. Too bad you didn't ask for my help from the beginning, because it's too late to do it my way now, and you'll just have to live with the shame of knowing I was right and you were wrong."
I mean, seriously. That's pretty immature.
Posted Jan 27, 2011 23:25 UTC (Thu)
by dlang (guest, #313)
[Link] (9 responses)
there are even people who have been saying this (some of them very vocally) since the plan was presented, before it was voted on.
Posted Jan 27, 2011 23:38 UTC (Thu)
by khim (subscriber, #9252)
[Link] (6 responses)
Yet it was voted on and accepted by IETF. DJB's plain failed to do even that. Any transition depends on acceptance. Which plan is better: the one which was adopted by committee or the one which was adopted by few fanboys? Yes, the committee is not always right (sometimes industry implements something totally different from what the IETF or ISO proposes), but current trends show the situation clearly: IETF's plan is adopted by millions while DJB's plan was not adopted by anyone (I know few crazy fanboys who talk about it constantly but noone who ever tried to actually implement it). So if our current translation plan is "failure" DJB's plan is "failure of such an epic proportion that it's not even funny".
Posted Jan 28, 2011 0:17 UTC (Fri)
by bojan (subscriber, #14302)
[Link] (5 responses)
> So if our current translation plan is "failure" DJB's plan is "failure of such an epic proportion that it's not even funny".
So, people that were warning about the dangers of sub-prime mortgage markets, default swaps, pyramid selling etc. (i.e. the plan that was _not_ put in action) are a failure of epic proportions? Not the ones that caused the GFC? You are really funny.
Posted Jan 28, 2011 0:44 UTC (Fri)
by khim (subscriber, #9252)
[Link] (4 responses)
Sure. "The ones that caused the GFC" architected the Reaganomics to kill the USSR. Plan successed brilliantly, but GFC become unevitable at this point. "People that were warning about the dangers of sub-prime mortgage markets, default swaps, pyramid selling" and other "atrocities" just described what they see - they had no idea what they are talking about, why the structure they are talking about was created and how it works in first place. All these "atrocities" posponed the GFC by about 3-5 years, but made it more profound. Was is good trade-off? Well, it's hard to say, but it gave people few more years of respite before decade (or may be two) of suffering. Just like with IPv6: people who are moving it forward are solving real problems while clueless people like DJB complain that the plan has unintended consequences. Well, duh - but what is your plan?
Posted Jan 28, 2011 0:59 UTC (Fri)
by bojan (subscriber, #14302)
[Link] (3 responses)
Here is my plan. I have this program called ping on my system. With it, I can check whether my Internet connection works. I tried it with ipv6.google.com, but it didn't work. I'm pretty sure my connection works (it's been on for many years now). I can also ping pretty much everything out there. So, it must me some kind of a software problem.
I'd like to get a series of software upgrades so that my connection works with ipv6.google.com. Yeah, I know - I can't get that. It was a rhetorical request anyway.
So, back to the real world. My plan is to wait and see. Maybe my ISP will do something so that I can really see IPv6 world without wasting hours and hours on currently useless effort of enabling IPv6. Maybe I won't need to because they'll just whack several layers of NAT in between. I dunno.
Or maybe they'll tell me I have to do all this useless work after all. I'll have to "connect again" although I have a perfectly good connection.
That's my plan. Pretty much anything goes. Isn't it grand?
Posted Jan 28, 2011 1:33 UTC (Fri)
by cesarb (subscriber, #6266)
[Link] (2 responses)
Actually, you can. If someone made a software upgrade which installed and enabled teredo (which needs no configuration to work), your connection would work with ipv6.google.com. On Windows, there is no need to install teredo at all, just enable it - and I heard some Bittorrent clients did enable it for you automatically. And teredo works perfectly with ipv6.google.com.
Posted Jan 28, 2011 1:57 UTC (Fri)
by bojan (subscriber, #14302)
[Link] (1 responses)
Posted Jan 28, 2011 2:53 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
Actually, scrap that. The ping would not have come from my IPv4 address, so it doesn't really count.
Posted Jan 27, 2011 23:43 UTC (Thu)
by lutchann (subscriber, #8872)
[Link] (1 responses)
The very fact that no credible alternatives to IPv6 have gained traction (at least since NAT appeared in the mid-'90s) kind of suggests that the problem is not as easy to solve as you insist.
Posted Jan 28, 2011 0:12 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
People did come up with alternative ideas, they were not accepted. Sometimes such mistakes happen. For instance, we had this thing called GFC in 2008. Huge carnage all around the world, caused by a similarly bad plan.
Posted Jan 28, 2011 0:06 UTC (Fri)
by bojan (subscriber, #14302)
[Link] (2 responses)
Nobody is calling anyone an idiot. It just a bad, bad plan that didn't really work.
How do I know this? I cannot ping ipv6.google.com and I am connected to the Internet right now. It's that simple.
But, forget DJB, me, dlang and the rest of the "unimportant" folk. Cerf and Huston are saying the exact same thing, just a touch more politically correct.
To quote Wikipedia (http://en.wikipedia.org/wiki/IPv4_address_exhaustion): "By early 2012, new devices and services are expected to appear on the Internet that are only reachable by IPv6. These will only be accessible from the IPv4 Internet if older hosts that cannot implement IPv6 utilize special translator gateway services."
So, the grand plan for a clean new protocol needs "emulators" to work. Simply hilarious!
I know that things will eventually sort themselves out. They always do. That does not mean we are not allowed to criticise a bad plan.
Posted Jan 28, 2011 0:31 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
Sorry, but there is a difference: Itanium was great success for a time - before AMD started selling Opterons. When Opteron outsold Itanium is was easy to see and say that Itanium is failure - but not before. Now, where is your alternative to IPv6 with more users then IPv6 (or at least with estimates which show that it'll overcome number of IPv6 deployments any time soon). Till such alternative materializes DJBs plan is just a useless rant. Why do you say it didn't work? Where is your alternative which pushes IPv6 away? It's sad, not hilarious, but it's no different from AMD64, for example: without syscall 32bit emulation layer your old programs no longer work. And your 32bit drivers no longer work period.
Posted Jan 28, 2011 0:42 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
Hey, when did we switch to stand up comedy? I wasn't warned! Good one - love it. ;-)
> Why do you say it didn't work?
Remember that ping6 I did to ipv6.google.com? It says network unreachable. I'm pretty sure I'm connected. Not sure what's going on there... :-)
> Where is your alternative which pushes IPv6 away?
I don't want to push it away. I'd like to use it. But I can't.
> without syscall 32bit emulation layer your old programs no longer work. And your 32bit drivers no longer work period.
Yes they do. On my 32-bit OS running on amd64.
Oh, and on 64-bit, I didn't even know I had 32bit emulation layer (OK, I did, but I didn't have to know) and they still worked. Good folk at Red Hat and Microsoft did all that for me. So sad they couldn't reuse my IPv4 address to use on IPv6.
Posted Jan 27, 2011 21:54 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (2 responses)
You are saying this like it's not the case with the current plan. Every single router needs to understand the new way. Of course.
But guess what, right now, all these supposed routers have _nothing_ to route, because nobody even has an IPv6 address. Should the other plan been followed, _everyone_ would already have one (i.e. their old IPv4 address) and _everyone_ would be capable of sending such packets (current situation where I have unconfigured, parellel IPv6 stack means nothing - I cannot use it as is). And even if they do have an IPv6 address now, it's useless - there is nothing to see with IPv6.
In the alternative scenario, ISPs have an _incentive_ to be able to route IPv6 - all of their current and prospective _customers_ are on it. Right now, they don't.
So, of course they would have made sure that every single router can route. What better alternative would they have? Build layers of NAT when everyone already is on IPv6? What the hell for?
Also note that issuing IPv6 addresses to new customers is a no brainer. Issuing IPv6 addresses to new customers now is what - interoperability failure?
> Suppose you have a "new" host sending to a host with an "old" address. It has no way of knowing the host with the "old" address can understand "new" packets
Of course it has. Everyone has been upgraded already. Any destination that didn't (there would be no reason for them not to - they would get all this as part of regular updates) would be simply unreachable for "new" hosts. The amount of those would be very small indeed.
You see, one of the main problems with the current plan is that IPv6 is the "other" thing. The other network config nobody understands. The other firewall nobody understands. The other routing config nobody understands. The other thing nobody cares about. Should IPv6 have been "the" thing, people with networks that "do" things (i.e. not ISP) would automatically care for it. It would be their one and only network, they spent all of their time building. You think they would not want their ISPs to route this?
There would be no 99% of users that are supposed to ask their ISPs to give them an IPv6 address. All these folks would _be_ IPv6 users already.
> And 8 years is not nearly enough.
The problem was identified 20 years ago. DJB (who I am not particularly big fan of) wrote his piece 8 years ago as a reaction to a disastrous plan unfolding right in front of his eyes. So, your timeline is not quite right. There would have been even more time to do this.
You are saying that you see this upgrade path as the same failure. You know what, this is 100% incorrect. At least everyone would have their host configured for IPv6 _right_ _now_, even if routing wasn't done yet. At least there would be an incentive to turn the pressure up on ISPs, so that the problem gets solved. Precisely because all of the edge (where the value is) would be done and ready. In the end, ISPs have to route the traffic for their customers - what else are they going to do?
Current plan produced no such incentive. That's exactly why ISPs are talking of layers of NAT and what not.
> On a lighter-hearted note, http://xkcd.com/386/.
Yeah, unfortunately in this case, it's not you or anyone else commenting here, but rather folks supposedly in charge of making things work. Or should I say, not work. :-)
But you are right. I should not post on this topic any more. Maybe I should just acknowledge that the current situation is a wonderful success. Never mind that Cerf and Huston are telling us it's a bloody disaster. Hey, what do they now?
Posted Jan 27, 2011 23:10 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
Sure they have. They have many IPv6 addresses. One comes from EUI-64 via MAC address in your Ethernet card, another via 6to4 assignment, etc. They all are equally useless if your ISP does not support IPv6. Sure it's capable of sending packets! You can easily do that right now. The problem is: nobody is listening. How exactly addition of yet-another-useless-IPv6-address was supposed to solve the problem is mystery to me. Bingo! And DJB's plan does not change anything. Actually it's easy to see why DJB's plan is epic fail. The most IETF (or any other organization) can do is publish some specifications. I can do the same, you can do the same, everyone can write them. The question after that becomes the following: will anyone implement them or not. Guess what: noone implemented DJB specifications so they failed. It's as simple as that. I still wonder what we are discussing here. Government intervention? You don't need DJB's plan for that. Government may simple mandate switch to IPv6 by the given date. Voluntary cooperation? Does not work - DJB's plan was not implemented, right? What alternative scenario? One where DJB's plan is published under IETF name? Where is the evidence that plan rejected when it was published on DJB's site will be accepted under IETF's name? Magical letters I E T F were unable to push other plans - why do you think they may push DJB's plan? To make customers happy? Why do you think all these TCP/IP networks were built when everyone was on IPX? The answer is simple: these IPX addresses were unroutable. Guess what: these uberperfect DJB's magic addresses are just as unroutable today... well, some of them are routable: the ones which belong to IPv4 namespace. And to use them all these layers of NATs are built. Interesting idea. How come it's "no brainer"? As long as you have IPv4 addresses you don't need IPv6 in any shape or form: exist IPv4 infrastructure works just fine. But how to assign these "no brainer" DJB's IPv6 numbers when there are no more IPv4 addresses? Blatant lie. DJB published his rant. Noone upgraded. End of story. Ah... so you just ignore these poor souls who's ISP decided to ignore IPv6. Ok. if 99% is "very small indeed" then 99.7% is simply "small" so we can consider IPv6 transformation finished. Somehow I don't feel like it's the case. How do you propose to do that? By writing rants on different sites? Does not work - as your own experience shows. And IETF does not have the power to enforce anything. I don't think they'll not want to route this. I know they'll not route this. ISPs routinely ignore advances in the network technology unless they are under extreme pressure from customers. Think ECN. They are in business of making money, they are not in business of network advancement. Viewed as bit of fiction it's interesting work. Viewed as real plan it's utter failure. The very fact that DJB is rare supporter of it's plan shows how little hope there was for it's success. Sure, sometimes people miss obvious thing and it's enough for one person to find it - and then it's enthusiastically endorsed and changes the world. DJB's plan does not belong to this category - so it failed. How can this change anything? Try simple experiment: type "ipconfig" on any Windows system and press Enter. You'll see many IPv6 addresses assigned to your system. You can even use them to connect with some other systems on the same network. What you can not do is to use them to talk with other systems over the Internet - and DJB's plan can not change it. Today I have 3 IPv6 addresses (because I have three network adapters on my Windows system). DJB's plan will give me 6. Why do you think I'll want to use the last 3 more often then the first three? Note that three IPv4 address I have are 192.168.1.1, 192.168.42.3 and 10.0.0.4 so DJB's plan will give me something like 0::c0a8:101, 0::c0a8:2a02 and 0::a00:4 - and these same IPv6 addresses will be assigned to thousands (if not millions) computers in the world. What kind of use can I expect from these addresse? The edge is in pretty good shape today. Not perfect, but good. 90% of nodes are ready to use IPv6. But without changes in core all this is pointless. DJB's plan failed to change anything there. They are not talking. They are implementing them. In fact in most countries around the world NATs were part of the life lond before pointless DJB rant. DJB sceme gives these users only pointless numbers which are not useful at all. There are no such folks. There are folks which are guessing how it all should fit together, but there are noone "in charge" - that's why DJB's plan is so pointless: if someone is in charge - all that compatibility cruft is not needed, if noone is in charge it does not do anything useful at all - it just gives me useless numbers like 0::c0a8:101 which can not be used with IPv6 in any shape or form. And in both cases it's useless.
Posted Jan 28, 2011 0:19 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
I think that bit is pretty obvious. ;-)
Posted Jan 27, 2011 8:23 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (22 responses)
Chuckle! Search for Itanic here: http://lwn.net/Articles/424973/
Posted Jan 27, 2011 8:40 UTC (Thu)
by khim (subscriber, #9252)
[Link] (21 responses)
Posted Jan 27, 2011 9:15 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (16 responses)
Your logic needs some work.
Posted Jan 27, 2011 9:56 UTC (Thu)
by khim (subscriber, #9252)
[Link] (15 responses)
Well, yeah, exactly. Why? Oh, right: you look around, see all these shiny 64-bit system and perceive it as "fast and sudden uptake". Newsflash: 64bit chips are with us for more then 20 years (Alpha was introduced in 1992 and conceived much earlier). Heck: Nintendo started selling it's 64bit Nintendo64 system in 1996! But these efforts were largely ignored by mass market till AMD64 come around. Why? Because AMD64 was better? No: this was reason to choose AMD64 over Itanium. The reason why people switched to 64bit systems is because it was time where memory of typical system exhausted "32bit address space" and went beyond 4GiB. Even today there are lots of people who are using 32bit systems - and IPv4 will be used for many years after "exhaustion" of the address space. In short: IPv4 -> IPv6 transition is right on schedule and everything goes as planned. Few optimists believed they can move the world before real pain begins, but this is not how market work.
Posted Jan 27, 2011 11:12 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (14 responses)
It did not take amd64 20 years to succeed. That is all that matters here, because it was an i386 upgrade, just like that was an i286 upgrade.
Posted Jan 27, 2011 11:23 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (13 responses)
Posted Jan 27, 2011 11:29 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (12 responses)
Posted Jan 27, 2011 14:39 UTC (Thu)
by khim (subscriber, #9252)
[Link] (11 responses)
Yup. About the same time as for IPv6, actually. I don't know when most devices got IPv6 support, but it certainly happened already. Oh, you mean actual usage? Then 2006 is not even close to reality. Netbooks are still used with 32bit OSes. Heck, ChromeOS is scheduled to be released in 2011 - and it's 32bit-only! Either you use the one definition of success for x86-64 as for IPv6, namely, switch is declared "finished" when most vendors are shipping appropriate products - and then IPv6 already won and is huge success. Or you use another definition, namely switch is finished when everyone is using it in parallel to old technology - and then x86-64 is still not even half-way there.
Posted Jan 27, 2011 22:02 UTC (Thu)
by bojan (subscriber, #14302)
[Link] (10 responses)
Rubbish. If I have 32-bit software, I can use it just fine on my amd64 box. If I have an IPv4 address, I can wipe my arse with it on my IPv6 stack.
Posted Jan 27, 2011 23:17 UTC (Thu)
by khim (subscriber, #9252)
[Link] (9 responses)
Posted Jan 28, 2011 0:36 UTC (Fri)
by bojan (subscriber, #14302)
[Link] (8 responses)
Please be serious. I didn't have to touch a thing to use my old 32-bit software on 64-bit or 32-bit Linux/Windows/whatever on amd64. This was done by software upgrades (or not even that if I stayed on 32-bit OS) and other automatic means. Red Hat, Apple, Microsoft etc. did this for me and everyone else.
In contrast, if I want to have currently useless IPv6 connectivity, I have to get an address (or more than one), reconfigure my DNS, my firewalls, my services etc. And now multiply this by a few billion and you'll get the amount of effort required for IPv6 setup around the world. Then, I have to maintain these two in parallel for some time to come. Oh, and this is just so I get to the exactly same functionality I have right now on IPv4. And, I'm going to make a whole heap of mistakes in the process (it's a new thing), which will cause a whole heap of unforeseen problem on my networks.
Yeah, exactly like my amd64 transition. Not.
Black is white. Worse is better and so on.
Posted Jan 28, 2011 1:10 UTC (Fri)
by khim (subscriber, #9252)
[Link] (5 responses)
Actually there is a way to do it just like there are ways to use old 32bit drivers with 64bit OS. You need new 64bit drivers (in case of AMD64) and new IP number (in case of IPv6), but then you can use virtualization (in case of AMD64) or ecapsulation (in case of IPv6) to use your old driver or your old IP. In both cases there are a limitation: you can only use USB drivers (in case of AMD64) or TCP (in case of IPv6), but the similarity is stricking. It's not your task, that's right. Yup. They were supposed to provide new 64bit drivers which were needed to talk with old hardware (old 32bit drivers were pretty useless for that) - and they did that (eventually - see below). ISPs were supposed to privide new 128bit IP addresses - but they failed to provide them. Note that it took quite a long time before 64bit drivers become available: 64bit XP was and is pretty useless piece of crap. Let's compare it with Windows XP x64, shell we? You needed new 64bit drivers (but these were often not available), you needed replacement for all your 16bit programs, you often needed changes on network - all these just to keep the same level of functionality as with Windows XP. And now multiply this by a few million and you'll get the amount of effort required for 64bit transition. And it was not easy to setup all that at all. Well: yes and no. AMD64 transition was exactly like IPv6 transition before Windows Vista. After Windows Vista it suddenly become much easier. What happened? Monopoly power happened: Microsoft refused to certify vendors with only 32bit drivers so everyone was forced to support Windows x64. So yes, monopoly may be used to reduce transition pain - there are no doubt about it. But it does not work with IPv6 today: the only monopoly power which may force ISPs are governments (may be via FTC, may be some other government structure) and they are not interested. Yet. When/if they'll decide to mandate IPv6 support - it'll exactly like AMD64 transition. This is your tactic. You are trying to show that plan with 0.0% adoption rate is somehow better then plan with 0.3% adoption rate. Sure, 0.3% is pitiful adoption rate, but 0.0% is much worse no matter which way you are looking on it.
Posted Jan 28, 2011 1:44 UTC (Fri)
by bojan (subscriber, #14302)
[Link] (4 responses)
It's not my tactic. It's what happened. You know, a historical fact.
The common sense proposition (the one of backward compatibility) did not get accepted, ergo it never became "the plan" or "a plan" for IPv6 transition. This proposition did not get accepted by the same people that achieved the current 0.3% penetration, so the outcome of 0.0% counts against what they did too, which gives them a total score of 0.3%.
From my perspective, this is more like zero. My ping still doesn't work.
Your expose (or some of it) about various tribulations with OSes during the 64-transition is the stuff we should have been talking about in the last 10 years during the real IPv6 transition (i.e. stack upgrades). You know, real world problems that got solved, so that it would be really easy to upgrade today when the address crunch is upon us. As you've shown with the Windows example, it can be done so that it eventually becomes easy.
I love it when people keep avoiding simple, fundamental questions. There is always an elaborate, sophisticated, technical explanation, usually many pages long. In the end, the simple question asked at the beginning remains unanswered: why do people connected already cannot just stay connected?
Failure to answer that question leads to the current non-adoption of IPv6.
Posted Jan 28, 2011 2:55 UTC (Fri)
by cesarb (subscriber, #6266)
[Link] (1 responses)
"Your idea will not work. Here is why it won't work. [...] ( ) Requires immediate total cooperation from everybody at once" -- http://craphound.com/spamsolutions.txt
> There is always an elaborate, sophisticated, technical explanation, usually many pages long. In the end, the simple question asked at the beginning remains unanswered: why do people connected already cannot just stay connected?
The short answer to "why do people connected already cannot just stay connected" is "because the IPv6 network is a different network".
Of course, this is not the question you meant. What you mean to ask is, if I am understanding the massive sprawling thread forest (but please correct me if I am wrong), is something like "why could not a transition plan be made which would allow for the IPv4->IPv6 transition with no loss of connectivity at any moment". With an implied "if everyone followed DJB's plan, it would have worked".
Leaving aside DJB for a moment, this is NOT a simple question. It is also VERY technical. Either you use a heavy amount of jargon, which can be impenetrable to anyone who does not have a deep knowledge of the Internet architecture, or you use a simpler (but still very technical) language and your answer becomes quite long. To make things worse, most of it would be showing hypotheses of possible plans or parts of plans and explaining where they fail.
As to DBJ's plan, here is why it would not work: "Once these software upgrades have been done on practically every Internet computer, we'll have reached the magic moment: people can start relying on public IPv6 addresses as replacements for public IPv4 addresses."
With DJB's plan, we could only START using IPv6 addresses after PRATICALLY EVERY INTERNET COMPUTER had been upgraded to understand IPv6!
Posted Jan 28, 2011 3:54 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
Aha. The real problem right there.
> With DJB's plan, we could only START using IPv6 addresses after PRATICALLY EVERY INTERNET COMPUTER had been upgraded to understand IPv6!
As compared to now, when we cannot start using IPv6 addresses at all as well. Because not all of our computers understand IPv6 (tiny minority, not the real problem, easy to fix) _and_ they are not configured for IPv6 as well (vast majority, the real problem, will take lots of effort to fix).
Now, if we were able to deliver parallel, but not configured IPv6 stack to almost everyone, surely we could have delivered integrated, fully configured IPv6 to almost everyone already connected with IPv4.
> "For every problem there is always a solution that is simple, obvious, and wrong." -- Albert Einstein
Completely agree. A good example is the current IPv6 transition plan.
> "Your idea will not work. Here is why it won't work. [...] ( ) Requires immediate total cooperation from everybody at once"
Also agree. Essentially, everyone has to cooperate by reconfiguring their networks with brand new IPv6 addresses, DNS, firewalls, daemon configurations etc. End result? 0.3% penetration months away from IPv4 address exhaustion.
Posted Jan 28, 2011 12:01 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
Yup. DJB plan failed - it's historical fact. You still can change the history. You know: go out there, start producing new hardware and software, etc. Prove it's better. But till that happens we should accept DJB's plan as utter failure and our correct plan as moderate disaster. You seem to like "simple, fundamental questions". Here is the one for you. Ok, suppose I accept the crazy idea that DJB plan is "a way to go". Why DJB's plan failed? In other cases when the "committee in charge" produced unworkable standards and someone produced better non-standard alternative it quickly gained acceptance. Think SVG vs Flash for vector graphic or even TCP/IP vs OSI framework architecture for internetwork architecture. If DJB's plan was so perfect then why was it was only accepted by crazy fanboys on the internet forums and not by industrial players?
Posted Jan 31, 2011 16:40 UTC (Mon)
by nye (subscriber, #51576)
[Link]
*plonk*
Posted Jan 28, 2011 1:18 UTC (Fri)
by cesarb (subscriber, #6266)
[Link] (1 responses)
int on = 0;
This allows you to use a single IPv6 socket for both IPv6 and IPv4 transparently (IPv4 addresses show as IPv4-mapped IPv6 addresses).
Posted Jan 28, 2011 1:28 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
Posted Jan 27, 2011 9:15 UTC (Thu)
by dlang (guest, #313)
[Link] (2 responses)
people purchased the AMD64 systems who never intended to run 64 bit code, because the cpus were better at running 32 bit code than the prior generation, the 64 bit support was pure gravy.
Posted Jan 27, 2011 9:47 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
Yeah, but all this is true for Itanium as well - except the last part. And this last part is the reason for the Itanium failure. Today's routers also support IPv6 - but just like with AMD64 this support is usually disabled. This is why magic alternatives to IPv6 will not fly: while IPv6 support requires some configuration changes and some additional hardware (to handle higher load) other alternatives will require larger changes. ISPs do have IPv6-capable hardware (IPv6 was pure gravy when they bought routers but they just decided they don't need it), they just decided that it's cheaper for now to operate it in IPv4-only mode. And you can run IPv4-only stuff when router is dual-stack enabled. Looks more like AMD64 then Itanium to me.
Posted Jan 27, 2011 11:56 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
Posted Jan 29, 2011 17:55 UTC (Sat)
by jeleinweber (subscriber, #8326)
[Link]
Q: when shipped, will the clock rates be the same? A: no, Itanium was clocked 3x slower, negating the architectural advantage.
Q: can you buy it? A: no, Itanium was complicated and very late to market.
Q: is it cost-effective? A: no, Itanium was 10x the price of convention chips and ran Very Very Hot
This week, the high-performance crowd is chasing GPU offload, since CPU clock rates have stalled on amd64-style CPU's.
Noone, of course... and why should they?
Noone, of course... and why should they?
Noone, of course... and why should they?
Noone, of course... and why should they?
Noone, of course... and why should they?
Noone, of course... and why should they?
IPv6 *is* like AMD
quote: You know, it's like AMD64. At first, people had these things and nothing 64-bit to run. Chip makers stuck to it and little by little, people found ways of using this. IP should have been done the same way.
IPv6 *is* like AMD
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.
IPv6 *is* like AMD
IPv6 *is* like AMD
AMD64 in 64 bit mode can still run 32 bit software.
ipv6 just chucks ipv4 out the window.
See the difference now?
AMD64: No.
IPv6: No.
AMD64: Yes.
IPv6: Yes.
AMD64: No, you must use proxy.
IPv6: No, you must use proxy.IPv6 *is* like AMD
IPv6 *is* like AMD
You asked and answered a bunch of useless technical question, but you fail to see that the answer to a very simple and common question is still the main problem with IPv6.
A. For 99% of users the question is "how to convince ISP to provide IPv6". Because without support from ISP side there are no way to introduce IPv6.
B. For 0.3-0.5% of user the question is "how to use IPv6 without change in configuration". For 90% of them the answer is the answer is "there are no way to do it because all routers must be reconfigured no matter what and you have router in your own home already".Why does everyone already connected to
the net have to reconfigure and essentially run two setups?
Because someone wasn't thinking when they designed IPv6.
IPv6 *is* like AMD
IPv6 *is* like AMD
IPv6 *is* like AMD
Why DJB's plan fail
Why DJB's plan fail
Why DJB's plan fail
the IPv6 standard is so large and hard to get right
having to run dual stack is considerably more expensive and complicated than just running IPv4
Why DJB's plan fail
Why DJB's plan fail
Why DJB's plan fail
Why DJB's plan fail
Why DJB's plan fail
Why DJB's plan fail
So, people that were warning about the dangers of sub-prime mortgage markets, default swaps, pyramid selling etc. (i.e. the plan that was _not_ put in action) are a failure of epic proportions?
Not the ones that caused the GFC?
Why DJB's plan fail
Why DJB's plan fail
Why DJB's plan fail
Why DJB's plan fail
Why DJB's plan fail
Why DJB's plan fail
Why DJB's plan fail
Well, yes...
Oh, sorry. The grand plan forged 20 years ago that produced nothing thus far is a great success. Just like Itanium. :-)
Nobody is calling anyone an idiot. It just a bad, bad plan that didn't really work.
So, the grand plan for a clean new protocol needs "emulators" to work. Simply hilarious!
Well, yes...
Why DJB's plan fail
Why DJB's plan fail
But guess what, right now, all these supposed routers have _nothing_ to route, because nobody even has an IPv6 address.
Should the other plan been followed, _everyone_ would already have one (i.e. their old IPv4 address) and _everyone_ would be capable of sending such packets (current situation where I have unconfigured, parellel IPv6 stack means nothing - I cannot use it as is).
And even if they do have an IPv6 address now, it's useless - there is nothing to see with IPv6.
In the alternative scenario, ISPs have an _incentive_ to be able to route IPv6 - all of their current and prospective _customers_ are on it. Right now, they don't.
So, of course they would have made sure that every single router can route. What better alternative would they have? Build layers of NAT when everyone already is on IPv6? What the hell for?
Also note that issuing IPv6 addresses to new customers is a no brainer.
> Suppose you have a "new" host sending to a host with an "old" address. It has no way of knowing the host with the "old" address can understand "new" packets
Of course it has. Everyone has been upgraded already.Any destination that didn't (there would be no reason for them not to - they would get all this as part of regular updates) would be simply unreachable for "new" hosts.
The amount of those would be very small indeed.
Should IPv6 have been "the" thing, people with networks that "do" things (i.e. not ISP) would automatically care for it.
It would be their one and only network, they spent all of their time building. You think they would not want their ISPs to route this?
DJB (who I am not particularly big fan of) wrote his piece 8 years ago as a reaction to a disastrous plan unfolding right in front of his eyes.
At least everyone would have their host configured for IPv6 _right_ _now_, even if routing wasn't done yet.
At least there would be an incentive to turn the pressure up on ISPs, so that the problem gets solved.
Precisely because all of the edge (where the value is) would be done and ready.
Current plan produced no such incentive. That's exactly why ISPs are talking of layers of NAT and what not.
Yeah, unfortunately in this case, it's not you or anyone else commenting here, but rather folks supposedly in charge of making things work.
Why DJB's plan fail
Noone, of course... and why should they?
Everyone knows Itanic failed, but few people understand why it failed - even if it's totally obvious. Somehow people believe it failed because you needed to recompile everything to use it. Well, newsflash: AMD64 requires that too! Itanic failed because it was more expensive in 32bit mode then AMD64-based CPUs. This is exactly what will happen with crazy DJBs idea to embed IPv4 in IPv6: routers which will reject this idea will be cheaper in pure IPv4 mode and so will be used, while "brlliant ones" with "transparent IPv6 support" will be left to die like Itanic.
Heh. But have you actually lloked on the facts?
Heh. But have you actually lloked on the facts?
And your fact-checking need work too.
Just like pure 32 bit chips were cheaper than their dual-mode counterparts (that's true) and therefore widespread 64 bit uptake never happened?
Your logic needs some work.
And your fact-checking need work too.
And your fact-checking need work too.
And your fact-checking need work too.
Facts are ignored as usual...
Facts are ignored as usual...
Facts are ignored as usual...
If I have 32-bit software, I can use it just fine on my amd64 box.
Only if you enable 32bit syscall emulation.If I have an IPv4 address, I can wipe my arse with it on my IPv6 stack.
Of course. It's the same as Linux kernel with 32bit syscall emulation disabled - you can "wipe your arse" with 32bit programs in these cases too.
Facts are ignored as usual...
Yet another stupid rant.
Amazing. So, tell me, how does my software vendor enable "32bit syscall emulation" on my IPv6 stack to use my IPv4 address there? They can't. There is no way to do it.
I didn't have to touch a thing to use my old 32-bit software on 64-bit or 32-bit Linux/Windows/whatever on amd64.
This was done by software upgrades (or not even that if I stayed on 32-bit OS) and other automatic means. Red Hat, Apple, Microsoft etc. did this for me and everyone else.
In contrast, if I want to have currently useless IPv6 connectivity, I have to get an address (or more than one), reconfigure my DNS, my firewalls, my services etc. And now multiply this by a few billion and you'll get the amount of effort required for IPv6 setup around the world. Then, I have to maintain these two in parallel for some time to come. Oh, and this is just so I get to the exactly same functionality I have right now on IPv4. And, I'm going to make a whole heap of mistakes in the process (it's a new thing), which will cause a whole heap of unforeseen problem on my networks.
Yeah, exactly like my amd64 transition. Not.
Black is white. Worse is better and so on.
Yet another stupid rant.
Yet another stupid rant.
Yet another stupid rant.
Right. DJB plan failed. Other plans have minimal success.
> This is your tactic. You are trying to show that plan with 0.0% adoption rate is somehow better then plan with 0.3% adoption rate. Sure, 0.3% is pitiful adoption rate, but 0.0% is much worse no matter which way you are looking on it.
It's not my tactic. It's what happened. You know, a historical fact.I love it when people keep avoiding simple, fundamental questions. There is always an elaborate, sophisticated, technical explanation, usually many pages long. In the end, the simple question asked at the beginning remains unanswered: why do people connected already cannot just stay connected?
Right. DJB plan failed. Other plans have minimal success.
Facts are ignored as usual...
setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, &on, sizeof(on));
Facts are ignored as usual...
Heh. But have you actually lloked on the facts?
That's right.
That's right.
Itanic