IPv6 foot-dragging

Iljitsch van Beijnum iljitsch at muada.com
Fri May 13 17:12:43 UTC 2011

On 13 mei 2011, at 18:42, Matthew Petach wrote:

>> The current RIR practice to reserve a /44 when a /44 is given out is a very bad one. It assures unfilterability, because now you have random sizes from /44 to /48 in the parts of the address space used for PI. And if say, 64k /48s are given out the space actually holds 1M /48s so if someone wants to blow up the IPv6 internet they can just start announcing a million /48s and our filters are powerless.

> If they announce a million /48s, they're actively hijacking space from
> 64,000 other people,
> and should be dealt with in an appropriate manner as a hijacker.  :/

It would be mostly unused space. But that doesn't matter much, the point is that your prefix length filters can't stop this.

If, on the other hand, the RIRs only give out /48s from one limited set of address space swaths and /44s from another, /32s from yet another and so on, then if there are 64k /48s that comes from say two /32s and three /33s for a total deaggregation risk of 224k prefixes. This is something your router may be able to handle.

> The *only* thing that will prevent that, in real-time are
> techniques like PGBGP or so-BGP.  Not RIR policies.

See above.

All this BGP security stuff is still vaporware as of today. Hopefully that will change in the future but I'm not holding my breath for the benefits to kick in.

> (as a side note--in order to have your "million /48s"
> table explosion happen through *legitimate* holders
> of space deaggregating, it would require 64K individual
> choices to deaggregate in order to have that happen;
> we don't even have that many ASNs out there yet.  I'm
> not losing sleep over that at this point.)

If you boil it slowly enough the frog will sleep just fine.

I participated in the IETF multi6/shim6 and IRTF RRG efforts for years but I have since come to the conclusion that routing table growth is not a real problem, because if it were people would be more willing to accept the downsides that come with the proposed solutions.

More information about the NANOG mailing list