Routing problems to 2400:CB00::/32 CLOUDFLARE

Bernhard Schmidt berni at
Mon Jun 18 21:49:43 CEST 2012

On 16.06.2012 17:02, Laurent GUERBY wrote:


>> | 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?
> Mostly because we wanted IPv6 to work for our allocation before our
> provider was ready for full IPv6 deployment.

So, you are willing to throw stones for not adhering to the RIPE 
recommendation, but you have an excuse for not doing it yourself? :-)

> We asked RIPE and IPv6 PI cannot be used for ISP purposes (one end user
> only) so the only option other than PA is becoming LIR: both were
> proposed as solutions by RIPE, we went PA.
> For our kind of use (small AS) becoming LIR will waste address space
> since current policy is /22 IPv4 and /32 IPv6 (more an issue
> for IPv4 though).
> As noted in RIPE documents there's always a conflict between waste of
> address space and number of routes announced: in the end if RIPE-532
> "/48" is discarded we'll have to go the waste route.

Please do the math, you can have about 500 Mio /32s in 2000::/3. I think 
it will take a few more decades until we can carry that amount of 
entries in the FIB.

Best Regards,

More information about the ipv6-ops mailing list