Routing problems to www.eurovision.tv 2400:CB00::/32 CLOUDFLARE
michael at rancid.berkeley.edu
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