Please check your filters - reloaded

[Bernhard Schmidt]

Hi everyone again,

since I've apparently caused some sort of confusion I'd like to clarify
some things about my last mail.

There are two seperate issues with global prefix visibility at the
moment:

1.) 2400:2000::/20 SoftbankBB
    This prefix is sourced by SoftbankBB and distributed through several
    ASPAC networks including IIJ and AS4725.
    All large networks (that feed GRH or have downstreams that feed GRH)
    do see this prefix, so if you don't receive it from your upstreams
    and/or cannot trace there there is definitely something wrong with
    your or their filters.

    With my Sherlock Holmes genes and some trial and error I found out
    that 2400:2000::1 answers to echo requests (pings), so as long as
    Softbank doesn't shutdown this host due to a severe ping DDoS in the
    next days you can easily test your connectivity there. If you can't
    reach the network, check your filters and kick your upstream.

    http://www.sixxs.net/tools/grh/compare/?a=2400:2000::/20&b=2001:240::/32

    ASNs at the beginning of a red line should look at their
    configuration.


2.) 2003::/19  DE-DTAG
    If my interpretation of the table is correct this prefix isn't
    supposed to be visible worldwide at the moment, since the only
    connection up and running is a _peering_ to C&W. Thus C&W only
    exports this prefix to their downstreams. The ugly traceroutes
    posted by Daniel and James are the results of some leaks by networks
    not having a proper concept of upstream/downstream/peering, leaking
    learned prefixes all over the place. 

    Second, I do not know any host inside 2003::/19 that should answer
    to echo requests. Their router does send unreachables, but if we
    assume that only the peering to 1273 is up and running 3320 won't
    have a route back to networks not being C&W customers, thus you
    won't see any unreachables.

    So why did I include this prefix at all? Because there are similar
    issues as with Softbank. Check out

    http://www.sixxs.net/tools/grh/compare/?a=2003::/19&b=2001:7a0::/32

    which looks kind of broken at the moment. Now select another date at
    the top (e.g. Oct 10th) and suddenly you see that most large
    networks got the prefix, but still 22% of the GRH feeders don't. So
    this seems to be a filtering issue again.

    AGAIN: There is no host in 2003::/19 supposed to answer to echo
    requests, and _currently_ most of you should not be able to see that
    prefix at all. If it's broken for you, have a look at your filters 
    and if they look okay, wait.

Short story:
 * Please keep your filters up to date. Remember that there have beeen
   allocations outside of 2001::/16 (and 6bone) for quite a while now,
   and there are more to come.
 * If you cannot keep up with current developments in the IPv6 world or
   if you're leaving your company and your successor has no clue about
   IPv6-routing, please consider using a liberal filtering aproach, e.g. 
   allowing everything in 2000::/3 up to /32 (plus todays well-known
   micro-allocations/IXes) or even 2000::/3 up to /48. I hate proposing
   that, but it's better than outdated filters.
 * If you run your own ASN with IPv6 consider giving GRH
   (http://grh.sixxs.net) a feed to help debugging similar issues.

Regards,
Bernhard

PS: Anyone having a contact at AS29657? The ipv6-noc@ listed in the
    object is unresponsive, the personal ones bounce. They're currently
    announcing foreign prefixes (another thing GRH is nice to track
    down):

grh.sixxs.net> sh bgp ipv6 regexp _29657_
BGP table version is 0, local router ID is 213.197.29.32
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  2001:228::/35    2001:7f8:1::a500:9264:1
                                                           0 9264 29657 29657 29657 29657 ?
*  2001:230::/35    2001:7f8:1::a500:9264:1
                                                           0 9264 29657 29657 29657 29657 ?
[about 30 more]

    Currently those bogus routes are only visible by ASNET, but god knows 
    where it leaks next.