CloudFlare IPv6 BGP announcements - WTF guys?

Bernhard Schmidt berni at
Sun Jul 29 15:26:27 CEST 2012

On 26.07.2012 10:19, Emile Aben wrote:

Hello Emile,

>>> If 50% of the networks had filtered more-specifics from the beginning,
>>> we would not be in the situation where people announced
>>> smaller-than-allocated and got through with it. It would just be a known
>>> fact that these would not work (like >/24 in IPv4).
>>> I have the bad feeling it is too late now.
>> Aaaand here is the next one.
>> has IPv6 address 2a03:d680::200
>>> sh bgp ipv6 2a03:d680::/32 long
>> [...]
>> *  2a03:d680::/48   2001:15f8:1::1                         0 25384 3292
>> 3320 20504 i
> Hi,
> I'm hoping that this case study on IPv6 /48 filtering using RIPE Atlas
> sheds some more light on this situation:
> For ~500 IPv6 enabled RIPE Atlas probes, we see in the order of 1% that
> seem to be affected by strict IPv6 route filtering to the destinations
> mentioned in this thread.
> This is probably an order-of-magnitude-type of number.

Thanks, that test is very interesting. However, I feel there is a 
systematic error in it, because it is quite hard to believe that 
/48-PA-without-covering-prefix has even better reachability than a 
normal /32-PA announcement.

I believe these errors are caused by some other (temporary) routing 
issues going on. There are still a few known bad eggs in the transit 
market and your four test destinations have a widely different transit set.

Would it be possible to repeat this test with all prefixes for the tests 
being originated by the same entitity (i.e. RIPE themselves)?


More information about the ipv6-ops mailing list