[RFC] Babel: add v4viav6 support

[Andreas Rammhold]

On 17:51 15.12.20, Toke Høiland-Jørgensen wrote:
> Andreas Rammhold <andreas at rammhold.de> writes:
> 
> > On 13:05 15.12.20, Toke Høiland-Jørgensen wrote:
> >> Andreas Rammhold <andreas at rammhold.de> writes:
> >> 
> >> > This is a first attempt at implementing draft-ietf-babel-v4viav6-00 as
> >> > IPv4 via IPv6 extension to the Babel routing protocol that allows
> >> > announcing routes to an IPv4 prefix with an IPv6 next-hop, which makes it
> >> > possible for IPv4 traffic to flow through interfaces that have not been
> >> > assigned an IPv4 address.
> >> >
> >> > I've tried my best to be compliant with the current RFC version. One
> >> > point that is not entirely clear is how to implement in section 2.2.
> >> > regarding fallback when the device doesn't support v4-via-v6 routes.
> >> > (See notes below)
> >> >
> >> > The implementation is compatible with the current Babeld PR
> >> > (https://github.com/jech/babeld/pull/56). I've verified this with a few
> >> > VMs in the following setup:
> >> >
> >> > Bird <- v4 only -> Bird <- v6 only -> Babeld <- v4 only -> Babeld
> >> >
> >> > Each routing daemon was running on their own VM and had L2 connectivity
> >> > to only its direct neighbors. At the nodes at the edges v4 networks have
> >> > been announced and full end-to-end communication was possible over the
> >> > mixed AF network. The v6 only link between Babel and Bird (at the
> >> > "center" of the above setup) did transport the v4 packets via the v6
> >> > link-local next hop addresses just as expected.
> >> >
> >> > Thanks to Toke Høiland-Jørgensen for early review on this work.
> >> >
> >> > -----< notes >------
> >> >
> >> > (My current notes on the current implementation regarding
> >> > compliance with the current draft)
> >> >
> >> > Bird doesn't implement compression for outgoing (send) IPv4 prefixes and
> >> > thus this also hasn't been implemented for this AE. Best guess is that 4
> >> > bytes are cheap enough to not bother with the added complexity? In the
> >> > RX path compression is supported for IPv4 prefixes (for the IPv4 AE
> >> > as well as for IPv4-via-IPv6 AE).
> >> >
> >> > Especially the part last paragraph of 2.2. remains to be discussed/solved:
> >> >
> >> >  * If a node cannot install v4-over-v6 routes, eg., due to hardware or
> >> >    software limitations, then routes to an IPv4 prefix with an IPv6
> >> >    next-hop MUST NOT be selected, as described in Section 3.5.3 of
> >> >    [RFC6126bis].
> >> >
> >> >  * 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?
> >
> > That could work. I am not happy to use the documentation prefix for this
> > but I am also not aware of any other subnet that might be better suited
> > for this task. If someone is using the documentation prefix they will
> > probably not like this tho (but that is hardly our fault…).
> 
> Well, just used it as an example of something that was not likely to be
> in use; could be anything, really. Maybe you can even use 127.0.0.1/32
> on lo without any ill effects?

That sounds good and doesn't appear to have any noticeable side effects
while the route is installed. I'll have to see where in Bird such a
check could be added.