IPv6 Routing table will be bloated?

Mailman List Mirror (Read Only)
1

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

2

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.

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.

3

[..]

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

You are missing the point of making a proper plan which can justify
address space for your business for the next years.

If done properly, you have successfully justified it and you will never
ever have to go back to any of the five years.

Now what will cause routing bloat is folks who keep on doing the same
methods of "load balancing" and "chunking out of PA" and announcing that
in BGP.

Oh and then there are of course the various organizations who do not
know/understand what RPSL is and who do not understand what filtering
and aggregation means...

Greets,
Jeroen

4

You are missing the point of making a proper plan which can justify
address space for your business for the next years.

According to ARIN, initial allocations due NOT allot for growth, only for the existing infrastructure.

If done properly, you have successfully justified it and you will never
ever have to go back to any of the five years.

I'd have to lie about existing counts to plan for 5 years. I don't like lying.

Now what will cause routing bloat is folks who keep on doing the same
methods of "load balancing" and "chunking out of PA" and announcing that
in BGP.

I have customers who use my space and multihome. There is no reason or requirement for them to go to ARIN for this space. They can easily use my own. Ideally they would have (and I would have) large enough space for a single aggregate leaving their network, but with a minimal approach (vs HD-Ratio aligned assignment up front), that won't be possible.

Jack

5

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

Still waiting on ARIN to get back to my argument that I am allowed to assign /32s to my subtending ISPs who are of X size or are multihomed.

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

If the initial allocation from ARIN is only for current infrastructure and customers (the bare minimum), there is no room for reservation, nor will customers have room to grow in the initial allocation. This is the problem with minimal on initial instead of HD-Ratio (which is what the rest of the policy is based on), but it could lead to fragmented networks.

Jack

6

* Jack Bates:

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).

If you get better routing and reachability from not filtering at the
/32 boundary, network operators will stop filtering at the /32
boundary. So this issue will likely go away pretty soon because you
can use our initial assignment to gain the routing flexibility you
need.

7

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

8

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

9

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

He's talking about the bloat that comes from ISPs getting slow-started and then
only being able to increase their network in increments of 2x each time, so,
effectively ISP gets:

1 x /32 Initial
Fills that up, gets
1 x /32 First subsequent
Then
1 x /31
then
1 x /30
etc.

Probably not quite as bad as IPv4, but, potentially close.

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

Consider the scenario where you're dealing with an ISP that provides
services to other ISPs as his downstream customers and the above
statement doesn't hold true like you think it should.

Owen

10

dusty old routers with ram problems...

solution there: re-think the way you do your routing and compare the price of ram versus cpu cycles. (as well as having custom hardware developed to do it on, intel simply does not offer enough address bus lines to maintain bigass tables and address them linearily so you can keep entries for each ip or mac address out there and counters with them to automatically "migitate" ddos attacks and give every communications partner their own fair share on the outgoing interface's capacity).

(and no, we're not talking linux/bsd here... just dedicated routing firmware on let's say ibm's power-6/power-7 platform)

instead of buying the same old shit from juniper/cisco/foundry again which doesn't even have enough ram to announce /30's ipv4 (if everyone would do so ;), let alone properly prevent ddos attacks from even being possible

11

He's talking about the bloat that comes from ISPs getting slow-started and then
only being able to increase their network in increments of 2x each time, so,
effectively ISP gets:

[...]

Probably not quite as bad as IPv4, but, potentially close.

In theory, yes, it's bad.

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.

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.

APNIC seem to be delegating on /22 boundaries, and LACNIC on /28.

Nick

12

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

13

If the policy is broken, then submit a policy proposal to fix it.

Nick

14

I think ARIN is now doing sparse allocations on /28 boundaries.

My personal opinion is that it should be even more sparse, and that allocations should be done on nibble boundaries. Any reasonably-sized ISP should get at least a /28.

I deal with many small-ish ISPs, and most are 5,000-10,000 users. Those are probably served by a /32 for quite some time. When you get into the ones that are 20,000-50,000, it gets tricker to deal with. Those should get a /28. The mega-ISPs should get a /24, or even a /20.

Another problem is that the allocations from IANA to the RIRs are too small to begin with. If there are 5 RIRs, why does there have to be so much fragmentation? It is too late for that, though.

Anyway, I think there are some proposals floating around (Owen? :wink: ) That would make the /32,/28,/24 (nibble boundary) idea into policy. We'll have to wait and see what happens.

-Randy

15

Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP?

-Randy

16

to my knowledge, RIPE still does not issue ipv6 PI space.
so giving them their own space, is "problematic" to say the least.

17

Because they are my customer. They don't know much about RIRs, paying membership fees, etc. They just know they want address space, and I provide that.

1) Policy doesn't state that only a RIR can hand address space to an ISP

2) You don't have to be multihomed to be considered an ISP or qualify for space from RIR (you just have to be larger if you aren't multihomed)

3) It has been this way for many years in IPv4, with all of my customers being ISPs from small to medium size and several of them even having their own subtending ISPs (some of which are even larger than my customer ISP in consumer customer counts).

Jack

18

I got a /48 PI from RIPE a few months back.
Maybe your knowledge needs to be a little bit refreshed regarding RIPE
allocation policies :slight_smile:

19

Magically, indeed, an ipv6 pi request form showed up in the lirportal.
amazing!

20

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.

Wait... If you are issuing space to ISPs that are multihomed, they should
be getting their own addresses. Even if they aren't multihomed, they should
probably be getting their own addresses. Why would you be supplying them
with address space if they are an ISP?

-Randy

to my knowledge, RIPE still does not issue ipv6 PI space.
so giving them their own space, is "problematic" to say the least.

ISP's get an LIR assignemnt from RIPE, no?
<http://www.ripe.net/ripe/docs/ripe-481.html#lir&gt;
Customers could get an end-user assignment (PA space normally or PI)
<http://www.ripe.net/ripe/docs/ripe-481.html#_8._IPv6_Provider&gt;
   (ripe PI assignment policies)

-chris