<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 13, 2021 at 10:53 PM Amir Herzberg <<a href="mailto:amir.lists@gmail.com">amir.lists@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div></div></div></div></div><div class="gmail_quote"><div>I think it isn't the same.</div></div></div></blockquote><div><br></div><div>I am still not sure but maybe I misunderstood what you originally said. It is probably not important.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I think that the NANOG (or in general, operators) community may do well to state the `/24 rule' clearly in a BCP, preferably an RFC. A mismatch in the most-specific rule can definitely allow different problems (and attacks). As mentioned above, RIPE has essentially done this (although could be more explicit). I've seen a similar /48 rule for IPv6, btw. </div></div></div></blockquote><div><br></div><div>I am not sure how big a problem this is. We only had this one case that I described and it was easily fixed by allowing that one prefix from our transit. The peer also offered to fix their announcement. But we did not run with it for very long because we only reduced our routing table to debug a different problem.</div><div><br></div><div>Maybe we could have a community or other mechanism to mark the few routes that can not be dropped in exchange for a default route.</div><div><br></div><div>For all the stub networks out there we should be able to aggressively filter routes without much harm. </div><div><br></div><div>Regards,</div><div><br></div><div>Baldur</div><div><br></div><div><br></div></div></div>