This is simply incorrect. There are many, very good reasons that IPv6 should be adopted. Address space is only one of the many. While it is true that large portions of the IPv4 address space is unused, reclaiming them would, in many cases, force additional entries to be added to the core routing tables ... routing tables that already have, in many cases, on the order of 10,000 entries (reference) This is something that simply cannot be sustained.
However, it is, in fact, being sustained right now. And, given the reference that you listed, the rate of increase seems to be leveling off. And, IF IPv6 was so useable and so advantageous in the core, why are the vendors dragging their feet with implementations? Given your description, it would seem that the folks running the core routers would have jumped at the chance to simplify their routing tables. Maybe they are doing so, but it isn't exactly obvious from anything that I've read.
Which is a perfect segue into one of the major bonuses of IPv6, being that it will allow true prefix-based routing by virtue of the address space it affords. Prefix-based routing means that a typical domain needs to know exactly one upstream host (typical of today) and a relatively small number of downstream routers, trivially distinguished by longest match prefixes. Core routers need only know about the assigned top-level aggregators (TLAs) and routes within their own TLA hierarchy.
Except that in the current implementation, the available TLA addressing space is already exhausted. A source that I read was here (Google cache html, you might want to read the slides directly). His reasoning made sense to me. It's more of an argument of semantics really; the address space is big enough, but we can't divvy it up in an efficient way -- which amounts to "throwing away" a lot of address space.
Quite on the contrary, IPv6 headers are not at ALL extendable. They are of a fixed length, unlike IPv4 headers, which have variable-length options. These variable-length options are problematic for fast-path computations, and have been empirically shown to not be useful in the vast majority of cases.
Perhaps the author was confused by the concept of multiple discrete headers; there is nothing that says IPv4 cannot support the same thing. There is no law that says that an IP packet must directly carry ICMP, TCP, UDP, or some other transport protocol; as a matter of fact, in cases such as IPsec it does not. IPv6 merely removed a portion of the IP header that was seldom if ever used, and says, in effect "if you need this functionality you are better served with a specific additional header". This is easier, both conceptually and processing-wise, for routers and end hosts alike.
Could be. :) There is nothing that says you can't do the header shuffle in IPv4, but very few people do it. Why is that? Because it introduces complexity into something that doesn't need it. If variable-length options didn't work out, what makes variable-size (and variable number!) headers any better? I'll quote from 2460:
"Improved Support for Extensions and Options
Changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future."
Take a look at the difference between IPv4 headers and IPv6 headers. The IPv6 header looks cleaner (if a lot larger) but that's because a lot of things were simply slipped into the extensions. You should actually extend that diagram down another 20 or so lines, to include the routing header, the fragmentation header, the authentication header, the ESP header, etc. Most of these only get processed at the end points, so that's good for the core. Many of them may not appear in all IPv6 packets; this simply adds to the complexity of the protocol, because the recieving stack must carefully deal with each header as it gets to it, in an arbitrary order (althought there is a recommended order). So, functionally, we go from dealing with a fixed-size known entity (with some variable options) to a variably-sized set of headers, some of which could be undefined or unknown to the receiving stack, in a possibly unknown order. Hmmmm. Sounds yummy. In other words, I cringe when I hear the word "flexibility" coming from computer scientists and engineers. Too many bad experiences, I guess. I think that arbitrarily defined headers is a pretty serious security and compatibility issue. The standard does not restrict in any way the designing of custom headers, which means that I could make Joe's IP stack, compatible only with other Joe's IP stacks (and since the headers are encrypted, you'll never see my special header!). More likely, I'll have to upgrade my stack (or kernel, more likely), if I want to use such-and-such a service that requires a new header. Otherwise, my implementation will simply drop the packets. Yay. :(
I don't even know where to start here. For one, IPv6 and IPsec are two completely different things. Second, MD5 and SHA-1 are neither one "encryption", they are hashing algorithms -- and among the cryptographically strongest such hashes in use, to boot. (Although MD5 has been shown to have some (at least potential) birthday attack issues (collisions) recently.) DES, the one encryption algorithm mandated, is admittedly weak; however, as compliant stacks MUST implement these minimum standards, the selection of DES at the time was wise given the United States export policies. Nothing prevents the implementation of stronger encryption; in fact, numbers have already been assigned for several state-of-the-art encryption algorithms.
Ummmm, no. IPsec is a vital and important part of IPv6, as is clearly stated in RFC-2460 (which references RFC-2401 in the Security Considerations section, which is, of course, the IPsec RFC). They are designed to work hand in hand, and two of the first extension headers are authentication and ESP (payload encryption). You really can't talk about one without the other, since ensuring the correctness and valid state of the packet is the responsibility of the security section of the protocol and standard.
And sorry, my fault, hashing algorithms. I just lumped them all together. My point was that if you feel the need to implement encryption at the network layer, then the standard should be something solid, open, tested, and free for everyone to use. The encryption implementation is separate from the IPv6 standard as much as is possible (a good design choice), but a solid standard is needed, and it isn't DES. How many of your "state-of-the-art" encryption algorithms are patented or otherwise unavailable for public use? Are we going to introduce encryption incompatibility at the network layer? Doesn't seem like a good idea to me.
This means that the real gaming scenario is more likely to be that you can fork over an additional $5 a month to reduce your latencies if you so desire. Ditto for reducing jitter in video streams, blips in mp3 radio streams, etc.
Maybe, maybe not. It is not the user who decides what the QoS is going to be, and the individual user's influence on QoS decisions will be minimal at best. The amount of money involved is unknown at this time, but it could be substantial. The amount of space in the IPv6 header dedicated to QoS is three times the amount of the limited IPv4 TOS. Assuming a 100% full connection, if something comes in that is higher priority than my communication, I get bumped. So the company paying for high QoS gets their movies, while my game gets jacked around. The packets may not be lost, but they most definitely will be delayed, likely moreso than if the connection were shared on a first-come, first serve basis. Anyway, this is something of a moot argument -- we won't know the impact until things are implemented, which so far has been very, very slow. I just think that it introduces a variable that doesn't need to be there, and could potentially have effects on the social structure of the net in some really bad ways.
If you don't want jitter in your video stream, don't run it across a public network that can't possibly guarantee a rate of delivery that will play video smoothly.
I'm gettin tired. Just remember that a lot of smart people built System 390 too, but it wasn't exactly a rip-roaring success. Being smart doesn't protect you from creeping featurism, security problems created by complexity, or from designing a good system. Anyway, a fun discussion, and a good excuse to read RFCs. Have a good night!
[ Parent ]