MIT Technology Review Slams IPv6 709
PCM2 writes "In the MIT Technology Review, Simson Garfinkel, noted author of Internet security books, writes that "the next version of the Internet Protocol, IPv6, will supply the world with addresses by the trillions. Too bad it will also make the Net slower and less secure." His article goes on to explain that all IPv6 code is untested and therefore insecure; that IPv6 makes encourages 'peer-to-peer based copyright violation systems'; and of course, that the switch is never going to happen anyway (and yet, somehow, the United States is 'falling behind')."
Another "IPv6 won't be here soon" article... (Score:5, Informative)
Good summary of CIDR and NATing adoption, too.
Re:Is this technical or political? (Score:5, Informative)
These problems go away when every computer on the Internet really does have its own IP address--something that's impossible today with IPv4, but which is the raison d'etre for IPv6. In a world with IPv6 and without NAT, every computer in my house has its own unique IP address on the public Internet. That means my desktop can open up a peer-to-peer connection with my desktop at work, but it also means that my daughter can network her machine directly with some teenybopper P2P network in San Jose. Getting everybody's home machine out from being a NAT box should make possible a lot of interesting applications that are either very difficult or downright impossible today. And in all likelihood, some of those applications will not be popular with the Recording Industry Association of America or the Motion Picture Association of America, both of which have taken the lead against peer-to-peer networks. As soon as they understand what a threat IPv6 is to their police actions, they are likely to start fighting against.
Re:IPv6 Support (Score:5, Informative)
Re:IPv6 Support (Score:5, Informative)
If by 'routers' you mean Linksys, Belkin, or D-Link, you really need to redefine your concept of the word.
Re:MIT is one to talk (Score:5, Informative)
Re:How will IPv6 affect existing internet tools? (Score:5, Informative)
Will I need to update my apt.sources file?
Probably not if your favorite apt servers support it as well. Most of the switching over is handled by DNS (which has had v6 support for quite a while).
Re:Excuse me but... (Score:5, Informative)
Remember people, IPv6 has been around in RFC form since December 1998 (5 years) - the adoption rate simply hasn't matched what was seemingly necessary.
Besides, ARIN isn't even close to full address depletion. There's so many spare
Garfinkel Math (Score:5, Informative)
Damn,
with only 3 routers at the medium-sized business I work
for, this is going to cost us $187,500 !!!
No IPV6 for us
Re:Excuse me but... (Score:5, Informative)
1) I will define 'IP' for you now
2) This is why we need more Internet addresses (something above and beyond IPv4)
3) One problem with IPv6 is that no one uses it now. So the best thing to do is to make dual v4/v6 machines. But then you can never make v6 only because someone will always have v4. (wtf? 'we can never adopt v6 because we have not yet adopted v6'?)
4) NAT is super evil because its security is "a mirage"
5) The RIAA and MPAA will probably hate IPv6 because people can connect to each other more
6) IPv6 will only be introduced in the US when a government supplier wants it
I think that timothy must've posted this without reading the article itself -- or I've read the wrong article -- but the article author _NEVER_ says 'untested and therefore insecure', only talks about the increase in p2p applications as 'interesting' and likely to be opposed by the *AA, and the problems posed by inertia in the US as opposed to adoption in Asia.
NOWHERE does he slam IPv6 - he seems rather happy about it, in fact.
Re:IPv6 Support (Score:5, Informative)
The problem with IPv6 isn't software or hardware -- it's politics and money. Theres no benefit to service providers to update their IPv4 setup to do IPv6 because they'd have to find some way to still talk to the "normal" IPv4 internet (because, really, who wants to get on an ISP that isn't on the internet?). Additionally, many many ISP's charge a premium on extra IP addresses. What makes you think that they want to ditch that income so you and I can each address our refrigerator from the supermarket to see how much milk is left?
Re:MIT is one to talk (Score:3, Informative)
FUD on Speeds: IPv6 vs IPv4 (Score:5, Informative)
On this simple fact I assume that the author of this article just don't know what he is talking about. As for security and as for NAT (which is less secure than he even thinks it is, as a protection).
IPv4 has seen many, many security issues in the *recent* past btw (ISN Prediction anyone ? Spoof with any ip)
He also forgot that there are tunnels from ipv4 to ipv6 and from ipv6 to ipv4, effectivly adding compatibility. If someone is stuck with ipv4 somewhere on the globe, np, he setup a tunnel to ipv6 and none is stuck. Damn FUD, I say.
refs:
IPv6 FAQ [iij.ad.jp]
Routing [66.102.7.104]
(IPv6 has less headers => faster routing
(Better QoS => more efficient network
(etc.)
Re:NAT is bad? (Score:3, Informative)
NAT is a good idea for certain limited applications. Internet-enabled dishwasher? No problem*. Web browsing cell phone? Perfect. But for a general purpose computer running arbitrary applications, it's very constraining. Just look at the discussion surrounding Speakfreely [slashdot.org] and you can see some of the problems that happen when you turn on NAT. Basically, you turn a computer into a consumer of Internet services rather than a participant.
Depending on where the NAT translation is being done, there are ways around it. I have a static address with a good wireless provider, so the NAT is being done by my own router. I've told it to forward requests to ports 80 and 22 to my Linux box, so I can serve web pages and SSH into it.
But if the NAT is being done by the ISP directly, they have full control over who can make requests to your computer from the outside. Nobody can make requests of your computer from the outside, which eliminates both intrusions and ordinary requests for services.
* Though I'm still curious why my appliances need to surf the web. How can we not see that we're handing them the tools they need to organize and revolt against us?
Re:Excuse me but... (Score:3, Informative)
Re:untested code... (Score:1, Informative)
Also you may have noticed NO protected mode DOS apps run in XP. Because XP *IS* running in that mode.
The Win 3.1/9x series of 'OS' was ontop of DOS. They were what OS people call a shell or running enviroment.
Also the one thing I have against that very poor document is this. It was trying to prove something thats not really a problem one way or another. Also my fav out that was that its less secure because its all new code. Well sorta. You do not see too many problems out of the tcpip stack. Typicaly its out of the particular protocols that use the stack. They overrun some buffer inside the protocol code (or stack smashing). Thats akin to saying lets stop making anything new. Progress should stop because it might maybe possibley be insecure. What bunk!
1 dude out of MIT saying the thing is bogus is hardly the whole college saying it...
Also most of the 'shortage' is due to bad allocations. MIT is a good example of it. They have 16 million address's. Would it really be that big of a burden to MIT to fix this? Do they really need THAT many? If some parts of the world do not get the address they want they will leave the IPv4 world behind and just NAT in when needed.
Also his artical is disingenuous with his numbers. He got two different numbers and compaired them in the wrong way. 1.3 billion people have 23 million address's. OF that 1.3 billion most can not even afford a computer much less a ISP. The 23 million is what they currently need. Once again BUNK!
I am not quite sure what his artical was trying to prove. I think it was, IPv6 is bad mmmmmmkay.
Re:MIT is one to talk (Score:5, Informative)
They may have once been a reputable magazine, but since Bruce Journey [technologyreview.com] took over, they are more concerned with selling magazines than quality reporting. Mr. Journey used to work for such rags as Time and TV Sports. When appointing Mr. Journey to lead Technology Review, William Hecht said [mit.edu]:
Besides that, Technology Review is twice removed from MIT. They are run by the Association of Alumni and Alumnae of the Massachusetts Institute of Technology which is loosely associated with MIT.
I would really like to know why Slashdot keeps posting fantastical stories from that ratings-driven rag.
Re:Excuse me but... (Score:5, Informative)
Re:IPv4 in IPv6? (Score:5, Informative)
They even made it simple! If my IPV4 address is 203.131.45.99 my IPV6 address will be 0:0:0:0:0:0:203.131.45.99 (there's even an abbreviated notation for a V6 address which would just be
The likelyhood is that the migration to V6 isn't proceeding as fast as possible for political and financial reasons rather than technical ones.
Re:MIT is one to talk (Score:5, Informative)
If you are going to pick on Class A owners, then I think there are plenty you can pick on before MIT. HP owns both the 15 and 16 spaces (16 was DEC, bought by Compaq, and now owned by HP). GE, Halliburton, Xerox, Apple, BBN (x2), FoMoCo, Prudential, Eli Lily, and even the US Postal Service are all official owners of at least a Class A network.
Re:MIT is one to talk (Score:1, Informative)
Everything on campus has a public IP -- no NAT anywhere. One of the largest dorm systems in the country, 2-3 IP addresses per room (depending on occupancy, everyone gets a public IP), and you're telling me that MIT is using an entire class B for one dorm building? What the fuck? They're the ones causing the problem!
Honestly, I'd like to know how many of those IP addresses are UNUSED.
Re:NAT is bad? (Score:5, Informative)
The other problem is more aesthetic than anything... but it can be a problem if the NAT device is badly configured. Because it has to translate incoming and outgoing packets, the NAT device must track the state of the incoming and outgoing connections. This takes memory, and sometimes there's not really any way for the NAT device to tell when the connection has been severed. So it has to time them out, and this can result in connections evaporating without warning when the server and the client want them to stay open.
Fortunately, you can usually set this to something more reasonable with OpenBSD or Linux (or another BSD, Solaris, whatever). OpenBSD 3.4 with "set optimization conservative" waits 5 days. I've never had any problems with that, but it's tweakable if necessary.
It's native in OS X. (Score:1, Informative)
Re:IPv6 Support (Score:2, Informative)
Re:Another "IPv6 won't be here soon" article... (Score:1, Informative)
Re:IPv6: Not Ready for Prime Time (Score:3, Informative)
Assuming it is:
1. Cisco Routers suck at IPV6.
That's kind of an implementation issue rather than a protocol issue wouldn't you agree? If word gets out that Cisco Routers aren't providing bang for buck then there are always alternatives as you have suggested. If performance really matters then IT managers can argue the point that the corporate policy is outdated and has to change...
2. There are too many addresses.
Too many addresses is certainly a better situation to be in than not enough addresses I'd argue. Pretty much everyone in this thread that has had to deal with NAT has put forward that it's a deal with the devil: it's a just barely sufficient hack to a tricky problem.
3. IPV6 addresses are too large.
Extreme amount of memory to hold routing tables? Sure, if addresses were picked at random with no regard for the overall layout of the Internet. There's nowhere in the protocol specification that says all 64 network bits have to be used at once when rolling out. Give every ISP it's own separate chunk of the IPV6 address space to which it can portion out to it's customers, and routing may actually become easier, not harder. With 64 bits used for routing I'm sure every ISP in the world could have way more individual IP addresses than it could possibly need, and there would still be plenty of network prefixes left over. We as a community now have a lot more experience in dealing with address allocation issues than we did in 1970...
4. The IPV6 header is too large.
Oh, please. If you're worried about conserving a mere 20 bytes in each packet don't you think more would be saved by design superior compression schemes for when the data intensive applications like Voice, TV, Radio, etc become an integral part of the internet? Also, what's the difference today if a web page takes 40 seconds to load, or 41 seconds to load?
These aren't discussion points, the complaints are too trivial for that. I would hope that you put a bit more effort into research if I were the one reading your dissertation. IPV6 may not be perfect, so point out some REAL design problems if you're going to try.
Comment removed (Score:2, Informative)
Re:Flaws a little more dramatic than the political (Score:2, Informative)
The Tech Review was right, 32 * 4 = 128. Note that they said the size of the Internet address field (number of bits), not the number of addresses.
Re:Another "IPv6 won't be here soon" article... (Score:1, Informative)
Re:untested code... (Score:2, Informative)
Re:Excuse me but... (Score:1, Informative)
3) One problem with IPv6 is that no one uses it now. So the best thing to do is to make dual v4/v6 machines. But then you can never make v6 only because someone will always have v4. (wtf? 'we can never adopt v6 because we have not yet adopted v6'?)
4) NAT is super evil because its security is "a mirage"
I'm posting this as AC so I don't blow my karma. I actually met Garfinkel, at a Computer Professionals for Social Responsibility "conference" a few years ago. (CPSR over-hyped their annual meeting as a "conference", pledging keynote speakers who did not plan to attend, except Garfinkel of course.)
IMO, Garfinkel was a complete weenie. He basically criticised any change, because it was (by definition) untested in the field and therefore (probably) very insecure. Can't have stuff that's not field-tested getting put in the field. (WTF?) He would then say that to get around this problem, you'd have to phase in {new technology} so that you'd test it as it was rolled out. But then cried over the fact that you'd have all these people on {old technology} and you could never fully adopt the new stuff. Vicious circle, gave me a headache.
At the time, he was using GPS devices as an example, because "someone" might figure out how to illegally tap your GPS and use it to track where you are at any time. So GPS is evil, according to Garfinkel. (!?)
So I'm not surprised to see some of the things that Garfinkel writes in his little article.
Re:Good article but a little too namby-pamby (Score:1, Informative)
Yes, as you say, the IPv6 header is larger. But it's not much larger, and overall the design is much better. They've thrown out a lot of the mandatory crap that should've been optional all along, and they've designed it so that optional things always go in the same order within the packet so that it's easier to do hardware acceleration for a router. (No more of this "these header options can occur in any order" stuff, which is just silly.)
The header isn't even that much larger anyway. There (128 - 32) * 2 = 192 extra bytes of address info in there, but the headers are only 20 * 8 == 160 bits larger.
Plus there are other advantages. The router is no longer responsible for fragmenting packets that are too large. Instead, just like flow control, this is now handled at the two endpoints only. And IPv6 allows for a "jumbo payload" option to have packets larger than 64 kilobytes. These advantages alone would seem to be enough to make IPv6 worthwhile. One day, when we reach the point where packets with very large payloads can go across the entire Internet, IPv6 will have a lower header overhead because it allows larger payloads.
Finally, you're also right that it's not using the 128 bits efficiently. This is by design. Right now, with 32 bits, IP addresses are scarce. I know this because my internet provider won't provide them to me for free. They cost money. This is silly because they are useful, and they are just integers, so why should they cost money? So the question is, what is the utility of eliminating scarcity of IP addresses at the cost of slightly increasing bandwidth scarcity?
Let's let the market answer that question. For earthlink.net, DSL service is $40 per month. A static IP address is an extra $15 per month. There seems to be no bandwidth limit. Bandwidth is too cheap, apparently, to meter. The incremental cost is zero. But a single static IP address is a 37% premium. So what does this example from the market say about their relative scarcity? I would say that trading a little bandwidth for the opportunity to have a static IP address is a pretty good bargain based on these numbers. (Yes, I realize I'm playing fast and loose with the distinction between one dynamic address vs. multiples and one dynamic address vs. one static address. And I realize there are other costs to supplying a static IP address besides overcoming scarcity in the address space. But still, you get the point, and they don't even offer multiple dynamic addresses at all, do they?)
Comment removed (Score:5, Informative)
Re:Another "IPv6 won't be here soon" article... (Score:4, Informative)
Re:Less biased than the summary... (Score:1, Informative)
The organisations entrusted with the large top-level allocations in the new system are very large in IP network terms, covering whole continents and in general answerable to local constituents.
If, for example, people settle under the sea, forming a new human empire of 10 billion previously unrepresented Internet users (very unlikely), then a new top-level entity will come into existence, and be given a many hundreds of billions of networks to issue, (yes, networks, not individual IPs, but full 64-bit networks) to these citizens.
Existing Internet Protocols don't scale well to inter-planetary communication, so it's unlikely that we'll ever need more actual addresses or routes than are technically provided for by IPv6. Therefore allocation policy has concentrated on politics - ensuring that everyone has enough addresses that they can't possibly feel cramped, yet not so very many that scarcity might occur in the future.
Re:Another "IPv6 won't be here soon" article... (Score:1, Informative)
Stanford gave theirs up! MIT could too. (Score:4, Informative)
Re:I hate these articles... (Score:2, Informative)
LinuxInDallas wrote:
Not trying to beat up on you... what you wrote is what people who weren't there commonly say with hindsight. The seeing eye moves, and moving, sees from different viewpoints over time. When 32 bits were selected to provide IP addressing for the the then-new phase, it probably seemed like a lot and any more than that would have run into objections of excess packet overhead and bandwidth waste.
Believe me, if anyone had suggested using more than six digits to store a date 30+ years ago it would have seemed idiotic and wasteful. Mostly these things don't even get discussed beyond unstated limits that are appropriate to the times and the circumstances. A real life example:
In late 1969 or early 1970 I was standing in a mostly empty computer room with people a lot older and wiser than I, and they were discussing what level of New York Stock Exchange trading volumes (as a measure of overall market ticker traffic in all exhanges) we should plan on for our second-generation network and computers, given a lifetime of, say, ten years. Our processing and communication loads were directly related to trading activity in stock, bond, commodities and other markets. NYSE volume was the common metric used to gauge all the market information traffic in the nation for load purposes.
The NYSE was doing, I think, about 6 million shares a day on a heavy day then. Some provision had to be made for growth but no one wanted to be the first to throw out too high a number. They looked at each other in turns in a most peculiar manner.
Finally the VP asked, "Do you think planning for 20 million shares a day would be going too far?" No one else had been willing to venture a number that high, but everyone agreed that that would be a good number for planning the network and computer capacity. Had anyone tried to sell the idea that we should have planned for much more than 20 million, he would have been noted as someone whose assessments were wildly outside the lines.
As it happened, our network and computers had to handle U.S. market information traffic measured by NYSE volumes of 200+ million shares per day before it was replaced by a newer system about 15 years later, and as early as 1976 the major exchanges began delivering information at a gross bit rate 70 times what it had been before. In that original discussion, anyone who might have insisted that 200 million was the right number probably would have lost his job on the spot for being so obviously out of touch with reality.
And so it goes. The viewpoint changes, the givens change, the parameters change, the changes change, and later judgments about decisions made decades earlier are rarely informed enough to be valid. In our case we blew it badly on the estimate of 20-million-share days, but we built our shit so well that it scaled without much difficulty to handle 10 times what we planned for and five years longer life than anyone had hoped for.
Also, system failures were not permitted. But that's another story for another time...
Re:all kinds of paperwork? (Score:3, Informative)
IPv5 was already taken (Score:5, Informative)
Comment removed (Score:3, Informative)
Re:Another "IPv6 won't be here soon" article... (Score:5, Informative)
Toredo lets you do IPv6 even if there is a NAT in the way and is supported by Windows XP.
IPv6 isn't hard, just people need to start doing it.
Re:MIT is one to talk (Score:3, Informative)
Re:Another "IPv6 won't be here soon" article... (Score:4, Informative)
Asia needs IPv6 because they got so little address space (at least that's the perception driving adoption, although in reality APNIC seems to have equitable access to IPv4 addresses). The Japanese government is pushing IPv6 hard, and many Japanese ISPs already support it. The US DoD mandated IPv6 for all new procurements for its key network from October 2003, so it's already causing vendors to have to support this.
As for home and 3G: huge volumes of IP-enabled kit will be shipped in the next 5 years (think TV, DVD recorder, hi-fi, personal MP3 players, fridge, alarm clock with weather forecast built in, etc.)
3G phones in Europe are beginning to mandate this (even my GPRS based SonyEricsson P800 has IPv6 built-in, as do all other recent Symbian phones). Even with GPRS, there are too many mobile phones for IPv4 to be practical and NAT is somewhat painful - this is why you can't do peer to peer from your phone (or laptop when mobile connected).
Peer to peer may be the one thing that really makes IPv6 take off - it doesn't necessarily have to be about copyright violations, of course, and it makes much better use of the processing power of phones, PDAs and laptops than client/server.
I agree that 2005 is not a reasonable prediction for wide adoption - I'd say at least 3-5 years out, depending on the above 'killer app' type scenarios.
Re:Wouldn't it be simpler... (Score:3, Informative)
Re:Out of IPv4 addresses? (Score:3, Informative)
There's none of the current stuff like "well, this packet matches six different network masks. Which one is the smallest subnet?".
IPv6 is built for speed. It's not just IPv4-but-longer.
not ipv4 OR ipv6, transition mechanisms allow both (Score:1, Informative)
There are many transition mechanisms defined and being defined for ipv6. These allow ipv4 only to talk to ipv6 only and all other combinations. Some require dual stacks but many are implemented in other ways.
A huge organization could switch to mostly ipv6 only internally and still interoperate with the Internet at large.
The backbone could switch to mostly ipv6 only and home users could remain using ipv4.
There is no line-in-the-sand switchover required, it can be staged and rolled out over time.
this is political (Score:3, Informative)
Unix Hater at work (Score:1, Informative)