Routing problems to 2400:CB00::/32 CLOUDFLARE

Michael Sinatra michael at
Sat Jun 16 00:23:40 CEST 2012

On 06/15/12 14:59, Mick O'Rourke wrote:
> +1 Tom.
> Its going to be the same number of routes in the table whatever way you
> go. In the case at least anyway.
> It's a valid use case a SP-content provider to want to use a single /32
> block for independent DC allocations. A use case for growth beyond a /48
> per site also exists. IMHO if the strict filters are correct APNIC et al
> got it wrong and have missed a valid use case, this should have been
> catered for.
> The above said why not relax filters to use /48? - will you wait for
> your customers to complain or leave your network as they can't reach
> content before you do? What's the projection on where this will be in 7
> years based on current de agg growth for v6?

Because if you allow /32 holders to de-aggregate to /48s then you end up 
allowing any (and potentially every) /32 holder to "accidentally" dump 
65,536 routes into your table.  In other words, it's not the same as 
having a limited set of /48s out of the PI space.

Otherwise, you have to have scripts that dig up registered routes, 
compare them with received routes, and flag any unreasonable anomalies 
before pushing out new filters.  IMO, operators need to do this anyway, 
but asking operators to accept all of your potential /48s when you're 
only announcing a handful, with the only other alternative to be "point 
default at your provider" will ultimately leave you unreachable to 
chunks of the Internet.  It's a simple consequence, regardless of the 
philosophical position of me or anyone else on this list.

(Note that I am not unequivocally opposed to careful de-aggregation; I 
just think originators MUST announce the proper covering prefix to 
prevent *them* from becoming unreachable.  OTOH, I recognize the 
reluctance of Bjoern and others to open the potential floodgates with 
loose policies.  Just because Cloudflare is being careful in only 
announcing a handful of /48s doesn't mean someone else isn't going to 
come in and announce 64K /48s.)

> Those who run strict v6 filters do you have similar filters for v4?

Remember: IPv6 is so many orders of magnitude bigger than IPv4 that you 
can't treat them the same way.  In IPv4, the RIRs make no 
differentiation between PA LIR allocation space and PI end-site 
assignment space, whereas they do in IPv6.  This was specifically done 
to allow strict filtering.


More information about the ipv6-ops mailing list