> Yes, sorry about that ambiguous use of terminology. But as you see from the
> calculation, most of the sites are consumed by individual entities (be it
> persons, vehicles, fixed locations or such) instead of traditional provider
> type large organizations ...
I don't know if I'd call a table of made-up numbers a "calculation",
but yes, you assumed that each "wealthy, envious" person would have a
lot of address space. Then you multiplied by 10 to include everyone,
then you made an extremely dubious second multiplication by 10 to say
that everyone would "take" address assignments ten times over without
"giving back" their old assignments. That idea just won't survive
contact with the IPv6 operational model of provider-based assignment
and renumbering at need.
> and therefore it is crucial that the assignment is
> done in blocks of /64 subnets.
Even with your dubious multiplicative factors, you still came up with
more than a factor of 10 to spare with assignment of /48s
everywhere. (Even to personal Bluetooth networks that can hold less
than 10 devices!) This falls considerably short of "crucial."
> And see that with some carefully chosen parameters we can
"Extravagantly", not "carefully".
> get close to exhausting the IPv6 address space (ok, within 7 bits
> to the limit)
In other words, a safety factor of more than 100.
> even with nowadays recognizable uses.
> Besides, that 90% waste resulting from suboptimal provider
> allocation is just due to the fact that there may be small scale
> providers down in the hierarchy that will never grow so big that
> their initial address space runs out. Unless we also aggregate the
> providers with mega-mergers...
"Providers down in the hierarchy" are to get their address space from
higher up in the hierarchy. I wonder if you're familiar with the
addressing and assignment architecture.
> The bottom line is that we shouldn't be absolutely confident that
> there's enough IPv6 addresses unless we take caution in the ways
> that we allocate them.
One form of caution is to make sure that a site can easily change its
prefix if it connects to a different point in the topology. making
all the leaf-site blocks the same side IS a cautionary measure to
make this possible.
Matt Crawford
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
