Routing problems to www.eurovision.tv 2400:CB00::/32 CLOUDFLARE

[Mick O'Rourke]

Very valid and good point on the accidental leak side - it happens all the
time. While v4 specific Dodo and Telstra are a good recent example of
operator error and also doubly a good example of what can happen when you
don't apply filters.

The registration of routes and the script suggestion a good middle ground
to this. Do you have a script you can share with people here?


>
> 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.
>
> michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20120616/99e44959/attachment.html