Andreas Rammhold <andreas@rammhold.de> writes:
On 13:05 15.12.20, Toke Høiland-Jørgensen wrote:
Andreas Rammhold <andreas@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@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