IPv6 Routing table will be bloated?

Tue Oct 26 13:57:41 UTC 2010

So, the best that I can tell (still not through debating with RIR), the 
IPv6 routing table will see lots of bloat. Here's my reasoning so far:

1) RIR (ARIN in this case, don't know other RIR interpretations) only 
does initial assignments to barely cover the minimum. If you need more 
due to routing, you'll need to provide every pop, counts per pop, etc, 
to show how v6 will require more than just the minimums (full routing 
plan and customer counts to justify routing plan). HD-Ratio has NO 
bearing on initial allocation, and while policy dictates that it doesn't 
matter how an ISP assigns to customer so long as HD-Ratio is met, that 
is not the case when providing justification for the initial allocation.

2) Subsequent requests only double in size according to policy (so just 
keep going back over and over since HD is met immediately due to the 
minimalist initial assignment?)

So I conclude that since I get a bare minimum, I can only assign a bare 
minimum. Since everything is quickly maxed out, I must request more (but 
only double), which in turn I can assign, but my customer assignments 
(Telcos/ISPs in this case) will be non-contiguous due to the limited 
available space I have to hand out. This will lead to IGP bloat, and in 
cases of multi-homed customers whom I provide address space for, BGP bloat.

I'm small, so my bloat factor is small, but I can quickly see this 
developing exactly as my v4 network did (if it was years ago when I 
first got my v4 allocation, growing to today, for each allocation I got 
for v4, I'd expect similar out of v6). Sure, the end user gets loads of 
space with those nice /48's, but the space within ISPs and their ISP 
customers is force limited by initial allocations which will create 
fragmentation of address space. This is brought about due to the dual 
standard of initial vs subsequent allocations (just enough to cover 
existing vs HD Ratio).

As an example, Using HD-Ratios as an initial assignment metric can 
warrant a /27, whereas the minimalist approach may only warrant a 
heavily utilized /30. 3 bits doesn't seem like much, but it's a huge 
difference in growth room. Bare minimums, as provided by me, only 
included the /24 IPv4 DHCP pools converted with a raw conversion as /32 
IPv4 = /48 IPv6 network

Am I missing something, or is this minimalist approach going to cause 
issues in BGP the same as v4 did?

Jack