[RFC] Babel: add v4viav6 support

[Toke Høiland-Jørgensen]

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?

-Toke