Slashdot Mirror
Vint Cerf Keeps Blaming Himself For IPv4 Limit
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."
Is this a backwards opportunity taken for asserting that he is one of the Fathers of the Internet?
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.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
Vint Cerf should blame himself for the IPv6 mess instead.
Have you got your LWN subscription yet?
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.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
In a speech around 2004, I remember Alan Cox said that the reason IPv6 wasn't advancing was that big software players were afraid to adopt it before it turns 20 in case there are submarine patents / patent ambush.
Anyone got links to confirm / disprove this theory?
http://en.swpat.org/wiki/Patent_ambush
Expert in software patents or patent law? Contribute to the ESP wiki!
Here's an interview where he says it:
http://www.velocityreviews.com/forums/t576610-alan-cox-on-software-patents.html
"""Alan Cox: The same has happened with IP version 6. You notice that everyone
is saying IP version 6 is this, is that, and there's all this research
software up there. 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."""
(More info would be good - any other prominent techs saying this?)
Expert in software patents or patent law? Contribute to the ESP wiki!
It was pre-home computer revolution and nobody thought computers would shrink to the size of everybody's pockets (cellphones). Nobody thought we'd be using machines will a billion bits (or more) or memory. Back than ~4000 was considered a lot (it was the hardcoded limit for the Atari console). Everything was smaller in scale, and Mr. Cerf is not to blame for not predicting the invention of the Web Browser (killer app) and how it would reach into every facet of our lives.
Only those with no imagination---
I can say with a great deal of confidence that plenty of us knew what was coming.
Now who do we blame for 32-bit time_t on 32-bit iron? There's a relatively new OS that lots of people use today that didn't have any ABI concerns when it was in its infancy, yet its creator didn't have the vision to see beyond doing pretty much what everyone else had done before him. (And I won't name him because then I'll just get modded a troll. But I bet you can guess who it is.)
The scary thing is that for every Class A returned to the pool, you only buy like a month of life for IPv4. It's just growing too fast now and we're going to start seeing a lot of stories about people not getting their IP addresses in a year or two. Luckily it won't affect existing customers too badly, but it will be a real limit on growth.
I read the internet for the articles.
... the lesson learned is that whenever you are planning on building something technical, be sure to go wayyyy overboard on the size and scope of the projected requirements in order to future-proof the technology.
Yeah! That's why we should be building CPUs with 1024-bit addresses!
That is all.
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.
Give me Classic Slashdot or give me death!
At the time, XNS, the Xerox protocol for Ethernet networks, was in use. It had 24 bits for the network number, and 24 bits for the device ID. Thinking at the time was that each network would be a local LAN, and "internetworking" would interconnect LANs. Xerox was thinking of this as a business system, with multiple machines on each LAN. So XNS had a 48-bit address spade. That's what we call a "MAC address" today.
The telephony people were pushing X.25 and TP4, which used phone numbers for addressing. Back then, phone numbers were very hierarchical; the area code and exchange parts of the number determined the routing to the final switch. "Number portability", where all the players have huge tables, was a long way off.
The problem with a big address space is that memory was too expensive in those days to deal with huge address tables. A big issue was locative vs non-locative address spaces. In a locative address space, there's a hierarchy - you can take some part of the address and make a local decision about what direction to go, even if you don't have enough detailed information to get to the final destination. IP was originally organized like that - routers looked up class A, B, and C networks. A huge, flat address space implemented using multi-level caches was way beyond what you could do in a router back then. Routers used to be dinky machines, with less than one MIPS and maybe 256K of RAM.
There was a lot of worry about packet overhead. Each key press on a terminal sends 41 bytes over a TCP/IP network. That was a big deal when companies had long-haul links in the 9600 to 56Kb/s range. Adding another 24 bytes to each packet to allow for future expansion seemed grossly excessive. Especially since the X.25 people had far less overhead.
So there were good reasons not to overdesign the system. I don't blame Cerf for that.
The foot-dragging on IPv6 is excessive. The big deployment problem was getting it into everyone's Windows desktop. That's been done.
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.
I don't know about you, but I'm extremely satisfied that my interface's home is in a Class A network.
I mean, who wants to live in a sub-class neighborhood?
$ host -t AAAA slashdot.org
slashdot.org has no AAAA record
$
'nuff said. Our organisation (that's me) is already 96% dual-stack. We treat non-ipv6 connectivity as fatal. When are you gonna do it?
Never, or in more practical terms, less than 6 years after the expiration of the patent. Patents need not be defended like trademarks, and you can "back sue" for up to 6 years of infringement. There was a recent story on /. about a company that bought a little known patent right before it expired, then went about suing everybody and anybody for infringement *after* the expiration, but going back 6 years for damages.
Is it just my observation, or are there way too many stupid people in the world?
Because, since all the hosts behind a NAT share a single routable address, that means to make inbound connections, you need to setup port forwarding. So, say I want to run Skype (which likes to have an inbound port), a game server, and a VoIP application, all of which need to be able to accept inbound connections. Well, to do that, on the NAT Gateway, I need to setup 3 ports to be forwarded to my computer. Only I can use those 3 ports, no one else can. Which means with 64k ports available on the NAT, you can probably only setup port forwarding service for maybe 10k-20k customers. You *might* be able to alleviate this a little bit by using multiple 'public' IPs - say one public IP for every 5000-10000 users on the ISP network.
There's also the issue of 'well known ports' - let's say I want to run a web server - well, almost all browsers expect a web server to respond to connections made to either port 80 or port 443 (for SSL encrypted connections). Likewise SSH, telnet, FTP, rdist, etc all typically use well-known ports. Games using iD Software engines usually accept inbound connections on a particular well-known port (27960). Only one computer per public IP may have port 80 or 443, or whatever, forwarded.
Also, perhaps even more importantly, every outbound connection also uses a port associate with the public IP address being used for NAT. Again, using one public IP for a few thousand users might give you enough ports to mostly work.
Basically, in a world where everyone is behind a NAT, no one can ever accept in-bound traffic from off the 'local' network (I put local in quotes, because in the case of Large Scale NAT, you could probably talk to all the other customers of your ISP directly, but not anyone who uses a different ISP), even when they *WANT* to. Some people like the 'comfort' of thinking that NAT somehow protects them better than a firewall, but I'd personally prefer routable addresses for all my devices, with a firewall that I control on my home router to block in-bound access. That way, I can simply open ports when I *want* inbound traffic, and leave all other closed - but when I do want to run services
I could explain this to you, but I would have to write a science fiction novel to do it. Well ok, I'll summarize the novel. Just remember this is a selective summary; pretend that all sorts of really cool things are happening and my characters are totally interesting and the plot is fucking fantastic. Can you do that for me, Wowbagger? Ok.
In an alternate universe, the IP4 designers did just as you suggest, and the loopback network was Class C. In this alternate universe, other things went in a different direction too. By 2010 we all have CPUs with thousands of cores, but they all run at 1 MHz and programmers discuss ways to improve the linearization of their code.
And we all have a weird crippled piece of shit operating system, which got popular despite all its limitations. (This may seem hard to believe to us, but remember I'm talking about an alternate reality.) One of its limitations, is that its networking code doesn't deal with port numbers, because the designers thought that was a waste of 16 bits. (Computers in this reality have about as much memory as what we're used to, but there are more addresses and the words are 4 bits wide, so working with 16 bit data is kind of a pain in the ass.) Another of its limitations is that is has no IPC as we currently know it. Fortunately in the 1990s some programmers "invented" IPC by having each process use the loopback network, but since there are no port numbers, each process has to have its own address on the loopback network so that the OS can sort out what process gets what message. This inevitably led to mocking jokes:
There were terrible hacks for running hundreds of processes and having them all be able to talk to one another, where a proxy process would emulate a sub-loopback network for 254 other processes and present a single loopback address to the OS. It was such a broken, terrible system, that it delayed the popularization of personal computer networking, so there was no "mainstream" use of the internet and the supply of IP4 addresses lasted much longer. In 2010, there was no non-loopback address shortage; it wasn't expected for another decade.
Then one day a poster named whoasacker got on Hyphencolon and asked, "Why didn't they just use a Class A network for the loopback?" And a poster named Slippery answered, explaining, "In an alternate universe, they did..."
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.