[sig-ipv6] BOUNCE sig-ipv6@lists.apnic.net: Non-member submission from ["Matt Crawford" <crawdad@fnal.gov>]

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

>From owner-sig-ipv6  Tue Jul 11 02:24:16 2000
Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1])
	by whois.apnic.net (8.9.3/8.9.3) with ESMTP id CAA93136
	for <sig-ipv6@apnic.net>; Tue, 11 Jul 2000 02:24:14 +1000 (EST)
Received: from gungnir.fnal.gov (localhost [127.0.0.1])
	by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id LAA26207;
	Mon, 10 Jul 2000 11:24:03 -0500 (CDT)
Message-Id: <200007101624.LAA26207@gungnir.fnal.gov>
To: Heikki.Waris@nokia.com
Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, sig-ipv6@apnic.net
From: "Matt Crawford" <crawdad@fnal.gov>
Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision 
In-reply-to: Your message of Mon, 10 Jul 2000 18:12:49 +0300.
             <01D91AFB08B6D211BFD00008C7EABAE1021673D4@eseis04nok> 
Date: Mon, 10 Jul 2000 11:24:03 -0500
Sender: crawdad@gungnir.fnal.gov

> 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

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