|
|
Log in / Subscribe / Register

LCA: IP address exhaustion and the end of the open net

By Jonathan Corbet
January 26, 2011
Geoff Huston is the Chief Scientist at the Asia Pacific Network Information Centre. His frank linux.conf.au 2011 keynote took a rather different tack than Vint Cerf's talk did the day before. According to Geoff, Vint is "a professional optimist." Geoff was not even slightly optimistic; he sees a difficult period coming for the net; unless things happen impossibly quickly, the open net that we often take for granted may be gone forevermore.

The net, Geoff said, is based on two "accidental technologies": Unix and packet switching. Both were new at their time, and both benefited from open-source reference implementations. That openness created a network which was accessible, neutral, extensible, and commercially exploitable. [Geoff Huston] As a result, proprietary protocols and systems died, and we now have a "networking monoculture" where TCP/IP dominates everything. Openness was the key: IPv4 was as mediocre as any other networking technology at that time. It won not through technical superiority, but because it was open.

But staying open can be a real problem. According to Geoff, we're about to see "another fight of titans" over the future of the net; it's not at all clear that we'll still have an open net five years from now. Useful technologies are not static, they change in response to the world around them. Uses of technologies change: nobody expected all the mobile networking users that we now have; otherwise we wouldn't be in the situation we're in where, among other things, "TCP over wireless is crap."

There are many challenges coming. Network neutrality will be a big fight, especially in the US. We're seeing more next-generation networks based around proprietary technologies. Mobile services tend to be based on patent-encumbered, closed applications. Attempts to bundle multiple types of services - phone, television, Internet, etc. - are pushing providers toward closed models.

The real problem

But the biggest single challenge by far is the simple fact that we are out of IP addresses. There were 190 million IP addresses allocated in 2009, and 249 million allocated in 2010. There are very few addresses left at this time: IANA will run out of IPv4 addresses in early February, and the regional authorities will start running out in July. The game is over. Without open addressing, we don't have an open network that anybody can join. That, he said, is "a bit of a bummer."

This problem was foreseen back in 1990; in response, a nice plan - IPv6 - was developed to ensure that we would never run out of network addresses. That plan assumed that the transition to IPv6 would be well underway by the time that IPv4 addresses were exhausted. Now that we're at that point, how is that plan going? Badly: currently 0.3% of the systems on the net are running IPv6. So, Geoff said, we're now in a position where we have to do a full transition to IPv6 in about seven months - is that feasible?

To make that transition, we'll have to do more than assign IPv6 addresses to systems. This technology will have to be deployed across something like 1.8 billion people, hundreds of millions of routers, and more. There's lots of fun system administration work to be done; think about all of the firewall configuration scripts which need to be rewritten. Geoff's question to the audience was clear: "you've got 200 days to get this done - what are you doing here??"

Even if the transition can be done in time, there's another little problem: the user experience of IPv6 is poor. It's slow, and often unreliable. Are we really going to go through 200 days of panic to get to a situation which is, from a user point of view, worse than what we have now? Geoff concludes that IPv6 is simply not the answer in that time frame - that transition is not going to happen. So what will we do instead?

One commonly-suggested approach is to make much heavier use of network address translation (NAT) in routers. A network sitting behind a NAT router does not have globally-visible addresses; hiding large parts of the net behind multiple layers of NAT can thus reduce the pressure on the address space. But it's not quite that simple.

[Geoff Huston] Currently, NAT routers are an externalized cost for Internet service providers; they are run by customers and ISP's need not worry about them. Adding more layers of NAT will force ISPs to install those routers. And, Geoff said, we're not talking about little NAT routers - they have to be really big NAT routers which cannot fail. They will not be cheap. Even then, there are problems: multiple levels of NAT will break applications which have been carefully crafted to work around a single NAT router. How NAT routers will play together is unclear - the IETF refused to standardize NAT, so every NAT implementation is creative in its own way.

It gets worse: adding more layers of NAT will break the net in fundamental ways. Every connection through a NAT router requires a port on that router; a single web browser can open several connections in an attempt to speed page loading. A large NAT router will have to handle large numbers of connections simultaneously, to the point that it will run out of port numbers. Ports numbers are only 16 bits, after all. So ISPs are going to have to think about how many ports they will make available to each customer; that number will converge toward "one" as the pressure grows. Our aperture to the net, Geoff said, is shrinking.

So perhaps we're back to IPv6, somehow. But there is no compatibility between IPv4 and IPv6, so systems will have to run both protocols during the transition. The transition plan, after all, assumed that it would be completed before IPv4 addresses ran out. But that plan did not work; it was, Geoff said, "economic rubbish." But we're going to have to live with the consequences, which include running dual stacks for a transition period that, he thinks, could easily take ten years.

During that time, we're going to have to figure out how to make our existing IPv4 addresses last longer. Those addresses, he said, are going to become quite a bit more expensive. There will be much more use of NAT, and, perhaps, better use of current private addresses. Rationing policies will be put into place, and governmental regulation may well come into play. And, meanwhile, we know very little about the future we're heading into. TCP/IP is a monoculture, there is nothing to replace it. We don't know how long the transition will take, we don't know who the winners and losers will be, and we don't know the cost. We live in interesting times.

An end to openness

Geoff worried that, in the end, we may never get to the point where we have a new, IPv6 network with the same degree of openness we have now. Instead, we may be heading toward a world where we have privatized large parts of the address space. The problem is this: the companies which have lost the most as the result of the explosion of the Internet - the carriers - are now the companies which are expected to fund and implement the transition [Geoff Huston] to IPv6. They are the ones who have to make the investment to bring this future around; will they really spend their money to make their future worse? These companies have no motivation to create a new, open network.

So what about the companies which have benefited from the open net: companies like Google, Amazon, and eBay? They are not going to rescue us either for one simple reason: they are now incumbents. They have no incentive to spend money which will serve mainly to enable more competitors. They are in a position where they can pay whatever it takes to get the address space they need; a high cost to be on the net, is, for them, a welcome barrier to entry that will keep competition down. We should not expect help from that direction.

So perhaps it is the consumers who have to pay for this transition. But Geoff did not see that as being realistic either. Who is going to pay $20/month more for a dual-stack network which works worse than the one they have now? If one ISP attempts to impose such a charge, customers will flee to a competitor which does not. Consumers will not fund the change.

So the future looks dark. The longer we toy with disaster, Geoff said, the more likely it is that the real loser will be openness. It is not at all obvious that we'll continue to have an open net in the future. He doesn't like that scenario; it is, he said, the worst possible outcome. We all have to get out there, get moving, and fix this problem.

One of the questions asked was: what can we do? His answer was that we really need to make better software: "IPv6 sucks" currently. Whenever IPv6 is used, performance goes down the drain. Nobody has yet done the work to make the implementations truly robust and fast. As a result, even systems which are capable of speaking both protocols will try to use IPv4 first; otherwise, the user experience is terrible. Until we fix that problem, it's hard to see how the transition can go ahead.

Index entries for this article
KernelNetworking/IPv6
Conferencelinux.conf.au/2011

to post comments

Unreliable?

Posted Jan 26, 2011 13:11 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]

Geoff talked a lot about IPv6 being 'unreliable', and spoke of the 'white screen of death' which you get in your web browser when trying to connect to a dual-stack server via IPv6 first, when you don't actually have working IPv6 connectivity. As he says, it does indeed take quite a while for the connection to fail after a number of SYN packets don't get responses, and for the stack to fall back to using Legacy IP.

But there are two important things to note about this failure mode that he made so much of:

  • It's rare. According to Wikipedia's testing it's less than half a percent of clients that would screw up by trying IPv6 if an AAAA record was advertised, when they don't really have IPv6 connectivity
  • It's a local problem on the client side. It's just the same as having a rogue DHCP server, giving you a false IP address and routes and thus breaking your Legacy IP connectivity. As soon as people start noticing their local problem because sites like Google, Facebook etc. just go ahead and publish AAAA records for their main hostnames instead of wimping out and using separate hostnames, even that 0.40% will be able to fix things fairly quickly.
As Legacy IP becomes afflicted with more and more levels of NAT, its reliability will fall; as the reliability of IPv6 increases because people have fixed their rogue route advertisements. The dystopic picture that Geoff paints of "Enable IPv6, see the white screen of death" will become even less realistic than it is today.

In the last decade or so that I've been running IPv6, I've lost count of the number of times that it has saved my connectivity.

Even at big conferences with only a single level of NAT, I've seen port-space exhaustion (and NAT table exhaustion) cause connectivity problems for the Legacy IP users, while those using IPv6 have been able to connect just fine.

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 13:23 UTC (Wed) by kleptog (subscriber, #1183) [Link] (12 responses)

The port number issue is interesting. I've seen situations where the same (src ip, src port, dest ip, dest port) are reused within 3 seconds of the FIN from the first connection coming past. A large corporation NATted behind a single IP. Luckily the sequence numbers are far enough apart to avoid problems, but I'm sure it's violating some RFC.

My experience with IPv6 has been pretty good, but it's a biased view since I haven't managed to get Firefox to open an IPv6 connection yet. Everything else works pretty good (except there's so few IPv6 sites around).

I'm disappointed the ISPs are so reluctant to do anything to help, and surprised that consumer equipment hasn't just worked around the problem using automatic 6to4 tunnelling.

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 13:37 UTC (Wed) by foom (subscriber, #14868) [Link] (7 responses)

> I'm disappointed the ISPs are so reluctant to do anything to help, and surprised that consumer equipment hasn't just worked around the problem using automatic 6to4 tunnelling.

...Remember when Apple did *just that* by default with the Airport wireless router and got flamed to a crisp for it?

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 13:48 UTC (Wed) by kleptog (subscriber, #1183) [Link] (6 responses)

From what I can find they got flamed because they provided no firewall in the default config. But were there problems besides that?

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 14:43 UTC (Wed) by foom (subscriber, #14868) [Link] (5 responses)

Yes, they allowed incoming TCP (and every other kind of) connections in IPv6 -- restoring End-to-End connectivity, just what everyone wanted, right? Oops.

Then they asked IETF what they should've done instead. IETF said "duh you need a stateful firewall"; Apple said "but wait? you mean we still need all that crappy NAT-code, just without translating the network address? And didn't you decline to standardize on what exactly such a thing needs?". Argument ensues over how mean Apple is for daring to say that stateful firewalls have the same impacts on end-to-end connectivity as NAT...or something like that.

In order to build a in-network firewall, you need to have a application-level understanding for a bunch of different protocols (FTP, IRC, SIP, H323, PPTP, RTSP, at least). And you need a protocol for endpoints to ask the firewall to pretty please actually allow it to allow incoming connections on some port (so that bittorrent and similar protocols requiring incoming connections work)

Both of these have existed for IPv4 for a long time, but IETF had declined to standardize them. And neither NAT-PMP or uPNP (at that time -- I don't know if they do now) supported IPv6 addresses.

And at least NAT-PMP *intentionally* only supported IPv4, because at the time they figured it was just a bad hack before residential gateways could let endpoints handle their own traffic again with IPv6, and restore the End-to-End principle like in the good old days.

I dunno what the current status is...I think there's still no such protocol support.

Some more history:
http://blog.karppinen.fi/2007/04/turning-a-feature-into-a...

The Apple guy in question has since taken it upon himself to write down in RFC form what such a home router should be expected to do...apparently said RFC was just approved two days ago, after over 3 years of discussions. And I'll note also that it's somehow turned from a "BCP" into "Informational", too.
http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-se...
http://www.rfc-editor.org/rfc/rfc6092.txt

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 16:14 UTC (Wed) by spaetz (guest, #32870) [Link] (1 responses)

> http://www.rfc-editor.org/rfc/rfc6092.txt

Ironically this resolves to an ipv6 address here which does not respond to a ping (other ipv6 sites work just fine). So loading that page took 5 minutes until it fell back to ipv4. :-)

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 17:55 UTC (Wed) by the2masters (guest, #27656) [Link]

works here

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 18:38 UTC (Wed) by foom (subscriber, #14868) [Link] (2 responses)

Oh, and in case it wasn't clear: the lack of uPNP/NAT-PMP IPv6 makes using IPv6 through such a stateful filter a *WORSE* experience than using IPv4 through NAT currently is.

Applications on home endpoints still can't directly accept incoming connections (wasn't the like the whole point of IPv6?), and unlike with IPv4 there was (is?) no widely-accepted/implemented protocol to allow random endpoints to request such access.

IPv6 for the home, if we're to have a stateful firewall between all users and the internet, seems basically useless -- it doesn't enable applications like video chat or p2p filesharing to work any easier or more reliably than on IPv4...

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 23:37 UTC (Wed) by drag (guest, #31333) [Link]

> IPv6 for the home, if we're to have a stateful firewall between all users and the internet, seems basically useless -- it doesn't enable applications like video chat or p2p filesharing to work any easier or more reliably than on IPv4...

If you have more then one person using the same protocol it can make all the difference in the world.

LCA: IP address exhaustion and the end of the open net

Posted Jan 28, 2011 11:27 UTC (Fri) by i3839 (guest, #31386) [Link]

That is total rubbish.

The way for an application to open an incoming port is, well, to open a socket on that port and listen to it. That's it. It magically works with no stupidity going on.

People have forgotten this because NAT madness and overzealous firewalls have entrenched themselves deeply enough.

You only need a firewall if you, as a user, want to restrict who and what may access what or who else. If applications can change that policy then you can as well have no firewall at all.

Firewalls are overrated. In this case Apple did the right thing and should have ignored all the whiners.

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 19:01 UTC (Wed) by dlang (guest, #313) [Link] (3 responses)

a large part of the reason why consumer equipment doesn't support NAT64 is that for many, many years every time someone suggested NAT in relation to IPv6 the response from the IPv6 people was 'NAT is evil, NAT is not needed, NAT is not allowed on an IPv6 network, go away until you agree with us'

it's only in the last year or two that I have seen people admitting that there will need to be NAT between IPv4 and IPv6

LCA: IP address exhaustion and the end of the open net

Posted Jan 27, 2011 14:25 UTC (Thu) by RobSeace (subscriber, #4435) [Link] (2 responses)

Well, NAT is evil, and should be abolished, yes... However, as long as there are still IPv4 hosts that need to be interacted with, there will need to be some kind of NAT for dealing with them... But, pure IPv6 hosts don't need to be behind NAT (from other IPv6 hosts); that's the point people tried to make... And, the argument was always with people who wanted NAT as a firewall replacement, instead of being bothered to just use a real firewall... NAT is a kluge to solve a specific problem; one which no longer exists if the world is all on IPv6... In that world, indeed no one should ever have any kind of NAT anywhere... Of course, I'm not sure I'll ever live to see that world... ;-/

role of NAT in the v4 -> v6 transition

Posted Jan 29, 2011 17:22 UTC (Sat) by jeleinweber (subscriber, #8326) [Link] (1 responses)

The IETF and IAB still hate the idea of NAT66, they want to return to the end-to-end transparency of the 1980's, once again allowing protocol innovation to flourish. See e.g. RFC-5902 from last July.

NAT46 such as NAT-PT has been given up on; e.g. RFC-4966. In addition to all the usual NAT issues you have the killer problem of being unable to reliably fake DNS A records for servers which have AAAA only at ISP scales. The implication is that v4-only clients will be cut off from v6-only services. Once v6-only services become interesting, consumers will demand v6 from their ISP's.

It's easy to dual-stack clients, except that we are out of v4 addresses. So new clients with public v6 trying to access the legacy v4 network have two basic options, both involving NAT translation. You could ditch v4 and do some kind of NAT64 gateway. That is probably going to lose out to dual-stack-lite, where instead you give the client private v4, tunnel it over v6 to a carrier NAT44, and only have to eat the usual NAT issues, not NAT plus the protocol translation issues. Expect at lot of dual-stack-lite on cell phone networks and in Asia.

While we are waiting for ISP's to finish eradicating the v4-only DSLAMS and CMTS from their networks in the US and Europe, expect a lot of 6rd, where clients with upgraded dual-stack modems and upgraded wifi routers use protocol 41 tunnels over v4 between their modem and a gateway at the ISP. This looks almost like native v6 at the client, incrementally and easily migrates to full native v6 as the ISP fixes its pipes, and is cheap and quick to deploy.

Recap: ISP's need to offer v6 to their business customers yesterday, and 6rd or native v6 to their consumers soon. Businesses need to dual stack their services ASAP, or the new v6 customers will have a terrible experience, the legacy v4 customers won't be able to reach them, and the v4 refugees from a degrading v4 multiple-NAT morass won't have any refuge to run to. Consumers can wait until the v6 availability improves, say 2013, and then go dual-stack in whatever fashion, lite or heavy, their ISP allows.

Teredo is only for masochists.

role of NAT in the v4 -> v6 transition

Posted Jan 29, 2011 22:01 UTC (Sat) by dlang (guest, #313) [Link]

what company is going to be willing to setup an IPv6 only service that 99.7% of the end-users will not be able to reach?

give it a couple of years with a lot of publicity and that number may drop down to 90% (a 30x increase in the number of people with usable IPv6) and the question remains.

one of the problems with killing off IE6 is that there are sill 20-30% (approximatly, I've not looked it up recently) users who have that browser, and companies are not willing to refuse to serve those customers. until the number of IPv4 only users drops to a number significantly lower than the current number of IE6 users, businesses won't be willing to cut them off.

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 13:30 UTC (Wed) by zander76 (guest, #6889) [Link] (15 responses)

The original idea of the internet was a way of getting all the computers to connect. At this point that issues has been solved so its time to go back to the original design concept and rethink it from the ground up.

Breaking the bound between the addressing stack and the control stack leaves some interesting possibilities.

Open addressing stack - IPv4, IPv6, Mac Addressing or whatever could all be used in harmony. The ISP would need to supply you with some form of addressing stack. How this would or could work is a difficult problem to solve but would open up the chance for the best technology to win.

Control stack - TCP, UDP or whatever could be used as the control layer over top of the addressing space. Some additional features like multicast would be a huge help.

Domain names - I don't even know where to start with this issue. It's largely out of control. Virtual hosts are certainly not the answer to this. One name should be bound to 1 address and if you want more then one name then you will need to use more addresses. The names are free the addresses aren't.

At this point most of the world is connected to the network or has access to the network. Distributed networking like torrents might be a better place to start looking for the answers.

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 14:47 UTC (Wed) by kleptog (subscriber, #1183) [Link] (14 responses)

Open addressing stack - IPv4, IPv6, Mac Addressing or whatever could all be used in harmony. The ISP would need to supply you with some form of addressing stack. How this would or could work is a difficult problem to solve but would open up the chance for the best technology to win.
I don't see how this can possibly work. For any form of addressing both endpoints and every router in between need to understand the addressing format and how to route it. The current internet actually works this way, but it's situation with a huge natural monopoly advantage. Once you have one format supported by almost everyone, there is zero point developing anything else. IPv4 simply wiped the alternatives out. There is simply no economic reason to invest in anything else.

What you need is carrots. News sites giving free access to people coming over IPv6, for example. Get one thing people really want (something like wikileaks maybe?), make it available free on IPv6 only and tell people to complain to their ISP when it doesn't work. We need more carrots, unfortunately I can't think of any good ones?

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 15:12 UTC (Wed) by fuhchee (subscriber, #40059) [Link] (13 responses)

"Get one thing people really want (something like wikileaks maybe?), make it available free on IPv6 only"

That reminds me of one IPv6 fan giving a talk, trying to motivate the audience by saying that there is some *uncensored usenet server* in Europe, only via ipv6. The embarrassing implications induced a few groans.

"We need more carrots,"

Why? If the IPv4 sky is really falling, a collapse-in-progress should motivate all those whose livelihoods depend on it.

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 15:29 UTC (Wed) by drag (guest, #31333) [Link] (7 responses)

The last of the major IPv4 blocks will get allocated by Feburary.

RIRs should run out of blocks to allocate ISPs by the end of summer.

After that is only carrier grade nat. Brave new protocols like NAT444.

NAT behind NAT behind NAT on the ISP level. You won't be limited by bandwdith anymore... you'll be limited by the number of connections that your ISP routers can maintain in memory and how fast they can process it.

You can kiss bittorrent goodbye. AJAX will run like shit and fail regularly. RSS feeds will start failing.

Hope you get used to getting your email in batches.

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 20:30 UTC (Wed) by dlang (guest, #313) [Link] (3 responses)

after that is buying IP addresses from other companies who suddenly find that they don't really need all the addresses that they are using (because they have all their desktops behind firewalls instead of exposed directly to the Internet like they were in 'the good old days')

LCA: IP address exhaustion and the end of the open net

Posted Jan 27, 2011 3:39 UTC (Thu) by thedevil (guest, #32913) [Link] (2 responses)

"after that is buying IP addresses from other companies who suddenly
find that they don't really need all the addresses that they are using
(because they have all their desktops behind firewalls instead of
exposed directly to the Internet like they were in 'the good old days')"

No kidding. One thing about the IPv4 exhaustion is that the allocations
are extremely sparse. There must be a huge number of class C
allocations to small businesses which ony use 10 or so unNATed addresses
each. The rational thing for the ISPs is to start squeezing all this
sponginess by providing such price breaks.

What is very unsettling about this situation is that it's a preview of
what will hit later this century with respect to fuel, and even more
ominously, water. So far, the "free" market hasn't handled it so well,
has it?

LCA: IP address exhaustion and the end of the open net

Posted Jan 27, 2011 5:51 UTC (Thu) by dlang (guest, #313) [Link]

actually, I think the free market is handling things fairly well with IPv4 addresses. just not the way the IPv6 advocates wish they would handle it.

Straight ratio looks bad, yes,

Posted Jan 27, 2011 10:50 UTC (Thu) by jthill (subscriber, #56558) [Link]

but see RFC 3194.

LCA: IP address exhaustion and the end of the open net

Posted Jan 27, 2011 0:36 UTC (Thu) by motk (subscriber, #51120) [Link] (1 responses)

UUCP will save us!

LCA: IP address exhaustion and the end of the open net

Posted Jan 27, 2011 9:25 UTC (Thu) by bronson (subscriber, #4806) [Link]

Now that would be awesome.

*bronson starts dusting off his Kermit skills...

LCA: IP address exhaustion and the end of the open net

Posted Jan 28, 2011 6:22 UTC (Fri) by butlerm (subscriber, #13312) [Link]

NAT444...NAT behind NAT behind NAT on the ISP level.

NAT444 is two levels of NAT, not three. Each digit refers to an addressing domain, not a translation layer. The translation layers are the invisible boundaries between the digits. In NAT444, all the addressing domains are IPv4, hence three "4"s.

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 15:44 UTC (Wed) by kleptog (subscriber, #1183) [Link] (4 responses)

The problem is, I think, that the running out of IPs has no effect on current businesses. Everyone who already has a block doesn't care one way or the other.

Put another way, running out of IP addresses is going to increase the pressure, but *not* on the group that's holding out (the ISPs). Throw in a layer of NAT, voila! It will just increase pressure on those trying to start new services.

Sorry, but no...

Posted Jan 27, 2011 0:30 UTC (Thu) by khim (subscriber, #9252) [Link]

The problem is, I think, that the running out of IPs has no effect on current businesses. Everyone who already has a block doesn't care one way or the other.

This is pretty naive approach. Sure, today people don't care because they expect to keep them, but... why are they so sure? At first people will start buying unneeded addresses, then they will start hijaking them, then IPv4 addresses will have a real price (they already have in many cases - only some organizations which got them early in bulk can ignore these problems... for now), then eventully the pain will be large enough to force IPv4-to-IPv6 migration.

Final exhaustion of IPv4 address pool is the beginning of migration process, not the end!

LCA: IP address exhaustion and the end of the open net

Posted Jan 29, 2011 17:04 UTC (Sat) by jeleinweber (subscriber, #8326) [Link] (2 responses)

> running out of IPs has no effect on current businesses...

This was historically true, even in the US. The future is looking different. If they are accessed by mobile devices (4G rollouts are all dual-stack-lite, i.e. native v6, carrier NAT for the legacy v4 stuff), or have an asian supply chain, or a government contract - they are going to need v6 externally ASAP. Those who linger on legacy v4 are going to be dealing with a degrading access experience after late 2012, while the v6 folks will be getting improvements instead. So businesses need to work on v6. Given that there aren't many v6-only services yet, consumers should just sit on their hands for 6-18 months while their ISP's and the modem & wifi vendors get their act together.

The timeline I'm expecting is along the lines of IANA runs out of v4 in February, v4-exhaustion makes the front page of the mainstream press, and the CEO's all panic. Northern hemisphere RIR's run out by late fall, ISP's mostly run out in 2012. That makes 2013 the real year of the "IPocalypse", as new v4 will be non-existent but v6 won't be universally available world-wide until, say, 2015. The tipping point is when v6 is broadly available, and something shiny is v6-only; this could be the 2014 Christmas holiday shopping season, brought on by some nifty asian electronic toy that ten year olds want. Three years after the tipping point, say 2017, figure 99% of internet traffic is v6. And while there wasn't an economic incentive to deploy v6 prior to v4 exhaustion, the roughly 18:1 decrease in backbone router CPU load for v6-only gives a heck of an incentive to ditch v4, so figure the tier-1 ISP's will schedule a flag day for 3 years after that, and turn off v4-routing around 2020. After which the smidge of remaining v4 will have to be tunneled over v6 until the last v4 device is retired, around 2036. Of course, everyone who has predicted the future of v6 has been wrong, so take my views with a grain (or even a peck) of salt.

The analogies I'm currently favoring are that v4->v6 is like either the conversion from analog to digital TV, or to standard gauge railroad tracks. It's not like Y2K for consumers: there is no hard deadline and it will be visible in that they'll have to buy new routers and modems. It's a little like Y2K for programmers, in that they'll have to port to new API's and cope with longer addresses in different formats.

LCA: IP address exhaustion and the end of the open net

Posted Jan 29, 2011 21:56 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

that 'asian toy' would have to be locked into using an IPv6-only website. but there's no good reason to have such a site.

yes the freely allocated IP addresses will run out, but that's not nearly the same thing as saying that all those IP addresses are going to be in use.

there are a lot of companies that have public IP addresses that aren't using all of them (and some older companies who got involved early who are using all of them, but would be happy to restructure their networks to not use them if they could sell them off)

there are also a lot of options out there to reduce the number of IP addresses in use, each with a different set of trade-offs. These include NAT (allowing end-users who have signed contracts saying that they are not going to run servers anyway to share public addresses), SNI (allowing servers running SSL to share an IP address), etc. implementing those things will free up more addresses.

yes, the ISPs may want to get companies to change the IP addresses that they are using so that they can have less fragmentation in their router tables, but that's a simple cost-benefit equation for both sides, what incentives will the ISP give companies to change their addresses (for many companies this can is probably surprisingly low, a free month of service would probably be enough)

I don't think that you are going to start seeing IPv6 only resources (other than by the IPv6 advocates) appearing anytime soon, i would be surprised if they were as close as 2015, and I would not be surprised if they were out as long as 2020 or later.

right now, the only real value that Ipv6 gives is in a private network as you don't have to contend with the limited RFC private addresses (and this can include ISPs using NAT464 to connect customers to the Internet passing over IPv6 on their internal network) for the endpoints it's really no value

LCA: IP address exhaustion and the end of the open net

Posted Jan 29, 2011 22:41 UTC (Sat) by dlang (guest, #313) [Link]

by the way, in case it's not clear, I agree with you on one point, users will demand IPv6 when there are IPv6-only resources that they want to access.

the difference is that you think that there will be such resources, and I don't see any valid reason for such resources to exist.

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 14:01 UTC (Wed) by ballombe (subscriber, #9523) [Link]

I use IPv6 everyday and it is neither slow nor unreliable.

What's so bad about IPv6?

Posted Jan 26, 2011 14:42 UTC (Wed) by dskoll (subscriber, #1630) [Link] (16 responses)

Like many other posters, I'm mystified by the notion that IPv6 is "slow" or "unreliable". I've found it just as fast and reliable as IPv4. Huston says "Whenever IPv6 is used, performance goes down the drain" without offering any evidence to back up that claim.

What's so bad about IPv6?

Posted Jan 26, 2011 15:08 UTC (Wed) by nettings (subscriber, #429) [Link] (13 responses)

I guess he was talking about big-iron border gateways. I could imagine that their performance suffers compared to IPv4 simply because of the longer addresses and more bookkeeping required. Cache tables and memory bandwidth don't magically increase when you switch.
And since this kind of hardware is a huge investment, it tends to be run at high loads even for standard use cases (i.e. IPv4). Switch to v6 and you suddenly max out your infrastructure. Sure, you could buy new routers, but where is the economic sense in that?

What's so bad about IPv6?

Posted Jan 26, 2011 15:11 UTC (Wed) by dskoll (subscriber, #1630) [Link] (12 responses)

I guess he was talking about big-iron border gateways. I could imagine that their performance suffers compared to IPv4 simply because of the longer addresses and more bookkeeping required.

OK, possibly, but I thought IPv6 was designed to simplify border routers. The addresses are 4x as large as IPv4, but the header is only 2x. And routers don't need to recompute checksums when decrementing the hop counter. See http://en.wikipedia.org/wiki/Ipv6#Simplified_processing_by_routers

What's so bad about IPv6?

Posted Jan 26, 2011 15:43 UTC (Wed) by drag (guest, #31333) [Link] (11 responses)

Yes.

IPv6 has massively simpler routing requirements then IPv6. Any core router will be able to handle the routing for the entire IPv6 routing space with a total of 4000 routes. Nowadays IPv4 requires 36000 or more.

The address space is also designed to be able to handled efficiently by 16 bit processors. The idea being, of course, that you would have most every electronic computer-controlled device with some sort of IPv6 support.

If anything IPv6 should provide a boost in performance over IPv4. It's just much more efficient since network addressing is much better designed.

What's so bad about IPv6?

Posted Jan 26, 2011 16:00 UTC (Wed) by hmh (subscriber, #3838) [Link] (9 responses)

That, of course, assume you have the ASICs/switching fabric able to actually grok IPv6 enough to hardware-route it. And switches that can understand IPv6 multicasting. And protections against the insanely idiotic "rlogin-style" stupidity that is IPv6 auto-configuration.

And therein is the real problem. Replacing the old infrastructure is the single largest problem we face when deploying IPv6.

What's so bad about IPv6?

Posted Jan 26, 2011 16:08 UTC (Wed) by drag (guest, #31333) [Link] (6 responses)

Most everything that has been deployed since 2004 should have IPv6 support. Most people's network supports it even if they don't know it.

What's so bad about IPv6?

Posted Jan 26, 2011 16:43 UTC (Wed) by mstefani (guest, #31644) [Link]

Should. How well is a different story.

Some devices will support it only "in software"; hitting the CPU on a busy network devices is basically "game over". Other devices support IPv6 only in a limited way, e.g. no VRF support for IPv6. Of course for those type of problems the network vendors are more than happy to sell you new hardware for $$$ with a questionable ROI. But for some features your network might rely upon all you will get back is a "IPv6 support will be added next year"...

In theory, theory and practice are the same. In practice, they are not.

Posted Jan 26, 2011 17:36 UTC (Wed) by khim (subscriber, #9252) [Link] (3 responses)

No, they don't support it. It's easy, really: you claim that IPv6 is simpler to process and so it should provide performance boost. But let's check the facts

up to 60 million packets per second (Mpps) of IPv4 unicast forwarding traffic and up to 30 Mpps of IPv6 unicast forwarding traffic

Oops? Looks like simple and logical way to save half of equipment is to just disable IPv6 - and this is what ISPs are doing... It does not matter if hardware has support for IPv6 or not if it's disabled.

In theory, theory and practice are the same. In practice, they are not.

Posted Jan 26, 2011 19:06 UTC (Wed) by ebiederm (subscriber, #35028) [Link] (2 responses)

Shrug line rate 10gbps software forwarded ipv6 in linux.

In theory, theory and practice are the same. In practice, they are not.

Posted Jan 26, 2011 21:40 UTC (Wed) by bronson (subscriber, #4806) [Link] (1 responses)

Markov generated text seeded with the iptables manpage?

In theory, theory and practice are the same. In practice, they are not.

Posted Jan 27, 2011 13:51 UTC (Thu) by hmh (subscriber, #3838) [Link]

Must be. It lacks everything, from content, to truth.

Being someone who has actually tried to do 10Gbps routing using Linux, I am well aware of its limitations. You need lots of tuning and the correct hardware to get high packets-per-second rates, and it gets nowhere close to the target 40Mpps. It really is useful only for large packets, or if you need nowhere near line-rate and don't care about DoS attacks with small packets.

One really needs hardware-assisted packet forwarding to do line-speed 10-gigabit routing at all packet sizes. Either that or a routing cluster, at which point TCO goes well above a proper 10Gbit Cisco/Juniper switch-router.

So, the question becomes: are there affordable, non-experimental hardware packet forwarding devices (preferably PCIe) that are compatible with Linux?

What's so bad about IPv6?

Posted Jan 26, 2011 20:08 UTC (Wed) by hmh (subscriber, #3838) [Link]

That is a blatant lie. There are many vendors that still have IPv6 in *roadmap* for several of their product families. I should know, we have several here and it is being an effective deterrent to switching to IPv6.

What's so bad about IPv6?

Posted Jan 26, 2011 18:00 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (1 responses)

Back in 2003 I was testing Cisco's hardware (as much as the IPv4 version is) IPv6 multicast snooping and routing. We were playing different full-rate video streams over a large multi-site IP network with maybe a dozen switch clusters. Without multicast, this was a quagmire (each person viewing incrementally increases the bandwidth needed at pinch points, until performance becomes excruciating) and without IPv6 it requires lots of management because the (Class D in this case) addresses were scarce and must be handled very carefully. With both it was a joy.

Granted, we found several nasty bugs and spent long evenings on transatlantic telephone calls getting their engineers to reproduce them. But that was now almost EIGHT YEARS AGO. This stuff was available for production users when ISPs were buying the gear that's now dusty and old and being thrown out. But they didn't buy it, because less capable gear is always cheaper.

In some way it's our fault as consumers. Most ISPs live on razor thin margins. If everybody was happily paying 50% more for Internet access there'd be money to buy anything the ISP's engineers could want, have real coffee in the DC quiet area, and still buy the Chairman a yacht. But it's a cut-throat business, only specialist players can afford to charge more and deliver better service.

What's so bad about IPv6?

Posted Jan 26, 2011 19:54 UTC (Wed) by cmccabe (guest, #60281) [Link]

> In some way it's our fault as consumers. Most ISPs live on razor thin
> margins. If everybody was happily paying 50% more for Internet access
> there'd be money to buy anything the ISP's engineers could want, have real
> coffee in the DC quiet area, and still buy the Chairman a yacht. But it's
> a cut-throat business, only specialist players can afford to charge more
> and deliver better service.

Our fault as consumers? That's outrageous.

Around here, people routinely get charged $50 a month by Comcast for mediocre internet service. And if Comcast has a technical problem, that requires a technician to solve, they will charge you for the time!

The real problem here is that the interests of the ISPs are not aligned with those of consumers. Consumer interests are best served by open markets and open standards. ISP interests are best served by creating high barriers to entry, locking in consumers, and offering the minimum acceptable level of service.

Nearly every place in the US has either a local ISP monopoly or duopoly. Comcast or AT&T are your choices. They're not even bothering to pretend that the different parts of AT&T are independent any more. It's not a free market, it's a monopoly. And they know how to milk it.

What's so bad about IPv6?

Posted Jan 26, 2011 18:32 UTC (Wed) by paravoid (subscriber, #32869) [Link]

Not to mention that IPv6 forbids fragmentation by routers, hence saving precious CPU (or ASIC) time.

I work at a relatively big ISP where we were an early deployer of IPv6 -- been running it for more than a decade. It was a bumpy road but we've stopped having problems for several years now. We even participate on Google's trusted partner programme.

I have IPv6 connectivity on all of my desktops (office & home) for over three years now and I don't remember to ever having a single connectivity problem with it.

I wholeheartedly believe that dual-stacking *is* the way to go.

What's so bad about IPv6?

Posted Jan 26, 2011 15:09 UTC (Wed) by BrucePerens (guest, #2510) [Link] (1 responses)

The header overhead is larger and the payload size is limited by the path MTU, so it's probably smaller. But it's not enough to send performance down the drain.

What's so bad about IPv6?

Posted Jan 29, 2011 5:48 UTC (Sat) by jzbiciak (guest, #5246) [Link]

The main place I've seen / heard of enabling IPv6 sending performance down the drain was when someone had it enabled, but some piece of the network they had to pass through or interact with (whether it was their weak ISP-supplied router or a crappy DNS server) didn't actually support it. So, you'd send out a DNS request via IPv6, wait for that to time out, and then fall back to IPv4.

Or, at least, so the story goes.

Since I'm not really any sort of IPv6 expert, I can only comment on the existence of reports such as these that I've seen go by the last year or two.

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 16:39 UTC (Wed) by jem (subscriber, #24231) [Link] (6 responses)

I don't understand why ISPs would want to start messing with (IPv4) NAT instead of providing pure IPv6 addresses to customers, combined with NAT64. Modern operating systems and applications are IPv6-ready already, and have been for quite some time. The problem is more the network itself.

Of course, you would want to be able to access IPv4-only hosts and for that the ISPs would translate between the customer's IPv6 addresses and the legacy v4 addresses.

The answer is obvious: money.

Posted Jan 26, 2011 17:42 UTC (Wed) by khim (subscriber, #9252) [Link] (3 responses)

You need a lot of layers of NAT before it'll be as expensive as IPv6. And to provide NAT64 with IPv6 for the end-user just makes no sense: why will they do that? It'll provide worse experience for larger price.

Actually the US is probably the last country where "white IP" is not considered luxury. In the most parts of the word you must pay extra for it - and I fail to see why exhaustion of addresses will change anything short-term. It'll gradually make these addresses more expensive, that's true, but short-term there will be no change.

The answer is obvious: money.

Posted Jan 26, 2011 18:33 UTC (Wed) by jem (subscriber, #24231) [Link] (1 responses)

So IPv6 is expensive, but NAT is not? What makes IPv6 so expensive?

That's not my experience, anyway. Of course, there aren't many providers offering IPv6 yet, but the one I know of in my area does not charge anything extra for IPv6. It's part of the package, take it or leave it. Tunnels are free, too.

How do ISPs respond when customers complain they can't reach IPv6-only sites? Sure, this won't happen for a while, but eventually it will.

End-to-end solution is expensive...

Posted Jan 26, 2011 20:44 UTC (Wed) by khim (subscriber, #9252) [Link]

So IPv6 is expensive, but NAT is not? What makes IPv6 so expensive?

I've not said NAT is not expensive. But it's less expensive then NAT+IPv6.

That's not my experience, anyway.

You mean: you have case study where ISP implemented NAT64 and saved money (in comparison to plain old NAT)? Hard to believe, but I'll be interested to hear more about your story.

How do ISPs respond when customers complain they can't reach IPv6-only sites? Sure, this won't happen for a while, but eventually it will.

I think they'll tell you these sites are broken and you should ask for them to be fixed. If you'll press they'll admit that yes, it may be fixed on their said and that they are "investigating it". The answer is the same for the last 10 years, so I doubt it'll change any time soon.

The answer is obvious: money.

Posted Jan 27, 2011 11:18 UTC (Thu) by job (guest, #670) [Link]

That's silly. I had no problem acquiring a class C network for one of my customers in Europe last year. I just filled out the application and that was it, didn't pay anything extra.

The moment IP address blocks will have economic value we'll be stuck in a downward spiral with no escape. Companies would want to "protect their investments" and we'd have no possibility of ever fixing any technical issues with IP ever again.

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 18:53 UTC (Wed) by lutchann (subscriber, #8872) [Link] (1 responses)

Really? You think provisioning residential customers with IPv6 only would be a seamless experience today?

Okay, here's an experiment to try. Grab my NAT64 daemon and install it on your edge router. It should take you about 15 minutes. Then disable IPv4 on your LAN and see what still works. Go ahead, I'll wait.

For the rest of you, here is a small list of the things that will NOT work out-of-the-box on an IPv6-only network:

  • Any version of Windows earlier than Vista
  • Any WiFi-capable cell phone (Android, iOS, etc, can use IPv6 over WiFi ONLY if IPv4 is available as well)
  • All game consoles
  • Virtually all PC and Mac games
  • Networked printers and scanners
  • Most VoIP phones
  • Your TV, receiver, or any other A/V equipment with an Ethernet jack
  • Etc...
It's possible to run IPv6-only to the edge today, but only if the CPE has a transition function like DS-Lite, 4rd or NAT46 to support legacy IPv4-only devices and software. Unfortunately, no existing home routers support these transition mechanisms, and it would take years for them to become commonplace at the rate most home users refresh their infrastructure.

It's looking increasingly likely that CGN will be the future for most residential customers, with only the lucky ones getting IPv6.

LCA: IP address exhaustion and the end of the open net

Posted Jan 27, 2011 12:28 UTC (Thu) by Quazatron (guest, #4368) [Link]

I think that list would make a good addition to the FAQ on your site.

World IPv6 Day, June 8th

Posted Jan 26, 2011 18:04 UTC (Wed) by roblucid (guest, #48964) [Link]

http://downloadsquad.switched.com/2011/01/13/world-ipv6-d...

Seems like the "encumbents" want to maintain their encumbency and be v6 ready.

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 19:04 UTC (Wed) by ebiederm (subscriber, #35028) [Link]

Currently the economics are simple. After the runout of ipv4 if you want your network to grow you must deploy ipv6, and carrier grade NAT. It is the networks that are expanding and changing that have to pay the cost. Once there is a real ipv6 presence Verizon LTE, Comcast, T-mobile, etc the rest of the issues will be worked out. This is something that we need to move forward with, but I totally fail to see how is something that must happen for everyone in 200 days, NAT gives IPv4 enough life to implement dual stack during the transition.

Furthermore it has been shown that if you plan ahead and get ipv6 into your normal equipment purchasing cycle it is not a significant cost. So I guess we will see who didn't plan ahead and how it bites them.

LCA: IP address exhaustion and the end of the open net

Posted Jan 26, 2011 19:07 UTC (Wed) by flewellyn (subscriber, #5047) [Link] (138 responses)

Seems to me that DJB was right: IPv6's lack of interop with IPv4 is a huge barrier. I confess, I still don't understand the decision to break backwards compatibility; it would have been so simple to transition if you could use both on the same network.

DJB was wrong... even if he was right too.

Posted Jan 26, 2011 20:56 UTC (Wed) by khim (subscriber, #9252) [Link] (137 responses)

Seems to me that DJB was right:

No, he was wrong.

IPv6's lack of interop with IPv4 is a huge barrier.

Sure, but his reasoning only offered solution for non-problem. His idea was that people "at the edge" are dead-set against reconfiguration, yet somehow ISPs are ready and willing to add IPv6 routing to their routers. In reality it's the opposite: IPv6 routing is more expensive and so we don't have global IPv6 network or IPv4/IPv6 - we only have global IPv4 network and bunch of small, sometimes not even connected, IPv6 networks. For his solution to overcome the real problem we'd need this magic function - and it just does not work.

I confess, I still don't understand the decision to break backwards compatibility; it would have been so simple to transition if you could use both on the same network.

It is possible to use both. What is not possible is to implement IPv6 as cheap as IPv4 - and that means ISPs are delaying IPv6 as much as possible. Compare performance of a typical pice of high-end hardware in IPv4 mode and IPv6 mode: "128K routes for IPv4" vs "64K routes for IPv6", "up to 60 Mpps of IPv4 packets" vs "up to 30 Mpps of IPv6 packets", etc. It's just cheaper to only implement IPv4 and ignore IPv6 - and without IPv6-capable routers the whole DJB's scheme just does not work.

DJB was wrong... even if he was right too.

Posted Jan 26, 2011 21:42 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

> Compare performance of a typical pice of high-end hardware in IPv4 mode and IPv6 mode: "128K routes for IPv4" vs "64K routes for IPv6", "up to 60 Mpps of IPv4 packets" vs "up to 30 Mpps of IPv6 packets", etc.

At least some of that could balance out in the end, as IPv6 should require fewer distinct routes and allow more data to be included in each packet. (IPv6 raises the minimum MTU from 576 bytes to 1280 bytes, and the maximum packet size, without optional extensions, from 1500 bytes to 64KB. With options the limits increase to 64KB for IPv4 and 1MB for IPv6.)

DJB was wrong... even if he was right too.

Posted Jan 26, 2011 22:47 UTC (Wed) by bojan (subscriber, #14302) [Link] (8 responses)

> For his solution to overcome the real problem we'd need this magic function - and it just does not work.

That's bullshit and you know it. No such function is required.

Just consider this again:

> This problem was foreseen back in 1990; in response, a nice plan - IPv6 - was developed to ensure that we would never run out of network addresses. That plan assumed that the transition to IPv6 would be well underway by the time that IPv4 addresses were exhausted. Now that we're at that point, how is that plan going? Badly: currently 0.3% of the systems on the net are running IPv6. So, Geoff said, we're now in a position where we have to do a full transition to IPv6 in about seven months - is that feasible?

> To make that transition, we'll have to do more than assign IPv6 addresses to systems. This technology will have to be deployed across something like 1.8 billion people, hundreds of millions of routers, and more. There's lots of fun system administration work to be done; think about all of the firewall configuration scripts which need to be rewritten. Geoff's question to the audience was clear: "you've got 200 days to get this done - what are you doing here??"

20 years later, we are still in this mess and you're telling us DJB was wrong? Never mind DJB, just use common sense. People connected to the net have to connect again for no good reason whatsoever. They already have perfectly good addresses.

Imagine a country operating like this. One day they realise that their citizen numbers (call them SSNs) do not fit into the database field. So, what do they do? Call all existing citizens back to have their citizenship ceremonies (after applying that is) and be issued with brand new numbers. Of course, these citizens now have to give their new numbers to their employers, doctors etc. Yeah, sound like a _great_ plan. Never mind they could have added a few extra zeros to the front of each number.

Why should I imagine anything?

Posted Jan 26, 2011 23:32 UTC (Wed) by khim (subscriber, #9252) [Link] (7 responses)

Imagine a country operating like this. One day they realise that their citizen numbers (call them SSNs) do not fit into the database field. So, what do they do? Call all existing citizens back to have their citizenship ceremonies (after applying that is) and be issued with brand new numbers. Of course, these citizens now have to give their new numbers to their employers, doctors etc. Yeah, sound like a _great_ plan. Never mind they could have added a few extra zeros to the front of each number.

Why should I imagine that? You've perfectly described how registration numbers of cars were handled in USSR, for example. They changed the form at least five times. Radically - totally new form was introduced, not an extension of an old one. Usually new form was introduced but you were allowed to keep old form for a time, but few years down the road you needed to change it anyway. Essentially what IPv6 developers proposed to do - only they have no government to enforce the change.

20 years later, we are still in this mess and you're telling us DJB was wrong? Never mind DJB, just use common sense. People connected to the net have to connect again for no good reason whatsoever. They already have perfectly good addresses.

Well, they have... for now. When/if IPv6 will be mandated in some places it'll create pressure to switch. Till then we have no incentive to switch and I fail to see what can induce the switch - DJB folly or no DJB folly. You still have not examplained how "DJB transion plan" will magically solve the real problem (you need to introduce new IPv6-capable routers - and this is expensive thing to do).

Somehow IPv6 developers believed people will start transition before IPv4 addresses are exhausted - but it can only happen if government will mandate it. Without government intervention it'll happen few years after IPv4 addresses are gone (because for a time you can trade/buy them from existing organizations).

Why should I imagine anything?

Posted Jan 26, 2011 23:47 UTC (Wed) by bojan (subscriber, #14302) [Link] (6 responses)

> You've perfectly described how registration numbers of cars were handled in USSR, for example.

Three points here:

1. USSR does not exist any more. This could be one of the reasons. ;-)

2. Cars with all types of regos could drive just fine. I cannot drive at all on this new IPv6 highway with my IPv4 address.

3. You are required to register you car every year. You are not required to register you net address every year. If fact, many people/orgs/companies had them for many, many years.

You see, where I live, people still have old rego plates. Like "4" or "6". And they still work just fine. We found a way to interoperate with new ones like "XYZ123". It was _very_ difficult, but it eventually worked :-)

This is where you are wrong...

Posted Jan 27, 2011 0:23 UTC (Thu) by khim (subscriber, #9252) [Link] (5 responses)

2. Cars with all types of regos could drive just fine. I cannot drive at all on this new IPv6 highway with my IPv4 address.

Sorry, but no. In fact the last change was introduced exactly because you can not use old ex-USSR regos on new European highways. Some older nameplates are not legal to use in other places.

3. You are required to register you car every year. You are not required to register you net address every year. If fact, many people/orgs/companies had them for many, many years.

Well, this is the problem, isn't it? Price of IPv4 address will rise with time and network registrars will start revoking addresses if they organizations will not pay. Organizations will lose the luxury of "IP addresses for life" very soon. That's why I'm kind of surprised when people say DJB is right: IPv6 intrusion is not even started yet! Somehow the people perceive a time when IPv4 pools are exhausted as the end of said process (the crazy "you've got 200 days to get this done - what are you doing here??" line). No, it's not the end of the IPv6 migration process. It's not even the middle. It's the beginning. Prehistory. For the beginning of the process 0.3% penetration is actually surprisingly high.

1. USSR does not exist any more. This could be one of the reasons. ;-)

Actually it's the other way around: USSR does not exist anymore so such painless switches are no longer possible.

This is where you are wrong...

Posted Jan 27, 2011 1:10 UTC (Thu) by bojan (subscriber, #14302) [Link] (4 responses)

> For the beginning of the process 0.3% penetration is actually surprisingly high.

We are at the beginning? The problem was identified 20 years ago.

Yeah, it was identified, so what?

Posted Jan 27, 2011 8:18 UTC (Thu) by khim (subscriber, #9252) [Link] (3 responses)

We are at the beginning? The problem was identified 20 years ago.

And so what? The need for 64-bit computing was clear 20 years ago, 64bit CPUs were produced in about that time, yet people only started to switch when Joe Average started reaching 4GB limit. Before that intermediate solutions like PAE were used. Compare with IPv4 -> IPv6: till IPv4 adddress space is not exhausted people are using IPv4. Even when it'll be exhausted people will continue to use IPv4 with band-aids like multi-level NAT. Only when pain is acute enough they will start to switch.

The brave people who are using IPv6 today can be compared to users of POWER/MIPS/SPARC/etc: they are numerous enough to iron bugs, but there are few of them because most users just don't need an IPv6 today (just like yesterday people were perfectly content with Xeon and 32GiB of RAM in PAE mode).

This is how market works: it's organically incapable of jumping from one "good" solution to another "better" solution if the intermediate steps go "down" (and in case of IPv4 -> IPv6 switch they do go down no matter what DJB says). "Good" solution must become "bad" first... And it'll only happen by 2012 or later. So yes, it is the beginning.

Yeah, it was identified, so what?

Posted Jan 28, 2011 3:31 UTC (Fri) by bojan (subscriber, #14302) [Link] (2 responses)

You keep forgetting the most important thing: people could take their 32-bit apps with them and run them on their 64-bit machines. Immediately. No modification, no reconfiguration - the hard yards were done by software vendors. People cannot do that with their IPv4 addresses and connections and IPv6. Everything has to be done (essentially) from scratch. Software upgrades alone do not help.

Some people mention things like toredo and other 4/6 cruft. What good does that do, when you get _different_ addresses, so if you have things like DNS, firewalls, services etc. set up, you have to do it all over again. It is completely different. In fact, the simple fact of needing to _think_ whether and what you'll need to do is sufficient to show that this has been handled poorly.

Of course people start switching only when the need to. That's why many folks still run 32-bit OSes and apps on their 64-bit machines, without even knowing or caring they are really 64-bit. And yet, pretty much any server, PC or notebook you buy today can do 64-bits. If IPv6 transition was handled the same way, most folks out there would not even be aware there was a transition. They would already be on IPv6, not caring one iota about the new connections having real IPv6 addresses. They could still see everything, just like they always did. And these new connections could see them just fine.

Just go talk to your average network/system admin out there. Most of them have absolutely no idea what to do. If they introduce IPv6 to their network, they will have to spend years battling two completely separate setups (essentially, they are building their network from scratch). Initially, for no benefit at all. This never happened with amd64.

If you told them that to get IPv6 support, they needed to install at least version x.y.z on all of their equipment or even just change the equipment and reload the config, that would be way easier.

The amd64 example shows nicely how the market does it with minimal disruption. Remember, even Intel, the leader in the field, had to succumb to an architecture designed by an inferior competitor.

Yeah, it was identified, so what?

Posted Jan 28, 2011 4:07 UTC (Fri) by foom (subscriber, #14868) [Link] (1 responses)

> They would already be on IPv6, not caring one iota about the new connections having real IPv6 addresses.

You can repeat that 40 or 50 times, but it doesn't make it more true the more often it's repeated.

I will again claim that even with your version of the transition, ISPs still wouldn't have bothered to upgrade their routers to support the longer addresses faster than they have been doing now, nor would the manufacturers of dsl routers, cable modems, etc have upgraded their software (and configuration protocols) to support the long addresses any sooner.

They wouldn't bother supporting long addresses because nobody would use long addresses. Nobody would use long addresses because you couldn't talk to the majority of the internet (the part that still had at least one router on the path not supporting long addresses or with a host endpoint that didn't support long addressing). Until there was actually a forcing function, such as running out of short addresses. Just like with actual IPv6.

But, nobody can prove any "what ifs", so maybe it's time to just drop the whole discussion.

Yeah, it was identified, so what?

Posted Jan 28, 2011 4:39 UTC (Fri) by bojan (subscriber, #14302) [Link]

Let's assume you are correct.

This leaves us currently with a situation that requires upgrade (for some) and reconfiguration (for most). The alternative requires only upgrade (for some).

That is not a what if. That is a fact.

But yeah, let's drop it. I'm getting a feeling a moderator may suspend my account soon. I have too much time on my hands. Maybe I should go and start configuring IPv6 instead. :-)

DJB was wrong... even if he was right too.

Posted Jan 26, 2011 23:39 UTC (Wed) by bojan (subscriber, #14302) [Link] (126 responses)

> His idea was that people "at the edge" are dead-set against reconfiguration, yet somehow ISPs are ready and willing to add IPv6 routing to their routers.

No, his idea is a common sense one: people already connected to the net should not have to reconnect.

ISPs would be _forced_ to support it, because all those IPv6 enabled hosts would start sending packets with IPv6 addresses over ISPs' network more and more. ISPs that could not support such traffic would either upgrade or be abandoned.

Right now, nobody with an IPv4 address can even attempt send a packet to anyone with an IPv6 address.

The only reason we don't have IPv6 network yet is because it's useless. There is no interesting things to see there.

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 0:21 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (125 responses)

> Right now, nobody with an IPv4 address can even attempt send a packet to anyone with an IPv6 address.

Sure they can. Everyone with a public IPv4 address also has 2**80 perfectly good public IPv6 addresses, any one of which can be used to send packets to IPv6-capable peers.

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 0:30 UTC (Thu) by bojan (subscriber, #14302) [Link] (124 responses)

Yeah and who and what is going to route that for me?

Noone, of course... and why should they?

Posted Jan 27, 2011 0:46 UTC (Thu) by khim (subscriber, #9252) [Link] (99 responses)

Well, you know these same ISPs which are _forced_ to support it.

The "pressure" is so great that they can safely ignore it - and rightfully so.

You are correct: we don't have IPv6 network yet is because there is no interesting things to see there, but... DJB's crazy ideas will not change it. Because noone will want to connect to IPv6 while it has no interesting things to see - and noone will want to put interesting things on IPv6 network while people can not reach it. Network addresses issue is total red herring. Sure: such issue exist, but this is such a small part of the problem that it's not worth even dicussing - in fact it's discussed in first place only because DJB is famous.

Noone, of course... and why should they?

Posted Jan 27, 2011 1:07 UTC (Thu) by bojan (subscriber, #14302) [Link]

> DJB's crazy ideas will not change it.

Yeah, they are crazy now. They were not crazy 8 years ago. But nobody listened, so that's why IPv6 works so well now on everyone's computer. Not.

Noone, of course... and why should they?

Posted Jan 27, 2011 1:20 UTC (Thu) by bojan (subscriber, #14302) [Link] (97 responses)

> Because noone will want to connect to IPv6 while it has no interesting things to see - and noone will want to put interesting things on IPv6 network while people can not reach it.

You're just showing here how you're not getting it at all. This is the result of the current plan. The other plan would make sure that IPv4 network _is_ the IPv6 network, so everything would be on it right away.

Noone, of course... and why should they?

Posted Jan 27, 2011 3:07 UTC (Thu) by lutchann (subscriber, #8872) [Link] (96 responses)

I'm really amused by the argument you've been making here and on the Cerf article. The gist of it seems to be:

(a) ISPs and businesses won't invest the time and effort to move to IPv6 because there's no demand from customers when 32-bit IPv4 works fine.

(b) If the IETF had instead enhanced IPv4 to transparently support extended addresses, we would simply need networking vendors to support it across their product lines and it would eventually be available everywhere on the Internet without any extra effort from ISPs or network administrators.

(c) All vendors would universally agree to take on the necessary manufacturing and development expense to do this, even though there was no demand from their customers for this feature. They would all discontinue their old products, even though they could, theoretically, continue to make and sell them for cheaper than the extended-addressing-compatible new products.

A good example of the failure of exactly this deployment model is TCP Explicit Congestion Notification. Even though it was standardized in 2001 and it's backward compatible with existing hardware and software, there's very little deployment of ECN in core infrastructure. Why? Because it reduces hardware performance per dollar, so without customer demand, ISPs are going to give it up to save some money.

ECN is nothing but flipping a bit and recalculating the TCP checksum! Extending the number of routed address bits would be much more invasive and silicon-intensive. There is no chance vendors would do this without dollars on the table.

Noone, of course... and why should they?

Posted Jan 27, 2011 4:01 UTC (Thu) by bojan (subscriber, #14302) [Link] (95 responses)

Not quite. ISPs have not been investing in IPv6 because they had no IPv6 traffic, current or projected. Should all of their customers been on essentially IPv6 through regular upgrades, their investment in IPv6 would come before IPv4 address exhaustion, because all of their customers (and pretty much any other host in the world) would already be ready and _fully_ _configured_ for IPv6, IPv6 addresses are cheap and content is _widely_ _available_. In other words, everything is ready. Why would they then need to think about several layers of NAT (how much is that going to cost?) and other nonsense? IPv6 would be fully ready for them by switching their gear or even just upgrading software.

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.

Noone, of course... and why should they?

Posted Jan 27, 2011 4:38 UTC (Thu) by lutchann (subscriber, #8872) [Link] (94 responses)

What I don't understand (along with khim, tialaramex, johill, etc) is why you think ISPs would have invested in hardware that supports your hypothetical IPv6-like hybrid protocol. What makes you think ISPs' projections for traffic using your protocol would look any different from their projections for IPv6 traffic? 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.

Noone, of course... and why should they?

Posted Jan 27, 2011 5:47 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

this could have been done in a way that would be completely transparent to the routers of ISPs that don't yet need the additional address space. see my post at http://lwn.net/Articles/424889/ for one possible approach that would not require any ISP investment until they needed the address space.

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.

Noone, of course... and why should they?

Posted Jan 27, 2011 16:57 UTC (Thu) by lutchann (subscriber, #8872) [Link] (1 responses)

You know, IPv6 was supposed to be deployed in a fashion very similar to what you proposed. 6to4 was developed to create automatic tunnels between site border routers, and ISATAP was developed to create automatic tunnels within sites, safely behind the protection of the site's firewall/NAT. The intent was that vendors would enable these technologies by default, thus allowing IPv6 to be used with no assistance from network administrators or the core IPv4 Internet.

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.

Noone, of course... and why should they?

Posted Jan 27, 2011 19:42 UTC (Thu) by dlang (guest, #313) [Link]

NAT64 and DNS64 would allow for deployment similar to what I have described (starting from the opposite end, with the new protocol on the client side, implemented first by ISPs that have lots of clients), and I hope that is actually what ends up happening. The problem with doing this is that all the devices on the client end of things need to handle IPv6, and due to the need for all the configuration/administration to be duplicated for no apparent benefit, there are a lot of devices out there that don't currently support (or at least don't enable) IPv6

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.

Noone, of course... and why should they?

Posted Jan 27, 2011 5:53 UTC (Thu) by bojan (subscriber, #14302) [Link] (90 responses)

> What makes you think ISPs' projections for traffic using your protocol would look any different from their projections for IPv6 traffic?

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.

Noone, of course... and why should they?

Posted Jan 27, 2011 7:01 UTC (Thu) by dlang (guest, #313) [Link] (89 responses)

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.

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"

IPv6 *is* like AMD

Posted Jan 27, 2011 8:03 UTC (Thu) by khim (subscriber, #9252) [Link] (65 responses)

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.

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.

IPv6 *is* like AMD

Posted Jan 27, 2011 8:39 UTC (Thu) by bojan (subscriber, #14302) [Link] (36 responses)

> 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.

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. :-)

IPv6 *is* like AMD

Posted Jan 27, 2011 10:26 UTC (Thu) by khim (subscriber, #9252) [Link] (35 responses)

We had a chance to do this, transparently, but because of a few purists, it never happened.

No, we had no such chance. Instead we had the following discussion:
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.

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.

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).

DJB's plan does not change it because it does not solve problem X.

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)

Valid question - and because DJB's plan does not solve problem X it does not change the answer.

And yet, some forward looking ISPs have the whole core enabled for IPv6 already.

Yup.

But guess what? No customers.

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.

Why? Because nobody cares to reconfigure for no immediate benefit. More importantly, why should they have to? It's just nonsense.

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.

You know, you are kinda disproving your own points :-)

Where exactly?

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. :-)

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.

IPv6 *is* like AMD

Posted Jan 27, 2011 17:22 UTC (Thu) by lutchann (subscriber, #8872) [Link] (32 responses)

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.

Thanks, this made me laugh, and it's a perfect summary of the argument.

IPv6 *is* like AMD

Posted Jan 27, 2011 22:05 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (31 responses)

It would be funnier if not for the fact that DJB does this _everywhere_

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.

IPv6 *is* like AMD

Posted Jan 27, 2011 22:17 UTC (Thu) by lutchann (subscriber, #8872) [Link]

Yeah, he is kind of like the Rush Limbaugh of IT...

IPv6 *is* like AMD

Posted Jan 28, 2011 1:44 UTC (Fri) by cmccabe (guest, #60281) [Link] (29 responses)

Let's be honest here. The IPv6 transition has failed. That was basically the gist of Geoff Huston's talk. That leaves two alternatives:

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.

IPv6 *is* like AMD

Posted Jan 28, 2011 1:51 UTC (Fri) by bojan (subscriber, #14302) [Link] (2 responses)

> Let's be honest here. The IPv6 transition has failed.

Don't say that! IPv6 transition is a grand success. Look, my ping6 started working too:

$ ping6 ipv6.google.com
64 bytes from imaginary internet returned

:-)

IPv6 *is* like AMD

Posted Jan 29, 2011 4:44 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (1 responses)

Here I don't have native IPv6, but rather than constantly tell people this as though I was proud of it, I enabled a tunnel a long time ago.

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.

IPv6 *is* like AMD

Posted Feb 7, 2011 15:42 UTC (Mon) by rleigh (guest, #14622) [Link]

Just for comparison, this is from a machine with native IPv6:

% ping6 ipv6.google.com
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

Not too bad!

IPv6 *is* like AMD

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--
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.

2002--
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.

2005--
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.

2010--
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.

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.

IPv6 *is* like AMD

Posted Jan 28, 2011 7:06 UTC (Fri) by cmccabe (guest, #60281) [Link] (14 responses)

It's a classic tragedy of the commons problem. Everyone has an incentive to delay doing anything for as long as possible, even though collectively we would all be better off if something was done.

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.

IPv6 *is* like AMD

Posted Jan 28, 2011 21:31 UTC (Fri) by lutchann (subscriber, #8872) [Link] (10 responses)

The IETF didn't expect anybody to transition to IPv6 because it was "the right thing". They expected people to use IPv6 because of its advantages over IPv4.

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.

IPv6 *is* like AMD

Posted Jan 29, 2011 9:43 UTC (Sat) by TRS-80 (guest, #1804) [Link] (6 responses)

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

Posted Jan 29, 2011 18:31 UTC (Sat) by lutchann (subscriber, #8872) [Link] (5 responses)

Well, right. The IETF thought that what people really wanted was a circa-1992 Internet, and they'd put up with a little transition pain to get back there. They were wrong, and that's why nobody switched.

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.

Their cost/benefit analysis was all wrong.

Posted Jan 31, 2011 0:51 UTC (Mon) by khim (subscriber, #9252) [Link] (4 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.

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:
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).

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!

Their cost/benefit analysis was all wrong.

Posted Jan 31, 2011 2:36 UTC (Mon) by dlang (guest, #313) [Link] (3 responses)

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.

Posted Jan 31, 2011 12:19 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

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.

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.

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?

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.

This is not a whole solution, true.

Posted Jan 31, 2011 22:25 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

but there is a catch 22 here:

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?

Have you actually read what I wrote?

Posted Feb 1, 2011 15:18 UTC (Tue) by khim (subscriber, #9252) [Link]

why would anyone demand IPv6 until there are any IPv6-only resources?

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!

and why would anyone ever willingly deploy an IPv6-only resource if the vast majority of users will not be able to reach it?

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.

until something breaks this stalemate how will IPv6 gain any traction?

Poorly are we can see.

That's the problem...

Posted Jan 29, 2011 12:38 UTC (Sat) by khim (subscriber, #9252) [Link] (2 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.

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!

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.

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...

That's the problem...

Posted Jan 29, 2011 22:34 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

I am like you and want end-to-end connectivity for my connection.

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

Of course my Grandmother needs end-to-end connecitvity!

Posted Jan 31, 2011 0:24 UTC (Mon) by khim (subscriber, #9252) [Link]

but I don't want the end-to-end connectivity for my Grandmother.

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!

IPv6 *is* like AMD

Posted Feb 1, 2011 10:21 UTC (Tue) by Cato (guest, #7643) [Link] (2 responses)

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. More generally, the huge cost of bypassing multiple NAT layers for complex applications will become an increasing issue.

This is more complex than that...

Posted Feb 1, 2011 16:04 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

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?

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 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.

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.

This is more complex than that...

Posted Feb 1, 2011 18:35 UTC (Tue) by Cato (guest, #7643) [Link]

Actually SMS is being replaced to some degree by mobile-based instant messaging, including push notifications, which provides some new features and are much lower cost. Many of the 4G LTE networks don't yet support SMS despite being from the same mobile operators.

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.

IPv6 *is* like AMD

Posted Jan 28, 2011 8:48 UTC (Fri) by khim (subscriber, #9252) [Link] (9 responses)

Ad hominem attacks against DJB-- or anyone else for that matter-- don't prove anything.

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?

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.

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.

Some examples of failed transitions are Commodore 64 to Commodore 128, x86 to Itanium, and the Apple ][ to the Apple III.

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.

The failed transitions all have something in common: the people in charge underestimated the importance of having a transition plan.

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".

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.

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.

IPv6 *is* like AMD

Posted Jan 28, 2011 18:24 UTC (Fri) by cmccabe (guest, #60281) [Link] (8 responses)

In the case of the LP to CD and VHS to DVD transitions, the dynamic was different. Owning a shiny new CD or DVD was a status symbol, so consumers were willing to pay more. The quality of the user experience was dramatically better on the new media. Also, CDs and DVDs were priced higher than LPs or VHS, so the business community made more money off of them. Even so, it took decades for the transition to really happen-- and for some older people, it hasn't happened even now.

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.

Agree 100%

Posted Jan 28, 2011 21:22 UTC (Fri) by khim (subscriber, #9252) [Link] (7 responses)

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.

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).

Give them a reason to upgrade, rather than just telling them to do it for the good of the galaxy.

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...

Agree 100%

Posted Jan 31, 2011 2:11 UTC (Mon) by cmccabe (guest, #60281) [Link] (6 responses)

From the wikipedia article on the Apple III:

> Originally intended as a direct replacement to the Apple II series, it was
> 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.

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
> was solved [by an EU directive].

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
> year or two.

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 -
> but why should they? Nobody is paying them and nobody punishes them...

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.

Agree 100%

Posted Jan 31, 2011 2:22 UTC (Mon) by cmccabe (guest, #60281) [Link]

> 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!

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"

We've already discussed it...

Posted Jan 31, 2011 11:53 UTC (Mon) by khim (subscriber, #9252) [Link] (4 responses)

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!

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.

Nothing happens instantaneously. Even recalls of tainted food take a few weeks to happen. The lack of any transition plan seems very foolish.

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.

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.

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...

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.

Yup. And you have limited amount of local ISPs to choose from. Often just one. That's why government regulation makes sense.

We've already discussed it...

Posted Jan 31, 2011 22:17 UTC (Mon) by dlang (guest, #313) [Link] (2 responses)

who is going to enforce the 'after date X no IPv4 only connections are allowed'?

there is no Internet Dictator who can enforce a policy like this.

Why do you need an "Internet Dictator" ?

Posted Feb 1, 2011 14:53 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

there is no Internet Dictator who can enforce a policy like this.

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.

Why do you need an "Internet Dictator" ?

Posted Feb 2, 2011 9:39 UTC (Wed) by cmccabe (guest, #60281) [Link]

Um, I don't think Egypt leaving the wider Internet shows that international cooperation always works well. I'm sure that the US isn't happy that they did that. Rather, it proves that the Internet is a patchwork of national networks and governments will get the last say, no matter what the international community thinks.

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.

We've already discussed it...

Posted Feb 4, 2011 21:18 UTC (Fri) by sorpigal (subscriber, #36106) [Link]

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.

IPv6 *is* like AMD

Posted Jan 28, 2011 2:24 UTC (Fri) by bojan (subscriber, #14302) [Link] (1 responses)

> bojan: Everyone is crazy - there was great plan to solve A, B, C, and D. And it was ignored. Fools you are!

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.

IPv6 *is* like AMD

Posted Jan 29, 2011 16:14 UTC (Sat) by khim (subscriber, #9252) [Link]

All I keep saying is that mistakes were made. Even the best of the best do that from time to time.

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?

Your claim boils down to this: it was not possible to design IPv6 as an upgrade to IPv4.

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?

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.

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.

But I know one thing: my ping6 still doesn't work and it should.

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.

So, even if DJB and myself are utter nutters (which is a distinct possibility) your grand technical solution still isn't working.

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.

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.

Interoparability and compatibility are not relevant. We either have the problem of IP address exhaustion from explosive growth of the Internet or not. If we do have such problem then what happens with "old" nodes is unimportant: they will be quickly outnumbered by "new" nodes, if we don't have such a growth then IPv6 transition is not needed at all. In both cases DJB's plan is useless.

IPv6 *is* like AMD

Posted Jan 27, 2011 9:11 UTC (Thu) by bronson (subscriber, #4806) [Link] (27 responses)

AMD64 in 64 bit mode can still run 32 bit software. This was a well planned transition.

ipv6 just chucks ipv4 out the window.

See the difference now?

IPv6 *is* like AMD

Posted Jan 27, 2011 10:06 UTC (Thu) by khim (subscriber, #9252) [Link] (26 responses)

AMD64 in 64 bit mode can still run 32 bit software.

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.

ipv6 just chucks ipv4 out the window.

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.

See the difference now?

Let me think about it...

1st try. Can you use new address space without core infrastructure update?
AMD64: No.
IPv6: No.

2nd try. Can you use new old clients with core infrastructure update?
AMD64: Yes.
IPv6: Yes.

3rd try. Can the old client talk with the new ones directly?
AMD64: No, you must use proxy.
IPv6: No, you must use proxy.

Hmm... Funny... All the questions have the same answer... So... where is the difference?

IPv6 *is* like AMD

Posted Jan 27, 2011 10:29 UTC (Thu) by bojan (subscriber, #14302) [Link] (25 responses)

The difference is that if I buy amd64 and decide to chuck 64-bit os on it, I won't have to touch my config files at all - they will just work from my 32-bit backups. Ditto most of my data. Also, my old apps will just work. And new ones too. Guess what? That's exactly what I did.

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.

IPv6 *is* like AMD

Posted Jan 27, 2011 10:46 UTC (Thu) by khim (subscriber, #9252) [Link] (24 responses)

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.

Wow! Yes, I fail to see that. You see, we have the situation today:
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".

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"...

Why does everyone already connected to the net have to reconfigure and essentially run two setups?

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.

Because someone wasn't thinking when they designed IPv6.

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.

IPv6 *is* like AMD

Posted Jan 27, 2011 11:05 UTC (Thu) by bojan (subscriber, #14302) [Link] (23 responses)

Minor issue of complete isolation from where the real net is :-)

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.

IPv6 *is* like AMD

Posted Jan 27, 2011 12:16 UTC (Thu) by cesarb (subscriber, #6266) [Link] (22 responses)

> These 99% would have been _on_ IPv6 now, had it been for a proper plan.

No, they wouldn't, because their ISP still would not have IPv6. What is your difficulty with seeing that?

IPv6 *is* like AMD

Posted Jan 27, 2011 12:33 UTC (Thu) by bojan (subscriber, #14302) [Link] (21 responses)

The difficulty is that the current plan produced zero results so far. Any _other_ plan would have been as good as that and most likely a lot better.

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.

Why DJB's plan fail

Posted Jan 27, 2011 14:17 UTC (Thu) by cesarb (subscriber, #6266) [Link] (20 responses)

I am not saying the current situation is a success. I am saying that DJB's plan would fail in the same way as the current situation.

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/.

Why DJB's plan fail

Posted Jan 27, 2011 19:47 UTC (Thu) by dlang (guest, #313) [Link] (16 responses)

I am not a big fan of DJB, and his 'plan' is not fleshed out 100%, but I really do thing that something close to what he was talking about is what was needed (see my thoughts at http://lwn.net/Articles/424889/ for a way to do the encapsulation)

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.

Why DJB's plan fail

Posted Jan 27, 2011 22:06 UTC (Thu) by lutchann (subscriber, #8872) [Link] (15 responses)

Your attitude of

the IPv6 standard is so large and hard to get right

and

having to run dual stack is considerably more expensive and complicated than just running IPv4

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.

Why DJB's plan fail

Posted Jan 27, 2011 22:18 UTC (Thu) by bojan (subscriber, #14302) [Link] (14 responses)

IPv6 is not an upgrade. It's a new setup. To see what? The 3 sites currently running on IPv6? Ergo the objections.

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! ;-)

Why DJB's plan fail

Posted Jan 27, 2011 23:08 UTC (Thu) by lutchann (subscriber, #8872) [Link] (13 responses)

*shrug* The market will decide. Providers will fix the address exhaustion problem with the cheapest solution that their customers will accept, which may or may not involve IPv6.

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.

Why DJB's plan fail

Posted Jan 27, 2011 23:25 UTC (Thu) by dlang (guest, #313) [Link] (9 responses)

for some of us it's not just waling in after two decades of development and saying 'you should have done this', many of us have been saying that the IPv6 'migration plan' was bogus for many years.

there are even people who have been saying this (some of them very vocally) since the plan was presented, before it was voted on.

Why DJB's plan fail

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".

Why DJB's plan fail

Posted Jan 28, 2011 0:17 UTC (Fri) by bojan (subscriber, #14302) [Link] (5 responses)

> Which plan is better: the one which was adopted by committee or the one which was adopted by few fanboys?

> 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.

Why DJB's plan fail

Posted Jan 28, 2011 0:44 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

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?

Sure.

Not the ones that caused the GFC?

"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?

Why DJB's plan fail

Posted Jan 28, 2011 0:59 UTC (Fri) by bojan (subscriber, #14302) [Link] (3 responses)

> Well, duh - but what is your plan?

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?

Why DJB's plan fail

Posted Jan 28, 2011 1:33 UTC (Fri) by cesarb (subscriber, #6266) [Link] (2 responses)

> 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.

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.

Why DJB's plan fail

Posted Jan 28, 2011 1:57 UTC (Fri) by bojan (subscriber, #14302) [Link] (1 responses)

OK, one problem solved. And people will then be able to access my IPv4 addressed site too over IPv6? My firewall will work? And all my services will be reconfigured? I think not.

Why DJB's plan fail

Posted Jan 28, 2011 2:53 UTC (Fri) by bojan (subscriber, #14302) [Link]

> OK, one problem solved.

Actually, scrap that. The ping would not have come from my IPv4 address, so it doesn't really count.

Why DJB's plan fail

Posted Jan 27, 2011 23:43 UTC (Thu) by lutchann (subscriber, #8872) [Link] (1 responses)

During the many years you and others were complaining about IPv6 being bogus, why didn't anybody come up with alternative solutions to the address exhaustion problem? It sounds like you've had plenty of time.

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.

Why DJB's plan fail

Posted Jan 28, 2011 0:12 UTC (Fri) by bojan (subscriber, #14302) [Link]

> During the many years you and others were complaining about IPv6 being bogus, why didn't anybody come up with alternative solutions to the address exhaustion problem? It sounds like you've had plenty of time.

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.

Why DJB's plan fail

Posted Jan 28, 2011 0:06 UTC (Fri) by bojan (subscriber, #14302) [Link] (2 responses)

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.

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.

Well, yes...

Posted Jan 28, 2011 0:31 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

Oh, sorry. The grand plan forged 20 years ago that produced nothing thus far is a great success. Just like Itanium. :-)

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.

Nobody is calling anyone an idiot. It just a bad, bad plan that didn't really work.

Why do you say it didn't work? Where is your alternative which pushes IPv6 away?

So, the grand plan for a clean new protocol needs "emulators" to work. Simply hilarious!

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.

Well, yes...

Posted Jan 28, 2011 0:42 UTC (Fri) by bojan (subscriber, #14302) [Link]

> Itanium was great success for a time

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.

Why DJB's plan fail

Posted Jan 27, 2011 21:54 UTC (Thu) by bojan (subscriber, #14302) [Link] (2 responses)

> 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?

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?

Why DJB's plan fail

Posted Jan 27, 2011 23:10 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

But guess what, right now, all these supposed routers have _nothing_ to route, because nobody even has an IPv6 address.

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.

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).

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.

And even if they do have an IPv6 address now, it's useless - there is nothing to see with IPv6.

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?

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.

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?

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?

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.

Also note that issuing IPv6 addresses to new customers is a no brainer.

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?

> 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.

Blatant lie. DJB published his rant. Noone upgraded. End of story.

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.

Ah... so you just ignore these poor souls who's ISP decided to ignore IPv6. Ok.

The amount of those would be very small indeed.

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.

Should IPv6 have been "the" thing, people with networks that "do" things (i.e. not ISP) would automatically care for it.

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.

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?

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.

routinely fail to support existing protocols like stop thing like SMTP or CIFS from working over the Internet. Why will they want to support some weird useless yet resource sucking extension? They don't - and this is just as true today without IETF endorcement and it'll be true in the alternate history with IETF endorcement. DJB's plan has failed - it failed to attract even few IETF developers so it never had any hope of success. In some alternate universe where people's brains are wired differently and where all members of IETF are enthusiastic endorsers of DJB's plan it may work, but in our universe it's doomed.

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.

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.

At least everyone would have their host configured for IPv6 _right_ _now_, even if routing wasn't done yet.

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.

At least there would be an incentive to turn the pressure up on ISPs, so that the problem gets solved.

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?

Precisely because all of the edge (where the value is) would be done and ready.

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.

Current plan produced no such incentive. That's exactly why ISPs are talking of layers of NAT and what not.

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.

Yeah, unfortunately in this case, it's not you or anyone else commenting here, but rather folks supposedly in charge of making things work.

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.

Why DJB's plan fail

Posted Jan 28, 2011 0:19 UTC (Fri) by bojan (subscriber, #14302) [Link]

> but there are noone "in charge"

I think that bit is pretty obvious. ;-)

Noone, of course... and why should they?

Posted Jan 27, 2011 8:23 UTC (Thu) by bojan (subscriber, #14302) [Link] (22 responses)

> IPv6 plan was the same as the Intel Itanium plan

Chuckle! Search for Itanic here: http://lwn.net/Articles/424973/

Heh. But have you actually lloked on the facts?

Posted Jan 27, 2011 8:40 UTC (Thu) by khim (subscriber, #9252) [Link] (21 responses)

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?

Posted Jan 27, 2011 9:15 UTC (Thu) by bronson (subscriber, #4806) [Link] (16 responses)

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.

Posted Jan 27, 2011 9:56 UTC (Thu) by khim (subscriber, #9252) [Link] (15 responses)

Just like pure 32 bit chips were cheaper than their dual-mode counterparts (that's true) and therefore widespread 64 bit uptake never happened?

Well, yeah, exactly.

Your logic needs some work.

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.

And your fact-checking need work too.

Posted Jan 27, 2011 11:12 UTC (Thu) by bojan (subscriber, #14302) [Link] (14 responses)

Utter nonsense. People chose amd64 because they could run all of their software (they spent money on and time mastering) just the same on it, while being able to do more.

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.

And your fact-checking need work too.

Posted Jan 27, 2011 11:23 UTC (Thu) by bojan (subscriber, #14302) [Link] (13 responses)

In fact, first Opteron appeared in 2003. Buy 2008 it was game well and truly over for i386.

And your fact-checking need work too.

Posted Jan 27, 2011 11:29 UTC (Thu) by bojan (subscriber, #14302) [Link] (12 responses)

Actually, I should say by mid 2006. That's when Core 2 hit the notebooks. So, what, just over 3 years?

Facts are ignored as usual...

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.

Facts are ignored as usual...

Posted Jan 27, 2011 22:02 UTC (Thu) by bojan (subscriber, #14302) [Link] (10 responses)

> and then IPv6 already won and is huge success.

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.

Facts are ignored as usual...

Posted Jan 27, 2011 23:17 UTC (Thu) by khim (subscriber, #9252) [Link] (9 responses)

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...

Posted Jan 28, 2011 0:36 UTC (Fri) by bojan (subscriber, #14302) [Link] (8 responses)

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.

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.

Yet another stupid rant.

Posted Jan 28, 2011 1:10 UTC (Fri) by khim (subscriber, #9252) [Link] (5 responses)

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.

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.

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.

It's not your task, that's right.

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.

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.

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.

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.

Yeah, exactly like my amd64 transition. Not.

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.

Black is white. Worse is better and so on.

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.

Yet another stupid rant.

Posted Jan 28, 2011 1:44 UTC (Fri) by bojan (subscriber, #14302) [Link] (4 responses)

> 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.

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.

Yet another stupid rant.

Posted Jan 28, 2011 2:55 UTC (Fri) by cesarb (subscriber, #6266) [Link] (1 responses)

"For every problem there is always a solution that is simple, obvious, and wrong." -- Albert Einstein

"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!

Yet another stupid rant.

Posted Jan 28, 2011 3:54 UTC (Fri) by bojan (subscriber, #14302) [Link]

> "because the IPv6 network is a different network"

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.

Right. DJB plan failed. Other plans have minimal success.

Posted Jan 28, 2011 12:01 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

> 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.

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.

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?

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?

Right. DJB plan failed. Other plans have minimal success.

Posted Jan 31, 2011 16:40 UTC (Mon) by nye (guest, #51576) [Link]

For fuck's sake, will you stop fucking trolling with your inane shit?

*plonk*

Facts are ignored as usual...

Posted Jan 28, 2011 1:18 UTC (Fri) by cesarb (subscriber, #6266) [Link] (1 responses)

> So, tell me, how does my software vendor enable "32bit syscall emulation" on my IPv6 stack to use my IPv4 address there?

int on = 0;
setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, &on, sizeof(on));

This allows you to use a single IPv6 socket for both IPv6 and IPv4 transparently (IPv4 addresses show as IPv4-mapped IPv6 addresses).

Facts are ignored as usual...

Posted Jan 28, 2011 1:28 UTC (Fri) by bojan (subscriber, #14302) [Link]

Oh, wow! Why don't you show this to the IPv6 working group (or whoever is not in charge of the transition). I'm sure they'd like to fix the Internet with this 2 line patch. ;-)

Heh. But have you actually lloked on the facts?

Posted Jan 27, 2011 9:15 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

AMD64 did not require people to recompile everything just to run on it. it supports running a pure 32 bit system just fine, it also supports running a 64 bit OS while still being able to run unmodified 32 bit binaries.

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.

That's right.

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.

That's right.

Posted Jan 27, 2011 11:56 UTC (Thu) by bojan (subscriber, #14302) [Link]

Some configuration? Will contact you when we start where I work - I'm sure you'll figure it out for us in 5 minutes or so. Hilarious!

Itanic

Posted Jan 29, 2011 17:55 UTC (Sat) by jeleinweber (subscriber, #8326) [Link]

One of the intel Itanium designers showed up in my neck of the woods working on a Ph.D, and he naturally gave some talks. He made a very convincing case that at a given clock rate, the Itanium was about 3x better performance than conventional RISC designs. That left a few pesky practical issues on the table, like:

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.

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 1:04 UTC (Thu) by cesarb (subscriber, #6266) [Link] (23 responses)

> Yeah and who and what is going to route that for me?

The anycast router at 192.88.99.1 in one direction, the nearest router announcing 2002::/16 in the other direction.

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 1:15 UTC (Thu) by bojan (subscriber, #14302) [Link] (22 responses)

Bullshit:

------------------------------
[bojan@shrek ~]$ dig +short AAAA ipv6.google.com
ipv6.l.google.com.
2404:6800:8004::68
[bojan@shrek ~]$ ping6 ipv6.google.com
connect: Network is unreachable
[bojan@shrek ~]$ dig +short www.google.com
www.l.google.com.
66.102.11.104
[bojan@shrek ~]$ ping -c 1 www.google.com
PING www.l.google.com (66.102.11.104) 56(84) bytes of data.
64 bytes from syd01s01-in-f104.1e100.net (66.102.11.104): icmp_req=1 ttl=55 time=18.3 ms

--- www.l.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 18.333/18.333/18.333/0.000 ms
------------------------------

As I said, useless.

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 1:40 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (21 responses)

Did you happen to try actually assigning one of those IPv6 addresses to your PC? Just as with IPv4, if you don't designate which public IP address to send packets from (out of the 2**80 6to4 addresses available to you) you're not going to get anywhere. IPv6 routing via 6to4 is trivial to configure on any modern system possessing a public IPv4 address, but you do have to put a modest effort into setting it up.

DJB's proposal to make all public IPv4 addresses directly routable as IPv6 addresses would save a trivial amount of reconfiguration (the easy part) in the short term, while IPv4 addresses are still dominant. It would not avoid the necessity of updating all existing OS and application software, routing hardware, and address-aware network protocols, scripts, etc. to deal with the longer addresses, which is the real bottleneck standing in the way of IPv6 adoption.

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 1:50 UTC (Thu) by bojan (subscriber, #14302) [Link] (20 responses)

> Did you happen to try actually assigning one of those IPv6 addresses to your PC?

Why should I? I already have a perfectly good setup here. I can browse, e-mail and do other things on the real net just fine. For instance, I can post this comment on LWN just fine :-)

> trivial amount of reconfiguration (the easy part)

Trivial? I think you haven't read the article above:

> To make that transition, we'll have to do more than assign IPv6 addresses to systems. This technology will have to be deployed across something like 1.8 billion people, hundreds of millions of routers, and more. There's lots of fun system administration work to be done; think about all of the firewall configuration scripts which need to be rewritten. Geoff's question to the audience was clear: "you've got 200 days to get this done - what are you doing here??"

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 2:33 UTC (Thu) by cesarb (subscriber, #6266) [Link] (19 responses)

Do not try to move the goalposts. All this was an answer to "Right now, nobody with an IPv4 address can even attempt send a packet to anyone with an IPv6 address.", which said nothing about the amount of configuration needed.

From my own experience at work, it was very easy - a few lines in /etc/network/interfaces on the firewall/router, and install and configure radvd on the same machine (its configuration was also only a few lines and very simple). That was enough to make every computer on the network have working IPv6 (even the printer, which surprised me). Yes, I did not have to do anything on any machine other than the router.

And there is also teredo. With it, any machine with an IPv4 address, even behind most NAT setups (as long as the teredo port is not blocked by a firewall), can use IPv6 (not only outgoing but also incoming).

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 2:46 UTC (Thu) by bojan (subscriber, #14302) [Link] (18 responses)

Not shifting anything. You have some Joe Sixpack on IPv4 now. He simply cannot use IPv6 network. And why? Because someone decided that he needs a new address, when he's got a perfectly valid one. Or that he needs to "reconfigure" a perfectly good setup for no immediate benefit.

See the sentence in my post you replied to:

> No, his idea is a common sense one: people already connected to the net should not have to reconnect.

I have no idea why people are trying to justify this screwed up plan. It's a bit like Itanic. We'll have this beautiful new CPU, but _all_ application writers will have to optimise software for it when they compile their apps. Brilliant plan. Just like the current reconfiguration of every single working setup out there.

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 3:21 UTC (Thu) by foom (subscriber, #14868) [Link] (17 responses)

> You have some Joe Sixpack on IPv4 now. He simply cannot use IPv6 network. And why? Because someone decided that he needs a new address, when he's got a perfectly valid one.

Sorry, but that's bullshit. Joe Sixpack's computer will *automatically configure itself* to start using IPv6 as soon as it's attached to a network which supports it, similarly to how it automatically configures itself to use IPv4.

Mr. Fancypants System Administrator might have to change *his* configuration to get all his services talking IPv6 (he probably has custom firewall rules, has services listening on specified some subset of IP addresses assigned to the host, etcetc), but Joe Sixpack most certainly does not -- his OS just supports it out of the box, and will magically start working.

Getting everyone using routers with IPv6 support is the tricky part. But that's required no matter what!

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 3:30 UTC (Thu) by bojan (subscriber, #14302) [Link] (16 responses)

> Sorry, but that's bullshit. Joe Sixpack's computer will *automatically configure itself* to start using IPv6 as soon as it's attached to a network which supports it, similarly to how it automatically configures itself to use IPv4.

Oh, really? Right now we have lots of such networks floating around? 20 years after the problem has been identified and we're on the brink of IPv4 address space exhaustion? Not even close. That exactly is the problem.

> Mr. Fancypants System Administrator might have to change *his* configuration to get all his services talking IPv6 (he probably has custom firewall rules, has services listening on specified some subset of IP addresses assigned to the host, etcetc), but Joe Sixpack most certainly does not -- his OS just supports it out of the box, and will magically start working.

So, both are really screwed. Joe Sixpack has no network to connect to (e.g. me being Joe in this case - no IPv6 in sight unless I specifically buy new equipment, request IPv6 from my ISP etc.). And Mr. Fancypants is up for many a late night. Just peachy.

> Getting everyone using routers with IPv6 support is the tricky part. But that's required no matter what!

Well, yeah. If the plan to have v4 embedded into v6 was followed, this would have been around years ago. And you wouldn't even know you had it.

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 8:16 UTC (Thu) by roblucid (guest, #48964) [Link] (1 responses)

Yes, and simply because until you cannot add new connections to the IPv4 Net, there's no incentive (outside of enthusiasts) to move to IPv6.

What's needed is a global IPv6 network. That requires the big content providers and the big ISPs to meet and say, "we want to be able to serve new customers not stagnate" so we need to invest and facilitate a transition.

That will only happen, and the investment made when the address scarcity bites.

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 8:31 UTC (Thu) by bronson (subscriber, #4806) [Link]

> That will only happen, and the investment made when the address scarcity bites.

And maybe not even then. There's still a good chance that someone will invent a more practical solution than ipv6. Necessity can be such wonderful inspiration.

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 10:10 UTC (Thu) by dan_a (guest, #5325) [Link] (5 responses)

One of the reasons why IPv6 is being introduced, separate to the address space exhaustion issue, is because of an explosion in the size of routing tables.

By aggregating together large numbers of fragmented IPv4 routes which belong to the same autonomous system the routing table shrinks massively which theoretically reduces router memory requirements and routing table lookup times.

If we kept the old, fragmented, IPv4 routes in the new IPv6 table then this benefit would never ever be felt. That's why the global migration plan does not include embedding existing IPv4 addresses in IPv6.

The routing table issue

Posted Jan 27, 2011 14:48 UTC (Thu) by mstefani (guest, #31644) [Link] (2 responses)

And how does IPv6 alleviate the routing table explosion?
By assuming an hierarchical internet where everybody but the tier 1 providers are single homed? And to enforce their "reality" they didn't give out provider independent IPv6 addresses? That helped tremendously with acceptance of IPv6 in the enterprise space </irony>. Grudgingly they had to change that policy a couple of years ago. That brought the routing table explosion problem back. And it would make matters even worse due to the increased size of the IP address. The fix? Ignore the problem for now as IPv6 is barely used...

IPv4 addresses run out this year? We run into the routing table issue 8 years ago. Trying to route something smaller than a /24 is an exercise in futility. But we had even fun like "Your IP address is from an IP space that is allocated in /20 blocks; we are filtering out any routes smaller than that. Have a nice day."

The routing table issue

Posted Jan 27, 2011 15:41 UTC (Thu) by foom (subscriber, #14868) [Link] (1 responses)

> By assuming an hierarchical internet where everybody but the tier 1 providers are single homed?

Actually the (completely unworkable) idea was that people who had multiple providers would simply have multiple IP addresses, and advertise all of them. That *possibly* could have even worked (with a lot of effort) if TCP supported multiple endpoints and transparently switched between them in real-time. But, it doesn't.

The one (pretty minor) remaining thing IPv6 does to help reduce routing-table size is reduce fragmentation of the address space -- a single organization at a single location is less likely to need multiple non-contiguous addresses spaces than in IPv4.

The routing table issue

Posted Jan 28, 2011 7:20 UTC (Fri) by butlerm (subscriber, #13312) [Link]

That *possibly* could have even worked (with a lot of effort) if TCP supported multiple endpoints and transparently switched between them in real-time. But, it doesn't.

That is why they invented SCTP, which does all that and more. Perhaps too much even.

DJB was wrong... even if he was right too.

Posted Jan 28, 2011 7:18 UTC (Fri) by cmccabe (guest, #60281) [Link] (1 responses)

Moore's law is still holding. Twice as many transistors will be able to fit on a single chip 18 months from now.

On the other hand, the world population growth rate is well under 1% per year (according to wikipedia.)

Sound like the routing table problem will solve itself pretty quickly, without us doing a thing.

Nope.

Posted Jan 28, 2011 12:20 UTC (Fri) by khim (subscriber, #9252) [Link]

Routing table is supposed to handle devices, not people. Population is not growing, yet number of devices is growing exponentially. You have computers, mobile phones, power meters and other gadgets connected to the internet. Often they use totally different networks. Heck: there are more mobile phones users then there are IPv4 addresses! So no, Moore's law will not save us.

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 13:49 UTC (Thu) by foom (subscriber, #14868) [Link] (7 responses)

> > Getting everyone using routers with IPv6 support is the tricky part. But that's required no matter what!
> Well, yeah. If the plan to have v4 embedded into v6 was followed, this would have been around years ago. And you wouldn't even know you had it.

So why would anyone have added support for an IPv4 "long address" option which wasn't even being used by anyone? They wouldn't have, any more than they added IPv6 support. Both things are equivalent: addition of a new feature to your software that none of your customers are going to actually use.

My router could have added IPv6 support 10 years ago, too, without me knowing it. But it didn't.

Cable modems didn't get IPv6 support until DOCSIS 3.0, which only *just* started showing up in new devices. It looks like they've also released an addendum to DOCSIS 2.0 to allow older hardware to add IPv6 support -- in November 2010. So *maybe* firmware upgrades for older devices might add IPv6 support in the future (but I'm not holding my breath)...

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 20:08 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

software developers are frequently willing to add features that aren't yet needed (just to get bragging, marketing rights), but only if those new features are not huge and invasive.

the 'implement a new stack, with mandatory features that are complex, and largely unknown' aspect of IPv6 made it a major project, not something that could be added in easily.

Hardware

Posted Jan 27, 2011 21:15 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (2 responses)

And yet all the _software_ developers who matter did just this. I was using IPv6 _software_ ten years ago, maybe closer to fifteen now. Our biggest worry in _software_ is Microsoft Windows 95, long obsolete and unsupported, but widely used for the same reason people are still watching TVs with dial tuners (yes, really, they are even in countries with DVB - backward compatibility is a bitch)

So software is great, it's enough to have IPv6 in your house, share it with a few friends in a tiny startup's office, or even across a few hundred hosts if you can afford a beefy FreeBSD box as a router. All these things were being done last _century_ in preparation for the transition we are now undertaking.

But that only gets you so far. Eventually (today probably somewhere about gigabit speed) it is only cost effective to switch IP with custom hardware designed for that specific purpose. Eventually the cost of wider addresses doesn't vanish, but instead dominates. And there the story changes.

Hardware

Posted Jan 27, 2011 21:31 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

the latest generation of networking technology always requires custom ASICs, back in the 90s you needed ASICs for 10Mb switching.

this is part of the problem, by designing IPv6 so that everything had to change we have these problems. If this was something backwards compatible, that could run through existing devices in the middle without them having to change (think of it as being similar to tunneling, but with every ISP being a potential tunnel termination point without having to configure it explicitly) then we would not have to deal with the ISPs support or lack of it as an issue, only the question of getting enough endpoints to support it.

this wouldn't have solved the problem entirely, but it would have helped.

And if you are claiming that all developers who matter have implemented IPv6, please go back to the earlier post that pointed out that no current generation game console supports IPv6, many printers don't support IPv6, let alone other, smaller embedded systems.

Hardware

Posted Jan 28, 2011 16:13 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

Again, the scenario where any ISP can offer valid tunnel endpoints and have them automatically used without explicit configuration by the user _already exists_

The ISPs don't provide such tunnels because the tunnel would _cost money_ and they don't want to spend money.

DJB was wrong... even if he was right too.

Posted Jan 27, 2011 22:09 UTC (Thu) by bojan (subscriber, #14302) [Link] (2 responses)

> Both things are equivalent: addition of a new feature to your software that none of your customers are going to actually use.

Equivalent? I can't even test IPv6 without obtaining a new address. I could if my IPv4 worked instead. That's why it would get included - it would be actually useful at some point to people _connected_ to the net. In fact, we wouldn't even be talking about the address crunch.

> My router could have added IPv6 support 10 years ago, too, without me knowing it. But it didn't.

Yeah, of course it didn't. Where would you get an IPv6 address from anyway?

DJB was wrong... even if he was right too.

Posted Jan 28, 2011 15:09 UTC (Fri) by zlynx (guest, #2285) [Link]

> Where would you get an IPv6 address from anyway?

Did you miss that every IPv4 address is automatically assigned an entire IPv6 network of its own in the 2002::0 range?

Here is mine, for example: 2002:4051:69fa::1 You should be able to get the web page at http://[2002:4051:69fa::1] or http://oberon.zlynx.org/ The DNS has both A and AAAA records.

See the 4051:69fa? That's my IPv4 address: 64.81.105.250

If home routers were preconfigured with 6to4 and radvd, every home user would already be on IPv6.

Sure, an inefficient IPv6 that is tunneled through IPv4, but it sets the stage for moving to ISP assigned addresses later on.

DJB was wrong... even if he was right too.

Posted Jan 28, 2011 15:53 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

You can test almost everything via a tunnel. The various _automatic_ tunnels which other people have mentioned all use your IPv4 address in order to assign you an IPv6 unicast subnet for your use.

In this scenario you are an IPv6 island, connected to other IPv6 islands by tunnel. If they _wanted to_ ISPs could compete by providing a tunnel endpoint closer to their subscribers, so IPv6 would work faster on their network than on a competitors. Technologies like 6to4 even made this very easy by using an anycast address, so the ISP can put the tunnel endpoint anywhere with no config change for the user. The natural endpoint of such competition would be native IPv6, no tunnels.

But the major ISPs as we've tried repeatedly to explain, do not care. If the closest endpoint is on another continent, why should they care? Providing the minimum possible service is a cost saving. So if you try to use such a tunnel, expect poor performance and zero technical support from your ISP. It's just not in their interest to care.

Have I told the story about the cable TV company who added a "digital surcharge" to pay for equipment upgrades ready for digital cable? I bet you're thinking that they had to do that - to pay for the upgrades, right? Nope, there were no upgrades. It was just another way to get more money. When digital cable actually arrived they couldn't offer it, because their equipment was too old. No matter, the customers still have money, just charge them again.

LCA: IP address exhaustion and the end of the open net

Posted Jan 30, 2011 14:23 UTC (Sun) by trekker.dk (guest, #65149) [Link]

From article:
Currently, NAT routers are an externalized cost for Internet service providers; they are run by customers and ISP's need not worry about them. Adding more layers of NAT will force ISPs to install those routers. And, Geoff said, we're not talking about little NAT routers - they have to be really big NAT routers which cannot fail. They will not be cheap.
Well, I don't know about US/Australia, but this seems to me like something we're doing for a long time around here (CZ). Most people get internet connection behind NAT by default (only exception I'm aware of is ADSL.) Sometimes (depends on your ISP) you get globally-visible IP when you ask, sometimes you have to ask and pay for it and sometimes - bad luck.

LCA: IP address exhaustion and the end of the open net

Posted Feb 1, 2011 17:02 UTC (Tue) by b7j0c (guest, #27559) [Link]

you have to wonder....how many sites out there have hardcoded ipv4 into dbs, regexes, etc etc....the transition to ipv6 could make y2k look like a picnic.
get ready to see a whole new industry of ipv6 consulting


Copyright © 2011, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds