Subject: RE: IPv6: Past mistakes repeated?

From: "David A Higginbotham" <[email-masked]>
Date: Mon, 24 Apr 2000 07:22:06 -0400

I agree! Why create a finite anything when an infinite possibility exists?
On another note, I have heard the argument that a unique identifier already
exists in the form of a MAC address why not make further use of it?

David H

-----Original Message-----
From: Anthony Atkielski [mailto:[email-masked]]
Sent: Monday, April 24, 2000 6:05 AM
To: [email-masked]
Subject: IPv6: Past mistakes repeated?

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

---

From: Peter Johansson <[email-masked]>
Date: Mon, 24 Apr 2000 08:42:01 -0700

>exists in the form of a MAC address why not make further use of it?

Well, because it's too Ethernet-centric, for one thing! Other transport
media (suitable to transport IP) do not necessarily base their link-levevl
addressing on static schemes whose addresses are assigned at time of
manufacture.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: "Dick St.Peters" <[email-masked]>
Date: Mon, 24 Apr 2000 13:39:39 -0400 (EDT)

> exists in the form of a MAC address why not make further use of it?

I can remember early TCP/IP implementations that used class A
addressing only, with the host portion of the Enet MAC address as the
host portion of the IP address - "because ARP is too hard" or
something like that.  I think the first Suns did this.

--
Dick St.Peters, [email-masked] 
Gatekeeper, NetHeaven, Saratoga Springs, NY
Saratoga/Albany/Amsterdam/BoltonLanding/Cobleskill/Greenwich/
GlensFalls/LakePlacid/NorthCreek/Plattsburgh/...
    Oldest Internet service based in the Adirondack-Albany region

---

From: "Anthony Atkielski" <[email-masked]>
Date: Mon, 24 Apr 2000 21:45:43 +0200

> I agree! Why create a finite anything when an infinite

Exactly.  If you designed an open-ended protocol, you're far less likely to
ever have to rewrite it.

> On another note, I have heard the argument that
> a unique identifier already exists in the form of
> a MAC address why not make further use of it?

Not every machine on the Internet has an Ethernet card with a MAC address,
otherwise it might not be such a bad idea.  I think using the MAC address is
an excellent idea for software protection schemes (it's a lot more elegant
than a hardware key such as a dongle), but nobody seems interested in that.
In any case, this latter application is outside the scope of Internet
discussions.

  -- Anthony

---

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Apr 2000 17:55:06 -0400

>Exactly.  If you designed an open-ended protocol, you're far less likely to

You just have to redeploy new implementations when you add new 
features.  "Open-ended" isn't helping us in extending DHCP.  That's not to 
say a practical, extensible, open-ended protocol can't be written...

- Ralph

---

From: [email-masked]
Date: Mon, 24 Apr 2000 21:21:19 -0400

> than a hardware key such as a dongle), but nobody seems interested in that.

Nobody is interested in it because it doesn't work.

The Ethernet spec requires that each card have a unique MAC address
that's burnt onto the card.  However, due to some truly wierd stuff
done by DecNet "way back when", cards were *also* required to support
loading a new MAC address on the fly.

So to pirate a softare package that locks based on the MAC address, all
you have to do is pirate it off any compatible machine on any subnet
other than your own.  You can even pirate it off your own subnet
if you don't care about ARP working. ;)

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Apr 2000 10:45:16 -0700

> Exactly.  If you designed an open-ended protocol, you're far less likely to

PS - that's what we have version numbers for.

Open-ended can sometimes mean "you never know when you're exercising
(exorcising) new code" too.

Joe