[140559] in North American Network Operators' Group
Re: IPv6 foot-dragging
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Fri May 13 13:14:16 2011
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <BANLkTimcYfE3z+A02nm7945BQy7==f5mjw@mail.gmail.com>
Date: Fri, 13 May 2011 19:12:43 +0200
To: Matthew Petach <mpetach@netflight.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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.
