Re: [v6ops] [GROW] Deaggregation data

[Nick Hilliard <[e-mail]>]

On 17/10/2014 17:58, Randy Bush wrote:
> [ not pickin' on you, nick ]
> 
> trying to find protein in this whole thread.

thin pickings :-(

> in the long run, why will v6 not suffer the <your expletive about
> reasons goes here> same deaggregation which is about half of the v4
> routing table?

It might, but it won't matter as much because the number of baseline ipv6
allocations will be a whole pile lower.  Here's why.

1. retrospectively: the RIR policies of not handing out piecemeal
allocations based on 2Y policy means that most organisations will never
need a second allocation outside their /32.  If you look at existing RIR
allocations, many of them are to the same organisations.  Looking at:

ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt

There are:

	7564 LIRs with ipv4 allocations outside 185/8
	19856 ipv4 allocations outside 185/8

so the average # of allocations per LIR is ~2.62 for pre-last /8 addresses.

Over all allocations, the numbers are 24416 allocations and 10134 LIRs.
I.e. the last /8 policy has dramatically increased the number of LIRs with
a single allocation.  Possibly this is related to lack of PI space.

RIPE has allocated 8069 ipv6 prefixes to 7849 LIRs, i.e. an allocation rate
of 1.02.  This includes last /8 assignments from RIPE's silly policy of
requiring an ipv6 allocation for a last /8 assignment.

This indicates that virtually all LIRs are staying within the bounds of
their original allocations.  This will reduce future pressure on the number
of prefixes in the dfz.

2. in future: there are 10398 LIRs listed in alloclist.  Of these, 7849 or
almost exactly 75% of LIRs already have IPv6 allocations.  So assuming that
all RIPE LIRs will have an ipv6 allocation in future, that's growth from
8069 to ~10700 + one for each new LIR.

3. further deaggregation of the ipv4 dfz will be driven by the market
economics of address holders splitting up their net blocks.

4. down the road, if we can get RIPE to stop its silly policy of requiring
an ipv6 allocation in order to get an ipv4 allocation from the last /8,
this will further reduce pressure on the overall number of allocations,
which leads to:

> maybe if we start filtering now.  but we know how well that went in ipv4
> when their suits called our suits and said "we pay you to let us contact
> <deaggregator>.

The baseline for starting to deaggregate will be much lower for ipv6 and
there will be much less pressure in future to deaggregate.

I haven't looked at the other RIR figures.  No doubt they differ in
numbers, but my hunch is that they tell a similar story.

Nick