Vint Cerf Keeps Blaming Himself For IPv4 Limit 309
netbuzz writes "Everyone knows that IPv4 addresses are nearly gone and the ongoing move to IPv6 is inevitable if not exactly welcomed by all. If you've ever wondered why the IT world finds itself in this situation, Vint Cerf, known far and wide as one of the fathers of the Internet, wants you to know that it's OK to blame him. He certainly does so himself. In fact, he does so time and time and time again."
Things people do... (Score:5, Insightful)
Is this a backwards opportunity taken for asserting that he is one of the Fathers of the Internet?
Glad thats sorted out! (Score:5, Insightful)
Cool. Now that we've assigned blame, hopefully we can move forward with FIXING the problem.
Since there is already a fix available (IPv6), if/when this DOES become a problem, THAT problem should be assigned squarely on the shoulders of the people who failed to implement the FIX in a timely enough manner.
Frankly... (Score:4, Insightful)
Vint Cerf should blame himself for the IPv6 mess instead.
Don't blame him, thank him. (Score:5, Insightful)
It's a good thing IPv4's address space is 32-bit. Without that limitation we'd never move to IPv6 and get all of the other benefits that it offers.
Re:Bogus shortage (Score:5, Insightful)
Re:Bogus shortage (Score:4, Insightful)
There are more people on Earth than there are IPv4 addresses. There is a true shortage, whether companies are sitting on address blocks or not.
IPV6 is the problem. (Score:4, Insightful)
Choosing 32 bits for IPV4 was reasonable at the time when 56kbps was considered a fast link.
The real problem is that when IPV6 was designed it did not allow IPV4 to be included as a subspace.
so you cannot have an IPV4 address that is a valid IPV6 address.
That means that there is no soft migration path from IPV4 to IPV6.
The people who designed IPV6 did not consider the problems of real world users;
they designed in a vacuum. A properly designed IPV6 would be in widespread use by
now, and the problem would be under control.
Re:And then what? (Score:3, Insightful)
Who is this Vince you speak of and why are we blaming him instead?
Vince, vint, whatever. Listen up unix beardlings because I am about to drop some real history and knowledge on you.
He is some surfer guy who was too stoned on Maui Wowie to figure out we needed more than 3.4 Billion Addresses.
His name is Vint Cerf, and actually is the REAL REASON why we call it "web surfing".
Back in the olden days before young punks like you had global village modems, ISPs and dialup access and stuff,
us oldbeards were sitting pretty on T3's, "Cerfing" the internet. Well, it wasn't long until Cerf became Surf, and
that you young whippersnappers is how the fax machine was invented.
Re:Is it a software patents issue? (alan cox) (Score:3, Insightful)
If this is true then wouldn't it mean that IPv6 won't get adopted until 2018? 20 years after the original RFC was published.
I personally think the problem is that compatibility with IPv4 seems like it was an afterthought. The designers of IPv6 should have designed the system so that individual computers/routers/networks could be upgraded independently of each other in much the same way you can easily upgrade your network from 100mb to GigE.
Re:an alan cox interview (Score:3, Insightful)
No one at Cisco is releasing big IPv6 routers.
Not because there's no market demand, but because they want 20
years to have elapsed from the publication of the standard before
the product comes out -- because they know that there will be
hundreds of people who've had guesses at where the standard
would go and filed patents around it. And it's easier to let things
lapse for 20 years than fight the system.
I'm glad to see our patent system is still "promoting the progress of science and the useful arts". :^P
Wrong. (Score:2, Insightful)
Re:Things people do... (Score:4, Insightful)
Is this a backwards opportunity taken for asserting that he is one of the Fathers of the Internet?
I would say so. Below is the references section of RFC 791 [ietf.org]. Cerf shows up only on the "Catenet" article while the bulk of the heavy lifting was apparently done by John Postel, a rather more humble person it would appear. And Bob Kahn, who for some reason does not appear in these references. On the whole, Cerf seems to have mainly acted as a PM and money man.
[1] Cerf, V., "The Catenet Model for Internetworking," Information
Processing Techniques Office, Defense Advanced Research Projects
Agency, IEN 48, July 1978.
[2] Bolt Beranek and Newman, "Specification for the Interconnection of
a Host and an IMP," BBN Technical Report 1822, Revised May 1978.
[3] Postel, J., "Internet Control Message Protocol - DARPA Internet
Program Protocol Specification," RFC 792, USC/Information Sciences
Institute, September 1981.
[4] Shoch, J., "Inter-Network Naming, Addressing, and Routing,"
COMPCON, IEEE Computer Society, Fall 1978.
[5] Postel, J., "Address Mappings," RFC 796, USC/Information Sciences
Institute, September 1981.
[6] Shoch, J., "Packet Fragmentation in Inter-Network Protocols,"
Computer Networks, v. 3, n. 1, February 1979.
[7] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and
Newman, August 1979.
[8] Postel, J., "Service Mappings," RFC 795, USC/Information Sciences
Institute, September 1981.
[9] Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences
Institute, September 1981.
Re:IPV6 is the problem. (Score:4, Insightful)
IPv4 was created decades before 56kbps was considered a fast link.
I've heard this complaint before about IPv6 not being backwards compatible, but, and no offence, I've never heard a constructive argument about how it should have been designed. I have my doubts that people who make this complaint have actually sat down and worked through the details of how they would have made IPv6 backwards compatible.
Consider a hypothetical IPvA (short for IPvAwesome) which obsolesces IPv4 and is backwards compatible. We have to imagine that the IPvA address space is bigger than 32 bits, either a fixed larger address space or a variable-length "extension" address stuck in the optional parts of the IP header or something like that. The problem is that no matter what mechanism you choose, every packet you send across the Internet is going to hit a 10 year-old router that's never even heard of IPvA. There's a 100% chance this router will have no idea whatsoever what to do with the parts of the IP header it's never seen before. If you're lucky the router will just drop the packet as being malformed. If you're unlucky maybe it'll do something silly like truncate the packet down to the RFC-specified 32-bit IPv4 address and your reply packets will end up getting routed to China somewhere.
The problem is this: whatever protocol you put in to replace IPv4, most of the infrastructure on the Internet will have no idea what to do with it. That means it's virtually impossible that you'll ever be able to seamlessly bridge between stupid old ignorant IPv4 routers and the more aware routers.
What you could do is have routers that nicely bridge between IPvA and IPv4. So you send out an IPvA packet and it magically finds its way to a router that speaks both IPvA and IPv4 and can nicely bridge between them. That would be cool, and in fact, I've just described to you how 6to4 works.
Truth be told, even you sat down and came up with a new protocol that was designed for nothing else but bridging between codgy old IPv4 routers and some kind (any kind!) of new Internet protocol, I doubt you could do better than IPv6 and its cohorts (6to4, 6over4, 6in4, 4in6, etc.)
Maybe I'm missing something, but if you're going to make this complaint, you're going to have to come up with something better than "they didn't think about backwards compatibility". They did think about backwards compatibility and they did it in the best way possible from what I can tell.
Re:Glad thats sorted out! (Score:3, Insightful)
IPv6 is a good example of a fix to an existing problem which adds more problems in the meantime.
It's like an application bug/security fix which adds a new user interface, which is entirely different than the original, exports different functionality, and has a massive learning curve. If a vendor were to release something like this, they'd be laughed at and ridiculed until they released a proper 'fix' which didn't break functionality and usability.
Whatever the fix may be, it needs to be backward compatible - and by backward compatible, I mean older devices with IPv4 stacks need to be able to talk to IPv6-only address space. "Running two competing and partially compliant network stacks for compatibility" is about as stupid and complicating as having to reboot to use different applications in another OS: sure, it's one possible solution, but it is by no means ideal or preferred.
People - like the the writers of the wikipedia IPv6 article - fail to grasp the scope of IPv6 compatibility issues with statements like "IPv6 compatibility is mainly a software/firmware issue like the year-2000." No; no it is not like the Year 2000 bugs: those were present in only a handful of currently-used systems, had massive financial backing (due to most of them occurring in big-money industries), and did not impact common system operation unless year-2000 compliance was strictly required by the applications (most did not).
Today, most applications are "Internet aware". There are tens of thousands of different vendored applications and hardware device variants out there which are IPv4 only. The consumer - never mind business - cost would we HUGE.
Look, it's not like the internet would stop working when IPv4 exhaustion occurs. We're not even talking about tenacious limited supply like Peak Oil or Lithium. There are ways to free up years worth of IPv4 address space, and beyond that, there are further ways to reduce address space use - ways which are actually fairly congruent with good network administration practices.
While NAT may have been conceived as a fix to a routing problem, there's a reason we've got non-routed address space; the same applies to why it's a good idea to have as few exposed services on an interface/IP/network. Resorting to NAT for a lot of uses, where it is currently not used, would be a good step (UCal and Berkley, we're looking at you and your friends.)