[ppml] Big numbers

[Leo Bicknell]

In a message written on Mon, Apr 07, 2003 at 05:28:24PM -0500, Bill Darte wrote:
> Of course, we are not talking about numbering individuals, but potentially
> every electrical and electronic component as well as subsystem elements
> perhaps....  there is no census data for these things, but undoubtedly this
> represents a very large number as well.

But, probably smaller.

For instance, it's easy to invision every house having an IPv6
network inside it where the refrigerator talks to the toaster or
whatever.  Sure, all those devices need an address, but a /64 should
be _more_ than enough for even the largest palace. :)  Even if we
assume a 2nd network to support "internet" stuff (so the first one
can be firewalled/secured/protected differently and easily) that's
two per house.

Items outside the house (electrical grids, water systems, whatnot)
are likely to be "aggregated" by the authority running them.  Again,
while /64 subnets may be sparsely populated by what they could
hold, they would probably often still have hundreds, or thousands,
or more devices in them.

I'm not too worried about the number of numbers available.  I am
very worried about the routing system.  Let's allocate one /64 to
every home for home automation.  Let's allocate one /48 to every
person for them to do with as they please.  Let's give utilities
some /40's to make every meter be "online", number wise, no problem.
However, let's now try and have a routing system that allows every
house to have it's own subnet, and be provider independent, and
not have to renumber when someone sneezes.  That's a huge problem.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20030408/2962b0ab/attachment.sig>