Re: IPv6 Routing table will be bloated?

[TJ <trejrco () gmail com>]

Quick comment:
IGP bloat != BGP bloat.  Your customers cannot announce the space you gave
them externally - unless ~/32s, i.e.  forced aggregation.

Also, your customers shouldn't need to come back for more very often and
ideally you have some reservations for them a well :).

/TJ
PS - apologies for top posting.
On Oct 26, 2010 9:59 AM, "Jack Bates" <jbates () brightok net> wrote:
> 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