> > So we need 2*10^12 subnets just for currently foreseeable
> uses. Or in terms
> > of address space, consumption of 41 bits. If we leave out
> the 3 bit format
> > prefix, this leaves us with 20 bits to waste (if subnets
> are /64). If the
> > default subnet is /48, we only have 4 bits to waste. And
> that's not much.
>
> Point 1: Subnets (under format prefix 001 binary) *are* 64 bits, not
> 48. That is not under any sort of argument by anyone, as far as I
> know. The question the registries are trying to open is how many
> subnets get assigned in a block to a "site".
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 and therefore it is crucial that the assignment is
done in blocks of /64 subnets.
Real organizations could be eligible for /56 or /48 prefixes but this should
not force the above mentioned entities to get the same prefix lengths by
default. So I still see some relevance in this point.
> Point 2: You've already built in a 90% "waste" into your numbers, so
> saying that you are left with "only n bits to waste" is pure
> deception.
Buffers on top of buffers, but it is nevertheless useful to look at the
issue from a different angle. And see that with some carefully chosen
parameters we can get close to exhausting the IPv6 address space (ok, within
7 bits to the limit) 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...
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. Keeping to the default /64 block at least initially is a good start.
Heikki Waris
>
> 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]
--------------------------------------------------------------------
