ietf
[Top] [All Lists]

RE: IPv6: Past mistakes repeated?

2000-04-24 06:21:37

IPv6 is designed to be compatible with IPv4?

If what you suggest should be implemented, then probably
the entire software of all the switches and hubs need to be
upgraded (if not entirely scrapped) . 

As also everytime the source and destination addresses are
upgraded, all the systems and the related software needs to 
be upgraded. Personally my telephone number has changed
3 times within the last couple of years. So in this case, it is not
possible to change the code of the intermediate routers every time.
But yeah, the numbers can be made configurable.

Although I agree that the concept being advocated is indeed 
revolutionary, and also might be beneficial to some extent. 
But the million dollar question is that whether the protocol and 
switch vendors would like to scrap the years and amount 
of investment that they have already made in the existing system.

Furthur study of your proposal needs to be done !!! and can be a 
hot topic of discussion. 

Cheers !!!

Manish.

--------------------------------------------------------------
** Nothing is Impossible, Even Impossible says I'm possible !!! **
--------------------------------------------------------------

Manish R. Shah.
Senior Software Engineer,
Future Software Pvt Ltd.
480-481, Anna Salai, Nandanam
Chennai 600035.
Phone: +91-(44)-433-0550 Xten 294.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++

-----Original Message-----
From:   Anthony Atkielski [SMTP:anthony(_at_)atkielski(_dot_)com]
Sent:   Monday, April 24, 2000 3:35 PM
To:     ietf(_at_)ietf(_dot_)org
Subject:        IPv6: Past mistakes repeated?

 << File: ATT00001.txt; charset = Windows-1252 >> 

What I find interesting throughout discussions that mention IPv6 as a solution 
for a shortage of addresses in IPv4 is that people
see the problems with IPv4, but they don't realize that IPv6 will run into the 
same difficulties.  _Any_ addressing scheme that uses
addresses of fixed length will run out of addresses after a finite period of 
time, and that period may be orders of magnitude
shorter than anyone might at first believe.

Consider IPv4.  Thirty-two bits allows more than four billion individual 
machines to be addressed.  In theory, then, we should have
enough IPv4 addresses for everyone until four billion machines are actually 
online simultaneously.  Despite this, however, we seem
to be running short of addresses already, even though only a fraction of them 
are actually used.  The reason for this is that the
address space is of finite size, and that we attempt to allocate that finite 
space in advance of actual use.

It should be clear that IPv6 will have the same problem.  The space will be 
allocated in advance.  Over time, it will become obvious
that the original allocation scheme is ill-adapted to changing requirements 
(because we simply cannot foresee those requirements).
Much, _much_ sooner than anyone expects, IPv6 will start to run short of 
addresses, for the same reason that IPv4 is running short.
It seems impossible now, but I suppose that running out of space in IPv4 seemed 
impossible at one time, too.

The allocation pattern is easy to foresee.  Initially, enormous subsets of the 
address space will be allocated carelessly and
generously, because "there are so many addresses that we'll never run out" and 
because nobody will want to expend the effort to
achieve finer granularity in the face of such apparent plenty.  This mistake 
will be repeated for each subset of the address space
allocated, by each organization charged with allocating the space.  As a 
result, in a surprisingly short time, the address space
will be exhausted.  This _always_ happens with fixed address spaces.  It seems 
to be human nature, but information theory has a hand
in it, too.

If you need further evidence, look at virtual memory address spaces.  Even if a 
computer's architecture allows for a trillion bits
of addressing space, it invariably becomes fragmented and exhausted in an 
amazingly short time.  The "nearly infinite space" allowed
by huge virtual addresses turns out to be very finite and very limiting indeed.

The only real solution to this is an open-ended addressing scheme--one to which 
digits can be added as required.  And it just so
happens that a near-perfect example of such a scheme is right in front of us 
all, in the form of the telephone system.  Telephone
numbers have never had a fixed number of digits.  The number has always been 
variable, and has simply expanded as needs have changed
and increased.  At one time, a four-digit number was enough to reach anyone.  
Then seven-digit numbers became necessary.  Then an
area code became necessary.  And finally, a country code became necessary.  
Perhaps a planet code will be necessary at some point in
the future.  But the key feature of the telephone system is that nobody ever 
decided upon a fixed number of digits in the beginning,
and so there is no insurmountable obstacle to adding digits forever, if 
necessary.  Imagine what things would be like if someone had
decided in 1900 that seven digits would be enough for the whole world, and then 
equipment around the world were designed only to
handle seven digits, with no room for expansion.  What would happen when it 
came time to install the 10,000,000th telephone, or when
careless allocation exhausted the seven-digit space?

Anyway, some keys to a successful addressing scheme, in my opinion, are as 
follows (but the first is the only mandatory feature, I
think):

1. The number of digits used for addressing is not limited by the addressing 
protocol.
2. Every machine in the network need only know in detail about other points in 
the network that have the same high-order digits in
their addresses.
3. There is a distinction for every machine between "local" addresses (those 
that implicitly have the same high-order digits as the
address of the machine in question) and "remote" addresses (those that have 
different high-order digits).

With such an address scheme, a single international body can allocate one digit 
to each region of the world (the size of the regions
is irrelevant).  Beneath that, other, more local bodies, one per initial digit, 
can allocate more digits below that.  There is no
need for anyone to allocate the entire address space in advance, so there is no 
need to worry about problems with the initial
allocation that will have to be fixed later.  And since the actual number of 
digits in a machine address is unlimited, different
parts of the world, different companies, different organizations, etc., can 
expand addresses as needed.  At any given time, the
maximum number of digits would be fixed at some very high number (128 decimal 
digits, perhaps), but if this ever became too
limiting, it would be sufficient to simply up that number--no reallocation or 
modification of the address space would be necessary.

Imagine computers in the United States under such a scheme.  All IPtNG 
addresses (IPtNG=IP: the Next Generation--I have to call it
something, right?) for the U.S. would start with one.  Since there are lots of 
computers in the U.S., you'd see addresses like:

14872883747534 for a machine in San Jose
1487048377212  for a machine in Sacramento
1412278987831  for a machine in Los Angeles
1248819473     for a machine in Wyoming
134875810869   for a machine in Boston

... and so on.  Notice that the lengths vary based on the number of machines in 
a given region--if you need more address space, you
just add more digits.  Wyoming has relatively few machines, so addresses there 
are short.  San Jose has a zillion machines, so
addresses there are long.

Now picture the small country of Vulgaria, and its address space:

486174         for a machine in Vulgaria Minor (where most of the population 
lives)
48631          for a machine in Vulgaria Major

Vulgaria is a tiny country with only a few hundred machines.  The 4 designates 
the region of the world in which Vulgaria is found.
The 86 is allocated to all of Vulgaria.  The remaining digits are allocated 
within Vulgaria itself.

If you haven't already noticed, this pattern is essentially the one already in 
use for telephones.  It works extremely well.

Some might say that this ties the IP address to a geographical region.  Well, 
yes, it does.  So what?  If you want to use IP for
security (as in identifying individuals), you're making a mistake to begin 
with.  The address of a machine just locates it for
routing purposes; it does not authenticate its identity.  If you want identity 
information for machines, you give them a separate
"identity address" that follows them anywhere in the world, even if their IPtNG 
address changes.  And if you want identity
information for people (which is often the real goal), you give _them_ an 
"identity address" that follows them anywhere in the
world.

Here again, with respect to security, the telephone network sets the pattern: 
if you move, your telephone number changes, but your
identity does not.  Nobody calls a telephone number and simply assumes the 
identity of the person who answers; normally an
authentication process is carried out ("Can I speak to Jane?"), because 
everyone knows that a telephone number just gets you to a
specific telephone, but not to a specific person.  Nobody lets you charge 
purchases to a specific credit card just because you are
calling from a specific telephone--you still have to identify yourself.

Anyway, I suppose it's too late to change anything in IPv6, but I'm convinced 
that IPv6 will just show the same problems as IPv4,
and it will be more like 20-40 years down the road, and not the billions of 
years that some people seem to assume.  I think that
history shows that the leading mistake of all engineers is to underestimate 
future capacity needs, and I see that happening with
IPv6, just as it did with IPv4 (and with Y2K, and with the IBM PC address 
space, and so on, and so on).  I just thought I'd add my
$0.02.  Maybe I've overlooked something in IPv6, but I fear that I have not.

I'd be interested in hearing what others think of this potential problem.  (Or 
at least correct me if I've overlooked something in
IPv6 that will prevent the problems listed above from occurring.)

  -- Anthony