Iljitsch van Beijnum writes:
When I first learned about IPv6 I felt strongly that 128 bits was too
much, especially since all those bits have to be carried in every IP
packet twice, once as a source address and once as a destination
address.
When I first learned about IPv6 I started worrying that it wouldn't
last for very long before being exhausted in turn. And I worried a
lot more when I saw the mistakes of the past being repeated--the very
mistakes that wasted so many IPv4 addresses.
However, since that time I've learned to appreciate
stateless autoconfiguration and the potential usefulness of having
the lower 64 bits of the IPv6 address as a place to carry some
limited security information (see SEND and shim6 HBA).
Once it's carrying information, it's no longer just an address, so
counting it as pure address space is dangerous.
The trouble is that you need to build in space for growth.
You build in space for growth by not trying to allocate address spaces
in advance. For example, you allocate 0...0+33 bits for new
addresses, and now you've doubled the IPv4 address space (and bought
yourself years of additional time), while using up only an
infinitesimal portion of the IPv6 space.
But when you start chopping the address into sections, you throw
almost all the address space away ... and when that happens, you are
going to exhaust that space in no time, no matter how many bits it
has.
Building in space means not allocating it--not even _planning_ to
allocate it. Nobody has any idea what the Internet might be like a
hundred years from now, so why are so many people hellbent on
"planning" for something they can't even imagine?
Unfortunately, at the time IPv6 was created variable length addresses
weren't considered viable.
Variable-length addresses are the only permanent solution, unless IP
addresses are assigned serially (meaning that all routing information
has to be removed).
Variable-length addresses work very well for the telephone system, and
they'd work just as well for the Internet, if only someone had taken
the time to work it out.
The only thing I'm not too happy about is the current one address /
one subnet / /48 trichotomy. Ignoring the single address for a
moment, the choice between one subnet and 65536 isn't a great one, as
many things require a number of subnets that's greater than one, but
not by much.
It's a good example of waste that results from short-sightedness. It
happened in IPv4, too.
The thing that is good about IPv6 is that once you get yourself a /
64, you can subdivide it yourself and still have four billion times
the IPv4 address space.
It sounds like NAT.
I'm not a huge fan of the HD ratio either, because it substitues a
rule of thumb for actual knowledge. But the point is that EVEN if you
waste 99.9756% in this way we STILL have enough addresses to give
every person living on the planet when the population hits its peak
several /48s which are wasteful in their own right.
Famous last words. I've seen virtual memory systems run out of
virtual address space, even when that space contained (in theory) more
bytes than anyone could ever possibly build into any real-world
system. The reason? Careless allocation of the addresses. No matter
how many bits you have, you can blow through them in linear time if
you allocate them based on bit fields, and it seems that virtually no
engineers can resist the urge to do exactly that.
So while I wouldn't want to take away your right to begrudge the way
all of this is done in IPv6, I must object to your conclusion that
we'll run out of IPv6 soon, for any reasonable value of "soon".
Well, time will tell, won't it?
I hope good engineers don't think that ...
Any engineer setting aside bit spans in an address for future use is
thinking exactly that, and he'll be wrong.
Engineers should build stuff that still works reasonably well even if
they get their predictions wrong.
Engineers don't like to think that they've left anything out or that
they are less than omniscient in assessing what must be done, so many
of them are allergic to anything that is simply "reserved for future
use." I had the same trouble when I first started in computers, but I
grew out of it.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf