[arin-ppml] Controlling the IPv6 address consumption rate

[Tony Hain]

William Herrin wrote:
> ...
> We badly underestimated at the start of IPv4.

You know, it would really be a good idea to understand history before
spouting inaccuracies on the list.

Believe it or not, there were serious concerns about the size of the routing
table way back when. From the perspective of current technology and policy
it might appear that people underestimated, but I challenge you to be honest
about making a different decision when faced with the constraints of that
time period. I was one of the people doing technical reviews for address
requests, and impact on the routing system was often a bigger concern than
then actual number of end systems in hand, let alone growth projections.

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

There is no reasonable way to compare the IPv4 host based consumption
against the IPv6 lan based consumption. At best you could try to correlate
an IPv4 customer unit at /32 with an IPv6 customer unit at /48, but given
that almost every provider explicitly disassociates the number of IPv4 /32's
from the number of customers, that is an impossible task.

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

And exactly where are those very large providers going to find customers to
consume that space? Seriously, equating anything about IPv4 growth rate,
which has a hard tie to end devices, with an IPv6 prefix per customer unit
is a waste of time. 

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

You assume that the end user has a network manager that is trained in
network design. Figure out how to do a plug-n-play model with a sparse
matrix of maybe 16 live subnets, but you can't constrain the topology that a
random end user might build. Then figure out the set of simple rules that
will allow every cpe vendor to ship a self-configuring device that plays in
that sparse matrix without a network manager or a support call. Stop
assuming that every environment has the constraints of an IPv4 enterprise
and/or isp with conservation being top priority. 

Tony