[OPSEC] RFC7454 Sec. 6.1.5.2 IXP LAN Prefixes in the DFZ

[Tobias Fiebig <[e-mail]>]

Heho,
After debugging some pmtud issues with a route via an ix due to packets (datagram too big in this case) with ixp peering lan sources being dropped by the network of one of the participants in the connection [0], i stumbled over rfc7454/bcp194 sec. 6.1.5.2.

This recommends announcing peering lan prefixes into the dfz to make pmtud work, also suggesting that--to accomplish that--the ix should announce the peering lan with the rs themselves. Iirc, operational practice goes more into the direction of 'keep the peering lan out of the dfz, do not fill it into your igp', and most ixps even push for peering lans to be considered bogon (see, e.g.: [1]). The reasoning usually being that the chances of somebody 'holding it wrong' are just too high when a peering lan is in the dfz.

Would it maybe make sense to eratta rfc7454/bcp194 to note that most ixps prefer peering lans not being in the dfz, and operators should follow their ix'es prefrences re: filling it into their igp/announcing it to downstreams?

Similar, as i have been bitten by it, too, it might be a good idea to think about known ixp prefixes' relation to uRPF even if they are not in the dfz? Reasoning being here that pmtud will work with an unroutable source as long as the destination is routable. (There is a lot more considerations here, and it may also relate to other transfer links often using unannounced/unroutable addresses/rfc1918 etc.; This is more of an impulsive thought than a well though through idea for now.)

With best regards,
Tobias

[0] https://doing-stupid-things.as59645.net/networking/bgp/nsfp/2022/08/07/making-it-ping-part-6.html
[1] https://github.com/peeringdb/peeringdb/issues/352
--
Tobias Fiebig
M [e-mail]