Routing problems to 2400:CB00::/32 CLOUDFLARE

Bernhard Schmidt berni at
Sat Jun 16 16:13:50 CEST 2012

On 16.06.2012 16:09, Laurent GUERBY wrote:


>>> Our experience operating a /40 PA from RIPE is that a very low number of
>>> AS filter at /32 on RIPE PA space and thus do not follow RIPE-532: based
>>> on our users feedback we found only 3, one of which has announced it
>>> will try to follow RIPE-532 in the future.
>> You might just not see the problem, because (as opposed to the
>> Cloudflare case) your /32 aggregate IS announced. Traffic will go out of
>> filtering ISPs and either hit the /40 more-specific somewhere or go on
>> down the /32 route.
> Hi,
> Yes the /32 is currently announced: our experience with AS not
> respecting RIPE recommandations forced us to do so.
>> csr1-0q1#sh bgp ipv6 2a01:6600::/32 long
>> [...]
>>      Network          Next Hop            Metric LocPrf Weight Path
>> *>i2A01:6600::/32   2001:4CA0::5             0    100      0 680 3356
>> 174 39405 i
>> * i                 2001:4CA0::5             0    100      0 680 3356
>> 174 39405 i
>> % NOTE: This command is deprecated. Please use 'show bgp ipv6 unicast'
>> Yes, my network does not accept /40s from PA.
> Out of curiosity what made you decide not to follow issuing RIR
> recommandation in this matter?


| Recommendation
| It is suggested that prefix filters allow for prudent subdivision of
| an IPv6 allocation. The operator community will ultimately decide
| what degree of subdivision is supportable, but the majority of ISPs
| accept prefixes up to a length of /48 within PA space.

That does not sound to me like a recommendation for /48, more like 
status quo. Prudent subdivision is /36 for me (especially in light of 
2011-04), and I'm accepting that deaggregation.

| Advertisement of more specific prefixes should not be used unless
| absolutely necessary and, where sensible, a covering aggregate should
| also be advertised. Further, LIRs should use BGP methods such as
| NO_EXPORT [RFC-1997] and NOPEER [RFC-3765] or provider-specific
| communities, as described in RIPE-399 to limit the propagation of
| more specific prefixes in the routing table.

What makes YOU want to ignore this way more specific recommendation in 
the very same document?


More information about the ipv6-ops mailing list