ietf
[Top] [All Lists]

Re: Address allocation revisited

2000-08-04 17:00:02
Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu writes:

How many Ethernet address blocks has 3com gone through?

MAC addresses do not affect routing.  They are just numbers.  IP addresses
cannot be randomly assigned, as they are correlated with routing.  This
severely restricts the allocation of the address space.

If you allow 48 bits for hardware address blocks, and
assuming 8G people on the planet, each one can own some
8,000 things that have addresses.

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

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.

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.

Telephone numbers in the United States have 11 digits.  That's enough for
one hundred billion telephones, or about 400 for every man, woman, and child
in the country.  And the country isn't anywhere near that point yet.  And
yet this telephone-number space is nearing exhaustion.  Why is that?  It's
because the routing is embedded in the numbers, and whoever allocated them
apparently always thought in terms of the maximum theoretical address space
available with random assignment of numbers, and not of the address space
with the constraints imposed by routing considerations.

The only way to fully utilize any address space is to assign addresses from
that space sequentially, one after another, without any regard at all for
who or what is requesting the address, and without any allocation of
"blocks" of addresses in advance.  Anything other than straight sequential
allocation of addresses introduces additional information content into the
address, and since the maximum amount of information that can be held in the
address representation is fixed, this inevitably reduces the number of
available addresses.  Introducing routing information into addresses adds a
great deal of information to them, and thus greatly reduces the number of
available addresses.  There is no way around this.

It is important for anyone considering these addressing issues to remember
that, unless addresses are assigned sequentially, one at a time, without
reference to any other criteria at all, the assumption that the number of
available addresses will equal the total size (total information capacity)
of the address space is not valid--in fact, it may be seriously in error, by
many orders of magnitude.

Let's say you have a routing scheme that involves ten hops, each of which
can take two possible paths.  If you encode this into your addressing
scheme, it will require 20 bits.  If your address space is 32 bits wide,
that leaves only 12 bits--4096 addresses--at each routing endpoint.  If one
of your endpoints runs out of addresses, you're stuck, because you cannot
allocate addresses from the other endpoints, because there is no way to
route them.  This is what happens in IPv4, and it is also what will happen
in IPv6, and in any other fixed-length addressing scheme that encodes
anything more than a machine identifier into the address.  Furthermore, even
if you have lots of bits to dedicate to routing, it is impossible anticipate
which routes will require the greatest number of addresses, so no matter how
you try to allocate them in advance, eventually--soon--some subspaces will
run dry, with no possibility of swiping addresses from other subspaces that
still have room.

It has happened before, and it will happen again, and it will always be much
sooner than anyone thinks.