filtering /48 is going to be necessary

Sun Mar 11 15:48:15 UTC 2012

On 9 Mar 2012, at 10:02 , Jeff Wheeler wrote:

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

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

The IETF and IRTF have looked at the routing scalability issue for a long time. The IETF came up with shim6, which allows multihoming without BGP. Unfortunately, ARIN started to allow IPv6 PI just in time so nobody bothered to adopt shim6. I haven't followed the IRTF RRG results for a while, but at some point LISP came out of this, where we basically tunnel the entire internet so the core routers don't have to see the real routing table.

But back to the topic at hand: filtering long prefixes. There are two reasons you want to do this:

1. Attackers could flood BGP with bogus prefixes to make tables overflow

2. Legitimate prefixes may be deaggregated so tables overflow

It won't be quick or easy, but the RPKI stuff should solve 1.

So that leaves the issue of deaggregating legitimate prefixes. There are around 100k prefixes given out by the RIRs and nearly 400k in the routing tables. A quick look at the IPv4 BGP table shows that unless I missed the day in school when they covered "reasons to advertise 64 /22s instead of a /16" a good percentage of those deaggregates happen without any legitimate reason.

Although the RIRs don't make this as easy as they could, it IS possible to determine the maximum prefix length for any given block of RIR space, and then simply filter on that prefix length. That takes care of the /48s and /32 deaggregating, but unfortunately not the /44s out of space used for /48s or the /20s out of space used for /32s. So the RIRs should up their game here, then we can really hold LIR's feet to the fire and stop them from deaggregating.

That does of course leave people who do have a good reason to deaggreagate in the cold. But that's also easy to solve: if you run two separate networks, you need two prefixes and two AS numbers. So the RIRs should develop policies that allow for this if it's reasonable. If that means that an organization can't have both a bunch of independently announced prefixes AND have all those prefixes be part of one aggregate for easy firewall configuration, that's too bad.

The RIRs should pick up on this, because there WILL be a moment an ISP deaggregates a /32 into 65000 /48s with the result that half the IPv6 internet goes down.