Re: IPv6 Routing table will be bloated?

[JORDI PALET MARTINEZ <jordi.palet () consulintel es>]

Totally agree.

In IPv6, polices are in some RIRs and MUST be in all them, balancing
conservation and aggregation, but in case of conflict aggregation is the top
priority.

I can read it at the NRPM:

6.3.8. Conflict of goals
The goals described above will often conflict with each other, or with the
needs of individual IRs or end users. All IRs evaluating requests for
allocations and assignments must make judgments, seeking to balance the
needs of the applicant with the needs of the Internet community as a whole.

In IPv6 address policy, the goal of aggregation is considered to be the most
important.


Regards,
Jordi




> From: Tony Hain <alh-ietf () tndh net>
> Reply-To: <alh-ietf () tndh net>
> Date: Tue, 26 Oct 2010 09:02:00 -0700
> To: 'Jack Bates' <jbates () brightok net>, <nanog () nanog org>
> Subject: RE: IPv6 Routing table will be bloated?
>
> You didn't miss anything, past ARIN practice has been broken, though using
> sparse allocation it is not quite as bad as you project. In any case, ISP's
> with more than 10k customers should NEVER get a /32, yet that is what ARIN
> insisted on giving even the largest providers in the region. Every ISP
> should go back to ARIN, turn in the lame /32 nonsense they were given (that
> allocation size is for a startup ISP with 0 customers), follow that with an
> 'initial allocation' request that is based on your pop structure with a /48
> per customer including projected growth. I don't care what you actually
> allocate to your customers at this point, just get a large enough block to
> begin with that you could give everyone a /48 the way policy allows. There
> is absolutely no reason to have to grovel at ARIN's feet every few months as
> you grow your IPv6 deployment. Get a 'real block' up front.
>
> Tony
>
>
> > -----Original Message-----
> > From: Jack Bates [mailto:jbates () brightok net]
> > Sent: Tuesday, October 26, 2010 6:58 AM
> > To: nanog () nanog org
> > Subject: IPv6 Routing table will be bloated?
> >
> > 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



**********************************************
The IPv6 Portal: http://www.ipv6tf.org

This electronic message contains information which may be privileged or confidential. The information is intended to be 
for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, 
copying, distribution or use of the contents of this information, including attached files, is prohibited.