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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf