Subject: RE: IPv6: Past mistakes repeated?

From: "Manish R. Shah." <[email-masked]>
Date: Mon, 24 Apr 2000 18:39:29 +0530

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

---

From: Leonid Yegoshin <[email-masked]>
Date: Mon, 24 Apr 2000 11:55:05 -0700

>From: "Steven M. Bellovin" <[email-masked]>
>
>In message <BB2831D3689AD211B14C00104B14623B1E7569@HAZEN04>, "David A Higginbot
>ham" writes:
>>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?
>
>Would it surprise anyone to hear that all of that was considered and
>discussed, ad nauseum, in the IPng directorate?  That's right -- we weren't
>stupid or ignorant of technological history.  There were proponents for
>several different schemes, including fixed-length addresses of 64 and later
>128 bits, addresses where the two high-order bits denoted the multiple of 64
>to be used (that was my preference), or CLNP, where addresses could be quite
>variable in length (I forget the maximum).
>
>But the first thing to remember is that there are tradeoffs.  Yes, infinitely
>long addresses are nice, but they're much harder to store in programs (you can
>no longer use a simple fixed-size structure for any tuple that includes an
>address) and (more importantly) route, since the router has to use the entire
>address in making its decision.  Furthermore, if it's a variable-length
>address, the router has to know where the end is, in order to look at the next
>field.  (Even if the destination address comes first, routers have to look at
>the source address because of ACLs -- though you don't want address-based
>security (and you shouldn't want it), you still need anti-spoofing filters.)
>I should add, btw, that there's a considerable advantage to having addresses
>be a multiple of the bus width in size, since that simplifies fetching the
>next field.)
>
   Routers may use the different addresses for routing. Outbound router
may assign "route address" to keep intermediate route tables small.

   It is not the same as NAT because original and real destination address
never replaced.

		       - Leonid Yegoshin.

---

From: Bob Braden <[email-masked]>
Date: Mon, 24 Apr 2000 18:59:41 GMT

*> 
  *> 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,

Right idea, wrong link layer. The low-order 24 bits of an IP address
was originally a 24-bit ARPANET (/Milnet/DDN) host address.

Bob Braden

---

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

> 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) .

That's what has to be done, anyway.  I'm not sure that I see what you are
saying.

> be upgraded.

If you design it correctly in the first place, this isn't necessary.

Think of a railroad network as an analogy.  The current design for IP
addressing allows a fixed number of tracks, and you have to allocate them
all in advance.  If the future evolution of the network is such that your
allocation turns out to be less than optimal, you have to redo entire
sections of the network to reallocate tracks.

Now compare this with an open-ended addressing scheme.  All you have to do
in this case is allocate the first track.  As additional tracks are needed,
you build new ones, branching off from the first track.  If some branches
evolve more than others, no problem--they can just add additional branches
of their own.  No branch impinges on any other branch.  You might have only
two branches leading away from your original track.  One of them might lead
to a total of fifty stations (endpoints), but the other might lead to ten
trillion stations.  It doesn't matter, and you don't have to care, since
when you route trains on your section of the network, all you'll look at is
the first digit of the destination, which will tell you which of your two
branches the train must follow.
And you might be on a branch yourself, for that matter.  The network can be
restructured upstream or downstream of your little section of track, and it
remains transparent to you, as long as the digit designations for you and
the two branches you serve remain the same.

> Personally my telephone number has changed
> 3 times within the last couple of years.

Probably because the telephone numbering scheme was not truly open-ended.
In the U.S., for example, attempts to fix the number of digits in telephone
numbers have caused great problems, with things like area codes being
exhausted, exchanges being exhausted, and so on.  A truly open-ended scheme
wouldn't have this problem--you'd just add more digits in the areas that
needed more numbers.  This open-ended scheme is actually in place for
international calling.  (Equipment usually has fixed-length buffers for
telephone numbers, but all you have to do is boost the size of the buffers
if you ever come across numbers that won't fit.)

> 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.

Looks like they're pretty much doing that with IPv6 now!  And with a
fixed-length addres, they'll be doing it again in 15 years, only it will
cost a thousand times more than it did on this pass.

  -- Anthony

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 24 Apr 2000 18:00:11 EDT

> > Users shouldn't care or know about the network's internal addressing.
> > Some of the application issues with NATs spring directly from this issue
> > (e.g. user of X-terminal setting display based on IP address instead of
> > DNS name).
> 
> it's not the same issue.  the point of using IP addresses in DISPLAY 
> variables is not to make them visible to the user - it's because 
> using the IP address is (in a non-NATted network) far more reliable 
> than depending on the DNS lookup to work.  the fact that doing this
> makes the address more visible to the user is just a side effect;
> most users don't care diddly about it one way or the other as long
> as it works.
> 
> Keith
> 

The default DISPLAY variable for an X Server on the local machine is

  unix:0

This means contact the 0th display attached to the 0th X Server on the
local machine.  When you make a connection to a remote machine you
cannot count on the return from gethostname() is going to have any
relationship to the name in the DNS.  Not to mention that on a
multi-homed machine you need to be able to choose the IP address that
is actually accessible to the remote.  So what you do is look at the
IP address on the local end of the socket that is being used to
connect to the remote system and insert that IP address into the
exported DISPLAY variable.  This has of course worked for 20 years and
fails when a NAT is in the middle.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

---

From: Sean Doran <[email-masked]>
Date: Tue, 25 Apr 2000 00:36:59 +0200 (CEST)

Dick St.Peters writes:

| I should probably just go back to lurking

No, these are fundamentally hard problems, and nobody has real answers.
What is interesting is that people haven't asked real questions either,
and yet have decided that the correct approach is IPv6.

| but ... my take on every
| house being multihomed was to imagine full local meshing - each house
| peering with its neighbors redundantly.

Well, this presupposes some infrastructure built especially for
that purpose, or some surprising business-to-consumer cordiality.
I can't imagine for example the cable people offering free (if
local) connectivity to everyone for this purpose -- there is the
issue of owning&operating copper/fibre/brouter gear.  Likewise,
I can't imagine ANY operator who would allow unconditional access
to local infrastructure, including people who do not pay bills,
or who do destructive things.

| If, say, my power-line port
| was down, that information needn't be known by anything outside my own
| neighborhood.

Well, no - there is the issue of how traffic from elsewhere
in the world arrives to your neighbours' houses on your behalf.

That is, whatever arrangements were in place for the 
mapping 
your.place.ny.us -> 1.2.3.4/32 -> sprint -> netheaven -> DSL-line -> your router
would have to be adjusted to now prefer 
your.place.ny.us -> ... -> access -> your neighbour -> something -> your router

The "..." piece is what's interesting.

If the DNS were less "sticky" your.place.ny.us could map to a new address 
that already was going as far as your neighbour.

If the routing system were really robust to microscopic changes,
the DNS could stay the same and the difference would be that now
traffic would be attracted not to netheaven but to your neighbour.
This implies that the traffic is not attracted to netheaven and
possibly therefore also not sprint, but rather c&w and then "access",
which would now know that 1.2.3.4/32 goes to your neighbour rather
than to c&w.

| When the local power distribution center couldn't get a
| power-grid packet to me directly, they'd give it to my neighbor 

What if your neighbour is not being supplied by the power people,
because he doesn't like the price-performance and doesn't want
to pay the power people's bills?

What if your neighbour simply doesn't like you?

Why use your neighbour for backup when there is cable tv coax
running into your household also?

How can you deal with a failure at a power company transformer,
that cuts off both you AND your neighbour(s)?

| and
| let his smart house determine whether to send it to mine by wireless
| or cable or whatever else has come along.  The rest of the world could
| just engage in some kind of "get it closer" routing.

Right - the problem is that the physical geography and the network
topology can be disjoint.  Your neighbour may be physically next door,
and it may be that logically he is directly connected to you when
your copper through the wall is working.  But when that copper fails,
you have to go to netheaven, netheaven's next hop is sprint, sprint's
next hop is c&w, c&w's next hop is "access", and access finally delivers
over the cable plant to your neighbour.

I see no practical means of making sure that EVERY household
shares a single common logical supplier of traffic.

| Don't ask me about mobile users.  I'm going back to lurking ...

Don't give up - there is a learning opportunity for all of us.

	Sean.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 24 Apr 2000 20:16:00 -0600 (MDT)

> > 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.
>
> 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. ;)

Both of those positions seem odd.  The first because not all boxes have
unique MAC addresses, and not merely because of the "locally administrated"
nonsense or even because not all boxes have Ethernet interfaces, although
the second of those is a good reason.  Another good reason is that all of
the major and reputable Ethernet vendors I've heard of have accidentally
shipped significant numbers of Ethernet interfaces with duplicate MAC
addresses.  In theory it's trivial to assign unique MAC addresses, but in
practice it is very hard to do it right all of the time.

Note also that many outfits have been using MAC addresses and other
tactics other than dongles to do node locking for at least 15 years.
I've heard rumors that Windows 2000 will join that creaky old bandwagon,
I assume by using what Microsoft calls a GUID for the obvious.

The stuff about breaking software "node locking" is just as odd.
Never mind that all the systems I've worked on did the right thing
even while using a locally assigned MAC address when an application
asked for the permanent, offical address.  The statement about prirates
assumes that they'll will abide by the hope in the locked software
that when it askes the operating system and libraries for MAC address,
it gets any of the host's MAC addresses instead of some other 6 byte
string that is more convenient for the pirate.  In other words, why
would you bother the network machinery instead of, for example,
improving the dynamic library that contains the system call wrappers?

    ...

About local addresses, neighbors passing each other's traffic, unlikely
commercial cooperation, and so forth--does no one remember UUCP,
perhaps before the Mapping Project tried (and failed) to make hostnames
globally unique?

  ...

I'm flummoxed by the reawakening of the years IPng argument.  All of
the positions stated seem very familiar, both those that I think
are better ideas than IPv6 and those that I still think are crazy.
Does anyone really hope that anything decided, discussed or considered
now will have any positive effect?  What can you expect to do by
re-opening the can--no--train load of worms except delay IPv6 by
another 10 years to recapitulate the entire sorry history, including
highlights such as the decision of the IAB to throw away TCP/IP and
switch to the OSI protocol suite?  If you did restart history, how
would you hope to avoid yet another restart in about 2010?

Aren't the years of IPng flaming in the main IETF list captured
somewhere so that those of us who were not overjoyed by the first
edition can rest in peace?

Vernon Schryver    [email-masked]

---

From: Ian King <[email-masked]>
Date: Mon, 24 Apr 2000 20:57:12 -0700

Yes, we made a guess -- a design compromise.  Folks, we're engineers, and we
come up with "good enough" answers.  Sure, we try to make sure that the
"good enough" answers are good enough for the majority of situations, for a
reasonable length of time.  But we're not prophets or philosophers or
prescient -- we're just engineers.  We made some "good enough" guesses with
IPv4 that, as Keith points out, got us to the situation of a global Internet
-- and our present dilemma is a byproduct of that solution's success.  I
would not be disappointed if our next "good enough" guess lasts us as long
as the last one.  After all, I'll want SOMEthing entertaining to do twenty
years from now.  :-)  

BTW -- I feel the same way about NAT: it's "good enough" for many
situations.  :-) Send me mail at home, it goes to one machine on my internal
172.16 LAN; check out my personal webpages, you're talking to another
machine (and a different OS) in that address space.  You don't see that, and
frankly I don't think about it very often.  It's close to a "it just works"
solution -- which is "good enough" for now.  

-- Ian 

> From: Keith Moore [mailto:[email-masked]]
> Sent: Monday, April 24, 2000 5:38 PM
> To: Anthony Atkielski
> Cc: [email-masked]
> Subject: Re: IPv6: Past mistakes repeated? 
> 
> 
[snip]
> 
> but this same impossibility means that we do not know whether 
> we should
> put today's energy into making variable length addresses work 
> efficiently
> or into something else.  so we made a guess - a design compromise -
> that we're better off with very long fixed-length addresses because 
> fast routing hardware is an absolute requirement, and at least today
> it seems much easier to design fast routing hardware (or software)
> that looks at fixed offsets within a packet, than to design 
> hardware or
> software that looks at variable offsets.
> 
[snip]

---

From: "vinton g. cerf" <[email-masked]>
Date: Tue, 25 Apr 2000 06:54:47 -0400

For those of you who don't know, and Jim is too modest
to tell you, he was a member of the Stanford team that
designed and implemented the first TCP protocol versions.
Later he went on to build the first versions for the
portable Digital LSI-11s used in the Packet Radio network.

Vint
=================================================================
I moved to a new MCI WorldCom facility on Nov 11, 1999

MCI WorldCom
22001 Loudoun County Parkway
Building F2, Room 4115, ATTN: Vint Cerf
Ashburn, VA 20147
Telephone (703) 886-1690
FAX (703) 886-0047

"INTERNET IS FOR EVERYONE!" 
See you at INET2000, Yokohama, Japan July 18-21, 2000
http://www.isoc.org/inet2000

---

From: "Jim Stephenson-Dunn" <[email-masked]>
Date: Tue, 25 Apr 2000 16:12:30 -0700

Jim, I totally agree with you. We need to move and start deploying this now
rather that later. Starting with the carriers, then the ISP's and the trend
will flow down until eventually (in 10-15 years) everyone and everything
will be IPv6.

I have been tasked with looking into the feasability of upgrading our core
network to v6. I work for a company in San Francisco. We link LAN's and
MAN's But we will be looking to interconnect all of our cities in the US
together and IMHO I think IPv6 is the ONLY long term solution to achieve
this, what is the point of building a network and then having to renumber it
a couple of years down the line, it is better to use v6 numbering now and
continue that way.

It may be painful but no where near as painful as having to renumber
everything in 5/10/15 years time. There WILL be issues, undoubtably, but
usually anything worth while has these problems and issues, that is what
makes it worth while, striving for.

We need to embrace this and move forward as one community, with everyone
singing from the same hymn sheet as it were. If (we)the engineers won't
deploy v6 ourselves, then how can we expect anyone else to. There is alot of
fear,uncertainty and doubt in the world about what we are trying to do here
(I seem to experience it in one form or another every day {;-( ), and surely
we should be taking the lead here (isn't that in the charter somewhere ?) If
the Engineers lead, the masses will follow.

I think it is now a well established fact that eventually we will deplete v6
address space, but as Ian says, in twenty years time we can take what we
have learnt with the deployment of v6 and apply it to the new version of IP.
Who know's, maybe it will be 256 or even 512 bits long, and if that isn't an
argument for a global DHCP server, I don't know what is.(and you think we
have problems now ;->)

Jim

Jim Dunn

Senior Network Engineer
San Francisco NOC

-----Original Message-----
From: Mathis Jim-AJM005 [mailto:[email-masked]]
Sent: Monday, April 24, 2000 8:02 PM
To: [email-masked]
Subject: RE: IPv6: Past mistakes repeated?

A brief history lesson...

There was some concern about a 32-bit address space.  MIT-LCS
proposed 48 (or 64-bit) addresses but that was coupled with a
reduction of the TCP sequence number to 16 bits.  After some
discussion, we settled on 32-bits based on the computing
resources available at the time.  At that time, there was no
separate IP header, only addressing fields in the TCP header.

Around that time, the ARPANET had recently scaled up from
8-bit host addresses to 24-bits.  Seemed unlikely that anyone
would build more than 100 ARPANET-sized networks with its huge
IMPs and PDP-10 mainframe computers (and UCLA's 360).  48-bit
Ethernet addressing wasn't around yet; otherwise we probably
would have picked 64 bits just to not have to deal with ARP.
This was before Moore's law; Intel had just released the
8008 microprocessor.  There were less than 100,000 large
commercial buildings (>500,000 sq. ft) in the world; seemed
that the number of class-c addresses were sufficient.  For
better or worse, the size of the address field went unchanged
from the original version of TCP (before IP was a separate
header).

We were caught short by a technology paradigm shift coming
from semiconductor physics.  If computers rode the same
technology advancement curve as cars, we wouldn't be having
an address space problem now.

We cannot predict the next big technology paradigm shift.
The real lesson to learn from IPv4 - IPv6 (which I think
was described by Knuth in regards to conversion of computer
instruction sets but I can't find the reference) is the
cost of delaying conversion.  For the longer you delay
the inevitable, the more installed base you have to
convert and the exponentially higher the resulting cost.

The excellent engineering to keep v4 running was too good
and has slowed the inevitable movement to larger address
spaces.  While there are no guarantees that 128-bits won't
be exhausted sometime in the future, we do know a lot more
about address space management and allocation than when Jon
started handing out net numbers. The Internet has always
been a balancing act between being ready for the future
and getting something working today.  IPv6 will not change
this, so we need to be prepared for change.  The next "big"
problem facing the Internet that will require a broad-scale
swap-out of software probably won't be address-space related.

We need to move forward with IPv6 both by deploying it in
the "core" and setting a time-frame after which non-IPv4
compatible addresses will be assigned.  Unless there is a
clear reason to move, no one wants to change software just
to change.  Once IPv6 is in the major backhaul carriers, ISPs
can role out improved services based on IPv6 which will be
the real reason end-users upgrade.  Seems like a real
leadership vacuum here...

Jim

> Sent: Monday, April 24, 2000 2:36 PM
> To: Anthony Atkielski
> Cc: [email-masked]
> > 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,
>
> I suppose that's true - as long as addresses are consumed at a rate
> faster than they are recycled.  But the fact that we will run out of
> addresses eventually might not be terribly significant - the Sun will
> also run out of hydrogen eventually, but in the meantime we still find
> it useful.
>
> > and that period may be orders of magnitude shorter than anyone might
> > at first believe.
>
> it is certainly true that without careful management IPv6 address
> space could be consumed fairly quickly.  but to me it looks like that
> with even moderate care IPv6 space can last for several tens of years.
>
> > Consider IPv4.  Thirty-two bits allows more than four billion
> > individual machines to be addressed.
>
> not really.  IP has always assumed that address space would be
> delegated in power-of-two sized "chunks" - at first those chunks only
> came in 3 sizes (2**8, 2**16, or 2**24 addresses), and later on it
> became possible to delegate any power-of-two sized chunk.  but even
> assuming ideally sized allocations, each of those chunks would on
> average be only 50% utilized.
>
> so every level of delegation effectively uses 1 of those 32 bits, and
> on average most parts of the net are probably delegated 4-5 levels
> deep.  (IANA/regional registry/ISP/customer/internal). so we end up
> effectively not with 2**32 addresses but with something like 2**27 or
> 2**28.  (approximately 134 million or 268 million)
>
> (see also RFC 1715 for a different analysis, which when applied to
> IPv4, yields similar results for the optimistic case)
>
> allocating space in advance might indeed take away another few bits.
> but given the current growth rate of the internet it is necessary.
> the internet is growing so fast that a policy of always allocating
> only the smallest possible chunk for a net would not only be
> cumbersome, it would result in poor aggregation in routing tables and
> quite possibly in worse overall utilization of address space.
>
> but if it someday gets easier to renumber a subnet we might then find
> it easier to garbage collect, and recycle, fragmented portions of
> address space.  and if the growth rate slowed down (which for various
> reasons is possible) then we could do advance allocation more
> conservatively.
>
> > 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.
>
> IPv6 allocation will have some of the same properties of IPv4
> allocation.  We're still using power-of-two sized blocks, we'll still
> waste at least one bit of address space per level of delegation.  It
> will probably be somewhat easier to renumber networks and recycle
> address - how much easier remains to be seen.
>
> OTOH, I don't see why IPv6 will necessarily have significantly more
> levels of assignment delegation.  Even if it needs a few more levels,
> 6 or 7 bits out of 128 total is a lot worse than 4 or 5 bits
> out of 32.
>
> > 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"
>
> I don't know where you get that idea.  Quite the contrary, the
> regional registries seem to share your concern that we will use up
> IPv6 space too quickly and *all* of the comments I've heard about the
> initial assignment policies were that they were too conservative.
> IPv6 space does need to be carefully managed, but it can be doled out
> somewhat more generously than IPv4 space.
>
> > and because nobody will want to expend the effort to achieve
> > finer granularity in the face of such apparent plenty.
>
> First of all, having too fine a granularity in allocation prevents you
> from aggregating routes.  Second, with power-of-two sized allocations
> there's a limit to how much granularity you can get - even if you
> always allocate optimal sized blocks.
>
> > This mistake will be repeated for each subset of the address space
> > allocated, by each organization charged with allocating the space.
>
> It's not clear that it's a mistake.  it's a tradeoff between having
> aggregatable addresses and distributed assignment on one hand and
> conserving address space on the other.  and the people doing address
> assignment these days are quite accustomed to thinking in these terms.
>
> > 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.
>
> this is only amazing to those who haven't heard of Moore's law.
> (presumably the same set of people who thought DES would
> never be broken)
>
> on the other hand, it's not clear how valid this analogy is for
> predicting the growth of the Internet - just because Moore's law (if
> it keeps on working) might predict that in a decade we could
> eventually have thousands of network-accessible computing devices for
> everyone on the planet, doesn't mean that those people would be able
> to deal with thousands of such devices.  and there do appear to be
> limits to the number of human beings that the planet can support.  and
> if by that time the robot population exceeds the human population then
> I'm happy to let the robots solve the problem of upgrading to a new
> version of IP.
>
> and as for other planets, all kinds of assumptions about the current
> Internet fail when you try to make it work at interplanetary
> transmission latencies.  so if we do manage to significantly populate
> other planets or if we find extraterrestrial species that we want to
> network with, we'll have to build a new architecture.  and people are
> already working on that.
>
> > The only real solution to this is an open-ended addressing
> scheme--one
> > to which digits can be added as required.
>
> variable length addresses do have some nice properties.  there are
> also some drawbacks.
>
> fwiw, phone numbers do in fact have a fixed maximum length which is
> wired into devices all over the planet - not just in the phone system
> but in numerous computer databases, etc..  it is not much easier to
> increase the overall length of phone numbers than it is to make IP
> addresses longer.  and once you set a fixed maximum length then it's
> just a matter of representation - do you have a variable-length
> address field or do you have a fixed-length field with zero padding?
> fixed-length fields are a lot easier for routers to deal with.  (and
> for similar reasons a lot of software uses fixed-length fields for
> phone numbers)
>
> 128-bit IPv6 addresses are roughly equivalent to 40 digits, which IIRC
> is a lot longer than the maximum size of a phone number under E.164.
> (sorry, I don't have a copy handy to check)
>
> and the means by which IPv6 addresses are being allocated is actually
> not so different from the means in which phone numbers are allocated -
> the major exception being that IPv6 prefixes are assigned to major
> ISPs rather than to geographic regions.  (the latter difference might
> affect routing but probably does not affect allocation efficiency).
>
> so I think the bottom line answer to your message is that your concers
> are valid (if perhaps a bit exaggerated) and an allocation mechanism
> similar to what you suggest is already in place.
>
> Keith
>

---

From: "Connelly, M " <[email-masked]>
Date: Wed, 26 Apr 2000 10:16:47 +0200

On the subject of infinite possibilities - given that there are an infinite
number of of possible mistakes and only one correct solution, it is
statistically impossible to do anything right.

IP4 was definitely a mistake. Whatever replaces it will invariably also be a
mistake.  Besides, if everything was done correctly this forum would be very
dull!

-Michael C

> ----------
> Van: 	David A Higginbotham[SMTP:[email-masked]]
> Verzonden: 	maandag 24 april 2000 13:22
> Aan: 	'Anthony Atkielski'; [email-masked]
> Onderwerp: 	RE: IPv6: Past mistakes repeated?
> 
> David H
> From: Anthony Atkielski [mailto:[email-masked]]
> Sent: Monday, April 24, 2000 6:05 AM
> To: [email-masked]
> 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
> 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.
> 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
> 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
> 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:
> 
> ... 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
> 486174         for a machine in Vulgaria Minor (where most of the
> population
> lives)
> 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
> 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
> I'd be interested in hearing what others think of this potential problem.
> (Or at least correct me if I've overlooked something in

---

From: "Michael B. Bellopede" <[email-masked]>
Date: Wed, 26 Apr 2000 09:19:02 -0400

I fear your logic is flawed.  If there are an infinite number of
possibilities, than not only are there infinite possible mistakes, but an
infinite number of good solutions.  Also, just because a solution is good,
does not mean it will or should last forever.

-Michael B. Bellopede
 [email-masked]
 "There is no spoon."

>From: Connelly; M [mailto:[email-masked]]
>Sent: Wednesday, April 26, 2000 10:17 AM
>To: [email-masked]; [email-masked]'
>Subject: AW: IPv6: Past mistakes repeated?
>
>
.> Subject: IPv6: Past mistakes repeated?