Subject: RE: Addresses and ports and taxes -- oh my!

From: "Book, Robert" <[email-masked]>
Date: Thu, 3 Aug 2000 12:57:49 -0400

Vinton's idea has much merit. A scheme to allocate blocks of addresses to
manufacturers would be much easier to support than an organization
attempting to process individual email requests, or CGI scripted forms from
a webpage, or a world-wide DHCP server for Amana ( and one for Maytag, etc.)
to register a refrigerator. And easier administration should translate into
lower cost...... :-) My apologies in advance for polluting the IETF announce
list. Btw, did we ever find out how many people were on that elevator? :-)

-----Original Message-----
From: vinton g. cerf [mailto:[email-masked]]
Sent: Thursday, August 03, 2000 10:51 AM
To: Dennis Glatting; [email-masked]
Subject: Re: Addresses and ports and taxes -- oh my!

Dennis

thanks for drawing attention to this question. One of the reasons
for fees, of course, is that the Address Registries also have responsibility
to support ICANN so they have some new costs in addition to their operating
costs (or if you like, their operating costs include support for ICANN).

It is a very good question whether one's internet-enabled household
appliances
will induce a monthly charges - do you suppose there would be a way to have
a
one-time charge to "pay" for some number of such addresses - perhaps built
into
the cost of the appliance (and paid by the manufacturer who "burns" an
address
into the device - at least the low order 64 bits or something to make it
end-to-end unique)? 

Please don't flame me for thinking out loud - Dennis' point is a good one
and
we ought to discuss - perhaps in a smaller group than the whole of ietf
announce
list!

Vint Cerf

At 05:32 AM 8/3/2000 -0700, Dennis Glatting wrote:

>I've been thinking about the issue of ARIN fees from last night's plenary
>and arrived at two philosophical questions.
>
>I run my business out of my home and my DSL link is an important part of
>my business. About six months ago my ISP started charging me a $20/mo. fee
>for my /27 because "ARIN is now charging us." I am unhappy about this fee
>but I understand its motivation -- conversation of IP space, though I
>believe fees do not really effect the true wasters of this space and the
>fee, or as it is called in some circles, a tax, is probably misguided.
>Nonetheless, with IPv6, I naively hoped, until last night, the
>conservation of space issues would go away, and thus the fees. Big duh!
>
>If we look at today's marketing hype and think forward a bit there is a
>thrust to "Internet enable" appliances, such as dryers, ovens, and
>stereos. Assuming ARIN fees persist, my first philosophical question is
>whether any consumer of these appliances MUST periodically (e.g., monthly)
>drop coins in the ARIN fountain?
>
>Thinking laterally, the reserved port space (<1024) is tight. Using the
>same IP space conversation logic, should fees be charged to conserve port
>space? If so, my second philosophiocal question is what is our role, as
>protocol designers and IETF volunteers, in creating, what is slowly
>becoming, an Internet consumption taxation model?
>
>Imagine for a moment the effect of a fee against the allocation or use of
>port 80 or 443, maybe even port 25 or 53.
>
>
>
>

=================================================================
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!" 
INET 2001: Internet Global Summit 
5-8 June 2001 
Sweden International Fairs 
Stockholm, Sweden 
http://www.isoc.org/inet2001

---

From: John Stracke <[email-masked]>
Date: Thu, 03 Aug 2000 15:44:37 -0400

"Book, Robert" wrote:

> manufacturers would be much easier to support

Mmm...that's already there, isn't it? The low-order 64 bits he's talking about
are things like Ethernet addresses, for use in IPv6 autoconfig.  (We can't
allocate blocks of actual IP addresses to manufacturers, of course, or the
routers will go mad.  I don't want to wake up in the middle of the night to
find a zombie router, with its front panel glowing insanely, standing over me
with a Cat5 garrotte and screaming, "Revenge!".  :-)

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |If God had not given us duct tape, it would have|
[email-masked]|been necessary to invent it.                    |
\=================================================================/

---

From: John Day <[email-masked]>
Date: Thu, 3 Aug 2000 15:37:03 -0400

>attempting to process individual email requests, or CGI scripted forms from

Good grief!  This is the worst possible solution.  We are allocating 
*addresses*, not serial numbers.

>a webpage, or a world-wide DHCP server for Amana ( and one for Maytag, etc.)

I presume that you assume that all Amana appliances will be in the 
same topological part of the network and all Maytag appliances will 
be a different part of the topology.

How do you suppose route aggregation will work with such an approach?

>list. Btw, did we ever find out how many people were on that elevator? :-)

John Day

---

From: [email-masked]
Date: Thu, 03 Aug 2000 16:19:14 -0400

> to register a refrigerator. And easier administration should translate into

You don't want to assign network addresses on a per-manufacturer basis.
Network addresses have to be aggregable.

That's why we have ARP because MAC addresses on an Ehternet are assigned
per manufacturer.  But that's OK, because IPv6 has ARP ;)
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: "vinton g. cerf" <[email-masked]>
Date: Thu, 03 Aug 2000 23:17:07 -0400

I had been assuming that the aggregation would take place
at the "prefix" level of IPv6 addresses and that the unique
component would be in some lower order part of the 128 bit space.

If I have a bad model of that, I'd appreciate offline explanation.

thanks

vint

MCI WorldCom

---

From: "Anthony Atkielski" <[email-masked]>
Date: Fri, 4 Aug 2000 08:52:37 +0200

Robert Book writes:

> Vinton's idea has much merit. A scheme to allocate blocks
> of addresses to manufacturers would be much easier to
> support ...

No.  This will only accelerate the exhaustion of IPv6.

---

From: [email-masked]
Date: Fri, 04 Aug 2000 13:04:41 -0400

> No.  This will only accelerate the exhaustion of IPv6.

Back of the envelope math time...

How many Ethernet address blocks has 3com gone through?

How many companies have been *allocated* Ethernet address blocks?

Remember that the MAC addresses can be *very* tightly allocated, with
little to no loss due to subnetting or aggregation concerns, and so
on.  You can think of it as a simple enumeration of connected items. If
you allow 48 bits for hardware address blocks, and assuming 8G people
on the planet, each one can own some 8,000 things that have addresses.

That's not enough?  Allocate another 8 bits.

How many people on the planet own 2 million ANYTHINGs?

And there's still 8 more bits in that low 64 bits.

And there's still another 64 bits for actually ROUTING.

				Valdis Kletnieks

---

From: "Anthony Atkielski" <[email-masked]>
Date: Sat, 5 Aug 2000 01:45:50 +0200

> How many Ethernet address blocks has 3com gone through?

MAC addresses do not affect routing.  They are just numbers.  IP addresses
cannot be randomly assigned, as they are correlated with routing.  This
severely restricts the allocation of the address space.

> If you allow 48 bits for hardware address blocks, and
> assuming 8G people on the planet, each one can own some
> 8,000 things that have addresses.

Not if all those things are routed to based on their address.

If you route all 123.xxx addresses to country A, and all 456.xxx addresses
to country B, and country A runs out of address space, you cannot allocate
any addresses to country A from the address space of B, even if the latter
is 99% unused, because it messes up the routing.

Because of this, and because you cannot predict which geographic areas will
require how many addresses in the future, the only way to avoid exhaustion
of the address space is with a variable-length address.

I'm surprised that this is not intuitively obvious.

Telephone numbers in the United States have 11 digits.  That's enough for
one hundred billion telephones, or about 400 for every man, woman, and child
in the country.  And the country isn't anywhere near that point yet.  And
yet this telephone-number space is nearing exhaustion.  Why is that?  It's
because the routing is embedded in the numbers, and whoever allocated them
apparently always thought in terms of the maximum theoretical address space
available with random assignment of numbers, and not of the address space
with the constraints imposed by routing considerations.

The only way to fully utilize any address space is to assign addresses from
that space sequentially, one after another, without any regard at all for
who or what is requesting the address, and without any allocation of
"blocks" of addresses in advance.  Anything other than straight sequential
allocation of addresses introduces additional information content into the
address, and since the maximum amount of information that can be held in the
address representation is fixed, this inevitably reduces the number of
available addresses.  Introducing routing information into addresses adds a
great deal of information to them, and thus greatly reduces the number of
available addresses.  There is no way around this.

It is important for anyone considering these addressing issues to remember
that, unless addresses are assigned sequentially, one at a time, without
reference to any other criteria at all, the assumption that the number of
available addresses will equal the total size (total information capacity)
of the address space is not valid--in fact, it may be seriously in error, by
many orders of magnitude.

Let's say you have a routing scheme that involves ten hops, each of which
can take two possible paths.  If you encode this into your addressing
scheme, it will require 20 bits.  If your address space is 32 bits wide,
that leaves only 12 bits--4096 addresses--at each routing endpoint.  If one
of your endpoints runs out of addresses, you're stuck, because you cannot
allocate addresses from the other endpoints, because there is no way to
route them.  This is what happens in IPv4, and it is also what will happen
in IPv6, and in any other fixed-length addressing scheme that encodes
anything more than a machine identifier into the address.  Furthermore, even
if you have lots of bits to dedicate to routing, it is impossible anticipate
which routes will require the greatest number of addresses, so no matter how
you try to allocate them in advance, eventually--soon--some subspaces will
run dry, with no possibility of swiping addresses from other subspaces that
still have room.

It has happened before, and it will happen again, and it will always be much
sooner than anyone thinks.

---

From: Robert Elz <[email-masked]>
Date: Sat, 05 Aug 2000 20:05:06 +1000

Date:        Sat, 5 Aug 2000 01:45:50 +0200
    From:        "Anthony Atkielski" <[email-masked]>
    Message-ID:  <003f01bffe6e$1fd89ad0$0a00000a@contactdish>

  | Not if all those things are routed to based on their address.

You left out the bit (from what you quoted) where Valdis said that
there were still another 64 bits to use for routing...

  | If you route all 123.xxx addresses to country A, and all 456.xxx addresses
  | to country B, and country A runs out of address space, you cannot allocate
  | any addresses to country A from the address space of B, even if the latter
  | is 99% unused, because it messes up the routing.

Leaving aside that "country" is the wrong model here (routing and national
boundaries are not much related) - we can use that as a convenient word to
use to express the insides of a routing boundary nevertheless.

  | Because of this, and because you cannot predict which geographic areas will
  | require how many addresses in the future, the only way to avoid exhaustion
  | of the address space is with a variable-length address.
  | 
  | I'm surprised that this is not intuitively obvious.

Perhaps because it is wrong.   The other solution, and the one IPv6 has
preferred, is simply to take back all the 123.xxx and 456.xxx addresses,
and reassign them again in a way that does allocate suitable volumes of
addresses to each "country" while retaining routing scalability.

Once you allow addresses to be reassigned, instead of insisting that an
address once assigned is fixed forever, the only issue remaining is whether
or not there is sufficient address space.   And I agree, that does need to
include space for the overheads incurred in making the addresses routable.
What's more, we know and agree that those overheads are not negligible,
in fact, they're quite huge (once they're multiplied).

But even with all that, the IPv6 64 bit routing space (plus 64 bits
of on-link identification space, which is overkill for sure, but
simplifies things) is plenty.

Truly variable length addresses would be another way to solve some of
the problems, but they introduce other problems, and in any case, it
isn't possible to use truly variable length addresses in any kind of datagram
network based upon any technology currently in use - packets all have
fixed maximum lengths (necessary because of checksum algorithm requirements
even if for no other reason), and sticking something (even worse, two of
something) that are truly variable length into a fixed length container is
an interesting exercise.   But even if you're willing to assume that
the variable length things will never get long enough to become a bother
for this (which would seem to be admitting that fixed length will do
after all - and then perhaps just disputing how big the space needs to be)
variable length assignment schemes of the type you're proposing forever
consign those who come later to a diminished service quality from those
who came before.  That is, if you get a shorter address (an early one)
you forever fit more payload per packet than someone who ends up with a
much longer address, having joined a popular tree somewhat later.

All this is not to say that IPv6 will remain with us forever - eventually
it too will need to be replaced.  Why that will happen we have no idea - if
we knew that we could take steps now to avoid whatever the problem will be.
However, it isn't going to be the address space that kills IPv6, it will
be something else, something that we haven't forseen (or just perhaps the
one thing that we have forseen, but aren't really sure how to overcome,
which is how to overcome the inertia and get IPv6 into widespread operation
in the first place - there is still the possibility that it might be
stillborn, though that isn't a scenario to really contemplate).

kre

---

From: John Day <[email-masked]>
Date: Sat, 5 Aug 2000 15:53:27 -0400

>Not if all those things are routed to based on their address.

Anthony,

You are absolutely correct in your analysis.  But this partly, why
addresses are supposed to be location dependent, not route dependent.  They
may have information embedded in them to tell you *where* they are, but not
*how* to get there.  This may be what you meant, but I wanted to clarify
it.  It may seem I am splitting hairs but it makes a big difference when
you get down to doing it.

Take care,
John