[sig-ipv6] BOUNCE sig-ipv6@lists.apnic.net: Non-member submission from [Brian E Carpenter <brian@hursley.ibm.com>]

[owner-sig-ipv6@lists.apnic.net]

>From owner-sig-ipv6  Tue Jul 11 04:29:12 2000
Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15])
	by whois.apnic.net (8.9.3/8.9.3) with ESMTP id EAA95398
	for <sig-ipv6@apnic.net>; Tue, 11 Jul 2000 04:29:09 +1000 (EST)
Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id TAA44420; Mon, 10 Jul 2000 19:28:39 +0100
Received: from hursley.ibm.com (lig32-225-4-144.us.lig-dial.ibm.com [32.225.4.144]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id TAA23122; Mon, 10 Jul 2000 19:28:50 +0100 (BST)
Message-ID: <396A0179.241F756D@hursley.ibm.com>
Date: Mon, 10 Jul 2000 12:01:45 -0500
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: Heikki.Waris@nokia.com
CC: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net
Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision
References: <01D91AFB08B6D211BFD00008C7EABAE1021673D3@eseis04nok>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by whois.apnic.net id EAA95399

Heikki,

Matt's calculation is based on Huitema's H-ratio which is based on
actual experience, not theory.

   Brian

Heikki.Waris@nokia.com 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:crawdad@fnal.gov]
> > Sent: 7. heinäkuuta 2000 21:22
> > To: ipng@sunroof.eng.sun.com; ngtrans@sunroof.eng.sun.com;
> > sig-ipv6@apnic.net; mir@ripe.net; joao@ripe.net
> > 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.)
> >


*              sig-ipv6:  APNIC SIG on IPv6 technology and policy issues           *
* To unsubscribe: send "unsubscribe" to sig-ipv6-request@apnic.net *