A Humorous Introduction To IPv6
zollman writes "Jonathan Richards, in the London times, explains how the introduction of IPv6 will change the Internet. From the article: 'As use [of the Internet] grew, it became clear that the old protocol, IPv4, wasn't big enough, so a new one was created using 32-bit numbers. That increased the number of available addresses to 340 undecillion, 282 decillion, 366 nonillion, 920 octillion, 938 septillion -- enough for the foreseeable future.'"
From the kernel.org FTP:
linux-2.1.8.tar.gz 6032 KB 11/09/1996 12:00:00 AM
Goten Xiao
Not even close.
2 to the power of 128 is approximately 10 to the power of 38.
There are, however, over 10 to the power of a hundred atoms in the universe.
A 1 followed by 38 zeros is, iirc, approximately the same order of magnitude as the number of molecules in the earth's crust.
File under 'M' for 'Manic ranting'
Every mobile device is individially addressable right now by its number and network (12223334444@serviceprovider.com) - effectively a single IP address. Since this is also its voice number, it's easy to remember and convenient. We won't be running out at anytime soon (10 billion mobiles per service provider capacity).
Each IP address can also directly address 64K computers, via the existing port structure. IP addresses can also be reused (over and over) on intranets and subnets, via NAT. Yes, it's a terrible thing - but we've already solved that problem, and the solution is in use (and works) worldwide.
Issues like bandwidth control and management are only symptoms of limited bandwidth. Every day that issue will become less and less of a problem (at the endpoints). Core network technologies are expanding bandwidth at an incredible rate. In 1995, core networks used T1 lines! Now, they are deploying OC-768. The bandwidth controls will be meaningless long before a conversion to IPV6 could be completed.
All in all, if IPV6 were being deployed in the early 1990's it might have made sense to avoid some of the pain we went through. Now, its like the pre-IP protocol stacks - its time has passed.
Can You Say Linux? I Knew That You Could.
This really pisses me off. I'm so sick of reading newspaper articles that read something like this:
...where all of the quoted terms are legitimate technical terms. If I turned the tables, and wrote a letter to the editor, saying:
...you know that they would be annoyed, because the quotes and the "so-called" make it sound like the term is not really what it's called, and that it's not really true. If writers are concerned that a reader doesn't know a term, there's no point in putting it in quotes to reassure the dumb reader that they're not dumb. It's much more helpful to write something like this:
Sure, it's a little choppier, but good writers can weave things together better (I could if I weren't lazy and I wasn't posting on Slashdot), and this form provides much more knowledge. Frankly, reporters shouldn't be writing about stuff they really have no clue about. I think if someone's going to be writing about internet addresses, it isn't much to ask that someone explain the rudiments of bits and bytes and binary numbers to them before they run off and misinform the public.
ttuttle is a rankmaniac
Duct tape is like the Force. It has a light side, a dark side, and it holds the universe together.
First, if you're going to do a design that involves a "big number", it is helpful for the number to actually be "big". If you're going to have addresses of a fixed size (and there are good technical reasons for doing so) then your addresses should all be "big" so that you don't have to change your addressing scheme at some point. Among the numbers that were thought to be "big" but which didn't turn out to be are the number of cylinders in an ST-506 hard drive, the number of bytes in an 8086 segment, and the number of IPv4 addresses.
Second, initial experience with IPv4 showed that addresses would be assigned very inefficiently. It was initially expected that most networks would assign fewer than 1% of their addresses to computers. In fact, the allocation efficiency of IPv6 addresses is tiny by design, as the promoters of IPv6 expect that the minimum allocation of addresses to a single host to be a /64, which means that there are really enough addresses to give 92,000 /64's to every square meter of the earth's surface. Actually, I think that 92,000 is wrong. The number I have for the earth's surface area is 510.0501e6 square kilometers which works out to about 36,000 /64's for each square meter of earth's surface. Maybe you were thinking millionths of a square mile, because then 92,000 would be about right, but that's kind of an odd unit.
Anyway, of course when people started allocating addresses willy-nilly, people learned to use IPv4 addresses more efficiently, (my home network has more than 2 computers on it for each real live IPv4 address I get with my feed) but IPv6 will always assign addresses inefficiently. I would expect that people will make use of that fact should use of IPv6 ever become widespread.
This article is actually on the front page of the Drudge Report right now (www.DrudgeReport.com), a heavily trafficked news website that is read by a lot of politicos. I think that the intended humor here was that the rest of the world just learned about IPV6, when it has been around for a lot of time. I'm guessing a couple years from now there will be headlines about the "new DVD's" that can store 50+ gigabytes of information on them. "That sort of capacity ought to last us for a while."
To give some examples of what goes wrong when you ignore ALT: The IBM PC was able to address the absurdly huge limit of 640K of RAM. Microsoft Excel to this day cannot address more than 65,000 rows in a single spreadsheet, which is nowhere near enough for high finance and some datalogging applications. The maximum addressable drive (partition) size used to be 8GB. Oh, and we're going to run out of IPV4 addresses right about the time my refrigerator needs a static IP to host my lettucecam.
Help stamp out iliturcy.
IP version 5 was reserved for Internet Stream Protocol Version 2 (ST2, RFC 1819), however it turned out that IPv6 was better, so they stopped working on it.