> > 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. >
https://datatracker.ietf.org/doc/html/rfc7454 6.1.3 <https://datatracker.ietf.org/doc/html/rfc7454#section-6.1.3>. > Prefixes That Are Too Specific > Most ISPs will not accept advertisements beyond a certain level of > specificity (and in return, they do not announce prefixes they > consider to be too specific). That acceptable specificity is decided > for each peering between the two BGP peers. Some ISP communities > have tried to document acceptable specificity. This document does > not make any judgement on what the best approach is, it just notes > that there are existing practices on the Internet and recommends that > the reader refer to them. As an example, the RIPE community has > documented that, at the time of writing of this document, IPv4 > prefixes longer than /24 and IPv6 prefixes longer than /48 are > generally neither announced nor accepted in the Internet [20 > <https://datatracker.ietf.org/doc/html/rfc7454#ref-20>] [21 > <https://datatracker.ietf.org/doc/html/rfc7454#ref-21>]. > These values may change in the future. On Fri, Aug 13, 2021 at 4:54 PM Amir Herzberg <amir.li...@gmail.com> wrote: > On Fri, Aug 13, 2021 at 12:50 PM Baldur Norddahl < > baldur.nordd...@gmail.com> wrote: > >> >> On Fri, Aug 13, 2021 at 3:54 AM Amir Herzberg <amir.li...@gmail.com> >> wrote: >> >>> On Thu, Aug 12, 2021 at 4:32 PM Baldur Norddahl < >>> baldur.nordd...@gmail.com> wrote: >>> >>>> >>>> >>>> On Thu, Aug 12, 2021 at 7:39 PM Amir Herzberg <amir.li...@gmail.com> >>>> wrote: >>>> >>>>> Bill, I beg to respectfully differ, knowing that I'm just a researcher >>>>> and working `for real' like you guys, so pls take no offence. >>>>> >>>>> I don't think A would be right to filter these packets to 10.0.1.0/24; >>>>> A has announced 10.0.0.0/16 so should route to that (entire) prefix, >>>>> or A is misleading its peers. >>>>> >>>> >>>> You are right that it is wrong but it happens. Some years back I tried >>>> a setup where we wanted to reduce the size of the routing table. We dropped >>>> everything but routes received from peers and added a default to one of our >>>> IP transit providers. This should have been ok because either we had a >>>> route to a peer or the packet would go to someone who had the full routing >>>> table, yes? >>>> >>> >>> Baldur, thanks, but, sorry, this isn't the same, or I miss something. >>> >> >> I think it is exactly the same? Our peer is advertising a prefix for >> which they will not route all addresses covered. Is that route not then a >> lie? Should they not have exploded the prefix so they could avoid covering >> the part of the prefix they will not accept traffic to? (ps: not arguing >> they should!) >> > > I think it isn't the same. This scenario, of an AS selling part of its IP > block, e.g., 10.0.1.0/24, and continuing to announce the block, e.g., > 10.0.0.0/16, is the classical example used (e.g. by me) to explain the > `most specific' rule. Due to `most specific', it is considered, imho, legit > to continue to announce 10.0.0.0/16; if 10.0.1.0/24 is reachable, traffic > will route to it anyway due to `more specific', so no problem; and if > 10.0.1.0/24 isn't reachable, then anyway no harm done... > > By dropping a legit 10.0.1.0/24 announcement, you may - and in the cited > example, did - break connectivity, imho. And quite unnecessarily, too. > >> >> >>> If I get you right, you dropped all announcements from _providers_ >>> except making one provider your default gateway (essentially, 0.0.0.0/0). >>> But this is very different from what I understood from what Bill wrote. >>> Your change could (and, from what you say next, did) cause a problem if one >>> of these announcements you dropped from providers was a legit subprefix of >>> a prefix announced by one of your peers, causing you to route to the peer >>> traffic whose destination is in the subprefix. >>> >> >> Your understanding is correct. But this is just the way we ended up in >> that situation. Does not change the fact that we got a route from a peer >> that we believed we could use, but turns out part of that announcement was >> a lie. >> > > Was not a lie, as I explained. > >> >> Consider that everyone filters received routes. The most common is to >> filter at the /24 level but nowhere is there a RFC stating that /24 is >> anything special. >> > > Oh that's a point I was quite annoyed with for years - who said one should > drop prefixes longer than /24 ??? And I searched for it, and indeed found > no RFC. But I did find it mentioned in some BCPs! > Unfortunately and stupidly, I didn't save these sources, but I did a quick > google now and found > > > https://nsrc.org/workshops/2018/linx103-bgp/networking/peering-ixp/en/presentations/05-BGP-BCP.pdf > > But that was years ago, and indeed, I also found mention in RFC 7454: > > >> 6.1.3 <https://www.rfc-editor.org/rfc/rfc7454.html#section-6.1.3>. Prefixes >> That Are Too Specific >> >> Most ISPs will not accept advertisements beyond a certain level of >> specificity (and in return, they do not announce prefixes they >> consider to be too specific). That acceptable specificity is decided >> for each peering between the two BGP peers. Some ISP communities >> have tried to document acceptable specificity. This document does >> not make any judgement on what the best approach is, it just notes >> that there are existing practices on the Internet and recommends that >> the reader refer to them. As an example, the RIPE community has >> documented that, at the time of writing of this document, IPv4 >> prefixes longer than /24 and IPv6 prefixes longer than /48 are >> generally neither announced nor accepted in the Internet [20 >> <https://www.rfc-editor.org/rfc/rfc7454.html#ref-20>] [21 >> <https://www.rfc-editor.org/rfc/rfc7454.html#ref-21>]. >> These values may change in the future. >> >> > I also did an experiment that seemed to confirm that most ISPs filter > announcements more specific than /24. > > 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. > > Theoretically, universal adoption of RPKI (incl ROV) could provide an > alternative solution to the disconnections, but will not protect against > explosion of the routing tables. > > >> So what if I was to filter at a different level, say /20 ? The same thing >> would happen, we would drop the "/24 exception route" and use the route >> that is a lie. >> > > Not a lie, but yes, this will lead to loss of connectivity; hence, it's > important to standardize this. > >> >> Regards, >> >> Baldur >> >>
