>> (There's also the PMTUD problem described in RFC 9229 Section 3.) > Juliusz, do you, or any one else, have info on: > How does ${vendor} behave when reverse path filters are enabled?
I was under the impression that some kinds of ICMP pakets are not subject to RPF. See RFC 4890 Section 4.3.1. I cannot find a similar recommendation for ICMPv4, though, so perhaps I'm wrong. > * Linux does just treat the whole 192.0.0.0/24 as "special" is is not > aware of the meaning of 192.0.0.8/32 That's new to me. Could you please describe how 192/24 is special? 192.0.0.8 requires special treatment, we need to cajole/bribe/bully Toke into helping. > However, it clashes as soon as you enable "strict" or even any RPF... > How do people treat this address in operational networks? Personal opinion here, please let me know if you think I'm wrong. Router-originated ICMP is inherently unreliable: just because there is a route from A to B that goes through C, there is no reason to assume that there is a route from C to A: A --------> C -------> B ^ . ......... That's why source quench (which relies on router-originated ICMP) has been replaced with ECN (which only does end-to-end). That's why ICMP-based PMTUd doesn't work. So in practice I'd expect people to use various hacks to work around the lack of PMTUd in the Real Interenet. Note that this problem is in no way specific to 192.0.0.8: strict RPF is almost as likely to break ICMP from a global address as it is to break ICMP from 192.168.0.8. -- Juliusz