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