Hi there,
hmm, eine Lösung habe ich nicht - ich wüsste keine Stelle, an der ich das zentral abfragen könnte. Es gibt genügend Listen (beispielsweise die unzähligen bogus-lists, die dementsprechend auch anti-bogus enthalten), aber die sind nicht immer aktuell.
Falls du nanog liest - dort betreiben das einige. Dort kannst du dir auch die Auswirkungen anschauen - es wird in der Regel viel zu viel mitweggefiltert. Netze werden ja auch ab und an zurück. und dann neu vergeben (wobei - heute bei IPv4 eher nicht mehr ;-)). Ich erinnere mich noch an einen recht großen Bereich (IIRC /19) den Telefonica bekommen hat, und der erst wenige Wochen zuvor erst ans ARIN zurück-, dann ans RIPE weitergegeben und dann an AS6805 vergeben wurde. Irgendwo dazwischen landete der Block (oder ein Teil davon - weiss nimmer) auf einer dieser Filterlisten. Das ist dann für die Techies äußerst nervig und vorallem schwer zu debuggen,w eil du das im looking-glass o.ä. ja nicht siehst - du wirst ja announced bzw. announced dich ja, und auch gesehen.
Anderes Beispiel ist CloudFlare. Die announcen 2400:cb00::/32 in ettlichen /48 (so wie auch viele andere ihre Netze in kleinen /22 oder sogar /24 announcen - ja, ist böse, kann aber auch mal Sinn machen). Deshalb blocken viele CloudFlare, um die zu "erziehen". Siehe die Diskussion dazu beispielsweise hier:
http://lists.cluenet.de/pipermail/ipv6-ops/2012-June/007067.html
Meine ganz persönliche Meinung dazu:
Es leidet ja doch im Endeffekt der Kunde. Ja, es bläht die Table auf, wenn man seine Netze so klein announced. Ja, das kleinste Prefix gewinnt, und man kann damit verhindern, dass jemand das Netz highjacked (bei Interesse mal nach Youtube und Pakistan Telecom oder so suchen - die haben mal versehentlich Youtube announced, weil sie es blocken wollten, und haben es ihrem Upstream mit announced, der es dann BGP-weit propagiert hat...). Es gibt aber so viele watch-my-net Angst-Watchdgogscripte, dass du das dann mitbekommen solltest und *dann* reagieren kannst (wobei deine Upstreams ja wohl kaum direkt alles weiterannouncen werden, hoffe ich ;-)).
Will sagen - diese ganzen Kommunikationsverhinderungsmechanismen widersprechen eigentlich dem Urgedanken des Netzes. Wir sind eh dauernd gezwungen aus wirtschaftlichen Überlegungen hinaus zu handeln (was ich auch ausdrücklich wertneutral meine) - aber wir müssen doch nicht ohne Not solche zusätzlcihen Schranken schaffen, die keine Probleme lösen, dafür aber das Potential für Störungen haben.
Es sind doch eh Peerings wie du sagst - mal rein wirtschaftlich betrachtet solltest du doch froh sein, wenn du da so viel Traffic wie möglich loswerden kannst ;-) Und schaden wirds auf keinen Fall, denn du nimmst ja höchstens deinem Upstream Traffic weg, alle direkten Peeringpartner gewinnen doch wahrscheinlich eh.
Zurück zum Problem:
Man kann ja auch nicht nach dem origin alleine gehen - beispielsweise ist Big-T ja deutlich mehr als nur AS3320. Big-T ist eh ein gutes Beispiel - schau dir mal deren whois an, da siehst du genau gar keine Netze.
Du müsstest also jedes Netz gegen die Registry prüfen (und dann hoffen, dass deren whois-server schnell genug upgedatet wurde) man kann da mit hooks arbeiten (also wenn was neues announced wird, prüfe das announcte netz gegen die whoisdaten der Registry), aber ne deterministische if-bedingung zu formulieren dürfte schwierig werden, denn wie gesagt aufs origin alleine kannst du nicht filtern. mnt-by könnte passen, oder last-changed. Ist aber alles ziemlich crude...
Cheers,
Toady
,