ietf
[Top] [All Lists]

Re: Address allocation revisited

2000-08-05 03:10:04
    Date:        Sat, 5 Aug 2000 01:45:50 +0200
    From:        "Anthony Atkielski" <anthony(_at_)ATKIELSKI(_dot_)COM>
    Message-ID:  <003f01bffe6e$1fd89ad0$0a00000a(_at_)contactdish>

  | Not if all those things are routed to based on their address.

You left out the bit (from what you quoted) where Valdis said that
there were still another 64 bits to use for routing...

  | If you route all 123.xxx addresses to country A, and all 456.xxx addresses
  | to country B, and country A runs out of address space, you cannot allocate
  | any addresses to country A from the address space of B, even if the latter
  | is 99% unused, because it messes up the routing.

Leaving aside that "country" is the wrong model here (routing and national
boundaries are not much related) - we can use that as a convenient word to
use to express the insides of a routing boundary nevertheless.

  | Because of this, and because you cannot predict which geographic areas will
  | require how many addresses in the future, the only way to avoid exhaustion
  | of the address space is with a variable-length address.
  | 
  | I'm surprised that this is not intuitively obvious.

Perhaps because it is wrong.   The other solution, and the one IPv6 has
preferred, is simply to take back all the 123.xxx and 456.xxx addresses,
and reassign them again in a way that does allocate suitable volumes of
addresses to each "country" while retaining routing scalability.

Once you allow addresses to be reassigned, instead of insisting that an
address once assigned is fixed forever, the only issue remaining is whether
or not there is sufficient address space.   And I agree, that does need to
include space for the overheads incurred in making the addresses routable.
What's more, we know and agree that those overheads are not negligible,
in fact, they're quite huge (once they're multiplied).

But even with all that, the IPv6 64 bit routing space (plus 64 bits
of on-link identification space, which is overkill for sure, but
simplifies things) is plenty.

Truly variable length addresses would be another way to solve some of
the problems, but they introduce other problems, and in any case, it
isn't possible to use truly variable length addresses in any kind of datagram
network based upon any technology currently in use - packets all have
fixed maximum lengths (necessary because of checksum algorithm requirements
even if for no other reason), and sticking something (even worse, two of
something) that are truly variable length into a fixed length container is
an interesting exercise.   But even if you're willing to assume that
the variable length things will never get long enough to become a bother
for this (which would seem to be admitting that fixed length will do
after all - and then perhaps just disputing how big the space needs to be)
variable length assignment schemes of the type you're proposing forever
consign those who come later to a diminished service quality from those
who came before.  That is, if you get a shorter address (an early one)
you forever fit more payload per packet than someone who ends up with a
much longer address, having joined a popular tree somewhat later.

All this is not to say that IPv6 will remain with us forever - eventually
it too will need to be replaced.  Why that will happen we have no idea - if
we knew that we could take steps now to avoid whatever the problem will be.
However, it isn't going to be the address space that kills IPv6, it will
be something else, something that we haven't forseen (or just perhaps the
one thing that we have forseen, but aren't really sure how to overcome,
which is how to overcome the inertia and get IPv6 into widespread operation
in the first place - there is still the possibility that it might be
stillborn, though that isn't a scenario to really contemplate).

kre