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

[Sascha Lenz]

Hi all,

> Hi Mikael.
> 
> Am 7/11/12 7:21 PM, schrieb Mikael Abrahamsson:
>> On Wed, 11 Jul 2012, Chris Welti wrote:
>> 
>>> Since I can not rely on the fact that longer prefix lengths just
>>> happen in certain well defined ranges (minimum allocation per
>>> address range) anymore, I see only three possibilites:
>> 
>> Why can't you rely on that?
>> 
>> https://www.ripe.net/ripe/docs/ripe-555
>> 
>> "The IPv6 PI assignments smaller than a /32 are taken from
>> 2001:678::/29."
>> 
>> So if you don't care about IXP networks in DFZ, then you just allow
>> /32s and larger from all of RIPE space, and /48 and larger from this
>> /29 and you're golden.
>> 
> 
> Two reasons:
> 1) As you say, this only applies to IPv6 PI assignments. But I also care about 
> IXP networks, Root Name servers and Anycast TLDs.
> 

That's the only thing i actually don't understand - why the NCC only mentions the IPv6-PI 
range now, not those other "micro allocation blocks" anymore.
Probably someone from the NCC can enlighten us about this? Or point us to the explanation we missed.

> 2) I'm a bit worried that people will get the impression from RIPE-555 that they can just
> get away with announcing several /48 out of their /32 without the covering /32 itself.
> That would break connectivity to "normal" networks when relying on such filtering in the DFZ.
> 

As we have figured out (again) in this thread, the internet has no routing police, and is a
de-central entity by design.

You can only educate your peers and downstreams, and probably filter them (max-prefix, whois db filtering..).

It is rather considered harmful to filter "everything", the past told us so.
Use default routes if you don't have the right network design to be able to deal 
with temporary de-aggregates in the table, solves the problem, too.

Hence, i don't REALLY see the problem. It's a thing the operators have to deal with themselves design-wise, not anyone else.
It's certainly not a RIR or IETF policy thing or anything like that. 
(yes i know, we're on the ipv6-ops list here, just saying....)

But i do not understand why the NCC dropped the "special ranges" for micro-allocations besides PI.

P.S.: I actually currently do filter /48s and longer from the "non-micro-allocation (PA) blocks" for exactly
      this reason - LIRs should aggregate their PA blocks, and /48s should be PI not PA, and to prevent
      accidentally de-aggregated /48s in my tables. That's why i am interested in an answer to the first 
      question. But i do use default-routes, too. So no problem here anyways. 
  
> Apart from that there is the issue of filtering IPv4 prefixes, which is a lot worse now.


That's just how IPv4 works now. Gert explained it in detail. It's just logical that there will
be smaller and smaller IPv4 allocations/assignments post run-out. Nothing anyone can do about it.

I doubt anyone will lower their filters past (v4)-/24s. (v4-)/29 were always there for "internal PI assignments" ...
but apart from filtering /25 and longer (+the well-known martians), that's about it in the IPv4 endgame (or again,
use additional default-routes).

And sorry for grammar, spelling and probably logical mistakes - i typed this one while attending a very annoying 
"WebEx meeting".

-- 
Mit freundlichen Grüßen / Kind Regards

Sascha Lenz [SLZ-RIPE]
Senior System- & Network Architect