[PATCH] Babel: add RFC9229 (v4 via v6) support

[Juliusz Chroboczek]

>> (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