[arin-ppml] Controlling the IPv6 address consumption rate

[Owen DeLong]

On Oct 13, 2010, at 7:43 AM, William Herrin wrote:

> On Sun, Oct 10, 2010 at 12:08 PM, Owen DeLong <owen at delong.com> wrote:
>> On Oct 10, 2010, at 7:09 AM, William Herrin wrote:
>>> 7 billion people in the world, each of which consumes Internet
>>> service, so as a lower bound we'll need 9 bits worth of 20M-equivalent
>>> ISPs to serve them.
>> 
>> 4,200,000,000 / 20,000,000 = 210 = 8 bits worth of 20M-equivalent
>> ISPs. However, it won't actually work out that way. The vast majority
>> of ISPs will be much smaller and there will be many more of them.
> 
> Okay. 8 bits, 9 bits. The key result from all the math is this:
> 
> Between an austere deployment of IPv6 (/60 end users, cramped routing,
> etc) and a deployment of IPv6 that will consume the entire address
> space prior to the retirement of IPv4, we have roughly 22 bits, not
> the 96 bits that one might naively expect with an expansion from 32 to
> 128 bits.
> 
Somewhere between 32 and 40 by my count, but, anyway...

> Responsible management demands that we treat some portion of that 22
> bits as a consumption suppressor so that we don't quickly run out of
> IPv6 addresses. Whatever is left over, be it 4 bits, 20, or anything
> in between, that's the number of bits we can actually afford to use
> for nice-to-haves, like a larger standard end-user assignment than /60
> (/56 or /48), sparse assignment and so on.
> 
Hence the /3 and the reservation of 7/8ths of the address space.
The IETF already put the consumption suppressor stake in the ground there.
I see no reason to move it.

> 
>>> : how should we divvy up the 22 bits
>>> between IPv4's consumption rate and IPv6's minimum needful consumption
>>> rate? How many bits of convenience and how many bits of responsibly
>>> slow consumption?
>>> 
>> _IF_ I understand what you mean by these terms correctly, then, yes,
>> I think an 8/14 ratio isn't such a bad ratio
> 
> It sounds to me like you do understand what I mean.
> 
> 8 bits of conservation worries me. We badly underestimated at the
> start of IPv4. I'd be more comfortable starting with a more
> conservative number (like 12 or 16) and then working down to 8 bits of
> conservation after we gain a decade or two of experience.
> 
Yeah, I think that's pretty absurd.  Conserving 255/256ths of the address
space is somewhat absurd to begin with, but, hey, why not... Plenty of
room in the 1/256th we're talking about, so, OK... Let's try that.

Conserving 4095/4096ths of the address space, well, that's getting
ridiculous on its face. Especially in light of the need for ridiculous
wastes of IPv6 like 6rd in order to get IPv6 deployed because the
vendors of last mile technology managed to get caught with their
pants down by an event that they had more than a decade of warning
was coming.

I agree it's tragic and wasteful. However, I think it is better to deploy
with 6rd than to fail to deploy and end up with LSN more widely
deployed.

> On the other hand, if the current address consumption rate holds at
> what eyeballs to me vaguely like 0.6(n^2), 8 bits of conservation
> should buy us around 115 years. If Geoff is lurking, I'm sure he can
> provide better information assuming completion of the IPv6 transition
> with IPv6 consumption at 1/256th of IPv4's current consumption and the
> same consumption growth rate exhibited over the last 15 years in IPv4.
> 
A very good argument for 8 bits or less...

> Anyway, let's run with 8 bits and see what it implies.
> 
> 8 bits means that the maximum allocation we can allow a single
> organization to seek both initially and due to prior consumption is
> /20. The largest holding we can allow an affiliated set of
> organizations (including merged and acquired ISPs) totals /16. The
> 4-bit difference comes from that hold-against-development set I talked
> about. Larger allocations than this, regardless of cause, are likely
> to see us deplete the IPv6 free pool faster than the 8-bits
> conservation target we've set.
> 
OK.

> 8 bits also means you have only 14 bits left for the nice-to-haves. If
> you spend 12 of those bits bringing the downstream end-user assignment
> from the austere /60 to your preferred /48, you'll have only 2 bits
> left. That doesn't give you much flexibility with your routing. Are
> you sure you wouldn't rather put 4 of your bits to bring the
> assignment up to /56 and use the remaining 10 to do smarter things
> with your routing hierarchies? 256 LANs is a lot of LANs for all but
> the largest customers.
> 
And here's where you run off the rails again by miscounting the bits.

Let's look at the reality...

Tiny ISPs with fewer than 30,000 end sites served fit fine in a /32.
Probably about 15% of total ISPs.
Small to medium ISPs with between 30,000 and 500,000  end
sites served warrant a /28. Probably about 50% of total ISPs.
Large ISPs with between 500,000 and 12,000,000 end
sites served (probably about 30% or more of total ISPs) warrant a /28.
Extraordinarily large ISPs with more more than 12,000,000 end
sites served would get a /20 or in extreme cases, maybe a /16.
I'll divide these up as 4% get a /20 and 1% a /16 for purposes
of discussion. I suspect the real numbers are more like 4.99% and
0.01%.

Assuming for the moment that there are roughly 30,000 ISPs
on the planet, those percentages work out as follows:
Quan	Pfx		/32 equiv.
4,500	/32		4,500
15,000	/28		240,000
9,000	/24		2,304,000
1,200	/20		36,864,000
300		/16		19,660,000

Total			59,072,500 /32s

This would mean that we consume a total of 3.5 /16s to
number the entire existing internet according to my
suggested way of numbering things.

I'm willing to set aside a few other /16s for 6rd to be deployed
temporarily (~5-10 years, hopefully), so long as they are done
in such a way that a community decision to deprecate them and
reclaim them is enforceable. (specific prefixes which can be
filtered without harming native deployments).

Since we've already given each RIR a /12 to start off with and
we still have 506 /12s left in the /3 from which we are
allocating, I think we're OK.

Owen
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101013/1c25cd43/attachment.htm>