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]
--------------------------------------------------------------------
