[RFC] Babel: add v4viav6 support

[Toke Høiland-Jørgensen]

Ondrej Zajicek <santiago at crfreenet.org> writes:

> On Tue, Dec 15, 2020 at 01:05:22PM +0100, Toke Høiland-Jørgensen wrote:
>> Andreas Rammhold <andreas at rammhold.de> writes:
>> 
>> >  * What if the kernel doesn't accept the RTA_VIA value we gave it?
>> >    Does BIRD generally handle this already?
>> >    One example is hitting: "ipv4: use IS_ENABLED instead of ifdef"
>> >    (id:20201115224509.2020651-1-flokli at flokli.de @ linux-netdev) Where
>> >    the kernel does support it but due to a bug fails to add those routes
>> >    when CONFIG_IPV6=m.
>> >    Kernel version comparison is probably a bad idea. Which kind of route
>> >    can we attempt to install to test this functionality without breaking
>> >    any setup?
>> 
>> Can't we just have Bird do the equivalent of:
>> 
>> ip r add 192.0.2.1/32 via inet6 ::2 dev lo onlink
>> ip r del 192.0.2.1/32 via inet6 ::2 dev lo onlink
>> 
>> on startup, and set a system flag depending on whether the operation
>> fails or not?
>
> Well, i would prefer to just add Babel protocol option to accept these
> extended next hops, make it disabled by default, and left it to the user.
>
> It is similar to ECMP, which may not be supported by kernel (if its
> support is disabled). We also had it disabled by default in BIRD 1.x, but
> changed the default in BIRD 2, as it is now widely supported.

Heh, well that's a nice way to sidestep the whole problem, I guess ;)

> We could perhaps implement later some generic mechanism later to detect
> global system properties during start, so they can be accessed during
> configuration processing to have different defaults based on system
> abilities.

Yeah, I think I was envisioning something like this. The v4-via-v6 thing
is nice in that it Just Works without any other system config as long as
the kernel supports it. So it would be neat to just turn it on by
default when supported and save the user some configuring.

> Note that even if Kernel supports this feature, there is no surety that
> such route is used for forwarding. For example, Kernel protocol may not
> be even configured, or export filter on it may filter out routes with
> such next hops.

Sure, users can always configure things in a way that doesn't work. But
at least they have to actively do something to achieve this, it won't
just be broken by default...

-Toke