IPv6 Routing table will be bloated?

Tue Oct 26 17:19:30 UTC 2010

On 10/26/2010 12:04 PM, Nick Hilliard wrote:
> In practice, the RIRs are implementing sparse allocation which makes it
> possible to aggregate subsequent allocations. I.e. not as bad as it may
> seem.
>

Except, if you are given bare minimums, and you are assigning out to 
subtending ISPs bare minimums, those subtending ISPs will end up with 
multiple networks. Some of them are BGP speakers. I can't use sparse 
allocation because I was given minimum space and not the HD-Ratio 
threshold space.

> ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if
> you get an initial allocation of /32, then find you need more, your
> subsequent allocations will be taken from the same /29, allowing
> aggregation up to /29.
>

My minimum /30 allocation per ARIN met a /27 in HD-Ratio thresholds. To 
not be given the threshold space means no reservations for subtending 
ISPs, no room for subtending ISPs to grow, and multiple assignments. If 
ARIN only does /29 boundaries, I'll also be getting multiple /29's, and 
not just working within a /27 per the HD-Ratio guidelines.

It's the mixed viewpoint that is the problem. HD-Ratio is useless as a 
justification and as a metric which promotes route 
conservation/aggregation if it is not used for initial allocations. 
Initial allocations (including those handed out to subtending ISPs) 
should all be as large as the immediate use HD Ratio permits. ie, If you 
are immediately assigning X /56 blocks, your assignment should have a 
length one less than the highest threshold you crossed. To assign any 
less is to constrain the assignments, not allow for growth, and to 
increase routing table size. It also circumvents and completely destroys 
the concept of HD Ratio (as the initial assignments all are well in 
excess of the thresholds for requesting much larger blocks).

Jack