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:[EMAIL PROTECTED]]
Sent:   Monday, April 24, 2000 3:35 PM
To:     [EMAIL PROTECTED]
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

Reply via email to