Heikki,
Matt's calculation is based on Huitema's H-ratio which is based on
actual experience, not theory.
Brian
[EMAIL PROTECTED] wrote:
>
> I'd like to contribute my view on this prefix length issue.
>
> If we start by trying to estimate the total amount of routers required at
> the edge of the network, this whole conversation will gain some perspective.
> Let's make a quick calculation, assuming that there are 500 million
> well-to-do people in mainly industrialized countries with enough financial
> resources who healthily envy their neighbors with more gadgets and gizmos
> (and therefore need to have those themselves):
>
> offices/corporate sites 50M
> (small separate units, subnet per avg. 5-10 employees)
> personal 2G/3G terminals 5M
> (1 base station serves 1000 people, 10 overlapping operators)
> WLAN access points etc. 50M
> (covering all rural areas, avg. 10 users within the radius)
> Bluetooth etc. local networks 500M
> (ubiqutous, offer routing mainly in business environment)
> personal mobile routers 500M
> (for connecting wearable equipment, personal subnet)
> houses/apartments 500M
> vehicles 500M
> =====
> ca. 2100M
>
> Make this available to total active population worldwide, multiply 10x.
> Then we add another decade due to the human tendency of hoarding resources
> and not freeing address subnets that are no longer used.
> Then assume that the total efficiency in assigning the subnet space will be
> close to 10% due to (30% efficiency at two levels, or 47% at three levels of
> hierarchical providers)
>
> 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.
>
> Organizations can be worried about not getting enough continuous address
> space that they can autonomously manage. This is not an excuse for sloppy
> address allocation. Why not instead suggest providers to initially assign
> only every 8th or 16th SLA ID for growing organizations? This would leave
> the provider address space in semi-allocated state (could hamper reaching
> the 90% mark) but leave some back doors for those that require it. Solving
> the preferences or problems of individual organizations with case-by-case
> negotiations instead of generalized rules that may have wider consequences
> seems to me like a reasonable approach.
>
> Heikki Waris
>
> > -----Original Message-----
> > From: EXT Matt Crawford [mailto:[EMAIL PROTECTED]]
> > Sent: 7. hein�kuuta 2000 21:22
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document
> > Revision
> >
> >
> > The question to answer is, for a liberal estimate of the number of
> > "sites" required 50 years from now, how efficiently (how
> > non-wastefully)
> > do assignments need to be made to fit within available space?
> >
> > An extremely liberal estimate of the number of sites required would be
> > one per person. Taking the upper range of the year 2050 population
> > projection from http://www.popin.org/pop1998/ ...
> >
> > World population currently stands at 5.9 billion persons and
> > is growing at 1.33 per cent per year, or an annual net
> > addition of 78 million people. World population in the mid
> > 21st century is expected to be in the range of 7.3 to 10.7
> > billion. The medium-fertility projection, which is usually
> > considered as "most likely", indicates that world population
> > will reach 8.9 billion in 2050.
> >
> > tells us to reckon on 11 billion sites. The available space for
> > assignment of /48 site identifiers is 45 bits worth if we confine
> > ourselves to one three-bit Format Prefix. (Six more such are
> > potentially
> > available.) Using the H-ratio of RFC 1715 to compute the required
> > efficiency of assignment as log_10(1.07*10^10) / 45 = 0.22.
> > This is less
> > than the efficiencies of telephone numbers and DECnetIV or
> > IPv4 addresses
> > shown in RFC 1715*. Coupled with the generous assumption of
> > a site per
> > person, the reasonable expectation of easier renumbering for IPv6 than
> > IPv4 or the telephone, and the availability of 6x more unicast address
> > space, I can't see any way to justify a claim that a /48 per
> > site can't
> > be supported.
> > Matt Crawford
> >
> > (* Actually, RFC 1715 understates the efficiency of phone number
> > allocation by using the number of nodes /before/ an increase in
> > numbering space was made but counting the bits /after/ the increase.)
> >
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
