Subject: RE: draft-ietf-nat-protocol-complications-02.txt

From: Ian King <[email-masked]>
Date: Sun, 23 Apr 2000 22:08:14 -0700

Maybe we need to help make it easy to GET assignments of blocks of addresses
for individuals/small businesses/etc.  Part of the problem is the obvious:
IPv4 addresses are running short.  Part is the "K-Mart" level of product
understanding I've experienced with many vendors of Internet connectivity.
When I asked a cable IP vendor about getting a static address assignment,
the (sales) person said, "Oh, there's no static, it's the Internet."  <sigh>
That's a priceless quote, but frankly dial-up vendors weren't any better.  

The first is an engineering problem, and we're working on that one (IPv6),
right?  :-)  The second is a market problem, and I don't think it's going to
go away until either telcos realize that they need to make a commitment to
being in the IP business (and train their staff), or we have meaningful
alternatives to the telcos for individual connectivity.  

From the individual user's perspective, NAT does seem a lot easier.  You
hook computer A to the ISP, computers B and C to computer A, and everyone
can surf -- cool.  I AM a networking geek, and NAT was a lot easier (and
cheaper) than the alternatives.  I suspect it will remain so for at least a
while -- Ian 

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]]
> Sent: Sunday, April 23, 2000 8:44 PM
> To: Dick St.Peters
> Cc: [email-masked]
> Subject: Re: draft-ietf-nat-protocol-complications-02.txt 
> 
> 
> > Most users are not
> > networking geeks.  They like NAT because NAT boxes make 
> what they want
> > to do so easy.
> 
> presumably they don't realize that the NATs are making it hard 
> to do other things that they might want to do.
> 
> I wonder...how many of these folks really want network address 
> translation, versus those who just want the other things that
> NAT boxes often do?   (DHCP, firewall, hub, router, all with 
> really easy setup)
> 
> maybe we need to make it as easy to connect a small net to the 
> Internet, as it is to connect a host. 
> 
> Keith
>

---

From: "Anthony Atkielski" <[email-masked]>
Date: Mon, 24 Apr 2000 12:04:36 +0200

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: Keith Moore <[email-masked]>
Date: Mon, 24 Apr 2000 09:19:01 -0400

> understanding I've experienced with many vendors of Internet connectivity.

right.  but for folks with a K-Mart level of understanding you need a 
K-Mart interface.  buy your "internet interface box" at the K-Mart,
take it home, plug it in to your phone line or whatever, and get
instant internet for all of the computers in your home.  
(almost just like NATs today except that you get static IP addresses).

> alternatives to the telcos for individual connectivity.  

I don't think it's just a marketing problem.  User interfaces are also 
an engineering issue.  Seems like there's a gap between the things we
produce in IETF and what is needed to actually make things work well
for K-Mart-level customers.  If the specifications defined by IETF
and implemented by ISPs aren't sufficient to allow plug-and-ping,
it's hardly surprising when NAT vendors fill in the gaps - and given
that the network didn't provide the level of service that was needed, 
it's hardly surprising that the gaps are filled in a technically dubious 
manner.

Keith

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 24 Apr 2000 16:43:31 +0100

its ironic you should send this today, when 12 million people in
london, england, had to learn to dial 8 digits instead of 7 because of
lack of foresight from the telephone regualtor when re-numbering less
than a decade ago - it is reported that 2--30% of calls today are
misdialled...

repeat after me:
variable length addresses dont stop you having to renumber

of courser, the DNS hides all this from many applications, in exactly
the same way that NATs dont.

j.

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Apr 2000 15:36:06 -0400

> 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: "Anthony Atkielski" <[email-masked]>
Date: Mon, 24 Apr 2000 22:21:59 +0200

> its ironic you should send this today, when 12
> million people in london, england, had to learn
> to dial 8 digits instead of 7 because of lack
> of foresight from the telephone regualtor when
> re-numbering less than a decade ago ...

France has increased the number of digits in telephone numbers several times
over the past 20 years, and it has always been without a hitch.  Each time
the telco has prepared for a barrage of misdials, just in case, but they
have never materialized.  Currently, numbers are ten digits long, everywhere
in the country, although the first digit is actually a selector for your
chosen local telco provider (0 = France Telecom, the historical operator).

  -- Anthony

---

From: John Stracke <[email-masked]>
Date: Mon, 24 Apr 2000 17:00:24 -0400

> I'm happy to let the robots solve the problem of upgrading to a new

Ah--the Iron Man's Burden.  :-)

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Beware of wizards, for you are crunchy and good|
[email-masked]|with ketchup.                                  |
\================================================================/

---

From: "Anthony Atkielski" <[email-masked]>
Date: Mon, 24 Apr 2000 23:26:01 +0200

From: "Keith Moore" <[email-masked]>

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

Ah ... famous last words.  I feel confident that similar words were said
when the original 32-bit address scheme was developed:

"Four billion addresses ... that's more than one computer for every person
on Earth!"

"Only a few companies are every going to have more than a few computers ...
just give a Class A to anyone who asks."

And so now we are running out.

But the real thing here is, even with the wisest allocations imaginable, we
would still run out much, much faster than the total number of addresses in
the address space might lead one to believe.  And that is because we have to
_predict_ how addresses will be used, and we cannot easily change the
consequences of those predictions.  So there are always significant blocks
of unused addresses, even as we run out of addresses in other ways.

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

Ten years, I'd say.  And then redefining a new addressing scheme will cost a
thousand times more than it will today, at least.  Even washing machines
will have to get new programming!

> not really.  IP has always assumed that address space
> would be delegated in power-of-two sized "chunks" ...

Aye, there's the rub.  It has always been necessary to _assume_ and
_delegate_ address space, because the address space is finite in size.  It
has always been necessary to predict the future, in other words, in a domain
where the future is very uncertain indeed.

> ... 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 by then, a lot of the biggest chunks were already in use.

> ... but even assuming ideally sized allocations, each
> of those chunks would on average be only 50% utilized.

Right.  So the only solution is to get rid of the need to allocate in
advance in the first place.

Think of variable addressing and the needs of the tiny country of Vulgaria.
Vulgaria needs address space.  Okay, so you say, well, Vulgaria is in, say,
Eastern Europe, and all addresses in Eastern Europe begin with 473.  All the
addresses from 4731 to 4738 are taken.  So you add address 4739, which now
means "everyone else in Eastern Europe," and you assign 47391 to Vulgaria.
That's all you have to do.  If Vulgaria wants to further subdivide, it can;
it can assign 473911 to Northern Vulgaria, and 473912 to the rugged
Vulgarian Alps region.  It doesn't matter to anyone except Vulgaria.

Given this, North America doesn't have to change anything at all.  Before,
anything that started with 473 went to Eastern Europe, and that's still the
case.  Some European routers have to smarten up a bit, because now they have
to be aware that 4739 goes to another routing point that handles "all other"
Eastern European countries.  And this new routing point (heck, maybe
Vulgaria will host it, eh?) must know that 47391 goes to Vulgaria, but
nothing more.  Only routers in Vulgaria itself need to care where 473911
goes as compared to 473912.  And only routers in the rugged Vulgarian Alps
need to know that 4739124 goes to Smallville, and 4739126 goes to
Metropolis, both cities nestled there in the Alps.  And since the addressing
scheme is open ended, even if Vulgaria one day has ten trillion computers on
the Net, nothing outside Vulgaria needs to change.

> allocating space in advance might indeed take away
> another few bits. but given the current growth rate
> of the internet it is necessary.

Only with a fixed address space.

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

Exactly ... but that's the magic of the variable address scheme.  You only
have to allocate disparate chunks in a fixed address scheme because the size
of each chunk is limited by the length of an address field.  But if the
address field is variable, you can make any chunk as big as you want.  If
you have addresses of 4739124xx initially (Metropolis only had a few
machines at first), and you run out of addresses after 473912498, you just
make 473912499 point to "more addresses for Metropolis," and start
allocating, say 4739124990001 through 4739124999998 (you always leave at
least one slot empty so that it can point to "more addresses").

> I don't know where you get that idea.

That's how it happened for IPv4.

> 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

No matter how conservative they are, the finite length of the address field
will eventually cause problems, and much sooner than anyone thinks.

> IPv6 space does need to be carefully managed, but it
> can be doled out somewhat more generously than IPv4 space.

And in 2030:

"Of course, nobody in 2000 realized that we'd eventually need 1048576
listener addresses for each of our cellphones and wristwatches, even if that
is obvious now.  As a result, we've nearly exhausted the IPv6 space, and we
are looking at a new scheme.  We think that a new fixed address space of 192
bits will surely be all anyone will ever need before the sun turns cold, and
we'll never have this problem again."

> First of all, having too fine a granularity in allocation
> prevents you from aggregating routes.

Only with a fixed address length.

Look at it this way:  Think of fixed-length addresses as rays streaming out
from the center of a circle.  You allocate rays so that they are adjacent to
facilitate routing.  However, no matter what you do, the time will come when
you just cannot allocate the number of adjacent rays that you require for
some purpose, and at that point, your routing system breaks, or you deny
someone an allocation.

Now think of variable-length addresses as rays also--but in this case, you
have the option of splitting any ray to create more rays.  Now you can
allocate adjacent rays as required, and if you run out of rays, you split a
few to make more, and they are still adjacent.  You can split them as many
times as you want.

Or you can look at it as numbers.  Fixed-length addresses are integers.
Variable-length addresses are real numbers.  You can only have so many
integers between 1 and 100, but you can have an infinite number of real
numbers between those two limits--you just keep adding decimal places.

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

It's a mistake in that it is imposed by a finite address space.  Eliminate
the finite address space, and this is no longer an issue.  You don't have to
care about aggregating addresses--you just create more, if you need them.

Surely you've seen this in technical manuals: If you need to put something
between section 1 and section 2, you just add a section 1.5.  That's
variable addressing.  But if you limit yourself to fixed addressing, your
only choice is to move every section in the manual so that you can put in a
different section 2 (making the old section 2 section 3, and the old section
3 section 4, and so on).

> this is only amazing to those who haven't heard of

Moore's law isn't the cause of the problem.  The problem isn't created by
advances in hardware or software or network capacity; it is created by the
inevitable impossibility of knowing the future with certainty.  You cannot
know what a network will look like in the infinite future, so there is no
way to optimally allocate addresses in a fixed address space without
eventually being required to do everything over again.

> fwiw, phone numbers do in fact have a fixed maximum
> length which is wired into devices all over the planet ...

Yes, but it's way easier to make a field larger than it is to build and
implement a new protocol.  And if you design for variable length, you can
trap anything that exceeds your buffer space and fix it when the time comes
(or before the time comes, if you check ahead).  If you don't design for
variable length, you just rewrite everything.

> ... it is not much easier to increase the overall
> length of phone numbers than it is to make IP
> addresses longer.

But in a variable-length system, you can make both ends variable.  You can
thus add length at either end without affecting more than a tiny part of the
network (the part that has to know about the portions of the address that
you've extended).  Routers that look only at the parts that haven't changed
(in the middle) don't require any modifications.

  -- Anthony

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Apr 2000 18:08:34 -0400

> 6 or 7 bits out of 128 total is a lot worse than 4 or 5 bits out of 32.

the last sentence contains a thinko.  it should read:

6 or 7 bits out of 128 total is a lot better than 4 or 5 bits out of 32.

(I originally wrote the comparison in the other order, but when I swapped
sides, forgot to change the direction of the comparison.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Apr 2000 20:37:46 -0400

> just give a Class A to anyone who asks."

I wasn't there, but I expect it would have sounded even more preposterous
for someone to have said: "I'm absolutely positive that this Internet thing 
will reach to nearly everyone on the planet in a couple of decades, and 
therefore we need to make sure it has many times more than 32 bits of 
address space"  even though that's what eventually happened.  

but just because it happened once doesn't mean that it will happen again.
we do well to learn from the past, but the past doesn't repeat itself
exactly.

it often seems to be the case that if you design for the long
term, what you get back isn't deployable in the near term because
you've made the problem too hard.  and if you design for the near 
term, what you get back will break in the long term.  but at least 
you get somewhere with the latter approach - the fact that we got 
a global Internet out of IPv4 demonstrated to people that the 
concept was viable.

today's design constraints aren't the same as tomorrow's.  with
today's Internet a lack of address space is a big problem.  with
IPv6 there's a considerable amount of breathing room for address 
space.  address space shortage is just one of many possible problems.
as long as the network keeps growing at exponential rates we are 
bound to run into some other major hurdle in a few years.  it might
be address space but the chances are good that before we hit that 
limitation again that we will run into some other fundamental barrier.  we 
can either try to anticipate every possible hurdle that the Internet 
might face or we can concentrate on fixing the obvious problems now 
and wait for the later problems to make themselves apparent before 
trying to fix them.  if we try to anticipate every major hurdle, 
we will never agree on how to solve all of those problems, and the 
Internet will bog down to the point that it's no longer useful.

> consequences of those predictions.  

no, that's just bogus.  on one hand you're saying that we cannot predict
how addresses will be used, and on the other hand you're saying that you 
can definitely predict that we'll run out of IPv6 addreses very soon.

> Ten years, I'd say.  

right now you're just pulling numbers out of thin air.  you have yet to 
give any basis whatsoever to make such a prediction credible.

> _delegate_ address space, because the address space is finite in size.  

wrong. you need to make design assumptions about delegation points, and
delegate portions of address space, even for variable length addresses
of arbitrary size.

> But by then, a lot of the biggest chunks were already in use.

true, several of the class A blocks were already in use by then.  
but initial allocations of IPv6 space are much more conservative .

> advance in the first place.

no.  even with variable length addresses you want to exercise some 
discipline about how you allocate addresses.  otherwise you end up
some addresses being much longer than necessary, and this creates 
inefficiency and problems for routing.

> Only with a fixed address space.

nope.  even phone numbers are allocated by prefix blocks.

> of each chunk is limited by the length of an address field.  

no, there are lots of other reasons for doing it.  you seem to be 
forgetting that routing hierarchy doesn't necessarily follow 
address hierarchy.  and that the point of a network protocol is
to get payload, rather than addresses, from one point to another.

> But if the address field is variable, you can make any chunk as big 
> as you want. 

actually, no you can't.  because addresses still have to fit within 
the minimum size of a datagram on the network and have room left
over for payload.

> will eventually cause problems, and much sooner than anyone thinks.

eventually I can buy.  but your predictions about the specific 
timeframe have no substance. 
 
> > can be doled out somewhat more generously than IPv4 space.

In 2030 (if I'm still doing this stuff) I will be much more concerned
about the overflow of UNIX time in 2038.

> Only with a fixed address length.

variable length addresses with no constriants on address growth
have their own set of routing problems.

> inevitable impossibility of knowing the future with certainty.  

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.

now it might turn out that in a few decades this will cause an address
space shortage.  but that doesn't mean that we made a wrong decision 
because in today's world having fixed offsets for addresses within
a packet (and thus fast routing) is more important than having arbitraily
long addresses.  

the biggest problem with IPv6 is the difficulty in getting it deployed.  
and IPv6 has enough barriers to deployment already without variable 
length addresses making it harder to route than IPv4.

> implement a new protocol.  

it depends on how many places have that length limitation wired-in.
we might could have made the IPv4 address larger except that every 
application on the net assumed fixed-length addresses.

> But in a variable-length system, you can make both ends variable.  

no you can't, because you still need globally scoped addresses, and
you have the incremental upgrade problem.  if you change the 
root of the address space you have to do it for everything at once.

Keith

---

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

> least one slot empty so that it can point to "more addresses").

Seems like that's very inefficient. You're building a tree. You make the
tree deeper in places where you have more nodes.

Even with forward-looking allocations, the tree is going to lopside
toward a linear organization, and need to be rebalanced.

(e.g., renumbered).

> will eventually cause problems, and much sooner than anyone thinks.

And variable length addrs. will cause problems eventually too, but it'll
be harder to explain why.

Joe

---

From: "Anthony Atkielski" <[email-masked]>
Date: Tue, 25 Apr 2000 20:07:05 +0200

> I wasn't there, but I expect it would have sounded
> even more preposterous for someone to have said:
> "I'm absolutely positive that this Internet thing
> will reach to nearly everyone on the planet in a
> couple of decades, and therefore we need to make
> sure it has many times more than 32 bits of address
> space"  even though that's what eventually happened.

Well, I suppose it would depend on who was listening at the time.

> but just because it happened once doesn't mean that
> it will happen again.  we do well to learn from the
> past, but the past doesn't repeat itself exactly.

It often repeats itself approximately, though.  And I predict that, since
computer engineers have been underestimating capacity requirements for the
past fifty years, they'll do it yet again this time, and then this
conversation will be repeated a few decades from now.

> it often seems to be the case that if you design for
> the long term, what you get back isn't deployable
> in the near term because you've made the problem
> too hard.

I dunno.  I don't think that adding two more digits in the 1960s to year
fields would have really made any problems too hard.  It was more a question
of people wanting to do things the easy way.  And you can't say that it was
a technological barrier, because they were still making Y2K-related mistakes
into the 1980s and beyond.

Also, making things hard is probably the second-most-common mistake of
computer engineers.  First they don't plan for the required capacity, and
then they get so lost in ever-expanding features that they never actually
deploy anything close to what they put in the specs.  This is more a problem
for software engineers than hardware enginers, though; hardware engineers
are constrained by the harsh realities of actually having to build things
that work, whereas software engineers can throw together buggy
approximations and limp along with those indefinitely.

It seems that, in the early days of [insert any major computer development
here], engineers just try to get something to work--anything.  Simplest is
best.  They make the capacity mistake, but they don't make the
software-bloat mistake.  However, ten years later, when they come up with
the "new and improved" version of whatever major development is in question,
not only do they _still_ underestimate capacity (even with past mistakes in
this area staring them in the face), but they slide into the abyss of
featuritis and software bloat, spending their time writing and reviewing and
honing ever-more-complex specifications that nobody will be able to actually
code, debut, and implement before the observable universe reaches thermal
equilibrium.  Sometimes the result is a "temporary" implementation that
actually does the job (even though it still has the capacity problem) and
eventually becomes the permaennt standard, with the original specs being
relegated to dusty archives somewhere.

> ... the fact that we got a global Internet out of IPv4
> demonstrated to people that the concept was viable.

Absolutely.  We just underestimated capacity requirements, as usual.

> with IPv6 there's a considerable amount of breathing
> room for address space.

Why settle for a "considerable amount" (which time will show to be less
considerable than first believed) when a "nearly infinite amount" can be
designed into the project?

> address space shortage is just one of many possible problems.

True, but it is much better understood than many of the others.  It's a
classic capacity problem.  And, as in most cases of capacity problems, it's
more a nuisance than something fun to work on, so it doesn't get as much
attention as it probably deserves, compared to the rest.

> as long as the network keeps growing at exponential
> rates we are bound to run into some other major hurdle
> in a few years.

It won't continue to grow at exponential rates, but it will grow in a way
that doesn't match the addressing scheme, and the modes of its future growth
will probably be different from anything we can expect or foresee today.  So
the only option is to just allow for the unforeseeable, instead of trying to
predict and implement for it.

> we can either try to anticipate every possible hurdle
> that the Internet might face or we can concentrate on
> fixing the obvious problems now and wait for the later
> problems to make themselves apparent before trying
> to fix them.

Address space is a pretty obvious problem.  But as I've indicated, it's not
a very exciting one.

> on one hand you're saying that we cannot predict
> how addresses will be used ...

Yes.

> ... and on the other hand you're saying that you

No, I cannot predict that.  But consider this:  If a fixed-length address
field is used, and we exceed the capacity of the field, we have a serious
problem.  If a variable-length address field is used, we do not exceed the
capacity of the field, ever.  And if we never exceed the capacity of the
fixed-address field, well, we'll never exceed the capacity of the variable
field either, will we?  So a variable field is a win-win scenario--you don't
have to hope that you can predict the future--whereas the fixed-length field
is a win-lose scenario, in which you have to just hope that your predictions
are right.

> right now you're just pulling numbers out of thin air.

Yup.

> you have yet to give any basis whatsoever to make such
> a prediction credible.

It doesn't have to be credible, it just has to be possible.  The increment
of work required for a variable address space is not so very great, if it is
carefully thought through, and the potential benefits are enormous.  In
contrast, the increment of work required to fix exhaustion of a fixed
address space is staggering, and no amount of thinking things through will
prevent it, if and when the address space is exhausted.

> wrong. you need to make design assumptions about
> delegation points, and delegate portions of address
> space, even for variable length addresses of
> arbitrary size.

Any examples of this?  None come to my mind.  With a variable-length
address, you don't have to care how the entire space is allocated; you just
allocate the part that you are responsible for.  You do not need to predict
all future use with a variable-length address, whereas you _must_ predict
all future use with a fixed-length address.

> true, several of the class A blocks were already
> in use by then.  but initial allocations of IPv6
> space are much more conservative .

With a finite address space, they can never be conservative enough, unless
you discard the inherent routability of the addressing scheme (by assigning
consecutive addresses one at a time on individual demand, for example).
This is because you cannot predict future evolution of the allocation
criteria for the address space, and you cannot expand the space.

> no.  even with variable length addresses you want
> to exercise some discipline about how you allocate
> addresses.

Why?

> otherwise you end up some addresses being much
> longer than necessary, and this creates

In what cases would a variable-length address be longer than necessary?  I
can easily think of allocation schemes that would break the routability of a
fixed-length addressing scheme, but I don't see this problem with
variable-length addresses.

> nope.  even phone numbers are allocated by prefix blocks.

Not on a worldwide basis.  The U.S. treats its address space as fixed (which
is one reason why it is now in trouble), but this isn't really true for the
world overall.  If a call is routed to Vulgaria from the U.S., nobody in the
U.S. has to care how Vulgaria allocates its telephone numbers.

> you seem to be forgetting that routing hierarchy
> doesn't necessarily follow address hierarchy.

It can't, with fixed addresses.  At some point you have to allocate
non-contiguous addresses for the same routing destination, and then your
routing breaks.

With a variable-length address, this is not a problem.

> actually, no you can't.  because addresses still have
> to fit within the minimum size of a datagram on the network
> and have room left over for payload.

Don't use fixed datagrams sizes.  Or, if you must, implement within limits,
but leave indicators for exceptions to the limits, so that you don't have to
redo it all from scratch when you eventually exceed the limits.

> timeframe have no substance.

Time will tell.

> In 2030 (if I'm still doing this stuff) I will be much
> more concerned about the overflow of UNIX time in 2038.

Seems that UNIX wasn't engineered with the necessary capacity, either.

> variable length addresses with no constriants on
> address growth have their own set of routing problems.

Such as?

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

We should put today's energy into designing systems that make no irrevocable
assumptions about tomorrow.

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

It's always easier.  However, you need to design something into the protocol
that tells the hardware when it is dealing with information outside the
envelope for which it was designed.  Then you can trap the exception and fix
things.  If you simply assume that there will never be any exceptions, you
get dramatic and dangerous failures when they finally come along.

> the biggest problem with IPv6 is the difficulty in
> getting it deployed.  and IPv6 has enough barriers to
> deployment already without variable length addresses
> making it harder to route than IPv4.

Maybe it is overambitious.

The easiest way to get it deployed, though, would be to have Microsoft ship
it as part of Windows.  In a year or two, everyone would be using it.  And
as long as this doesn't happen, it will never get deployed (at least not
anywhere near the desktop or home user).

> it depends on how many places have that length

You build them so that the wiring is easy to change and is not duplicated
any more times than absolutely necessary.

> no you can't, because you still need globally scoped
> addresses, and you have the incremental upgrade problem.

That doesn't seem to have stopped the world's telephone networks from
connecting to each other, and they had exactly this problem.

> if you change the root of the address space you have
> to do it for everything at once.

Only if everything already assumes that the root it sees is the only root
that exists, which is not a good way to design things.  In a telephone
system, the "root" can be my central office, or my area code, or my country
code, depending on how far I'm calling.

  -- Anthony

---

From: [email-masked]
Date: Tue, 25 Apr 2000 15:28:35 -0400

> fields would have really made any problems too hard.  It was more a question

You never had to fit 2 more bytes onto a punch card, did you?

I'm not being facetious here - you had 80 columns and that was IT.

Some databases were laid out with (for instance) exactly 3 6144-byte
records per physical track on the disk.  Adding 2 more digits would have
dropped it to 2 per track, with a lot of wasted space - and forcing not
only the consumption of 50% more disk, but also re-doing any indexing (see
below for a related story).

> into the 1980s and beyond.

When I got to VT in 1989, chargeback accounts on the IBM mainframe
were of the form 'nxxxy'. n was a 0-9 type code, and xxx was a 3-digit
hex number and y was a single digit 0-7.  Turns out that the xxx and y
were the track humber and record number when the database lived on an
IBM3330 disk drive.  The database had since been moved to 3350, and
then to 3380/3390.  However, it proved to be just too much of a
challenge to track down ALL the places those numbers were used and fix
them.  Not only does the database itself need to be redone, but you
get to re-do all the userids to give them the new numbers, find ALL
the JCL that has chargeback accounting information, fix all the files
on secretary's PCs that have a professor-to-account lists.. the list
goes on and on....

And we're a relatively small shop - our machine room is only 10K sqare feet..

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Keith Moore <[email-masked]>
Date: Tue, 25 Apr 2000 16:39:49 -0400

> fields would have really made any problems too hard.  

you've obviously never tried to write business applications for a 
machine with only a few Kbytes of memory.  memory was expensive
in the 1960s, and limited in size.  so was secondary storage.
people optimized every byte, and for good reasons.

> And you can't say that it was a technological barrier, because 
> they were still making Y2K-related mistakes into the 1980s and beyond.

up and into the early 1980s the technological barrier was real.
after that, some of the problems were habit or oversight and some 
of them were due to the need to backward compatibility.  there's
also a more subtle problem that it's difficult to maintain old software
and every time you fix an old bug you stand a good chance of introducing
a new one.  so software tends not to get updated as long as it's mostly 
working.  it's hardly surprising that people didn't bother to fix 
some of the y2k problems until they were forced to do so.

> designed into the project?

this has been explained already.  "nearly infinite" imposes technological 
limitations which make it unimplementable at wire speeds, and thus,
undeployable.

and I've already addressed most of the other questions you ask, so I'm
not going to respond to them again.

Keith

---

From: John Stracke <[email-masked]>
Date: Tue, 25 Apr 2000 16:58:25 -0400

> fields would have really made any problems too hard.

Hard, no; expensive, yes.  Consider a DMV system for a state with, oh, 10
million people; each person has a record with at least 3 dates (birth, license
expiration, and one registration date for each car).  Using 4-digit years would
have required over 60MB more storage space.  I don't know 1960s storage prices,
but I know that 60MB would have cost enough to be worth saving.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Anyone who has a conditioned response        |
[email-masked]|immediately thinks of Pavlov.                |
\==============================================================/

---

From: Steve Deering <[email-masked]>
Date: Tue, 25 Apr 2000 15:08:13 -0700

Anthony,

One interesting example:  OSI NSAP addresses are variable length, with a
theoretical limit of 255 bytes I believe (perhaps there's an escape
mechanism to grow them longer?).  There was an "implementors'
agreement" to limit the maximum length in actual use to 20 bytes "for now",
to make implementations practical.  Two things happened:

	(1) Almost all of the addressing plans designed for NSAPAs
	    produced addresses that were *exactly* 20 bytes long, in
	    some cases inserting padding in the middle of the address
	    to fill it out to 20 bytes!  I suspect that was done to
	    make the address allocation job easier, e.g., making
	    sure delegation boundaries fell on byte boundaries.

	(2) Many of the implementations ended up with the 20-byte limit
	    wired into them, such that the use of addresses longer than
	    20 bytes would have required updating most of the installed
	    base (the changes being of a similar nature to those required
	    to modify an IPv4 application or protocol to support IPv6).

This (admittedly anecdotal) example led me to surmise that:

	- any variable-length address scheme will have a maximum size
	  imposed upon it, for pragmatic implementation reasons.

	- any variable-length address scheme will quickly degenerate
	  into a fixed-length scheme of maximum size, for human nature
	  reasons (the humans being the people doing the address
	  allocation).

At which point, you are back to the problem you were trying to avoid.

I think the only reason this hasn't happened in the phone system is due
to resistance by humans to reading, writing, and entering very long
strings of digits.  Unfortunately, computers aren't as fussy.

Perhaps you could think of IPv6 addresses as variable-length addresses
within a fixed-size container, in which the variable-length part is in
the middle and not at the right hand end?  :-)

Anyway, as pointed out by others, the IPv6 work anticipates that there
may be a need to "rebalance" the address assignments (i.e., renumber) in
the future, if/when our predictions of where the growth will be turn out
to be wrong, which ought to be less painful than making the changes to
deployed implementations that your scheme would require whenever a
significant number of addresses started to exceed the length that caused
traps into the exception-handling code.  And we avoid the risk of having
many very long addresses (in this case, longer than 16 bytes) being used,
which is important for a connectionless protocol like IP, in which the
addresses are overhead in every packet.

Steve

---

From: Andrew Partan <[email-masked]>
Date: Tue, 25 Apr 2000 18:57:38 -0400 (EDT)

> limitation again that we will run into some other fundamental barrier.

The problem some of us have been worring about is the routing table.

The routing table can either fill up or be overwhelmed by the rate
of change of routing entries.  There is a tradeoff between these
two - no changes means that you can have a large static table; lots
of changes and you will need a smaller table to have stability.

Unfortunately its hard to predict when you will tip over...
	[email-masked] (Andrew Partan)

---

From: George Michaelson <[email-masked]>
Date: Wed, 26 Apr 2000 10:08:08 +1000

My experience is that as people become more (internationally) mobile their
use of IDD +xx aaaa bbbb form number spec becomes more common.

Likewise with major slices of the UK and Australia recently renumbered, people
were forced to ditch their paper investment in old numbers and dropped into
line in a semi-standard form of representation which has to be full-number
aligned, because the new digits are in front of the old semi-optional prefixes.

In other words, the old '7 digits is all people can handle' rule is melting
in the face of a larger pool of people who have to use longer digit strings.

cheers
	-George
--
George Michaelson         |  DSTC Pty Ltd
Email: [email-masked]    |  University of Qld 4072
Phone: +61 7 3365 4310    |  Australia
  Fax: +61 7 3365 4311    |  http://www.dstc.edu.au