<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Just to put it in context,  I will report the motivation of this idea</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">--------------------------------------------------------------------</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">On 08 / Jan / 2020 <a href="http://IX.BR">IX.BR</a> started to change the netmask in São Paulo IX. <a href="http://187.16.216.0/21">187.16.216.0/21</a> -> <a href="http://187.16.208.0/20">187.16.208.0/20</a><br><br>Everything should have gone well...<br>But we had some classmates who hadn't done their homework well and were leaking the IX LAN prefix for their Downstreams and Upstreams as if they were their own networks. (And to make matters worse, there were very large people who were accepting this prefix.)</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><span class="gmail-tlid-translation gmail-translation" lang="en"><br></span></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><span class="gmail-tlid-translation gmail-translation" lang="en">While everyone was on the same netmask, the directly connected network metric was better than the BGP-learned network metric, and that didn't hurt.</span><br>But as some participants who were receiving this / 21 prefix from their UPstreams changed their netmask to / 20, the more specific prefix has won in FIB, and those participants lost connectivity to Lan IX.<br><br>We know that the "modern and beautiful" way to prevent this from happening is that there is a ROA with ASN 0 (or the ASN of IX itself) and this filtering happens through RPKI.<br><br>The <a href="http://IX.BR">IX.BR</a> team reported that this is already being discussed and should be forwarding it soon.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">But I must remember that Registro.BR started supporting RPKI in late 2019, so it is fully acceptable that this definition of ROA is still adjusting there.<br>PS: Congratulations to Registro.BR staff for implementing RPKI almost uneventfully and with EXCELLENT response time and quality for the minimum problems that have arisen.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br>Speaking of the Idea itself<br>---------------------------<br>Getting back to the "Accept or Not IX LAN Prefixes Worldwide" question.<br>- As there are still IXes that do not have the LAN prefix ROAs properly published.<br>- Since there are still many ASNs that do not validate RPKI<br>- Considering thar PeeringDB database is very consistent<br>I thought of creating a (cyclic) mechanism that takes LAN address information from PeeringDB IX informations and creates two prefix lists (v4 and v6).<br>And then use this prefix-list to discard these prefixes when coming from Upstreams.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br>A friend even helped me and set up the query in the PeeringDB API for this.<br><br>The question<br>------------<br>Does it make sense to automate this filtering mechanism?</div><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><font size="2"><span style="font-family:courier new,monospace">Douglas Fernando Fischer</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">Engº de Controle e Automação</span></font><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;word-wrap:break-word;color:black;text-align:left;line-height:130%;font-family:courier new,monospace"></div></div></div>