Well, in the case of IPv6 we're currently playing in a sandbox 1/8 the size of the available address space. So if what you say is true, and we manage to use up an exponential resource in linear time, then we can change our approach and try again with the second 1/8 of the space, without having to go through the upgrade pain that is the v4-v6 transition again.
I suspect even arrogant engineers can get it right in 8 tries. :) -Scott On 03/29/06 at 6:15am +0200, Anthony G. Atkielski <[EMAIL PROTECTED]> wrote: > Thomas Narten writes: > > > This is FUD. Care to back up your assertions with real analysis? > > Sure. > > The consistent mistake engineers make in allocating addresses is that > they estimate capacity in terms of sequential and consecutive > assignment of addresses--but they _assign_ addresses in terms of bit > spans within the address itself, which exhausts addresses in an > exponential way. They do this in part because they attempt to encode > information directly into the address, instead of just using it as a > serial identifier. An address of n bits contains 2^n available > addresses _only_ if they are assigned serially and consecutively; > dividing those bits into any arrangement of smaller fields reduces > capacity exponentially. > > For example, if you have a 16-bit address field, at first it looks as > those it has 65,536 addresses. And it does ... if you assign addresses > as 0000000000000001, 0000000000000010, and so on. But if you allocate > addresses by dividing those 16 bits into fields, you dramatically > reduce the total address space available. If you reserve the first > eight bits for a "vendor," and the second eight bits for a "product," > you've cut the address space by 99.6%, not by 50%. You will run out of > addresses in record time, and yet you'll never use more than a tiny > fraction of the theoretical capacity of the address space. All because > you wanted the short-term convenience of encoding information into the > address itself. > > Engineers make this mistake over, and over, and over. I don't know if > they are just too stupid to understand the above concepts, or if they > are so arrogant that they think they can somehow short-circuit > information theory and do the impossible. > > I tend to vote for arrogance, since I think (and hope) that engineers > aren't really that stupid. And further evidence for pure arrogance is > that engineers try to allocate address spaces now for a future that > they are unable to imagine. They allocate /64 fields out of 128 bits > for purposes that they understand now, even though the real need for > addresses is likely to be completely different (and unforseeable) by > the time addresses actually start to run short. > > I know I'm wasting my breath; if engineers were that easy to persuade, > they would not have made the same mistake over and over for nearly a > hundred years. I'm sure others have tried to point out their errors > time and again, especially in recent years as more people have caught > on to the problem. But they can't be told. They are convinced that > it won't happen to them, even though it happened to everyone else. > > A 128-bit address seems like "more than the universe will ever need," > and it definitely is ... but only if addresses are assigned serially > from the address space, without any information encoded into the > address itself. As soon as you reserve any portion of the field in > any way, there are multiple exponential reductions in capacity, which > can exhaust the address space entirely in a very short time. > > The mistakes have already been made with IPv6. Someone decided to > allocate bit spans out of the address, instantly invalidating the very > vast majority of all possible addresses in the address space, and > thereby reducing address capacity exponentially. Nobody really knows > how addresses will be used 20 years from now, so why do people try to > guess and sacrifice the capacity of IPv6 in the process? Don't > they ever learn? > > Is there a safe and conservative way of allocating IPv6 address space? > Yes. Set the first 96 bits to zero, and set the remaining 32 to the > current IPv4 addresses. When that runs out, set the first 95 bits to > zero, set the 96th bit to one, and use the remaining 32 bits for > another IPv4 address space. And so on. A space of 128 bits will last > for eternity in this way, and most of the space will remain available > for any conceivable future addressing scheme, even those we cannot > dream of today. In other words, don't allocate bit spans within the > address field, allocate address _ranges_ out of the full 128 bits. > > But I know that won't happen. However, perhaps this message will > remain archived somewhere so that I can say "I told you so" when the > address space finally runs out (I'm pretty sure I'll still be > around--we all will). > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
