filtering /48 is going to be necessary

Owen DeLong owen at delong.com
Fri Mar 9 19:27:38 UTC 2012


On Mar 9, 2012, at 1:02 AM, Jeff Wheeler wrote:

> On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin <mehmet at akcin.net> wrote:
>> if you know anyone who is filtering /48 , you can start telling them to STOP doing so as a good citizen of internet6.
> 
> I had a bit of off-list discussion about this topic, and I was not
> going to bring it up today on-list, but since the other point of view
> is already there, I may as well.
> 
> Unless you are going to pay the bill for my clients to upgrade their
> 3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need
> to do two things before IPv6 up-take is really broad:
> 
> 1) absolutely must drop /48 de-aggregates from ISP blocks
> 2) absolutely must make RIR policy so orgs can get /48s for
> anycasting, and whatever other purposes
> 

Item 1 will be interesting.
Item 2 is already done in ARIN and I think RIPE and APNIC.
I'm not sure about AfriNIC or LACNIC.

> If we fail to adjust RIR policy to account for the huge amount of
> accidental de-aggregation that can (and will) happen with IPv6, we
> will eventually have to do #1 anyway, but a bunch of networks will
> have to renumber in order take advantage of #2 down the road.
> 

Can you point to specific RIR policies that you believe need adjustment?
I'm willing to help (and somewhat adept at doing so), but I'm not seeing
the problem you are reporting, so, I need more data.

> The way we are headed right now, it is likely that the IPv6 address
> space being issued today will look like "the swamp" in a few short
> years, and we will regret repeating this obvious mistake.
> 

I don't think so, actually. First, I don't think the swamp was a mistake so much
as a temporary problem with resource limitation on routers.

The problem in today's routing table is NOT the "swamp". (Where swamp is
defined as the large number of /24s issued to organizations in a non-
aggregable manner often as direct assignments from the InterNIC before
CIDR and provider-assigned addressing existed).

The total scope of the swamp is limited to about 65,000 prefixes.

All of the growth beyond about 65,000 prefixes is, instead, attributable to
a number of other factors, not the least of which are disaggregation for
convenience (which could be  an issue in IPv6), disaggregation due to
ignorance (which will likely be an issue in IPv6), de-aggregation due
to differences in routing policy and/or for traffic management strategies
(which will also happen in IPv6), general growth of the internet (which
will also happen in IPv6, but, at a lower prefix-growth rate), and finally,
one of the biggest causes... slow start, growth constrained RIR policies
handing out incremental (often 1 year worth or less) growth in address
blocks due to scarcity (which should not be a problem in IPv6).

In the ARIN region I think we have pretty well prevented this last issue
with current policy. I tried to propose similar policy in the APNIC region,
but it was not well accepted there. The folks in Asia seem t want to cling
to their scarcity mentality in IPv6 for the time being. I believe RIPE is
issuing reasonably generous IPv6 allocations/assignments. I don't
know enough about the goings on in AfriNIC or LACNIC to comment
with any certainty.

> We had this discussion on the list exactly a year ago.  At that time,
> the average IPv6 origin ASN was announcing 1.43 routes.  That figure
> today is 1.57 routes per origin ASN.

That represents a 10% growth in prefix/asn for IPv6.

Compare to 9.3->9.96/ASN (7%) in IPv4 over that same time, While
I would agree that this is a trend that merits watching, I think
we're probably OK for quite some time. The higher growth rate in
IPv6 can be largely attributed to the fact that IPv6 is still in its
infancy and we probably haven't seen much IPv6 traffic engineering
route manipulation yet. I don't think IPv6 is at all likely even with
current policies and trends to reach 9:1. I expect it will most likely
settle in somewhere around 2.5:1.

Owen





More information about the NANOG mailing list