RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?

[Chris Welti]

Hi Gert,

Am 7/12/12 10:23 AM, schrieb Gert Doering:
> Hi,
> 
> On Thu, Jul 12, 2012 at 10:05:44AM +0200, Chris Welti wrote:
>> Apart from that there is the issue of filtering IPv4 prefixes, which 
>> is a lot worse now.
> 
> I don't know any background about this document change - but regarding
> IPv4 prefix filtering, this is just what we'll have to live with.  IPv4
> is running out, and as soon as the wall has been hit, the RIPE NCC will
> not be able to maintain minimum allocation/assignment sizes - how do
> you justify telling people "well, there still is space in 62.0.0.0/8,
> but we are not giving you your /22, because the minimum allocation size
> is /21, and there is no policy that we can ever give you a /21 under"?

I don't have a problem with RIPE allocating/assigning up to a /29 after all the
available ipv4 address space has been used, but it would help if at that point
they documented out of which address blocks these smaller allocations/assignments
are coming. That way, one can still filter the way we used to for "old" address
ranges and add exceptions for the few new ones that are left.
What I want to prevent is accepting unnecessary longer prefixes that are
leaked either accidently or on purpose. Another case is where people would
just illegaly "sell off/rent" unused parts of their PA space and could now do so
up to /29s because those would still be globally routable (as there is no efficient
way to filter out just the "invalid" /29...)

By removing the statement "Network operators taking routing decisions based on prefix
length are requested and encouraged to route at least blocks of sizes corresponding
to the longest prefix and larger." in RIPE-555, RIPE basically says that operators
should now use other means to decide which prefix lengths are acceptable to route.
I just don't see easily how we should do that.

> If you do not want to carry everything there is, you could just put
> up an arbitrary limit of your own choosing, and add a default route
> to your upstreams.  (Which is what we do for prefixes coming from
> other regions, as it doesn't make a huge difference for us where we
> send traffic for a random american /24 to - all our upstreams will
> do a reasonable job in delivering the packets.  If they don't, we find
> new upstreams that do)

Yeah, but that strategy doesn't help the routing table size in the DFZ.
You're just moving the problem up one tier (your upstreams).
Someone will have to carry all those prefixes.
As long as only the "valid" assignments/allocations end up in the DFZ that isn't
a problem, but if people begin to de-aggregate their larger allocations for
traffic engineering or just because they are too lazy to only announce aggregates,
that leads to a really unnecessairy and uncontrollable bloating of the global
routing table (DFZ).

Anyway, as this is an IPv6 list, we should probably stop the discussion about the
IPv4 prefixes, as it is off topic. Allthough a few arguments apply to IPv6 as well :)

Regards,
Chris