IPv6 Routing table will be bloated?
jbates at brightok.net
Tue Oct 26 12:19:30 CDT 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
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
> 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).
More information about the NANOG